MiniCPM 4.0 發布了
依然是端側模型：原生稀疏，帶來更強的端側模型

https://github.com/OpenBMB/MiniCPM

作為開源產品，附帶了翔實的技術報告，共 43 頁

https://github.com/OpenBMB/MiniCPM/blob/main/report/MiniCPM_4_Technical_Report.pdf

下面，我帶大家快速量子速讀 一下

技術亮點 他們搞了套原生稀疏，讓模型本身就有了一些rag 的特性，打破很多端側的限制，更快、更強

不得不說，正如刻板印象：面壁搞端側，是專業的

無論是 0.5b 還是 8b 這個端側領域，MiniCPM 幾乎是都是最快、成本最低的

速度

以 Jetson AGX Orin 和 RTX 4090 兩款典型端側芯片為例，MiniCPM4 的速度，大幅領先同類模型

顯存極限場景下，推理速度最多快 220 倍

如圖表所示 性能

以最適合放在移動設備里的 MiniCPM-0.5B 為例，盡管其訓練數據只有 Qwen3-0.6B 的 3%，但各類評分卻大幅超越：

MMLU：55.55（Qwen 是 42.95）
CEval：66.11（Qwen 是 45.53）
HumanEval：46.34（Qwen 是 40.85）

兩款模型，在同體量模型中，均非常耐打 長文本

MiniCPM4 基于 32K 長文本進行預訓練，并通過 YaRN 技術實現長度擴展，能夠支持 128K 長文本

作為端側模型，在 128K 大海撈針下全綠

而剛剛提到的43頁技術報告，我看了一遍，覺得可以拆成以下：

InfLLM v2：Attention 層只看重點
FR-Spec：草稿階段不全寫
BitCPM4：訓練時就考慮壓縮
CPM.cu + ArkInfer：定制推理 & 部署系統
風洞 2.0：小模型先試，大模型再訓

https://github.com/OpenBMB/MiniCPM/blob/main/report/MiniCPM_4_Technical_Report.pdf

下面容我一一拆解

InfLLM v2：自我 Rag

這次 MiniCPM 的主力架構，InfLLM v2 的東西，全稱是“可訓練稀疏注意力機制”

大致就是：在 Attention 里做了 RAG

傳統的大模型，每一個詞（token）都要和上下文中所有其他詞去交互一遍，來判斷“誰重要誰不重要”。這種方式雖然準確，但計算量非常大——輸入越長，算得越慢，顯存也越容易爆掉。

在下面的演示中，你可以點擊【陽光】【花香】【人們】【微風】【感嘆】或者【今天】，來看看大模型都關注到了什么。

InfLLM v2 做了些改變：讓模型像人一樣，只看“相關部分”

分兩步：
第一步：把上下文切成一個個“語義塊”——比如一段話、一個段落，作為候選記憶單元
第二步：讓每個新輸入的 token 自己挑選，它最需要參考的那幾個語義塊，然后只和它們交互

InfLLM 原理圖示

這套機制的效果非常實在：在長文本任務中，把 attention 的計算量從「一整個上下文」壓縮成「不到 5% 的上下文塊」。

更妙的是，MiniCPM4 有自動切換模式
短文本時：繼續用傳統稠密
長文本時：自動啟用稀疏機制

FR-Spec：更快的草稿

生成式模型推理慢，很多時候不是因為模型太大，而是因為每一步都太復雜。

尤其是在每次生成一個詞時，模型都要在幾萬個候選詞里挑一個出來——就像你每寫一個字，都要在整本字典里找一圈。這是語言模型最花時間的一步。

于是人們想了一個加速策略：草稿模型 + 驗證模型。

先用一個小模型“快速寫個草稿”，然后大模型來看草稿寫得靠不靠譜。如果靠得住，就直接用，省得大模型每次都從頭干一遍。

這個機制叫做“投機采樣”（Speculative Decoding），原理上很好用，但它也有自己的問題：

草稿模型本身，也要用整個詞表去算 softmax，它自己也很累，沒真正省多少。

MiniCPM4 的改進就是這里：草稿模型少管點事，只寫常規句子就行

這就是 FR-Spec（Frequency-Ranked Speculation）的核心。

具體做法是：

• ? 構造一個 高頻詞表 ，也就是平時出現最多的那幾千個詞；

• ? 草稿模型只在這些詞里選， softmax 的時候不需要考慮全詞表 ；

• ? 大模型依舊保留全詞表，負責細節和修正，保障質量。

這種“草稿不全寫，大模型兜底”的結構帶來兩個直接好處：

1. 1. 草稿模型跑得快， 軟硬件負擔更輕 ；

2. 2. 整個草稿 + 驗證鏈條穩定， 最終輸出沒變差 。

尤其是在端側設備，比如手機、筆記本、嵌入式芯片等，這種優化帶來的速度提升非常關鍵。

這么來記 原本：是兩個模型各自跑一套 FR-Spec：草稿模型弄一小半，剩下的由大模型快速補全 流程短了，速度自然快了

大模型所以叫大模型，首先是：大

這個大，也體現在了本身的體積上：又大又重，占顯存，占帶寬，跑得慢

為了讓模型運行的更快，人們會將原本的浮點計數，壓縮成整數，這一過程叫做量化

常見的壓法是 INT8、INT4——
也就是說，每個參數只用 8 bit、4 bit 來存。越小越快，但越小也越難保留原來的信息

MiniCPM 這次直接上了三值
參數只用三種值表示：-1、0、+1
平均下來是 1.58bit，已經接近量化的極限

各類模型的量化信息

通常情況下，壓縮到這么狠，模型會崩，而 MiniCPM 的做法，是把量化這個過程提前塞進訓練里

以前是：先訓完，再量化（PTQ，Post-Training Quantization）

這里是：奔著量化去訓練（QAT，Quantization-Aware Training）
在訓練時，就告訴模型：
你之后只能選三種值，自己想辦法適應吧

具體是兩步：
第一步：先訓一個正常精度的模型，比如 FP8
第二步：接著在三值限制下繼續訓練，讓它自己適應壓縮精度

訓練過程不復雜，用的 token 數只比正常 decay 多兩倍左右

結果：模型壓縮了 90%，但評測表現沒明顯掉
不是因為三值更強，而是訓練方式更適配

量化沒有優劣，只有取舍
在算力有限的前提下，這種極致壓縮，是非常實用的選擇

CPM.cu 和 ArkInfer

模型訓練得再好，最后都要落到一件事上：能不能跑起來，跑得快不快

之前我有一篇暴論，特別提到：
面壁和硅基流動，在模型部署上，有非常獨特的積累

話說回來，很多模型會直接用 vLLM、transformers 這種通用推理框架。
它們確實方便，但不夠輕，也不夠快，尤其在端側設備上，資源吃緊。

MiniCPM 自己寫了推理引擎，叫 CPM.cu，來支持自家的模型，比如剛才提到的 InfLLM 和 FR-Spec：從 memory 分配到 kernel 調用，全都圍繞自己模型結構打通。

而在「跑得快」之外，還有一個問題：能不能部署得開？

不同平臺，不同芯片，不同后端，部署流程一換就出 bug。

MiniCPM 在這塊配了 ArkInfer，用來做部署適配，作為跨平臺調度系統，做了三件事：
1. 統一模型調用方式：無論底層是 llama.cpp 還是 TensorRT，接口都長一樣
2. 封裝硬件差異：支持 NVIDIA、Intel、高通、MTK、昇騰等多種芯片
3. 一次訓練，多端部署：寫一套模型，不用每個平臺各改一版

這樣，模型從訓練出來，到部署上線，流程少了、接口穩了、速度快了

風洞 2.0：讓小模型先探路

訓練任何模型，都是很燒錢的

光是一個學習率、一套 batch size，試錯一次就是幾十萬 token，幾百張卡。
堆資源可以解決問題，但也太貴了

MiniCPM 的思路是：先用小模型，把風向試出來

這套系統叫做「風洞 2.0」，做的事很簡單：

• ? 先用 0.01B～0.5B 的小模型訓練幾十輪，觀察 loss 和性能

• ? 把這些數據拿去預測大模型應該怎么訓，用什么配置最穩

換句話說：

在重金投入之前，先模擬器跑幾圈再說

它用的評估標準叫 ScalingBench，能量化地預測性能曲線走勢，效果比人工調參準得多，token 花得也少

除此之外，MiniCPM 在訓練本身也做了兩件優化：

精度用 FP8：比 FP16 還低，能省顯存，能省傳輸
目標用多 token 預測：一次訓多個詞，訓練信號密度高，收斂更快

整套下來，MiniCPM4-0.5B 的訓練 token 用量只有 1T，但性能能打到 Qwen3（36T）那個水平

收束以上

MiniCPM4 是一個系統層面的優化閉環：

• ? Attention 稀疏，少算點

• ? 草稿機制，快跑點

• ? 參數量化，瘦一點

• ? 推理定制，貼合點

• ? 訓練搜索，準一點

• ? 部署調度，順一點

每一層，都做了迭代

最終堆出一個結果：在端側，128K 長文本，能穩定、快速、成本低地跑起來

這事兒，莫名讓我想到了 DeepSeek：訓練優化、推理優化、數據優化...一直不斷迭代。

模型行業的戰局，似乎正是被這一個個架構上的創新與微創新，所塑造

另外的，call back 下曾經寫的一份內容，并恭喜：