實測 Ornith-1.5 解碼加速，GB10 沒有 FP4 算力照樣翻倍

最近超熱門的 Ornith-1.5 是一個以自我改進強化學習訓練、主打終端機代理與程式任務的模型家族。我們把其中的 35B-A3B 版本放上兩台以 ConnectX-7 直連的 GB10，量測 bf16 與 NVFP4 兩種精度，再用 AIME 2026 全 30 題確認品質沒有跟著速度一起被犧牲。實測過程中還順手推翻了我們自己用來預測解碼速度的公式，而推翻它的，正是這個理論上不支援原生算力的量化格式。

Ornith-1.5 模型定位與官方評測

Ornith-1.5 把「自己出題、自己找解法、再用強化學習更新策略」當成主要訓練迴圈，剛好是近期社群熱門的新款 AI 開放模型。由 ornith-ai 發布，官方說明其建立在 Qwen3.5 與 Gemma4 之上，並加上額外的持續預訓練、中期訓練與後訓練。這套訓練迴圈持續生成新的訓練任務、找出解題策略，並透過強化學習改進策略，官方稱之為端到端的自我改進。這條路線的成果集中在代理與程式能力上，而不是通用聊天。

架構拆解：四層裡有三層不是傳統注意力

這顆模型的 model_type 為 qwen3_5_moe，架構名稱為 Qwen3_5MoeForConditionalGeneration。深入設定檔可發現多項對部署有重大影響的設計特點。

混合式注意力機制

在 40 層架構中，有 30 層為 GDN 線性注意力，每第 4 層才採用完整注意力。這代表 KV 快取只由那 10 層產生，長上下文的記憶體成本遠低於同尺寸的傳統模型。

稀疏 MoE 專家配置

架構配置 256 個專家，每個 token 選取 8 個專家，並額外設置 1 個常駐共享專家。

長上下文與視覺多模態

具備原生 262,144 token 上下文，官方另提供 YaRN factor 4.0 延伸到約 1M。它本質上是視覺語言模型，設定檔帶有完整的 vision tower 與影像／視訊 token。

投機解碼與開放授權

內建 1 層 MTP（多 token 預測）可作為投機解碼的草稿頭，整體模型採用 MIT 授權釋出。

測試平台設定與量測協定

實測硬體採用兩台 GB10，透過一條 ConnectX-7 直連線執行 100GbE，並採用 vLLM 內建的跨機執行器，完全不經由 Ray。

嚴謹量測協定的設計原因

選擇走 /v1/completions 而不是 chat 端點，是為了把 chat template、思考區塊與 reasoning parser 全部排除在計時路徑外。搭配 ignore_eos 固定 token 數，是為了讓每次取樣解碼的長度完全一致，否則模型自行決定思考長度會干擾速度數據。初次請求則必須確實暖機，以扣除 JIT 編譯的額外負擔。

實測成績：跨機 TP=2 效能對比

同一顆檢查點在兩種精度下，四個評測面向全面領先。各組數據獨立縮放，實測數字均為三次取樣之中位數。

以 262,144 token 的滿窗請求換算，bf16 的 KV 快取可支撐 24.18 倍並行，NVFP4 則能支撐 62.96 倍並行。對於需要同時掛載多個代理工作階段的場景，這個差距比單純的解碼速度更具決定性。兩者的數據散布都在 1% 以內（bf16 為 0.58%、NVFP4 為 0.93%），證實測量結果具備極高再現性而非抽樣雜訊。

GB10 沒有原生 FP4 算力，速度為何翻倍？

在載入 NVFP4 權重時，vLLM 明確提出了警告，GPU 不具備原生 FP4 計算支援，系統將透過 Marlin kernel 執行 Weight-only FP4 壓縮路徑，並指派 MarlinNvFp4LinearKernel 與 MARLIN NvFp4 MoE 後端。

在 sm_121 架構上，這條路徑實際執行的是 weight-only FP4（W4A16）。權重以 4-bit 儲存與搬運，進到矩陣乘法運算單元之前才反量化回 BF16。算力完全沒有變便宜，嚴格來說甚至因為多了反量化這一步而略增運算開銷。

而這正是它能勝出的核心原因。GB10 的解碼過程是記憶體頻寬受限，而不是算力受限。每產生一個 token，真正的瓶頸在於必須從記憶體搬運多少位元組的權重進到運算單元。把權重壓縮成 4-bit，搬運量便驟降到約三分之一，因此即使 GPU 沒有原生支援 FP4，速度依然接近翻倍。

工程判斷原則：看到 GPU 不支援該量化格式的警告時，需先辨識該工作負載是頻寬受限還是算力受限。在頻寬受限的解碼上，weight-only 量化即使沒有對應的張量核心也照樣能帶來顯著效益，反過來看，在算力受限的 prefill 階段，NVFP4 實測增益僅有 1.50×，遠低於解碼的 2.10×，落差便是由此而來。

預測模型失效的實證復盤

在此之前，CyberQ 團隊曾用三款不同模型擬合出一條解碼速度預測公式，每 token 時間 = 權重位元組 / 頻寬 + 層數 × 每層固定成本。舊係數設定為 518 GB/s 與 0.217 ms/層。動手前以此公式預測 Ornith bf16 為 49.40 tok/s，實測 48.41 tok/s，誤差僅 +1.9%。然而 NVFP4 實測跑出 101.86 tok/s，原公式預測卻為 84.20 tok/s，低估達 -21%。

活躍權重精確加總

要修正係數，必須先取得每 token 實際搬運的精確位元組。我們不採信概估的 ~3B 活躍宣稱，而是直接讀取 16 個 safetensors 分片的標頭，逐一加總每種層別的張量。

兩點實測反解方程式：

20.657 ms = (5.89 / bw) × 1000 + 40c (bf16)

9.817 ms = (1.66 / bw) × 1000 + 40c (NVFP4)

舊係數同時高估了頻寬與每層固定成本，在 bf16 這個頻寬項主導的點上恰好互相抵消。新係數在物理機制上更為合理：390 GB/s 是兩台合計峰值頻寬 546 GB/s 的 71%，而舊係數 518 GB/s 相當於 95%，對一個每 token 都要進行專家權重 gather 與 scatter 的 MoE 解碼來說高得不合常理。

每層 0.139 ms 亦合理低於 0.217 ms，精確反映出 40 層中有 30 層為線性注意力、省去逐 token KV 讀取所帶來的成本節省。這證明單一模型的單點命中無法驗證兩參數模型，唯有在同一個模型上取兩個頻寬項差異夠大的點，才能有效驗證推論公式。

品質驗證：AIME 2026 全 30 題實測零分歧

CyberQ 為確認加速並未犧牲模型推論品質，評測採用 math-ai/aime26 全部 30 道題目，在相同 harness、相同提示、貪婪解碼、max_tokens=32768 與並行 10 的嚴格條件下進行驗證。

兩邊都順利跑完的 22 題中，答案完全一致，沒有任何一題出現分歧。在貪婪解碼機制下，這代表兩顆權重在這 22 條、平均一萬多 token 的推理鏈上做出了完全相同的 argmax 序列決策。

兩者唯一的差異在於截斷題目微調了一題（bf16 截斷第 17 題，NVFP4 截斷第 13 題，其餘 6 題兩邊皆截斷）。成因在於 NVFP4 的推理鏈略長，同樣 22 題總輸出為 205,576 token，相較 bf16 的 194,679 token 多出約 5.6%，在 32,768 上限邊界處造成翻轉。76.7% 的成績代表的是特定 token 預算下的產出，而非模型能力上限。在 37,857 token 長上下文取值、XML 工具呼叫解析與額外四題推理抽查中，兩者亦皆全數通過。

Ornith-1.5 適用場景評估

CyberQ 認為，從實測數字反推，這款架構在特定應用場景確實具備明確優勢。

極為適合的場景

適合作為終端機與程式代理的本地後端，48 至 102 tok/s 的解碼吞吐對於自迴圈代理極為充裕；適合需要長上下文的整庫代碼理解，在原生 262K 視窗下 NVFP4 仍具備 62 倍並行空間；適合多工作階段並行與單機、雙機自架部署，NVFP4 權重僅需 23.4 GB，單張 24 GB 級顯示卡即可運行，bf16 亦僅需 72 GB。

較不適合的場景

不適合對延遲極度敏感的即時互動對話，因其預設會生成思考區塊，需明確關閉思考模式以壓低延遲；不適合作為通用知識庫，3B 活躍參數決定其知識密度主要仰賴工具檢索；亦不適合不容重試的一次性高風險決策。

397B 版本配置 512 個專家（每 token 選 10 個、hidden 4096），官方 NVFP4 體積達 238 GB，最小官方 GGUF（Q4_K_M）為 240.6 GB。兩台 GB10 合計系統可用記憶體約 220 GB 無法載入，部署門檻需 8 張 141 GB 級資料中心加速卡。

若以本文新解出之係數推算（約 9 GB/token、60 層），其在雙 GB10 上的解碼速率約落在 32 tok/s，與社群在 NVIDIA 開發者論壇上回報上一代 1.0 版 W4A16 實測之 33.13 tok/s 一致。

9B 密集版每 token 需讀取完整 9B 權重，比 35B-A3B 的 2.95 B 活躍參數多出三倍。在頻寬受限硬體上，9B 密集版的解碼速度會比 35B MoE 版更慢，其主要價值在於 18.8 GB 總體積能塞入低階硬體。

部署實務注意事項

以下為 CyberQ 本次實測踩過、且在模型卡上未載明的小問題：

推論內容欄位名稱：推論輸出欄位為 reasoning，而非模型卡標示的 reasoning_content，查錯欄位會誤判 parser 未生效。

思考標籤輸出特性：模型生成時僅輸出封閉標籤 ，不輸出起始標籤 。起始標籤是由 chat template 作為生成前綴塞入提示詞中。

思考模式預設配置：思考模式預設為開啟，若為延遲敏感型服務需在請求中明確傳入停用旗標。

快取機制相容性：混合架構與 prefix caching 完全相容，vLLM 會自動將 Mamba 狀態切換為對齊模式並調整 attention block size，無須手動關閉快取。

長上下文擴展設定：YaRN factor 4.0 延伸至 1M 需自行驗證，本次硬體測試在遠低於原生視窗長度即可能出現亂碼，建議優先使用原生 262K 上下文（已實測 37,857 token 運作正常）。

實驗複現資訊：權重取自 Hugging Face 官方庫 ornith-ai/Ornith-1.5-35B-A3B 與 NVFP4 版本，兩種精度採用相同容器映像檔、引擎旗標與量測腳本，各項數值皆為三次取樣之中位數。官方評測分數引自模型卡，所有速度、記憶體與活躍參數數字為本站實測。品質部分僅做抽查，明確不構成評測結論。