邊緣端做投機解碼，何時才划算

投機解碼（speculative decoding，SD）這兩年是 LLM 推論加速最乾淨的一招：用一個便宜的小草稿模型一口氣猜出 γ 個 token，再讓大的目標模型一次驗證這幾個，猜對的就免費省下，猜錯的退回重來。當草稿與目標放在同一台機器時，效果很實在。Yuan Lyu、Bharath Irukulapati、Jaya Prakash Champati 這篇投到 arXiv 的論文，標題就把問題擺明了：「Speculation at a Distance: Where Edge-Cloud Speculative Decoding Actually Pays Off」。它要解的是一道反直覺的謎題：把草稿模型搬到邊緣裝置、目標模型留在雲端的這個分散式變體（論文叫 DSD），照理說也該享受到 SD 的加速，為什麼實際上單請求延遲常常不划算，甚至比雲端直接解碼還慢？這篇文章會跟著論文的調查脈絡，把你大概也會想到的幾個「它應該有用」的理由逐一拿出來檢驗，看著它們一個個在 WAN 的來回延遲面前縮水，最後落在一個論文自己也承認的、唯一站得住腳的使用情境上。

謎題：同樣的投機解碼，搬到邊緣就不靈了

先把加速的來源講清楚，才看得懂它為什麼會在跨網路時蒸發。共置（co-located）的 SD 之所以快，是因為驗證一批 γ 個草稿 token 的成本，遠低於目標模型逐個自迴歸生成這 γ 個 token；草稿生成本身又很便宜。論文把共置 SD 的加速幅度寫得很具體：「Speculative decoding (SD) accelerates LLM inference by 1.5-3 times when the draft and target models are co-located」——一點五到三倍，前提是兩個模型住在一起。整套機制裡，草稿模型送給目標模型的，是幾個 token id；目標模型回給草稿模型的，是一個「接受到第幾個」的訊號。在同一塊矽上，這個來回幾乎不要錢。

把草稿模型搬到邊緣、目標模型留在雲端，DSD 的算盤是：邊緣裝置自己跑草稿，省下雲端的草稿算力，還能就近服務使用者。問題是，原本那個「幾乎不要錢」的來回，現在變成一趟跨越廣域網路（WAN）的往返。每生成一輪草稿，邊緣得把草稿 token 送上雲端、等目標模型驗證、再把接受訊號收回來——這一趟 RTT，論文用封閉解的不等式說明它會把 SD 省下的時間吃掉：「We show with closed-form inequalities that DSD's per-request latency benefit is limited under WAN edge-cloud communication」。注意這裡的措辭是 limited（受限），不是消失；論文接下來要做的，正是把這個「受限」的邊界精確地畫出來——哪一段參數空間裡 DSD 還划算，哪一段裡它必輸。用封閉解不等式來框這件事的好處是，它不必依賴某一組實測數字，而是把延遲的好壞直接寫成接受率、草稿長度、RTT 三者之間的一條代數關係：等號的那一側就是 DSD 與對照基準打平的臨界面，不等號往哪邊倒，就決定你落在划算還是失效的那一半。換句話說，論文不是給你一個「DSD 快或慢」的結論，而是給你一道可以代入自己參數去判讀的條件式。下面這個 widget 讓你親手把這條邊界拉出來。

drag acceptance rate, draft length, and RTT to watch DSD cross above and below the two baselines · 3 sliders

接受率 α = 0.70

草稿長度 γ = 4

RTT（毫秒）= 40 ms

拖一下你就會看到那道反直覺的事實：把 RTT 拉到四十毫秒、接受率壓到 0.5 上下，橙色的 DSD 線會浮到藍色虛線（雲端自迴歸）之上——也就是說，這時候在邊緣做投機解碼，比雲端什麼花招都不耍、一個 token 一個 token 老實生成，還要慢。原因很單純：每一輪投機都先付一趟跨網路往返，而接受率一低，這趟往返換回來的有效 token 數就不夠抵這個固定成本。綠色的共置 SD 線之所以總在下面，正因為它根本不付那趟 RTT。論文整篇的調查，就是要把「DSD 浮到哪條線之上、沉到哪條線之下」這件事，從直覺變成可以算的不等式。

假設一：那就把草稿放雲端、和目標放一起不就好了

面對 DSD 的延遲劣勢，第一個會冒出來的念頭是：既然問題出在草稿與目標隔著一張 WAN，那把草稿也搬回雲端、和目標共置，不就回到那個一點五到三倍的好日子了嗎？論文對這個念頭的回答很直接，而且把帳算得很細：「If the server can host both models, co-located SD has lower latency and communication than synchronous DSD, with the same per-output FLOPs and model-weight memory」。逐句拆開來看，這句話的殺傷力在於它堵死了 DSD 在共置情境下的所有藉口。延遲，共置更低（不付 RTT）；通訊量，共置更低（不必把 token 推上 WAN）；而代價那一側——每個輸出 token 的浮點運算量、模型權重佔的記憶體——兩者一模一樣。

這就把「假設一」翻過來了：如果你的伺服器本來就放得下兩個模型，那根本沒有 DSD 的位置——共置 SD 在每一個你在乎的維度上都不輸、還更省。換句話說，DSD 不是共置 SD 的升級版，它是一個只有在「伺服器放不下草稿模型，或你刻意要把草稿算力推到邊緣」這個前提下才需要考慮的方案。論文用的詞是 synchronous DSD（同步 DSD），意思是邊緣每送一輪草稿就停下來等雲端的驗證結果回來才繼續。同步的代價就是那趟 RTT 變成串在關鍵路徑上、躲不掉的等待。那能不能不要同步等待？這就帶出下一個假設。

假設二：用 pipelining 把 RTT 藏起來

同步的問題既然是「送出去就停下來等」，那自然的解法是 pipelining：別等驗證結果回來，邊緣一邊等回應、一邊先樂觀地往下猜下一輪草稿，把網路往返的時間和本地草稿的時間重疊起來。論文有一整節在談這件事，標題就帶著保留：「What Pipelining Changes (And What It Doesn't)」——它改變了什麼，以及它沒能改變什麼。結論是 pipelining 確實有用，但用得有條件：「Pipelining can make DSD competitive with co-located SD only in low-RTT regimes where the round trip is shorter than the edge drafting time window」。

這句話裡藏著整個調查的關鍵門檻。pipelining 要能把 RTT 藏起來，前提是這趟往返的時間「短於邊緣草稿的時間窗」——也就是說，趁等回應的這段空檔，邊緣得有足夠的草稿工作可做來把它填滿。當 RTT 比這個草稿時間窗還短（low-RTT regime，低 RTT 區），重疊得起來，DSD 才追得上共置 SD。但論文緊接著把另一半講死：「at WAN RTTs, the cloud round trip remains too large for pipelined DSD to beat co-located SD」。在真實的廣域網路 RTT 下，那趟雲端往返大到藏不住——草稿時間窗根本填不滿它，超出的部分還是赤裸裸地串在關鍵路徑上。所以 pipelining 不是萬靈丹，它只是把「DSD 划算」的條件從「RTT 為零」放寬到「RTT 短於草稿時間窗」，而 WAN 的現實往往跨不過這道門檻。合理的推測是，這也說明了為什麼論文要把這一節的標題寫成「它改變了什麼、又沒改變什麼」：改變的是門檻的位置，從要求零往返放寬到要求往返短於草稿窗；沒改變的是，只要 RTT 大過那個窗，多出來的那一段就回到同步 DSD 的老樣子，赤裸裸地累加在每一輪的關鍵路徑上，pipelining 對它一點辦法也沒有。

把這個門檻翻成工程語言：你的邊緣草稿模型每輪要忙多久（取決於 γ 和草稿模型大小），決定了你能藏住多大的 RTT。草稿時間窗越長（γ 越大、草稿模型越重），能容忍的 RTT 越高；但 γ 拉大又會壓低接受率，這裡有一個你在第一個 widget 裡已經拖出來過的取捨。下面這幾個術語是論文反覆用到的，先用滑鼠停在上面把它們的精確意思釘住，後面的論證才不會糊掉。

hover or focus any dotted term to read its precise meaning · 4 terms

DSD 的整套算盤掛在四個量上：acceptance rate（接受率）決定一輪猜 γ 個 token 平均能被收下幾個；draft length γ（草稿長度）決定一輪猜多少、也決定drafting time window（草稿時間窗）有多寬，能藏住多大的往返；而WAN RTT就是那趟必須被藏住、否則就串在關鍵路徑上的雲端往返。四個量怎麼擺，決定 DSD 落在划算還是失效的那一邊。 小草稿模型對大目標模型的猜測被接受的比率。接受率越高，一輪投機收回的有效 token 越多，固定的網路往返成本就越攤得回來；接受率低時，猜錯整批退回，那趟 RTT 白付。 一輪投機一次猜出的 token 數。拉大 γ 能攤薄每輪的固定成本（含 RTT），但靠後的草稿 token 越來越可能被拒，邊際接受率遞減，所以 γ 不是越大越好。 邊緣端跑完一輪草稿所需的時間。pipelining 只能在這段時間裡藏住網路往返；論文的門檻是「the round trip is shorter than the edge drafting time window」——RTT 短於這個窗，才重疊得起來。 草稿模型（邊緣）與目標模型（雲端）之間一趟跨廣域網路的往返時間。論文反覆強調，at WAN RTTs，這趟往返大到 pipelining 也藏不住。

假設三：就算追不上共置 SD，至少贏過雲端自迴歸吧

退一步說：很多場景裡你根本沒有「共置」這個選項——目標模型在別人的雲上，你能掌控的只有邊緣。那拿 DSD 去比的對手就不是共置 SD，而是「雲端老老實實做自迴歸解碼」。這時候 DSD 至少該贏吧？畢竟它有投機，對方沒有。論文的回答還是把範圍框得很緊：「Against cloud autoregressive decoding, DSD can reduce latency only inside a bounded window given the target-model speed, acceptance rate, and RTT」。能降延遲，但只在一個被三個量——目標模型速度、接受率、RTT——夾出來的有界窗口（bounded window）之內。

這正是第一個 widget 想讓你親手感受的事。把 RTT 推高、把接受率壓低，橙色 DSD 線就會浮到藍色虛線（雲端自迴歸）之上：你以為投機一定比不投機快，但跨網路的往返成本，在接受率不夠、RTT 不夠低的時候，會把投機省下的全部吃光，甚至倒貼。所以「至少贏過雲端自迴歸」這個底線假設也站不穩——它只在那個有界窗口裡成立，窗口之外，邊緣投機是負優化。論文還補了一刀，把另一個現實場景直接判出局：「DSD is also infeasible against closed-source APIs without a verifier-only interface」。如果目標模型是閉源 API，而供應商沒有開放「只做驗證」的介面（讓你把草稿 token 丟進去、只拿回接受到第幾個），那 DSD 連跑都跑不起來——它在架構上就需要對方暴露一個驗證入口，而商用 API 幾乎沒有。

到這裡，三個「DSD 應該有用」的理由全被論文逐一收窄：共置情境下它不如直接共置 SD；pipelining 只在低 RTT 區救得了它；當對手是雲端自迴歸，它只在一個窄窗口裡贏，遇到閉源 API 還直接不可行。論文那一節的標題下得很重，把整個立場濃縮成一句——「Position: The Gain Window Is Narrow」，划算的那扇窗，很窄。那問題就剩下：這扇窄窗到底開在哪？

解答：別盯著單請求延遲，去看多租戶吞吐

論文的轉折，是把評判 DSD 的尺規整個換掉。前面所有的失望，都來自用「單請求延遲」去衡量 DSD——而這恰恰是它最弱的維度。真正讓 DSD 站得住的，是另一個量：多租戶容量（multi-tenant capacity）。論文寫得很明白：「The main case for DSD appears in multi-tenant capacity」。把草稿算力分擔到邊緣，省下的不是某一個使用者的延遲，而是雲端伺服器的算力——而省下的算力可以拿去服務更多並行的使用者。

這就接到全篇唯一一條有名字的公式。當很多客戶端的請求在雲端重疊（cross-client overlap），把草稿計算卸到各自的邊緣後，一台已經吃滿的雲端伺服器能多扛多少並行客戶：「offloading draft compute lets a saturated cloud server sustain (1 + γ t_d/t_v) times more concurrent clients at the same per-client rate, where γ is the speculation length and t_d, t_v are the per-step draft and verification times」。一加上 γ 乘以「每步草稿時間 t_d 除以每步驗證時間 t_v」這麼多倍的並行客戶——而且是在維持每個客戶相同生成速率的前提下。直覺很清楚：原本雲端要自己包辦草稿和驗證兩件事，現在草稿被推到邊緣，雲端只剩驗證，省下的就是 γ 個草稿步乘上每步草稿成本相對於驗證成本的比值。這裡有個轉折——同一個 t_d/t_v 在這裡扮演的角色，和它在單請求延遲那邊恰好相反：在延遲帳上，草稿越便宜（t_d/t_v 越小）越好，因為等草稿的時間越短；但在容量帳上，正是這個比值決定了把草稿分擔出去能替雲端騰出多少算力，草稿在雲端本來吃得越重，挪到邊緣後騰出的並行空間就越大。這也是為什麼公式裡的倍率是「一加上」一項，而不是憑空翻倍——它替雲端省下的，恰恰是它原本花在草稿那 γ 步上的相對開銷。下面這個 widget 把這個容量倍率畫出來。

這條線解釋了為什麼論文要把整個結論的重心搬走。看單請求延遲，DSD 在 WAN 下幾乎全盤皆輸；但看多租戶容量，同一個「邊緣負責草稿、雲端只負責驗證」的拆法，反而讓雲端在不增加每客戶延遲的前提下多服務出 (1 + γ t_d/t_v) 倍的並行客戶。論文的最後判斷因此非常明確：「DSD should therefore be evaluated primarily by multi-tenant capacity and server throughput, not only by single-request latency」——評判 DSD 該主要看多租戶容量與伺服器吞吐，而不只是看單請求延遲。這句話既是解答，也是對前面所有失望的重新框定：那些延遲上的劣勢不是 bug，而是因為我們一直拿錯尺在量它。

這個容量增益還有一個成立條件，論文用的詞是 cross-client overlap（跨客戶端重疊）。它的意思是：只有當很多客戶端的請求在雲端時間上重疊、把伺服器逼到飽和（saturated）時，把草稿算力挪走才換得到實際的並行容量。如果你的雲端伺服器本來就閒著，省下的草稿算力沒有別的請求來填，這個倍率就只是紙上的數字。換句話說，DSD 的真正甜蜜點，是一個被很多邊緣裝置同時打的、吃滿的雲端推論服務——而不是某一個追求最低延遲的單一請求。

Take-away：下次有人提議把草稿模型推到邊緣來加速 LLM，先別問「能省多少延遲」，問「你的雲端伺服器有沒有被多客戶端打到飽和」——前者在 WAN RTT 下幾乎注定讓你失望，後者才是 (1 + γ t_d/t_v) 那個倍率真正兌現的地方。