【2026 最新】Uno Ψ-Spec 是什麼？Diffusion-Augmented LLM 如何保留 AR 分布、一次驗證多個 Token

Diffusion-Augmented LLM 不是把整個語言模型改造成文字版圖片 diffusion。Uno 在同一模型中分開 AR 與 diffusion 兩組權重路徑：前者定義機率分布，後者平行提出多個 Token；可以從頭訓練兩者，也能替既有開放權重 AR 模型加上 diffusion adapter。2026 年 9 月公開的 Ψ-Spec 再讓 AR 路徑驗證提案；真正值得學的不是「一次吐很多字」這句口號，而是它如何在加速時仍以 AR 模型的機率分布為準。

這篇會從一個完整 Token 區塊走完 draft、verify、accept、correct，接著拆解 Linear 與 Tree sampler，最後給你兩張分開使用的評測卡：一張測 Uno 的同底模架構差異，一張看 Mercury 2.5 這類託管產品的實際交付。本文依 Uno 論文 v1與 官方程式核對機制；效能數字若被提及，都只代表作者或供應商的指定環境，不是 AlphaLab 自行量測。

先說結論：Uno 的核心是「diffusion 出題，AR 當裁判」

• 一般 AR：每次 forward 依序決定下一個 Token；前一步沒完成，後一步就沒有完整條件。
• 完整 diffusion LLM：在一段文字畫布上反覆去噪、修正多個位置；生成分布與取樣器本身都走 diffusion 路線。
• 傳統 speculative decoding：較便宜的獨立 draft model 先寫草稿，target model 平行驗證，配合 rejection correction 保留 target 分布。
• Uno：凍結的 AR 權重仍定義答案分布；額外的 diffusion LoRA 只負責提案，Ψ-Spec 再讓原 AR 路徑驗證。因此不需要另一個完整 draft model，但仍要負擔 adapter、draft 與 verify 的運算。

先記住這個錨點：Uno ＝ frozen AR verifier ＋ diffusion LoRA drafter ＋ Ψ-Spec rejection correction。它的「lossless」是分布保留，不是草稿永遠正確，也不是每次取樣都逐字相同。

Diffusion-Augmented LLM 與三種多 Token 路線差在哪？

若你已讀過 LLM 下一個 Token 預測器，會知道 AR 模型把已生成前綴當條件，一步一步抽下一個 Token。這個依賴鏈很可靠，卻讓 decode 階段難以把多個未來位置同時完成。完整 diffusion LLM 走另一條路：先放入帶噪或被遮住的 Token，再用多輪模型呼叫平行修正；更完整的 256-token Canvas 流程已在 DiffusionGemma 教學拆解，本篇不重複那套畫布。

Speculative decoding 則保留 target AR 模型，另外找一個更快的 drafter 猜未來 Token；target 能在一次 forward 中計算整段候選的機率，再接受合法前綴。原始方法用 rejection sampling 修正拒絕位置，因此能從 target 分布精確取樣。Uno 沿用這個「先提案、再驗證」骨架，差別是 drafter 不再是一個獨立小模型，而是共享 AR 基座、只在 noisy draft 位置啟用的 diffusion LoRA 路徑。

Uno Ψ-Spec 怎麼運作？完整走一次四個 Token

假設目前前綴是「台灣的首都是」，區塊大小 B=4。以下是機制示意，不是一段真實模型輸出：

1. 第一個位置先由 AR 路徑抽樣。把它記成 T₁，可想成答案「台北」的首個 Token 片段。因為它直接來自 verifier 的分布，所以這個位置必定接受。
2. diffusion 路徑平行補其餘位置。AR 權重加上 diffusion LoRA，在 noisy draft rows 一次提出 T₂–T₄；論文以 gated LoRA 讓 clean 與 noisy 位置走不同權重路徑。
3. 凍結的 AR 路徑一次評分整段。Verifier 依序套用 rejection rule，並保留最長連續 accepted prefix。
4. 第一個拒絕點做 correction。若前兩個候選通過、第三個被拒，verifier 會從修正後的 residual distribution 抽替代 Token；後面的草稿丟棄，下一輪再 draft。

如果整個 B 區塊都通過，verifier 還能從區塊末端的 logits 多抽一個 Token。Uno 每輪仍需要一次 draft forward 加一次 verify forward；論文因此把每次 forward 產出的平均 Token 數寫成 TPF，理論範圍是 1 ≤ TPF ≤ (B+1)/2。區塊開得更大不保證更快：後段更容易被拒，驗證成本也會上升。

為什麼 lossless 不等於答案完全一樣？

因為隨機取樣保留的是機率分布，不是固定字串。若 base AR 對下一個 Token 給「A 70%、B 30%」，正確的 lossless 加速器應讓大量取樣後仍接近這個 70/30 分布；某一次 Uno 抽到 B、基礎 AR 抽到 A，不能單憑兩行文字判定失真。相反地，即使兩次剛好同句，也不足以證明演算法保留分布。

Ψ-Spec 的保證來自 rejection correction 與凍結 verifier 的演算法推導。實作檢查能抓到程式、精度或設定錯誤，卻不能用幾個 prompt 取代證明。要做 sanity check，可固定 base model、temperature、top-p 與 prompt，對有有限答案集合的任務重複取樣，連同信賴區間比較頻率；不要拿「同 seed 是否逐字一致」當唯一門檻，因為兩條路徑消耗亂數的方式可能不同。

Linear 與 Tree sampler：一個顧整台服務，一個顧單一請求

Linear sampler 每個位置取一個候選，形成單一路徑。在大 batch 已接近 compute-bound 時，它避免驗證太多分支，目標是提高整台系統每秒處理的 Token。Tree sampler 則在每個位置保留多個高機率候選，再剪成有限 prefix tree 一次驗證；小 batch 尚有空餘算力時，它可能讓單一請求一次接受更多 Token，但候選越多，驗證開銷也越大。

這就是為什麼「最快設定」沒有單一答案。聊天產品在意單一使用者 latency；大量背景 Agent 任務可能更重視總 throughput。想補上 prefill、decode、KV cache 與 batching 的關係，可先讀 LLM 推論引擎教學。

怎麼公平評測 Diffusion-Augmented LLM？先拆成兩條賽道

Uno 與 Mercury 2.5 不能塞進同一張「架構誰比較快」的跑分表。Uno 論文提供同底模路徑的實驗；Mercury 2.5 則是託管 API，其發布頁的產品速度數字並非由同一套測試產生。正確做法是先問你要驗證因果機制，還是選一個可交付的 API。

• 賽道 A｜同底模機制：在同一台相容的 Linux／CUDA 機器，比較同一個 Uno Qwen3-8B bundle 的 base AR 路徑與啟用 adapter 的 Ψ-Spec 路徑，固定 prompt、取樣參數、輸入／輸出長度、精度與 batch。記錄 accepted prefix、TPF、每請求 TPS、整體 TPS、峰值記憶體；Linear 與 Tree 分開跑。品質門檻先凍結，分布檢查只作實作 sanity check。
• 賽道 B｜API 交付：把 Mercury 2.5 與候選 API 視為完整產品，比任務通過率、首個可見區塊時間、完成時間、有效輸出量與實付成本。工具呼叫另以 schema 驗證器與真實執行結果評分；這條賽道只能回答「哪個服務適合工作」，不能倒推出 diffusion 架構因果。

作者在 H200、固定 1K input／8K output 等條件下報告 Uno 的速度結果；不同倍數分別對應從頭訓練模型或 UnoQwen、低 batch 或高 batch，不能抽離範圍合併成一個保證。更穩健的讀法是：論文展示了 acceptance、batch size 與 sampler 會共同改變 throughput；你必須用自己的服務形態重算。設計評分器時，可搭配 AI Evals 入門；讀排行榜則要先看 AI 模型排行榜的測量邊界。

想跑 Uno：先確認官方程式需要的環境

截至 2026 年 9 月 10 日，Uno repo 的 commit b1cb7af9 安裝路徑鎖定 Python 3.10、PyTorch 2.11 CUDA 12.8、Triton 與 FlashAttention；預編譯 FlashAttention-2 wheel 是 Linux x86_64，Tree sampler 還需在 Hopper 路徑安裝 FlashAttention-3。這不是一般 Mac CPU 教學。環境符合後，官方 Uno Qwen3-8B recipe 的最小推論入口是：

git clone https://github.com/ifm-ai/uno.git
cd uno
git checkout b1cb7af9eda01342cc4e861ec2b135acf810c6d7
# 先依 README 建立官方 Python／CUDA 環境
bash examples/uno_qwen3_8B/run_inference.sh \
  --prompt "Explain why the sky is blue in three sentences."

這個入口會回報 output Token 數、elapsed time、TPS、decoder statistics 與 TPF。正式比較前還要把 repo commit、model revision、attention backend、block size、batch、temperature、top-k／top-p 一起寫進 run card。目前公開 recipe 的部分 LoRA 與 batch 設定和論文 v1 不同，所以「照 README 跑」不等於逐項復刻論文 v1。

Mercury 2.5 放在哪？驗收 API 行為，不把產品跑分當架構證明

Inception 在 2026 年 9 月 8 日發布 Mercury 2.5，官方模型頁列出 260K context、最多 65,536 output Token、tool calling 與 structured outputs。Inception 以「widely-available NVIDIA GPUs」口徑公布 1,107 tokens/s；Uno 論文則使用單張 H200 的固定 1K／8K throughput test，兩者不能直接相除，而且 Uno 論文實際比較的是 Mercury 2，不是 2.5。

Mercury API 最適合教學的一點，是官方 diffusing streaming 能把每個去噪階段的完整中間文字送回來；每個 event 應取代上一版，不是接在後面。準備 API key 後，可用這個最小請求觀察字串如何整塊變化：

curl --no-buffer https://api.inceptionlabs.ai/v1/chat/completions \
  -H "Authorization: Bearer $INCEPTION_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mercury-2.5",
    "messages": [{"role": "user", "content": "Explain speculative decoding in 3 bullets."}],
    "stream": true,
    "diffusing": true,
    "max_completion_tokens": 300
  }'

畫面上的中間版本能幫你理解 diffusion 的可視行為，卻不能證明 Mercury 2.5 內部等同 Uno。若要測工具，依官方 tool-use 文件提供 JSON Schema、開啟 strict mode，執行回傳的 tool call 後再把結果送回；最後評分的是 schema 是否有效、參數是否正確與任務是否完成，不是文字看起來多快。

最常犯的五個判讀錯誤

1. 把多 Token 當成同一技術：完整 diffusion、獨立 drafter、MTP head 與 Uno adapter 由誰定義分布、如何驗證和付出多少成本都不同。
2. 把 lossless 當成零錯誤：它只約束取樣分布，不保證知識正確、工具參數正確或草稿全數接受。
3. 只看單請求 TPS：Tree 可能適合低 batch；Linear 才可能在高 batch 提高系統總量。
4. 把供應商與論文跑分相除：GPU、batch、輸入輸出長度、量化與計數口徑沒有對齊，倍數沒有因果意義。
5. 同時換底模、硬體與 sampler：結果再漂亮，也無法知道收益來自哪一層。

如果你的任務會自動選工具，還要把工具描述與 routing 固定下來；可參考 Agent Skill Routing 評測方法，但把它當另一層實驗，不要混進 sampler 的因果結論。

FAQ：Uno、Ψ-Spec 與 Diffusion-Augmented LLM 常見問題

1. Diffusion-Augmented LLM 就是完整 diffusion LLM 嗎？

不是。Uno 保留 AR 權重定義的 target distribution，只讓 diffusion LoRA 路徑提出區塊草稿；完整 diffusion LLM 則由 diffusion 生成程序本身完成文字。

2. Ψ-Spec 的 lossless 代表每次答案都跟 Qwen3 一樣嗎？

不代表。隨機取樣下，它要保留的是 base AR 的機率分布；單次文字可以不同，正確性也仍受 base model 能力限制。

3. Uno 完全沒有 draft model 成本嗎？

沒有獨立完整 drafter，不等於零成本。它仍載入 diffusion LoRA，並在每輪執行 draft 與 AR verify；收益取決於接受長度能否抵銷這些工作。

4. Block size 越大，Uno 一定越快嗎？

不一定。區塊越長，後段草稿可能更常被拒；Tree 的候選與驗證也會加重運算。要依 batch 與硬體測 TPF、TPS 和記憶體。

5. 能直接說 Uno 比 Mercury 2.5 快嗎？

不能。目前 Uno 論文比較的是 Mercury 2，而且環境與服務設定不同；2.5 應在同任務、同輸入、同計費口徑的 API 賽道重新驗收。

6. Diffusion 會讓 tool call 自動更可靠嗎？

不會自動發生。速度機制不等於工具能力；仍要驗證 schema、名稱、參數、平行呼叫結果與失敗復原。

7. 可以直接在 Apple Silicon Mac 跑官方 Uno recipe 嗎？

官方目前不是這條路徑。README 鎖定 Linux x86_64、CUDA 與 FlashAttention；要照官方堆疊評測，應使用相容 NVIDIA GPU 環境。

8. 新手今天最值得做哪一步？

先畫出「誰 draft、誰 verify、誰定義分布」。再依目標選 Uno 同底模研究或 Mercury API 驗收，避免用一個 TPS 數字回答兩個不同問題。

給新手的 7 個重點

1. Uno 是 diffusion-augmented AR，不是完整 diffusion LLM。
2. Diffusion LoRA 提草稿，凍結 AR 路徑定義並驗證目標分布。
3. Ψ-Spec 的 lossless 是 distribution-preserving，不是固定答案或零錯誤。
4. 每輪有 draft 與 verify 兩次 forward，接受前綴長度決定收益。
5. Linear 偏系統 throughput；Tree 偏低 batch 的單請求 throughput。
6. Uno 同底模機制與 Mercury 2.5 API 產品要分開評測。
7. 任何速度結論都要綁定硬體、batch、長度、精度與 sampler。