AI-LECTURER 速報課|2026-08-30|約 28 分鐘

vLLM v0.28.0:一次省下17GiB顯存、拉快60%回應的推論引擎升級課

取材:vLLM v0.28.0(Hacker News(AI 高人氣))
📍 真實場景
阿凱,新創公司後端工程師,負責維護公司自架的內部 AI 客服機器人(用開源模型跑在公司自己買的 GPU 伺服器上)

這陣子使用人數暴增,客服機器人同時要應付幾十個對話視窗,阿凱每天緊盯監控面板,深怕又爆掉

😖 卡住的地方:GPU 記憶體常常被塞滿到系統直接拒絕新對話,尖峰時段回應也越來越慢,老闆已經在問「是不是又要多買一張GPU」,但預算已經卡緊了
💡 這篇帶你看懂 vLLM(一款開源 LLM 推論加速引擎)v0.28.0 這次到底改了什麼,讓同一批 GPU 能省下更多記憶體、回應也變快,還有這些設計背後工程師在權衡什麼

🧭 這到底是什麼(白話版)

你可以把 vLLM一套幫忙「跑」大型語言模型(LLM)服務的開源引擎,負責把使用者的問題丟進模型、算出回答、再把結果送回來的整套後勤系統 想成一間 AI 問答餐廳的內場管理系統——不是煮菜的主廚(那是模型本身),而是負責排菜單、控制爐火、管理食材庫存,讓同時湧進來的上百張訂單都能被有效率地出餐。這次的 v0.28.0,就是內場管理系統的一次大改版:584 個 commit、270 人參與,幾乎每個環節都被重新優化過。

這次改版火力全開在兩款最新熱門模型上:Kimi-K3 和 DeepSeek V4,這兩款都是 MoE 混合專家模型一種模型設計方式,把一個大模型拆成很多個「專家」小模型,每次回答問題只挑幾個相關的專家出來動腦,而不是整個大模型全部啟動,藉此省下大量運算 架構。針對這種架構,vLLM 做了「共享專家分片」優化——把所有 GPU 都要用到的共用部分不再每張卡各存一份,省下約 17GiB 的 顯存 VRAM顯示卡裡專門拿來存放模型與運算資料的高速記憶體,是自架 LLM 服務最貴、最緊繃的資源,爆滿時服務就會變慢甚至直接當機

另一個重點是 推測解碼 Speculative Decoding讓一個小的、很快的「草稿模型」先大膽猜幾個字,再讓真正的大模型一次驗證這一批猜測,猜對就直接採用,省下大模型自己一個字一個字慢慢生成的時間。新版讓這個猜測更聰明:依照即時的信心分數動態調整「一次要猜幾個字」,官方數字是讓 DSpark 模式的 TTFTTime To First Token 的縮寫,指使用者送出問題後,回應的第一個字要花多久才跳出來,是使用者感受「這系統快不快」最直接的指標 進步了大約 60%。

最後是 KV Cache模型生成每一個字時,都會把之前算過的中間結果記下來方便重複利用,這份記憶會隨著對話越聊越長而越滾越大,是 LLM 服務裡最吃顯存的部分。這次新版加入「分層卸載」:顯存放不下時,自動把不常用的 KV Cache 搬到 CPU 記憶體、甚至硬碟,讓系統能撐住更多、更長的對話,而不是直接拒絕新的請求或當機。這幾招合起來,剛好對上阿凱每天在煩惱的「記憶體爆滿」和「回應變慢」。

🎯 為什麼值得你花時間

同一張顯卡撐更多人記憶體省下來(像共享專家分片省 17GiB/GPU)代表同樣硬體可以同時服務更多使用者、或塞下更大的模型,對自架服務的團隊來說,這直接就是不用加購昂貴 GPU 的錢。
使用者體感的等待變短推測解碼加上動態調整,讓 DSpark 這類模型的 TTFT(第一個字要多久出現)進步約 60%,對使用者來說「感覺變快」往往比「平均速度變快」更重要,這決定了他們會不會覺得這個客服機器人好用。
這是基礎設施的深水區優化,不是噱頭一次改版 584 個 commit、270 人參與,砸的是 kernel 層級的融合、分散式並行架構,說明 LLM 服務的競爭已經進入「誰的推論引擎更省成本」的工程硬仗,不是單純比模型參數量大小的表面戰爭。

⚙️ 它是怎麼運作的

1
請求進站排隊多個使用者同時發問時,vLLM 先把請求放進佇列,依照可用資源動態組成一批(batch)一起處理,讓 GPU 閒置的時間降到最少。
2
檢查有沒有算過的東西如果新請求開頭跟之前處理過的一模一樣(像是同一份系統提示詞),直接拿快取結果用,不用重新算一次,v0.28 對 Mamba 架構模型預設打開這個「前綴快取」功能。
3
用推測解碼加速生成小的草稿模型先快速猜幾個字,大模型一次驗證整批;對 DeepSeek V4 這類支援 MTP/DSpark 的模型,新版還會依信心分數動態調整一次要猜多少字。
4
KV Cache 不夠放就分層搬家每個字生成時留下的暫存記憶(KV Cache)越積越多,GPU 顯存放不下時,新版能自動搬到 CPU 記憶體甚至硬碟,搬家順序依照使用頻率決定。
5
串流回傳給使用者產生的字一邊算一邊送回前端,使用者不用等整段話算完才看到第一個字,這就是 TTFT(第一個字回應時間)在意的地方。
v0.28.0 相對於前一版的幾個關鍵數字
改進項目改進前v0.28.0 效果
同時處理的 token 上限(max_num_batched_tokens)819216384(預設值直接翻倍,能同時塞更多請求)
Kimi-K3 all-gather 通訊優化kernel 層級快 1.5~3 倍
DSpark 推測解碼 TTFT約進步 60%(自適應猜測預算)
MoE 共享專家記憶體每張 GPU 各存一份分片後每張 GPU 省約 17GiB
Blackwell 架構 CUDA 圖形擷取上限5121024

🛠️ 動手做:自己動手算:GPU 記憶體省了多少、推測解碼加速多少

這是一個真實小專案:下載(或複製)檔案,照步驟在你電腦上跑起來。

📄 speculative_decoding_sim.py ⬇ 下載
'''
模擬 vLLM 新版「推測解碼」加速效果的迷你範例。
不需要 GPU、不需要安裝 vLLM,用純 Python 模擬概念,
讓你直觀感受官方說的「TTFT 快 60%」是怎麼算出來的。
'''

import random

NUM_TOKENS_TO_GENERATE = 50      # 假設要產生 50 個 token 的回覆
BASE_TOKEN_TIME_MS = 40          # 傳統做法:大模型自己一個一個吐字,每個字 40ms
DRAFT_TOKEN_TIME_MS = 8          # 推測解碼:小的「草稿模型」先猜,每個字只要 8ms
VERIFY_BATCH_TIME_MS = 45        # 大模型一次驗證一批猜測,驗證一批要 45ms
DRAFT_BATCH_SIZE = 4             # 草稿模型一次猜 4 個字
ACCEPT_PROBABILITY = 0.7         # 草稿猜對的機率(vLLM 用信心分數動態調整,這裡簡化成固定值)


def baseline_generate(num_tokens):
    return num_tokens * BASE_TOKEN_TIME_MS


def speculative_generate(num_tokens):
    total_time = 0.0
    tokens_done = 0
    random.seed(42)

    while tokens_done < num_tokens:
        batch = min(DRAFT_BATCH_SIZE, num_tokens - tokens_done)

        total_time += batch * DRAFT_TOKEN_TIME_MS
        total_time += VERIFY_BATCH_TIME_MS

        accepted = sum(1 for _ in range(batch) if random.random() < ACCEPT_PROBABILITY)
        if accepted == 0:
            accepted = 1

        tokens_done += accepted

    return total_time


def main():
    baseline_ms = baseline_generate(NUM_TOKENS_TO_GENERATE)
    speculative_ms = speculative_generate(NUM_TOKENS_TO_GENERATE)
    speedup_percent = (baseline_ms - speculative_ms) / baseline_ms * 100

    print('傳統逐字生成:{:.0f} 毫秒'.format(baseline_ms))
    print('推測解碼生成:{:.0f} 毫秒'.format(speculative_ms))
    print('省下的時間:{:.1f}%'.format(speedup_percent))
    print()
    print('提示:把 ACCEPT_PROBABILITY 調低(例如 0.3),')
    print('看看猜測命中率下降時,加速效果會怎麼消失甚至反而變慢。')


if __name__ == '__main__':
    main()
📄 memory_savings_calculator.py ⬇ 下載
'''
用官方公告的數字,換算「共享專家分片」能幫你的 GPU 叢集省下多少記憶體。
'''

SAVING_PER_GPU_GIB = 17  # 官方數字:每張 GPU 省約 17 GiB


def calc_total_savings(num_gpus, gpu_memory_gib):
    total_saved = SAVING_PER_GPU_GIB * num_gpus
    total_capacity = gpu_memory_gib * num_gpus
    percent = total_saved / total_capacity * 100

    print('叢集規模:{} 張 GPU(每張 {} GiB)'.format(num_gpus, gpu_memory_gib))
    print('省下的記憶體:{} GiB'.format(total_saved))
    print('相當於整個叢集多出 {:.1f}% 的可用空間'.format(percent))
    print('換算:多出來的空間大約可以多撐 {} 張 GPU 的量'.format(total_saved // gpu_memory_gib))


if __name__ == '__main__':
    calc_total_savings(num_gpus=8, gpu_memory_gib=80)
  1. 在「開始功能表」搜尋「PowerShell」並打開(不需要系統管理員權限)
  2. 確認電腦已安裝 Python(在 PowerShell 輸入 python --version,若沒反應可到官網下載安裝,全程使用預設選項即可)
  3. 新增一個資料夾(例如 D:\vllm_demo),把 speculative_decoding_sim.py 和 memory_savings_calculator.py 存進去
  4. 在 PowerShell 輸入 cd D:\vllm_demo 切換到該資料夾
  5. 輸入 python speculative_decoding_sim.py 執行,觀察「傳統逐字生成」和「推測解碼生成」的耗時差異
  6. 用記事本打開 speculative_decoding_sim.py,把 ACCEPT_PROBABILITY 改成 0.3 存檔後重新執行,比較猜測命中率下降時加速效果怎麼變化
  7. 輸入 python memory_savings_calculator.py 執行,看看 8 張 80GiB GPU 的叢集用共享專家分片能多出多少可用空間

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

🔭 為什麼 vLLM 要為 Kimi-K3、DeepSeek V4 這兩款特定模型砸大量心力客製化優化(專屬融合 kernel、專屬並行策略),而不是做一套放諸四海皆準的通用優化就好?
通用優化的好處是維護成本低、什麼模型都能吃到一點好處,但天花板也低——因為每個模型的架構(像 MoE 路由方式、注意力機制的稀疏程度)都不一樣,通用寫法沒辦法針對特定的計算模式做極限壓榨。vLLM 選擇替熱門模型開專屬優化路徑,是用維護成本換效能上限的典型取捨:社群夠大、這兩款模型夠熱門,值得花工程資源客製化;冷門模型就只能吃通用優化的基本盤。這也是為什麼開源專案的更新日誌常常是「針對 XX 模型的 OOO 優化」,而不是無差別的全面提升。
🔭 KV Cache 的分層卸載(GPU→CPU→硬碟)聽起來就是「變慢」,為什麼 vLLM 還要做這個功能?
這是典型的記憶體階層取捨:GPU 顯存最快但最貴、最有限;CPU 記憶體慢一點但便宜很多、量體大很多;硬碟更慢但幾乎沒有容量上限。如果沒有分層卸載,一旦 GPU 顯存塞滿,新的請求就只能被拒絕或排隊排到天荒地老。分層卸載是用「部分請求多一點延遲」換取「整體系統撐得住更多同時上線的對話」,特別是那些對話很長、不常被存取的舊上下文,搬到慢一點的儲存很划算——這跟把不常用的檔案丟到雲端硬碟、只留常用檔案在 SSD 上是一樣的道理。
🔭 推測解碼的自適應 token 預算是在解決什麼問題?為什麼不乾脆固定猜 10 個字就好?
固定猜的字數是一個賭局:猜太少,加速效果不明顯;猜太多,一旦大模型判斷猜錯,白白浪費的運算量反而拖慢速度。不同的請求、不同時間點,草稿模型的「猜中率」其實是浮動的,問題難度、上下文複雜度都會影響。自適應預算的做法,是讓系統即時看信心分數,猜得準就放膽多猜幾個字,猜不準就縮手,這是一個「用即時訊號動態調整積極度」的控制迴路設計,而不是死板地套用同一組參數打天下——這跟資深工程師常講的「別用同一個 timeout 值打遍全世界的 API」是同一種思維。
🔭 這次 release 把 bitsandbytes(一種模型量化工具)的支援移出核心變成外掛,這代表什麼樣的架構決定?
核心團隊維護的東西越多,每次改版要測試、要保證相容的範圍就越大,發布速度也會被拖慢。把非核心但仍有人用的功能(像特定的量化後端)切成外掛,是「縮小核心邊界、把選配功能交給外部維護」的常見架構策略——類似瀏覽器把非必要功能做成擴充套件、而不是全部塞進主程式。代價是使用這個功能的人要多裝一個套件、多一層版本相容的風險,但換來的是核心程式碼可以更快、更穩地往前走。

📝 隨堂考(點選答案,立即回饋)

Q1. 推測解碼(speculative decoding)加速的原理最接近下列哪一個?
✅ 推測解碼的核心是「小模型猜、大模型驗」,猜對就省下大模型逐字生成的時間,跟硬體升級或縮減內容無關。
Q2. 文中提到「共享專家分片」省下約 17GiB/GPU,這是靠什麼省下記憶體的?
✅ 共享專家分片針對的是 MoE 架構裡「共用元件」的重複存放問題,跟精度壓縮(量化)是不同的省記憶體手法。
Q3. KV Cache 的「分層卸載」代表了什麼樣的取捨?
✅ 把不常用的 KV Cache 搬到較慢的儲存裝置,本質上是用一點存取延遲,換取系統能同時撐住更多、更長的對話。
Q4. TTFT 指的是什麼?
✅ TTFT 量的是「第一個字」出現的等待時間,反映使用者感受到的即時性,不是整體生成時間或資料量。
Q5. vLLM 把 bitsandbytes 移到核心外變成「外掛」,最主要的用意是什麼?
✅ 這是常見的架構縮邊界策略:把非核心但仍有人用的功能切出去,降低核心的維護與相容性負擔。

🃏 翻牌記憶卡(先想答案,再點開對答)

TTFT點我翻面
Time To First Token:使用者發問後,第一個字跳出來要等多久,是使用者體感延遲最重要的指標之一
推測解碼(Speculative Decoding)點我翻面
先讓一個小的草稿模型快速猜幾個字,再由大模型一次驗證整批,猜對就省下大模型逐字生成的時間
KV Cache點我翻面
模型生成每個字時,拿來記住「之前算過的東西」的暫存資料,對話越長它就越大,是 LLM 服務最吃記憶體的部分
分層卸載(Tiered Offloading)點我翻面
GPU 記憶體不夠放的 KV Cache,依使用頻率搬到 CPU 記憶體、甚至硬碟,用一點延遲換取能撐更多使用者
共享專家分片(Shared-Expert Sharding)點我翻面
MoE 模型裡所有 GPU 都要共用的「共享專家」部分,不必每張卡都重複存一份,可省下大量顯卡記憶體
前綴快取(Prefix Caching)點我翻面
如果新請求開頭跟之前處理過的一樣,直接複用算過的結果,不用重新計算,vLLM v0.28 對 Mamba 類模型預設開啟

✅ 離開前自測(全勾=這課真的學會了)

0%