🚨 AI-LECTURER 快訊速報|2026-08-21|5 分鐘速讀

🚨 AI推理再加速:DFlash 2 讓「平行猜字」這招更進化

取材:DFlash 2: Keep Drafting Parallel(Hacker News(AI 高人氣))|完整課同日跟進,見書架
📍 真實場景
阿凱,接案工程師,正在幫客戶做一個會自動跑好幾個小時的 AI 客服 agent

阿凱的 agent 要一直讀資料、規劃步驟、呼叫工具,常常要跑好幾個小時才能完成客戶交辦的一個任務

😖 卡住的地方:客戶嫌 AI 回應太慢、任務跑越久 API 費用越貴,阿凱每天都在想辦法壓成本、壓速度,但預算根本不夠換更貴的 GPU
💡 看完這篇,你會知道有一招不用換硬體、結果保證不變,就能讓 AI 推理速度多出 20%~300% 的免費技術,而且很可能你正在用的模型已經有人幫你做好了

⚡ 一句話講清楚

AI agent 時代,模型常常要連續工作好幾個小時——讀資料、想計畫、呼叫工具,每吐出一個字都要把整個模型重新算一遍,這個「模型算出答案」的過程叫做推理(inference)讓已經訓練好的AI模型針對你的問題產生答案的過程,跟訓練不同——訓練是教模型學會東西,推理是模型學會後拿出來用,也是目前AI agent最大的速度瓶頸。業界因此發明了一招:先找一個小又快的草稿模型(draft model)一個體積小、速度快的AI模型,先幫大模型偷跑猜接下來可能出現的好幾個字,猜對了大模型就不用自己一個字一個字慢慢算,省下大量時間,快速猜出接下來一串字,再讓真正的大模型一次驗證整串,猜對的部分直接採用,猜錯的才丟掉重算。

但過去這個「偷跑」的動作本身還是自迴歸(autoregressive)AI模型產生文字時,一次只能吐出一個字,而且每個字都要先看到前一個字才能往下算,所以速度快不起來——草稿模型一樣得一個字一個字慢慢猜,快不了多少。今年初 Inco AI 團隊推出的 DFlash,讓「偷跑」這個動作也變成一次全部算完:一整串要猜的字同時、平行算出來,不用等前一個字先出來。這招已經被 NVIDIA、Google、Meta 等大廠採用,在 NVIDIA 的 Blackwell GPU 上最高測出 15 倍的推理速度提升,Hugging Face 上這類模型下載次數已經超過 350 萬次。

這次的 DFlash 2,則是解決了「大家一起平行用力猜」會出現的兩個副作用:猜出來的字彼此接不起來(不連貫)、越到句子後面猜得越不準。新版做法幾乎不增加額外運算時間(大約只多 1% 的運算週期),就能讓大模型每驗證一輪,平均多產出超過 20% 的內容——而且保證結果跟原本一字不差,不是用「差不多就好」去換速度。用新釋出的 Qwen3.8-27B 草稿模型實測,在 SGLang 這套推理引擎上,單一請求就能跑出一般自迴歸(autoregressive)AI模型產生文字時一次只能吐出一個字、每個字都要等前一個字先出來才能算的方式方式 2.7 到 3.4 倍的吞吐量(throughput)單位時間內AI能處理完成的工作量,通常用每秒能吐出幾個字來衡量

🏃 快速上手三步(今天就能做)

1
查:去 Hugging Face 搜你的模型有沒有專屬草稿模型打開 Hugging Face,用「你正在用的模型名稱 + DFlash」搜尋(例如你用 Llama 就搜「Llama DFlash」、用 Qwen 就搜「Qwen DFlash」)。目前 Meta、NVIDIA、Xiaomi 等官方都已經釋出對應的草稿模型,下載次數破 350 萬次,你要的很可能已經有人做好了,不用自己從零訓練。
2
試:在你的推理引擎打開 speculative decoding 設定如果你是用 SGLang、vLLM 或 llama.cpp 自己架模型(不是單純呼叫別人的 API),去查該引擎文件裡的 draft model / speculative decoding 設定,把 draft model 換成對應的 DFlash 版本、開啟量化(quantization)把模型內部數字的精細度降低,類似把彩色照片壓成較粗的色塊,讓模型檔案變小、跑得更快,但準確度會有些微下降、block size 先設 5,實際跑一次同樣的任務,比較前後花費的時間差異。
3
注意:用別人代管的服務,先問清楚有沒有內建如果你是直接用 CoreWeave 之類的代管服務或第三方 API,先查官方公告或問客服「你們這個模型有沒有用 DFlash / speculative decoding 加速」,像 CoreWeave 的 Kimi K2.7 Code 端點就已經預設開啟。如果服務商還沒支援,先持續追蹤消息就好,不必自己硬裝底層加速,以免花時間卻裝不進生產環境。

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 DFlash 2 為什麼敢保證「結果一字不差」,而不是像很多加速手法一樣犧牲一點準確度換速度?
關鍵在於它只在「猜測」階段偷跑,「驗證」階段仍然嚴格核對——草稿模型猜的每個字,都要被目標大模型逐字確認才會被採用,猜錯的部分直接丟掉重算,結果數學上等於原本大模型自己一個字一個字算出來的答案。這跟量化(quantization)把模型內部數字的精細度降低,讓模型變小變快,但準確度會下降或模型蒸餾那種「從根本讓模型變笨換速度」的做法不同:如果你的場景對正確性要求很高(像是生成程式碼、醫療建議),這種「無損」加速比犧牲品質的方法安全得多;代價是能省下的空間有限,不能無止盡拿正確性去換速度。
🔭 文章特別點名 Domino、DSpark 這些「靠額外運算修正每個位置」的對手做法,還強調自己不需要,這個立場透露了什麼工程權衡?
這反映推理加速領域現在的核心拉扯:平行猜測的速度,vs. 猜測彼此接不起來的風險。Domino、DSpark 選擇的解法是「多插入一層運算,把猜出來的字重新串起來」,等於拿一部分平行化的速度去換連貫性;DFlash 2 想證明這層「修正運算」其實可以省略。如果它是對的,代表以後設計草稿模型不用再為了連貫性犧牲平行度,「平行草稿」這條路線會從「能跑但有代價」的旁支,變成主流做法。