Liquid AI LFM2.5-8B-A1B：38 兆 token 訓練的開放權重 MoE，128K 上下文、1B 激活參數
Liquid AI · 2026-05-29
Liquid AI 釋出 LFM2.5-8B-A1B，一個 8B 總參數、1B 激活參數的 Mixture-of-Experts（MoE）推理模型，訓練語料達 38 兆 token（前代 LFM2 為 12T），上下文窗口 128K token，以開放權重釋出。模型在多項 agentic 和指令遵循基準上超越規模更大的競爭模型。
架構設計
LFM2.5 結合 MoE、GQA（Grouped Query Attention）和門控短卷積區塊（gated short convolution blocks）。詞彙表從 65K BPE 擴展至 128K，主要改善非拉丁語系（日、韓、阿拉伯語）的 tokenization 效率。這是純推理模型，輸出包含顯式思維鏈（chain of thought）。
上下文擴展訓練策略
128K 上下文分兩階段達成：
- 基礎預訓練後以 2T token 中期訓練（midtraining）擴展至 32K
- 再以 400B token 擴展至 128K
- 偏好優化：Avg@k 獎勵機制降低幻覺，針對推理迴路（doom loop）的 RL 防止無限思維循環
效能基準
| 基準 | LFM2.5-8B-A1B |
|---|---|
| IFEval（指令遵循） | 91.84 |
| MATH500 | 88.76 |
| AIME25 | 42.53 |
| BFCLv3（agentic） | 64.36 |
| Tau² Telecom | 88.07 |
在 agentic 任務上超越所有測試模型。CPU 推理：Apple M5 Max 達 253 tokens/sec，記憶體 <6 GB；H100 高並發下每日吞吐 16 億+ token。支援 HuggingFace、llama.cpp、MLX、vLLM、SGLang、ONNX。
原始來源：Liquid AI — LFM2.5
MONET：1.049 億張開放圖像資料集，讓 4B 參數擴散模型超越 DALL-E 3（12B）
Jasper AI / HuggingFace · 2026-05-29
Jasper AI 釋出 MONET（Massive, Open, Non-redundant and Enriched Text-to-image Dataset）：1.049 億張 Apache 2.0 授權的圖像，每張配備 5 份文字描述（1 份原始 web caption + 4 份不同 VLM 生成的 AI 描述）。基於此資料集訓練的 4B 參數擴散模型在 GenEval（0.74）和 DPG（85.56）上超越 DALL-E 3 與 FLUX.1 Dev，兩者均為 12B 參數的專有資料模型。
資料集篩選流程
從 29 億個 Common Crawl 來源 URL 開始，四個篩選階段：
- 美學預篩：最小 512×512 像素，美學分數 5.0+
- 安全過濾：三個 NSFW 分類器集成投票
- 去重：感知雜湊（perceptual hashing）+ SSCD embedding 副本檢測
- 域名過濾：移除庫存圖片和水印來源
合成資料比例定在 13%：作者以 FID 實驗系統化驗證了合成/真實資料的最優混合比，避免「AI 吃 AI」退化問題。
nano-t2i 最小化訓練框架
配套的 nano-t2i 是單 GPU 可執行的訓練代碼庫，單張 H200 約 1 天可訓練出競爭力的 4B 模型（8× H200 約 3 小時）。這讓缺乏大型計算資源的研究者也能從頭驗證圖像生成假設。arXiv 論文：arXiv:2605.21272。
torch.profiler 實戰指南 Part 1：讀懂 CPU/GPU 追蹤、診斷 overhead-bound 瓶頸
HuggingFace · 2026-05-29
HuggingFace 發布 torch.profiler 系列教程第一篇，以矩陣乘法（64×64 和 4096×4096 兩種規模）為例，從建立 profiler 到讀懂 Perfetto UI 追蹤圖，系統介紹 CPU/GPU 雙通道分析方法，在 NVIDIA A100-SXM4-80GB 上驗證。
基本設置
with torch.profiler.profile(
activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
schedule=torch.profiler.schedule(wait=1, warmup=1, active=3),
) as prof:
for step in range(5):
model_step(); prof.step()
prof.export_chrome_trace("trace.json")核心診斷模式
- Overhead-bound：Self CPU time 為 ms、Self CUDA time 為 µs → CPU dispatch 時間遠大於 GPU 計算，需增大 batch size 或融合操作
- Compute-bound：Self CPU ≈ Self CUDA（均為 ms）→ GPU 是瓶頸
cudaOccupancyMaxActiveBlocksPerMultiprocessor出現在 CPU lane = 準備 heavyweight kernel（如 cuBLAS GEMM）- 第一個 ProfileStep 異常寬 = cold-start（workspace 分配、cuBLAS heuristics、lazy module loading）
torch.compile 的追蹤特徵
torch.add(torch.matmul(x, w), b) 在 compile 後合併為 aten::addmm，operator fusion 在 dispatcher 層發生，而非 kernel 層。GPU kernel 不變，bias 加法透過 Device-to-Device memcpy 折入 GEMM epilogue。CPU overhead 因 Dynamo cache lookup 和 AOTAutograd 增加約 2×，需多個操作才能攤銷。
系列後續預計覆蓋 nn.Linear、小型 MLP，以及 LLM Transformer profiling。