推論系統
Ling-3.0-flash INT4 單機實測達 38.7 token/s，錯用主線 vLLM 可能無聲產生錯誤輸出
社群部署配方在單台 DGX Spark 上啟用 CUDA Graph 與一層 MTP 推測解碼，把 Ling-3.0-flash INT4 的生成速度由 20.8 提至 38.7 token/s。更關鍵的發現是主線 vLLM 尚未支援 V3 架構，強行套用舊注意力路徑不一定報錯，卻可能輸出看似流暢的錯誤內容。
一份新公開的部署配方顯示，124B 總參數、每個 token 啟用約 5.1B 參數的 Ling-3.0-flash INT4，可裝入單台具 128GB 統一記憶體的 NVIDIA DGX Spark。測試在相同機器、相同提示、單一串流及每次生成 512 token 的條件下執行，捨棄暖機後取三次平均：直接使用 eager mode、未開 MTP 時為 20.8 token/s；移除 `--enforce-eager` 並啟用一個推測 token 後升至 38.7 token/s。作為對照，社群 Q5_K_M GGUF 路徑測得 35.2 token/s。
速度差異主要不是量化格式，而是執行排程。Ling 每步只啟用少量專家，GPU kernel launch 的固定成本因而更顯著；CUDA Graph 可重播已捕捉的執行圖，降低逐 token 啟動開銷。checkpoint 另含一層 multi-token prediction 草稿層，讓服務端用 `bailing_hybrid_v3_mtp` 先猜下一個 token，再由主模型驗證。
部署風險比速度數字更值得注意。主線 vLLM 目前沒有 `BailingMoeV3ForCausalLM`，若把 V3 權重強制交給舊版 V2.5 類別，程式可能把 KDA 權重送入不同的 attention 計算路徑。服務仍能啟動，輸出也可能語法通順，因此一般健康檢查不易發現數值語意已錯；配方要求使用 inclusionAI 的 `vllm-ling-v3` 特定分支。
這仍是單一作者、單台機器的小型測試，只驗證到 16K context，且冷啟動載入 24 個 shard 時約有一半機率停滯，暫以 watchdog 重試處理。工程團隊應先加入已知答案與工具呼叫回歸測試，再比較吞吐、首 token 延遲及長上下文品質；也需等待主線 vLLM 正式支援與 GB10 專用 MoE kernel 調校。