[Benchmark] LFM2.5 24B-A2B 一張 2080 Ti 吐字 184.8 tok/s：全場最快，取樣參數一定要照官方

前言

#25 我在找一顆一張卡就能接手家裡兩張卡 27B 的模型。同一個晚上，Liquid AI 剛發了 LFM2.5 24B-A2B，也是每個字只算約 2B 的 MoE，我用同一套題目一起測。

它不是一般的 Transformer。40 層裡只有 10 層是 attention，其他 30 層是卷積。attention 層少，要存的 KV cache(模型記住前文用的暫存)就小，每個字要讀的權重又少，所以快。

簡單講：它是這輪最快的，一張卡吐字 184.8 tok/s，140 題跟 27B 一樣。但它關不掉思考，temperature 0 會一直想下去，agent 修 bug 只過 1/5，又不會看圖，所以家裡那一席最後選了 MiniCPM。下面是怎麼跑、量到的數字，還有取樣參數為什麼一定要照官方。--kv-unified 讓我誤判 12 題的那個坑，收在後面的進階區。

一張卡吐字 184.8 tok/s，131k context 只用 17.4G

官方說法是 24B 總參數、每個字啟用 2.45B，每層 64 個專家挑 4 個，context 上限 131,072。

同一台機器，三種跑法。tok/s 是每秒吐出幾個 token，一個 token 大約一個中文字；QAD Q4_0、Q4_K_M、Q8_0 是量化格式，把權重壓小的程度，數字越小檔案越小。看「吐字」那列：

	單卡 QAD Q4_0 13.6G	單卡 Q4_K_M 14.5G	雙卡 Q8_0
讀 prompt：512 / 8K / 32K(tok/s)	3243 / 3286 / 2881	2864 / 2959 / 2631	3086 / 4930 / 4659
吐字(tok/s)	184.8	180.0	135.0
吐字 @32K 深度(tok/s)	沒量	148.4	113.6
開滿 131,072 context	沒量	17.4G	每張 14.2G

QAD 是官方用量化感知蒸餾做的 Q4_0：比 Q4_K_M 小 0.9G，吐字還快一點。單卡吐字比雙卡快，原因跟 #25 一樣，權重小、每個字讀得少；雙卡強在讀長 prompt，8K 以上快約 1.5–1.7 倍。

12 萬 token 的撈針測試：單卡 52 秒(每秒 2,319 token)、雙卡 28 秒(4,256)，都答對。#25 的 MiniCPM 單卡讀 16.5 萬 token 要 154 秒，LFM 讀長文快很多。

這些速度是當晚的組態量的：llama.cpp b11588，另一張卡同時在跑別的測試。

140 題 128，跟原本兩張卡的 27B 一樣

同一套 140 題：GSM8K 50、MATH-500 30、MuSR 20、HumanEval+ 40。

	雙卡 Q8_0、官方取樣	單卡 QAD Q4_0、Qwen 取樣
GSM8K	49/50	47/50
MATH-500	29/30	28/30
MuSR	15/20	14/20
HumanEval+	35/40	36/40
合計	128/140	125/140
跑完要	3,169 秒	1,344 秒

原本家裡兩張卡的 27B 是 128。兩欄的量化和取樣都不同，所以 125 和 128 差的 3 題，分不出是量化還是取樣造成的。

這套題目我平常是關思考跑的，LFM 關不掉，所以它每題都先想。雙卡那輪跑了 3,169 秒，#25 的 MiniCPM 關思考是 576 秒。

難題組：指令比較強、程式比較弱，數學有幾題是想太久被截掉

難題組開思考。單卡 QAD 用 temperature 0，雙卡 Q8_0 用官方取樣。看最後一欄：

	單卡 QAD、temp 0	雙卡 Q8_0、官方取樣	原本的 27B
數學 AIME	23/30(7 題截斷)	23/30(6 題截斷)	21/30
推理 GPQA	21/30	23/30	25/30
指令 IFEval	27/30	29/30	27/30
程式 LiveCodeBench	9/20(7 題截斷)	11/20(6 題截斷)	14/20

「截斷」是思考寫到 32K token 的上限還沒結束，沒交出答案，算錯。

下面兩項 LFM 輸最多：

• agent 修 bug(Pi 在真的 repo 裡修 bug，Docker 裡的隱藏測試判分，單卡 QAD)：1/5。工具呼叫格式都對，另外 4 題在 20 輪內修不好。#25 的 MiniCPM 是 5/5。
• 長文三跳查找(11.6 萬 token 的文件裡連查三次)：0/10。這項我把回答額度放到 8,192 token(其他模型 2,048)，因為 2,048 的時候它第一題光是思考就用完了，回空字串。

取樣參數不是裝飾：temperature 0 會一直想下去

取樣參數決定模型每一步怎麼挑下一個字。temperature 0 是每次都挑機率最高的那個，結果固定；調高一點，就會偶爾挑別的。

我的測試平常用 temperature 0，讓結果可以重現。LFM 用 temperature 0 的時候，有些題目會一直想下去。

推理題的思考長度中位數是 1,771 token，正常；但有一題寫到 2.8 萬 token。單卡那輪，數學和程式各有 7 題撞到 32K 上限。

模型卡寫了建議的取樣：temperature 0.1、top_k 50、repetition_penalty 1.05。雙卡那輪改用這組，推理從 21 變 23、指令 27 變 29、程式 9 變 11，截斷從 7 題變 6 題。量化也不一樣(Q4_0 對 Q8_0)，所以這些差距不能全算在取樣上，但截斷還在，代表就算照官方，碰到難題它還是可能想很久。

要用它，請求裡直接帶這三個參數：

curl -s localhost:8080/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "messages": [{"role": "user", "content": "17 × 23 等於多少？"}],
  "temperature": 0.1, "top_k": 50, "repeat_penalty": 1.05,
  "max_tokens": 8192
}'

max_tokens 要給夠。它一定會先想，連 17×23 這種題目都會先想一段；額度太小，答案還沒出來就被截掉。請求裡帶 "chat_template_kwargs": {"enable_thinking": false} 沒有效果，模型卡也寫它是一定會先想的推理模型。

怎麼跑：下 QAD Q4_0，一張卡開 131k

這節是給要自己架起來的人，指令可以直接複製；不架的話可以跳過。

你需要一張改裝 2080 Ti 22G，和夠新的 llama.cpp(我用的是 b11588，自己編 sm_75，編法跟 #25 一樣)。

mkdir -p ~/models/lfm25 && cd ~/models/lfm25
curl -L -C - --retry 5 -o LFM2.5-24B-A2B-QAD-Q4_0.gguf \
  https://huggingface.co/LiquidAI/LFM2.5-24B-A2B-GGUF/resolve/main/LFM2.5-24B-A2B-QAD-Q4_0.gguf

啟動：

./build/bin/llama-server \
  -m ~/models/lfm25/LFM2.5-24B-A2B-QAD-Q4_0.gguf \
  -ngl 99 -fa on -t 24 --jinja \
  -c 131072 -np 1 \
  --temp 0.1 --top-k 50 --repeat-penalty 1.05 \
  --host 0.0.0.0 --port 8080

• --temp / --top-k / --repeat-penalty 是 server 的預設值，請求裡沒帶就用這組。
• 要讓好幾個人同時用，-np 調大的同時 -c 也要跟著放大，原因在進階區。
• 投機解碼沒得開：它沒有 MTP，也沒有官方的草稿模型。n-gram 投機我試了，只快 2–5%。

為什麼家裡那一席沒選它

同一個晚上兩顆都測完，LFM 吐字快 1.6 倍以上(184.8 對 111.5)，140 題也一樣好。我還是選了 MiniCPM：

• 它不會看圖。 LFM 是純文字模型，MiniCPM 會看圖。
• 關不掉思考。 短問題也要先想一段，想的時間會吃掉一部分吐字快的好處。
• agent 1/5。 那一席也接派工的 agent 工作，MiniCPM 是 5/5。

測完之後我把 LFM 的三份權重(53.6GB)從機器上刪了，測試結果留著。

---

進階：--kv-unified 誤判 12 題、長文要單獨跑、量測方法

不讀這節不影響使用。這裡是開多人同時用時踩到的 KV 坑、長文題為什麼要單獨跑、取樣不公平的修正，以及量法和環境，寫給想追細節的人和 AI。

--kv-unified 時，-c 是大家共用的總量

跑雙卡那幾輪的時候，我開 8 個位置(-np 8)、-c 131072、--kv-unified，以為是每條最多 131,072。結果有 12 題回 HTTP 500，被 runner 記成 error。

原因是 --kv-unified 之下，-c 是 8 個位置共用的 KV 總量。LFM 每條長思考會用掉 3 萬多 token，四條同時在想就快把 131,072 用完，再進來的就塞不下。

改成 -c 393216 之後，server 的 log 是這樣：

llama_context: n_ctx_seq (393216) > n_ctx_train (131072) -- possible training context overflow
srv    load_model: initializing, n_slots = 8, n_ctx_slot = 131072, kv_unified = 'true'

每條還是最多 131,072(不會超過訓練長度)，總量變 393,216。LFM 只有 10 層 attention，每個 token 的 KV 約 20KB，開大很便宜，兩張卡一樣放得下。那 12 題改完重跑，才是表上的分數。

長文題要單獨跑

11.6 萬 token 的長文題，跟難題同時丟進 8 個位置共用的 131k KV，一條長文就占掉大半，其他請求跟著擠爆回 500。長文組我後來改成單獨跑，不跟其他題目同時。

Qwen 的取樣對 LFM 不公平

140 題的 runner 預設用 Qwen 建議的取樣。單卡那輪沒改，所以 125 是在 Qwen 取樣下量的；雙卡那輪我改成 LFM 官方取樣，才是 128。

量測方法

速度：llama-bench，-ngl 99 -fa 1 -t 24，prompt 512、8192、32768，吐字 128 token；@32K 那欄加 -d 32768。

context 與撈針：llama-server -c 131072 載入，讀 nvidia-smi；撈針用約 12 萬 token 的隨機英文單字，中間埋一句密碼，問它密碼是什麼。

140 題：雙卡 Q8_0 用官方取樣，單卡 QAD Q4_0 用 Qwen 取樣；HumanEval+ 用 evalplus 判分。

難題組：開思考，每題上限 32K token。單卡 QAD temperature 0；雙卡 Q8_0 官方取樣(temperature 0.1、top_k 50、repeat_penalty 1.05)。

agent：單卡 QAD，Pi 在真的 repo 裡修 bug，最多 20 輪，Docker 裡跑隱藏測試判分。

長文三跳：11.6 萬 token，回答額度 8,192 token，單獨跑。

幾件要知道的：

• 每項只跑一次，沒有重複抽樣的信賴區間。
• 原本 27B 的分數是之前在別的日期量的，條件不完全一樣。
• 量速度那晚，另一張卡同時在跑別的測試。

版本與環境

• llama.cpp：b11588，自編 sm_75
• 模型：LiquidAI/LFM2.5-24B-A2B-GGUF 的 QAD-Q4_0、Q4_K_M(單卡)、Q8_0(雙卡)
• 機器：EPYC，128GB RAM，三張 RTX 2080 Ti 22G；單卡在第三張，雙卡用前兩張(那段時間 27B 先停掉)

還沒做的

• 單卡 QAD 用官方取樣重跑 140 題和難題組。
• 截斷的題目把上限放到 64K 再跑一次，看是想太久還是真的鬼打牆。
• 中文生成速度沒有另外量。

---

同系列：#25 一張 2080 Ti 接手兩張卡的 27B：MiniCPM-V 4.7 35B · #24 44GB VRAM 跑 177B：兩張 2080 Ti 用 Strata 單人寫程式 98.7 tok/s · #22 2080 Ti 沒有 FP4 也能跑 NVFP4：自己轉 Qwen3.8-27B