觀察後訓練模型並加碼實測新星

昨天處理 Perplexity 最新推的 Portable Computer 時有提到了二個小問題。第一，它的本地模型用的是注意力 FP8 加 MLP NVFP4 的混合精度配方，正好落在 Day 12 文章中量化階梯已經測過的兩級之間，我承諾把它接進同一條階梯、用同一份語料比一次。第二，Perplexity 地端 Agent 選單上那款「Qwen 3.8 27B」實際是 pplx-computer 家族的後訓練權重，那麼一顆為了跑 agent 而後訓練過的 27B 模型，跟 Hugging Face 上的原版比起來，到底換到了什麼呢 ?

不但如此，也順便把這款 2026 年地端甜蜜點模型該做的完整測試做完，包括速度、量化品質、長上下文、繁中與工具呼叫能力。

今天的主角 Qwen3.8-27B，採用 Apache 2.0 授權，原生 256K 上下文，帶視覺的多模態能力。昨天翻檔案還看到它架構上最聰明的地方是 64 層裡有 48 層是線性注意力、16 層完整注意力，每 4 層插一次，四分之三的層不隨上下文長度累積 KV，這才是 27B 級模型敢開 256K 長窗的原因，這件事在本文第四節會變成實測資料。

今天社群熱門的 Qwen3.8-Flash-Next ，剛好在文章發表前也出了，所以就加減一起加碼測試囉。

第一節：部署有三種路線

路線一，vLLM 跑官方 FP8（服務與 agent 場景）、路線二，llama.cpp 跑 GGUF 階梯（單人與品質對照），這兩個路線在 Day 8 與 Day 12 已經走過，可以直接沿用測試配方。

路線三則是今天的重頭戲，把 Perplexity 的權重從它的封閉容器裡請出來，讓 GB10 本機上另外部署的vLLM 來跑看看。

昨天找到了它的模型落點，是標準的 Hugging Face 快取結構，Perplexity 選擇將這個目錄唯讀掛給自己的容器用：

docker run --gpus all --ipc=host \
  -v ~/.local/share/perplexity-rpc-server/local-models/\
models--perplexity-ai--pplx-computer-qwen-3-8-27b-dflash2-20260824/snapshots/f1cb0e1c/:/models/m:ro \
  vllm/vllm-openai:nightly-aarch64 --model /models/m --served-model-name pplx-mixed

儘管如此還是可以請出來用，而且用的是我自己那款比它舊一個小版本的映像。 Perplexity 出貨的是 vLLM 0.27.2rc1.dev193，我手上是 0.26.1rc1.dev1102，同樣能辨識出 Perplexity 後訓練版本的 Qwen3.8-27B，也認得出它的量化：

Resolved architecture: Qwen3_5ForConditionalGeneration
Detected ModelOpt fp8 checkpoint (quant_algo=FP8)
Detected ModelOpt NVFP4 checkpoint (quant_algo=NVFP4)
Detected ModelOpt NVFP4 checkpoint (quant_algo=W4A16_NVFP4)
Detected ModelOpt MXFP8 checkpoint
Loading weights took 151.17 seconds
Model loading took 21.66 GiB memory

上面四行的 Detected，實際上是四種格式混在同一個檢查點裡，還有 W4A16_NVFP4 與 MXFP8。

這條路打通之後，第三節與第五節就更有意義，它跟其他模型都在同樣的量測環境，同一個引擎、同一份語料、同一把量尺，剛好可以做出三者的對比。

第二節：速度，密集模型的物理現實

前兩週本系列文章採用的量尺 gpt-oss-120b 是 MoE，每個 token 只啟用約 5B 參數，Qwen3.8-27B 則是密集模型，每個 token 全部一起上。DGX Spark 的統一記憶體頻寬是 273 GB/s，如果用 Day 8 的天花板公式，預測和實際的比較會是如何呢? 答案如下:

BF16 的理論上限不到 5 t/s
比閱讀速度還慢。這就是密集 27B 在頻寬受限機器上的物理現實，它解釋了為什麼 Day 12 說 8 位元是這台機器的日常甜蜜點，也解釋了為什麼 MoE 會成為 2026 年 AI 模型開放權重的主流。

但真正的重點在下面這一列。

昨天在 Perplexity 自己的容器裡，同一顆模型實測到 24.98 t/s。今天在我自己的容器裡、沒開投機解碼，同一顆模型是 10.66 t/s。真相只有一個，因為人家它出貨就自帶 DFlash2 投機模型，一次猜 7 個 token。

24.98 ÷ 10.66 = 2.34 倍
要用純頻寬跑到 24.98 t/s，需要 581 GB/s
而這台機器只有 273 GB/s，也就是產生實體頻寬的 2.1 倍輸出成機的效果

投機解碼不是把記憶體變快，是讓你不必每個 token 都讀一遍全部權重。

「模型大小」與「跑起來多快」是兩回事，中間隔著啟用參數量與投機解碼這兩層。在 prefill 這一側，pplx 混合在 vLLM 上 pp2048 是 2,251 t/s、pp8192 是 2,336 t/s。對照它 10.66 的 decode，prefill 快了兩百倍。這款密集模型的 prefill 相對它的 decode 能力，這樣做實在是太划算了哪。長輸入短輸出的工作最適合它，反過來要它處理長篇的內容就不適合。

第三節：量化階梯的同尺規對決

這節是昨天承諾的正題。Day 12 的階梯加入三個新選手，並採用同一份英文與繁中語料。方法上有一道必須先過的關，llama.cpp 載不進 safetensors，所以 pplx 這一列只能用 vLLM 算 PPL。我把計分窗對齊 llama.cpp 的做法（每段 512 token 只計後半，也就是每個被計分的 token 至少有 256 token 的上下文），實測分段數兩邊完全一致（英文 580、繁中 147），代表 tokenizer 是同一套。

跨引擎校準
vLLM 的 FP8 原版對 llama.cpp 的 BF16 只差 +0.26% / +0.45%，而 llama.cpp 自己的 q8_0 對 BF16 是 +0.06% / +0.03%。同一個等級，姑且兩個引擎的數字可以並排一起比較。

幾個重點如下。

第一，混合精度的設計假說成立。

「注意力對量化敏感所以保 8 位元，MLP 耐操所以壓 4 位元」這個說法，在資料上是有來由的。pplx 混合模型以更小的體積（23.26 vs 25.96 GB）拿到比純 NVFP4 明顯更好的 PPL，且英文和繁中兩種語言都是。不但如此，要知道 pplx 是後訓練過的權重，後訓練通常會讓通用語料的 PPL 變差，也就是說這個配方的優勢在這裡是被低估的。

**第二，一個沒預期到的結果，llama.cpp 的 imatrix k-quant 打贏了 NVIDIA 的 NVFP4。

** 17.77 GB 的 q4_k_m 劣化 +0.50% / +0.84%，25.96 GB 的 NVFP4 原版劣化 +4.64% / +9.25%。比它大 8 GB 的模型，品質卻差了五到十倍。 這不是說 NVFP4 沒價值，它畢竟是為了 Blackwell 的 FP4 張量核心設計的，換的是速度不是品質，但如果你的取捨是同樣容量下要最好的品質，imatrix 校準的 k-quant 目前還是 GB10 這台機器上的最佳解。

第三，繁中的劣化一律大於英文，倍率 1.6 到 2.0 倍。

這重現並推廣了 Day 12 文章中的發現，當時這情況有在 llama.cpp 的 k-quant 家族看到，今天在跨越兩個引擎、兩個量化家族（k-quant 與 ModelOpt）的情況下依然成立。imatrix 與 modelopt 的校準語料都以英文為主，因此，英文幾乎無損，不代表繁中也是這樣無損，是有差的。

第四節：256K 上下文與線性注意力的紅利

我們來觀察 KV ，用自己的 vLLM 啟動日誌驗證：

head_dim 是 256 ，不是常見的 128。所以每 token 的理論成本是

16 層完整注意力 × 2（K 與 V）× 4 個 KV head × 256 dim × 1 byte（FP8 KV）= 32 KB

實測 34.5 KB，差額是線性注意力層的固定狀態與 vLLM 的層對齊 padding。關鍵是那個 16 層完整注意力的設計，倘若它設計成 64 層全是完整注意力，每 token 就得花上 128 KB，是現在的四倍耗用。而它的設計讓 128K 上下文現在只吃 4.31 GiB，全注意力的話會是 17 GiB。這就是昨天在 Portable Computer 看到 48 GB KV cache 卻還能開 256K 的原因。

效能面，來看同一份長文裁四檔：

decode 從 8K 到 121K 只掉 15%。 這正是線性注意力的紅利，有四分之三比例的層不隨上下文長度增加成本。反觀 prefill 掉了 36%，那是 16 層完整注意力二次方成本的影響。

品質面，在 121,472 token 的文件裡，開頭、中段、尾端做埋針測試：

三比三全中。 線性注意力的理論疑慮是長距離資訊保持力，這個埋針簡測沒有戳出問題，畢竟單針測試是最寬鬆的一種長上下文評估，相關繁體中文的測試要測那些，本文末的附錄有連結可參考。

第五節：後訓練的 27B 換到了什麼

最後回答昨天的問題。原版 Qwen3.8-27B（FP8）對上 pplx 後訓練版，同一個 vLLM、同一組取樣參數、同一份測試，結果是如何呢?

更正（2026/08/28）：繁中十題兩欄原記為 19 / 20，後來發現掉的那一分來自我判分腳本的關鍵字判斷式寫錯（把「任一命中」寫成「必須同時命中」），模型其實都答對了，修正後兩欄皆為滿分。判分腳本比模型更需要被檢查。

正確率完全打平。（decode 那一列的差距來自量化配方不是後訓練，混合精度比 FP8 小了六 GB。）

這次測試的題目相對簡單，沒辦法明顯區分兩者的差別，但這件事情本身跟 Perplexity 自己公布的數字方向一致，在他們 53 題的內部基準上，後訓練只值 2.8 分，而換一套 harness 則值 8.6 分。

當天我另外量到一個看起來很具體的差異。同一個提示詞，明確要求「只輸出一個 JSON 物件，不要有任何其他文字」，後訓練版十次全部吐緊湊單行（0 / 10），原版有七次自作主張加了換行與縮排（7 / 10），我當時把這個差距歸給「為 agent 後訓練買到的格式紀律」。

更正（2026/08/28）：這個結論被我自己在 Day 15 推翻了。當時這一題沒有記錄取樣設定，Day 15 以固定取樣（temp 0.7 / top_p 0.80）重測 50 輪，兩個 27B 都是 0 / 50 全緊湊，原版那個 7 / 10 在任何設定下都無法重現（思考模式開關、取樣拉滿都試過，最多 1 / 10）。「後訓練買到格式紀律」的證據不成立，緊湊輸出是 27B 這一家的基底，與後訓練無關。另外十輪的樣本量對這一題也不夠，實測同設定每十輪的比數散布可以差到 5，Day 15 起此項改為 50 輪並記錄全距。當初的錯誤結論保留在上一段供對照，由於測試腳本比模型更需要被檢查，以及沒有記錄取樣設定的比數，等於沒有測試到。完整重測數據見 Day 15 與考卷 repo 的 results。

後訓練值不值得做，正確率與格式紀律兩條證據都撐不起來之後，目前手上唯一站得住的差異只剩它出廠配好的 DFlash2 草稿模型（Day 13 實測 24.98 t/s 對 10.66 t/s 的加速），以及 Perplexity 內部基準那 2.8 分。這題留給後面的篇章繼續驗。

順帶一提，跑這一節時發現一件事，這款模型思考時用簡體中文，最終答案才切回繁體。做繁中評測時如果沒關掉思考模式、思考內容又混進了輸出欄位，會整個失真。

第六節：時事插播，才剛寫完，接班人就到門口了

就在整理這篇資料的同時，Qwen 把 Qwen3.8-Flash-Next 放上了 Hugging Face，官方定位寫得很直白，這是 Qwen4 架構的實驗性預覽。如果去觀察它的模型規格，天哪，每一條都像在對今天這篇文章隔空喊話：

125B 總參數，每 token 只啟用 6B。 今天第二節講的 decode 經濟學，它直接做成教科書等級的示範，啟用量只有今天主角模型的九分之一到四分之一，但是官方公布的基準分數卻全面領先，JobBench 55.7 對 27B 的 33.4，agentic 項目差距最大。模型大小與跑起來多快是兩回事，Qwen3.8-Flash-Next 可說是這個現象最極端的例證。

51B 的 n-gram embedding，官方明說這個參數軸「對記憶體受限的加速器友善、可卸載」。 這句話幾乎是說給 Spark 這類機器聽的，embedding 查表是稀疏存取，理論上可以放在較慢的儲存層。這個設計如果實測成立，前面 Day 13 文章的儲存判斷框架會多出一個全新的分支。

內建 1 層 MTP。 今天才講完投機解碼怎麼繞過頻寬鐵律，剛發表的 Qwen3.8-Flash-Next 出廠就是自帶草稿層的架構裡，跟 pplx 那款後訓練版模型的 DFlash2 是同一個概念的方式。

但是 GB10 放不下 Qwen3.8-Flash-Next BF16 的版本，它的權重 180B 參數約 360 GB 檔案大小，單台 Spark 放不下，4-bit 量化粗估 90 GB 上下才有機會塞進 128GB，而且要留 KV 的活路。所幸，社群很積極， GGUF 已經出了十幾個，能不能塞、塞進去跑多快，都需要實測驗證。

我原本打算寫「讓子彈先飛一會兒」就收尾。但這三條都太直接命中今天的主題了，所以當天就把它抓下來跑完同一套驗收。以下全部是本機實測。

記憶體：三個數字對得上，一個對不上

選 UD-IQ4_XS，磁碟 93.68 GB、載入後 87.24 GiB、4.25 bpw。unsloth 官方的硬體需求表寫 3-bit 要 90 GB、4-bit 要 112 GB，我文章前面那句「4-bit 粗估 90 GB 上下」是估錯了，90 GB 對應的是 3-bit。IQ4_XS 這一檔落在兩者之間，實測連權重帶執行環境峰值 95.3 GiB，在 128 GB 的統一記憶體裡還算寬鬆。

KV 的部分是有意思的，如果用 512 上下文的啟動日誌反推：

主 KV：      12.00 MiB / 512 token / 12 層完整注意力 = 24 KB/token
QSA 索引快取：4.50 MiB / 512 token                    =  9 KB/token
線性注意力狀態：124.88 MiB，固定值，不隨上下文成長

前面第四節算過， 27B 是 34.5 KB/token。Flash-Next 主 KV 只要 24 KB，因為它只有 12 層完整注意力而且 KV head 從 4 減到 2。但 QSA 的索引快取要另外收 9 KB/token，加起來 33 KB，跟 27B 幾乎一樣。 而且 27B 那個 34.5 是開了 8 位元 KV 量化的，這裡則是 f16，由於稀疏注意力不是免費的，它把省下來的 KV 又用索引結構收回去一部分，這件事呢，官方的架構圖倒是沒有寫出來。不但如此，開長上下文時 llama.cpp 警告計算緩衝區的實際用量比它自己預期的大了八到二十二倍，這不影響結果，畢竟是全新架構實作還沒調校好的痕跡，也讓我們知道這很新，後面社群就陸續有調好的路線可用。

速度：兩條天花板公式，差了三百倍

87.24 GiB 的模型跑出 28 t/s，比 23.26 GB 還開著投機解碼的 pplx 那顆更快。 這是本系列到目前為止「模型大小與跑起來多快是兩回事」最極端的例證。

現在把本文第二節那條公式拿來套，看它怎麼壞掉：

密集公式：273 GB/s ÷ 87.24 GiB 檔案      = 上限 2.91 t/s   實測 28.02 → 達成率 961%

達成率 961%，公式壞了。因為第二節那條公式的前提是密集模型每個 token 要把全部權重讀一遍。MoE 不是。正確的分母是每個 token 實際讀取的位元組，如果從 GGUF 的張量表逐一加出來：

路由專家張量  55.43 GiB，但 512 選 10，每 token 只讀 10/512 = 1.08 GiB
n-gram 查表   26.82 GiB，但每 token 只讀 16 個 160 維向量 ≈ 1.4 KB
其餘全部       4.98 GiB，每 token 全讀
                                          每 token 讀取 = 6.07 GiB

MoE 公式：273 GB/s ÷ 6.07 GiB = 上限 41.91 t/s   實測 28.02 → 達成率 67%

67% 這個數字才有意義，而且它落在第二節那些密集模型（77% 到 93%）的下緣。這種差距是怎樣來的呢? 來自 於 MoE 的存取形態，它每層要從 512 顆專家裡挑 10 顆，跳著讀小矩陣，不像密集模型可以整片串流。簡單說，稀疏和密集模型相比，它省下的是頻寬總量，而代價是存取效率。

品質

PPL 用第三節同一份語料、同一條命令列，分段數 英文 580、繁中 147，與第三節逐一相同。 加上 tokenizer 檔案本身逐位元相同（vocab、merges、pre_tokenizer、33 個 added token 全等），兩個模型其實吃的是同一串 token，所以可以並排比較。

英文贏三成，繁中輸一成三。 而且這個比較對 Flash-Next 不公平，它帶著 4.25 bpw 的量化損失，27B 那一側是無損 BF16。一顆被壓到四位元的模型在英文上贏無損對手三成，卻在繁體中文上輸了。

這跟第三節第三點是同一個主題的不同面向。第三節講的是量化對繁中的傷害是英文的兩倍，這裡講的是新架構帶來的增益幾乎沒有分給繁中。20,000,000 條 n-gram 的查表要靠訓練語料填滿，語料的語言分佈會直接刻進這個參數軸裡。架構升級不會自動變成你的語言的升級哪。

要說清楚兩件事。第一，第三節那張表的「劣化」欄位對 Flash-Next 是空的，因為那一欄以各自模型的 BF16 為基準，而它的 BF16 是 360 GB，這台機器放不下，算不出屬於它的劣化率。第二，PPL 只測「預測下一個 token 的把握」，不量能力，根據官方公布的資料，Qwen 3.8 Flash-Next 在 AI agentic 這項是全面領先Qwen 3.8 27B，那是另一個標準了，但可以參考。

Qwen 3.8 Flash-Next 的量化階梯

Qwen 3.8 Flash-Next 的 Q2_K_XL 模型手邊也有，所以 Flash-Next 有了自己的兩級階梯。連貫性同樣先過，英文與繁中都是完整通順的句子。

繁中的劣化比英文小，倍率 0.88。 第三節第三點說繁中的劣化一律大於英文、倍率 1.6 到 2.0，而且那個規律跨了兩個引擎、兩個量化家族都成立，但這裡是第一個反例。

翻檔案就找到了原因：

                    IQ4_XS              Q2_K_XL
n-gram 表           26.82 GiB           26.82 GiB      ← 位元組完全相同
                    4.50 bpw            4.50 bpw
其餘（Transformer 本體）  60.42 GiB           46.62 GiB
整體等效            4.24 bpw            3.57 bpw

那張 26.82 GiB 的 n-gram 表在「2 位元」的檔案裡一個位元組都沒動。 unsloth 在文件裡講明了為什麼，這些查表是隨機存取，壓太兇會傷得特別重，所以最低只到 4 位元。所以 UD-Q2_K_XL 的等效精度其實是 3.57 bpw 不是 2 bpw，被壓的只有 Transformer 本體那 60.42 GiB。

至於為什麼「保住查表」會讓繁中相對受益呢? 我只能提出假說而不能證明，詞彙層面的記憶大量存在那張表裡，繁體中文相對更依賴這種查表式的詞彙記憶，如果表沒有被壓縮，只有模型本體被壓縮時，那它它受到的保護就比英文多。如果要驗證這件事情，就得把 n-gram 表也壓到 2 位元重做量化，這不在今天的範圍內，很費時唷。

Q2_K_XL 比 IQ4_XS 快 20%（33.66 對 28.02），但只小了 16%。 對照第二節那張表，27B 從 q8_0 到 q4_k_m 是小了 39% 換來快 48%。這裡的性價比明顯差一截，因為那張佔了 36.5% 的 n-gram 表壓不動，自然體積和頻寬都省不下來。

結論是 Qwen 3.8 Flash-Next 這款模型的量化空間比它的檔名看起來小得多。想省記憶體的人要知道，它能壓的只有六成多。

長上下文：稀疏注意力沒有變成更平的曲線

絕對值它全程領先。但看衰減：decode 從 8K 到 121K 掉了 54%，而 27B 只掉 15%。 prefill 掉 63%，27B 掉 36%。

這跟官方那句「QSA 大幅降低長上下文延遲」的期待相反，至少在這台機器、這個實作上是這樣。我自己想到的合理解釋，是那個 9 KB/token 的索引快取，微塊選取本身要掃過全部上下文才能決定要挑哪些塊，這個掃描是線性成本，上下文越長就會越貴。稀疏化的是注意力計算，不是選取。

由於兩組的引擎與量化都不同（llama.cpp 加 IQ4_XS 對 vLLM 加 FP8），衰減比例各自跟自己的 8K 比所以成立，但絕對值不能直接比對，這是會混淆的，合先敘明。

品質面，在 121,472 token 的文件裡開頭、中段、尾端各埋一根針：

三比三全中，跟 27B 一樣。同樣的保留仍然適用，單針測試通不過代表有問題，但是通過了，也不代表沒問題喔。

繁體中文考卷三款模型對比

我的考卷對這三個模型都太簡單了，正確率一樣全滿。但有兩件事可以稍微提一下。

第一，繁體中文的品質意外地好。
十題零簡體洩漏，用詞也正確，「膠輪」「記憶體受限（memory-bound）」都答得出來。前面 PPL 說它繁中比 27B 差，而這裡卻看不出差別。這兩件事不衝突，PPL 量的是對一份特定語料的預測把握，考卷量的是能不能把事情做對。同一顆模型可以在前者輸、在後者平手，這正是為什麼不能只看一個指標。

第二，JSON 緊湊度這一題它輸了。
同一個提示詞明確要求「只輸出一個 JSON 物件，不要有任何其他文字」，十輪重複：

八次自作主張加了換行與縮排，比原版 27B 還多。這顆在官方 agentic 基準上大幅領先的模型，在「不多話」這個維度上輸給一顆為 agent 後訓練過的 27B。這佐證了第五節的結論， AI agentic 能力與 agentic 禮儀是兩件事，前者靠預訓練與架構，後者靠後訓練。

n-gram 卸載：官方說可以，這台機器上不划算

這是官方 highlight 裡最吸引我的一條，也是最需要實測的地方。先看它到底多大：

per_layer_token_embd.weight   26.82 GiB   佔全模型 30.7%
PLE 全族（含各層小張量）      26.85 GiB   佔全模型 30.8%

單一張量就是模型的三成。把它連同相關的小張量一起釘在 CPU，其餘照舊上 GPU：

前兩列符合預期，查表是稀疏存取，prefill 幾乎不受影響，decode 付出 16.7%。第三列才是重點，而且它推翻了我原本的假設。

在 GB10 上「把張量從 GPU 移到 CPU」不會省下任何記憶體，因為那是同一塊實體 DRAM。統一記憶體架構下，卸載這個動作只換位置不換總量。所以在這台機器上，這是純虧，付 16.7% 的 decode，換到效益零。

這個結論有明確的適用邊界。官方那句「對記憶體受限的加速器友善」講的是獨立顯卡，VRAM 與系統記憶體是兩個不同資源，把 26.82 GiB 從 24 GB 的顯卡上挪走，是「跑不跑得動」的差別，那當然值得付 16.7%。真正對 Spark 有意義的變體是 unsloth 提到的另一條路，把它 mmap 到 SSD，那才會真的降低常駐記憶體，代價是 NVMe 的隨機讀取延遲。那條路要另外測，Day 13 的儲存判斷框架剛好有現成的量測方法。

所以那句「Day 13 的儲存判斷框架會多出一個全新的分支」，答案是：會，但分支的判斷條件不是「要不要卸載」，而是「你的記憶體是不是統一的」。 統一記憶體的機器，這個參數軸的卸載價值歸零，這個架構就非常適合在具備獨立顯示卡的電腦上使用。

順帶一提，vLLM 那邊的對應功能也還沒走通，官方 issue 顯示單卡的 CPU 卸載會在暖機階段卡死，這條路線還在工程中。

這一節學到什麼

Qwen 3.8 Flash-Next 授權從 Qwen 3.8 27B 的 Apache 2.0 換成了 qwen-community-1.0，要商用的讀者，請務必把它的條款讀完再動手，這一條會寫進模型庫的 MANIFEST 裡（Day 5 的SOP）。

但今天想問的三件事都有答案了，GB10 塞得進去、跑得比 27B 快三倍、繁中沒有跟上英文的進步幅度。額外多拿到一個反例，讓繁中劣化大於英文這條規律有了它的邊界條件。

換代還是分工：以後用 Flash-Next 就好了嗎

今天同場測完兩個世代，大家最關心的就是這個。我的答案是現在談換代太早，談分工正是時候，怎麼說呢：

「以後用 Qwen 3.8 Flash 或 Qwen 4 預覽版就好」這件事，還缺三個條件，兩大引擎的支援都還在 PR 裡沒合併、繁中品質沒有跟上英文的進步幅度、以及它掛著「實驗性預覽」的名牌與比以往更限縮的授權。它是 Qwen4 的預告片，預告片可以讓你決定要不要期待正片，但你不會拿預告當每天用的東西。等 Qwen4 正式版帶著合併後的引擎支援與各種強化後出現，答案就會是肯定要換的。

至於「Qwen 在地端是不是真的比其他廠商強?」，用本系列實測過的實際資料來看，它的強不在單點分數，在梯度與速度，畢竟，從手機到 125B 的尺寸全梯度、視覺多模態內建、量化生態的支援永遠最快（今天 Flash-Next 上架幾天社群 GGUF 就有十幾個，你就知道社群心向哪邊），而且 n-gram 可卸載這種設計，可說是替記憶體受限的裝置著想，這是其他家開放權重沒有的態勢。
Qwen 的對手各有山頭，DeepSeek 的路線是大 MoE 加 harness 生態（最近 dsh 的爆發是另一個故事，我也會寫一篇喔），gpt-oss 已經不在市場前面了，Meta 推的 Muse 則走 agent 特化。

但今天的成績也給了這個「強」一個誠實的註腳，進步幅度的語言分配不均，Qwen 的英文跑得飛快，繁中則是在原地領先。 對台灣的使用者而言，選模型的除了看排行榜第一是誰，也要看自己的語言在他們的訓練語料裡是排第幾。

從這個角度來看，確實會更需要有在地模型的強化，基於中國模型或美國模型去後訓練也是一條路，即便是明天 Day15 的主角，最近熱門的 Ornith 1.5，也是採用 Qwen 模型和 Google 開源的 Gemma4 模型去打造出來的，大家都是站在巨人的肩膀上繼續前進，而這正是我覺得應該不拘泥於模型基底，從好的基礎繼續往上迭代的緣故。只是授權和訓練資料的問題，在未來勢必會有一番角力，可以多方觀察。

Qwen3.8-27B 與 Qwen3.8 Flash Next

Qwen3.8-27B 適合誰：長輸入短輸出的工作（prefill 比 decode 划算兩百倍）、需要 256K 長窗又吃不下全注意力 KV 成本的場景、要商用授權的團隊（Apache 2.0）、以及把它當 agent 底模的人（工具呼叫十輪全中）。加上今天第六節的對照，還要多一條：在乎繁體中文品質的人。 接班人 Qwen3.8 Flash Next 在英文 PPL 上贏它三成，繁中卻輸一成三，這件事在挑地端模型時比總參數量重要得多。

不適合誰：追求純文字 decode 速度的場景。密集 27B 在 273 GB/s 的機器上，8 位元只有 7.9 t/s。這一點今天被證實得很徹底，第六節那顆 87 GiB 的 MoE 跑出 28 t/s，是它的三點五倍，而且沒開投機解碼。明天的 Ornith 1.5 35B-A3B 會從另一個角度再示範一次。

量化選哪檔：日常用 q8_0，PPL 劣化 0.06%、速度 7.93，是無腦選擇。要壓體積用 q4_k_m，17.77 GB 拿到 +0.50% / +0.84%，是這張表上最好的性價比。不要因為名字新就選 NVFP4，它在這顆模型上比大它 8 GB 的 q4_k_m 差五到十倍，除非你要的是 FP4 張量核心的速度。至於第六節的 Qwen3.8 Flash Next，128 GB 的機器只有 UD-IQ4_XS（93.68 GB）與更低的檔位可選，官方標示的 4-bit 檔要 112 GB，記憶體放不下。

常駐陣容的位置：我會把 Qwen3.8 27B q8_0 留在系統中當「需要繁中品質又要能跑工具」的預設選項，把 pplx 混合那顆留著當投機解碼的實驗場，畢竟它是目前手上唯一一顆出廠就配好草稿模型的權重。至於 Qwen3.8 Flash Next 這款 93.68 GB 會留著，但不進常駐，它一顆就吃掉這台機器四分之三的記憶體，除非後續新的版本更穩定就有機會提高利用率。

明天預告

密集 27B 驗收完畢，明天改換近來地端模型光譜另一端的熱門新人，DeepReinforce 的 Ornith 1.5，35B-A3B 的 MoE 設計，總參數比今天的主角大、每 token 啟用量卻只有九分之一。今天講的 decode 經濟學會在它身上得到具體呈現，同一台機器、同一條頻寬，換一個架構就提升一個等級。這次在本文第六節已經先用 125B 的極端版本示範過一次，明天換一個體型正常、能真的當日常主力的來看能不能打。在 Day 9 文中提到的完整實測承諾，明天兌現。

我們 Day 15 見囉。

附錄一：量測方法

本篇的效能與品質數字皆為本機實測，第六節另外引用了官方 model card 的架構規格與基準分數，以及 unsloth 的硬體需求表與 KLD 表，那幾項在文中都標明了出處，不是我測試的。量化階梯的 GGUF 各檔沿用 Day 12 的 llama-perplexity -c 512，vLLM 各檔為本次以 prompt_logprobs 逐 token 取 log-prob，計分窗對齊 llama.cpp 的 first = n_ctx/2。繁中語料為自產，與 Day 12 同一份。工具呼叫與 agent 情境的判準皆為機器可驗，測試用的路徑與收件人均為虛構。

附錄二：考卷公開

第五節的測試都是機器可驗的，我的考題算是簡單的，可以把題目拿去考自己手上的任何模型。

繁中十題的判分方式：每題兩分，答案含必要關鍵字得一分、全文無簡體字再得一分。題目刻意都帶一個硬性關鍵字要求，這樣判分不必靠人。示例三題（完整十題見文末連結）：

1. 用繁體中文一句話說明什麼是投機解碼，句子必須包含「草稿」兩個字。
   （關鍵字：草稿）
2. 用繁體中文列出三個 NVMe 比 SATA SSD 快的原因，
   每點一行，開頭用「1.」「2.」「3.」。（關鍵字：1. 2. 3. 三者皆須出現）
3. 台北捷運文湖線是哪一種系統？用繁體中文回答，答案要包含「膠輪」。
   （關鍵字：膠輪）

繁體中文評分用的是一張手工的簡體專用字表，數的是「洩漏字數」而不是二元通過。這台機器上沒有 opencc 或 zhconv，所以覆蓋率不是百分之百，但同一把量尺套在所有受測模型上，相對比較仍然成立。這份字表刻意排除了繁簡同形字與兩邊通用的異體字。

工具呼叫十輪的 schema（只有一個工具，換十個任務）：

{
  "name": "search_files",
  "parameters": {
    "dir": "string",
    "pattern": "string",
    "max_results": "integer"
  }
}

提示詞要求「只輸出一個 JSON 物件，格式為 {"name":..., "arguments":{...}}，不要有任何其他文字或 markdown 標記」，然後接十個不同的搜尋任務，例如「在 /var/log 找出所有 .err 檔，最多 20 筆」。

四項全中才算通過，抽得出 JSON 且能 parse、函式名等於 search_files、dir 與 pattern 與 max_results 三個欄位都在、且 max_results 是整數型別而不是字串。

多步 agent 三題的形狀（示例一題）：

你有 list_dir、read_file、write_file 三個工具。
任務：找出 /project 底下最大的 .log 檔，讀它的最後 100 行，
把摘要寫進 /project/summary.txt。
請只列出你會依序呼叫的工具名稱，一行一個，不要解釋。

三個工具名稱都要出現，而且在輸出中的先後位置必須是正確順序。只比對名稱與順序，不要求模型真的執行，這樣同一題可以考任何模型，不管它支不支援原生 tool calling。另外兩題分別是 http_get 到 parse_json 到 write_file，以及 run_sql 到 format_table 到 send_email。

JSON 緊湊度測試的原始提示詞（第五節那個 0 比 7 的發現就是它考出來的）：

只輸出一個 JSON 物件，不要有任何其他文字、說明或程式碼區塊標記。
物件需包含 host、status、latency_ms 三個欄位，
值分別為 "nas-01"、"online"、23。

十輪重複，數有幾輪輸出是單行緊湊格式、有幾輪自作主張加了換行縮排。你可以拿這題去考任何聲稱「適合 AI agent」的模型，這測試很簡單，但很誠實。

（完整考卷與測試腳本

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型