這支影片在講：Speculative Decoding 不是免費的推論加速器
小 draft model 先猜 token、目標模型再一次驗證，能縮短 decode 階段；但是否變快，取決於猜中率、額外模型與 KV cache 的顯存成本，以及工作負載的 context、batch 與輸出型態。
decode 是逐 token 等待
Prefill 可平行處理 prompt；生成階段卻逐 token 往前，這正是 draft model 想縮短的瓶頸。
猜得多不等於快
Draft 提案必須被 target 接受。創意續寫的預測分歧大，低接受率會讓額外計算與記憶體失去意義。
用 workload 做開關
以 acceptance rate、VRAM headroom、context length 與 concurrency 判斷；不要把單一 benchmark 當預設策略。
影片裡最該帶走的四個訊號
三個決定「值不值得」的取捨
先分清 prefill 與 decode
Speculative decoding 主要改善逐 token 的 decode，不會自動解決長 prompt 的 prefill 成本。若延遲瓶頸在讀取很長的 context，應先量測 prefill、KV cache 與 batching。
draft model 的相容性比「小」更重要
它既要便宜，又要足夠會猜；shared tokenizer 可降低對齊複雜度。挑選時同看大小、成本、預測品質與 target 的相容性，而非只挑最小模型。
acceptance rate 是營運指標
結構化輸出常有較穩定的 token 序列，因此容易高接受；創意寫作則更容易分歧。把不同 prompt 類別的接受率記錄進 serving telemetry，才能避免整體平均掩蓋差異。
把它當成有門檻的 serving 策略
輸出 schema 固定、提取／分類／JSON 生成等規律任務；短 context、小 batch、GPU 還有足夠 VRAM；經量測 acceptance rate 穩定偏高。
開放式創作、接受率低；長 context 讓 prefill 成主因；或高 concurrency 已讓顯存與 queue 成為限制。先投資 batching、cache 或模型／prompt 路徑。
按 workload 分群比較 end-to-end latency、tokens/s、acceptance rate、GPU memory 與成本；別只拿單一 prompt 的 token throughput 下結論。
先以可回退的 feature flag 在最規律的流量切一小段；持續觀察接受率與 P95 latency，讓不匹配的工作負載自動回到一般 decode。