為什麼 AI Agent 讓 GPU 需求暴增?以前不會、現在會的兩個原因

真正讓人困惑的其實不是「怎麼裝 GPU」,而是:為什麼現在 GPU 需求爆成這樣,以前不會?答案不在硬體變快,在基底(模型變大)與情境(需求變無限)同時發生。這篇先講清楚需求暴增的根,再用 SVG 拆解「算力到底怎麼被吃掉」、以及 Agent / Ollama / vLLM / GPU 每一層能調的節點。

🧭 一句話心法
需求暴增 = 兩件事相乘:① 模型變大(以前 node 沒那麼多,現在隨便就 B 級參數,單次推論本身就重);② 需求變無限(以前算完給有限服務、人偶爾用;現在 agent 幫你 24/7、無時間限制狂打 API)。人有天花板,agent 沒有。
重點摘要
  • 基底:以前 GPU 主要為了訓練/算出 model、node 少;現在是 B 級模型常駐,單次推論就很重。
  • 情境:以前算完 → 有限服務(人用、有邊界);現在 agent 無限、無時間限制狂打 API。
  • 兩者相乘 → GPU 需求跟以前不是同一個量級
  • 算力怎麼被吃掉:Agent → 推論層(Ollama/vLLM)→ GPU,算力=token 生成(prefill+decode)。
  • 再加一條:微調從一次性變持續性 → GPU 被推論與訓練兩頭吃、互搶同批卡。
  • 三層可調:Agent(模型選型/context)、推論層(量化/批次/KV)、GPU(VRAM/多卡);配合算力可插拔。
🧭 本文導覽
Part 一 — 為什麼需求暴增(基底+情境)
Part 二 — 算力怎麼被存取
Part 三 — 算力路徑
Part 四 — 每層能調什麼
Part 五 — 配合算力・決策・FAQ
Part 一 — 為什麼需求暴增(基底+情境)

以前的 GPU 為什麼不會暴增

倒回去看舊世界:GPU 主要是為了訓練 / 算出一個 model。而且那時的模型 node(參數)沒現在多,單次算力需求有限。更關鍵的是——算完之後是「有限服務」:模型上線後由偶爾去用,有次數、有時間邊界。人會累、會下班,需求自然有天花板。所以舊世界的 GPU 需求是可預期、有上限的。

現在為什麼暴增:B 級模型 × Agent 無限打 API

現在兩件事同時變了,而且是相乘關係:

  • 基底:模型變大 —— 隨便一個模型就是 B(billion)級參數,node 暴增;單次推論要負荷的算力,比以前大好幾個量級。
  • 情境:需求變無限 —— 以前是人用,現在是 agent 幫你用。agent 平行、24/7、無時間限制地狂打 API,一個任務能自己迭代幾十上百次。人有天花板,agent 沒有。
以前:訓練導向,算完給「有限服務」 訓練 Model(小)node 沒那麼多 有限服務 👤 人用:偶爾、有次數 / 有時間邊界 —— 會累、會停 小模型 × 有限次數 → 需求有天花板 現在:B 級模型 × Agent 無限打 API B 級模型常駐 GPU · node 暴增 Agent Agent Agent … 狂打 API 🤖 agent:平行、24/7、無時間限制 —— 不睡、不累、狂迭代 大模型 × 無限併發 → 需求暴增(人有天花板,agent 沒有)

把這兩件相乘:大模型的單次成本 × agent 的無限併發 —— 這就是為什麼 GPU 需求跟以前不是同一個量級。基底(模型)墊高了每一次的成本,情境(agent)把次數推向無限。接下來再看,這些算力具體怎麼被吃掉、又能從哪裡調。

關鍵:舊 ML 是「一次預測」,LLM 是「逐 token 無窮迴圈」

這才是「以前一張卡就夠、現在要一整排卡」的根本 —— 不是模型大而已,是運算的形狀完全變了

舊 ML:預測「一次」 輸入 模型 forward × 1一次算完 一個結果 → 一張卡夠 離散、便宜、做完就停 —— 一張卡服務整個 ML 團隊 LLM:生成「逐 token 無窮迴圈」 輸入 模型 forward動用整個 B 級模型 next token 把 token 接回,再算下一個(自迴歸) 🔁 agent:把整段回答無限重複 一段回答 = 數百~數千次 forward × agent 無限迴圈 → 一整排新卡

舊 ML 的 predict:一次 forward pass 就出結果(一個分類、一個數值、一句回覆)。離散、便宜、做完就停 —— 所以一張卡跑很多次 predict,服務整個 ML 團隊綽綽有餘。

LLM 的 generate:逐個 token、自迴歸。要吐一段話,是一個字一個字生:每產一個 token,都要把整個 B 級模型完整跑一遍(動用全部參數 + 讀整個 KV cache),再把這個 token 接回去、算下一個。一段回答 = 數百到數千次 forward pass,不是一次。

三層相乘,才是暴增的真相
① 大模型(每次 forward 動用 B 級參數)× ② 逐 token 自迴歸(一段回答數百~數千次)× ③ agent 把整段無限重複。舊世界只有「一次 predict」;新世界是「迴圈裡再套迴圈」。所以一張卡撐不住,要一整排新卡

你可能會反問:舊 ML 的 predict 不也要跑完整個模型的 node 嗎?那時怎麼沒爆炸?問得好 —— 差別不在「跑不跑 node」(兩邊都跑),而在三個乘數同時被推到極限:

乘數舊 ML predictLLM + agent
① node 大小(每次多重)小模型(百萬級)→ 便宜B 級參數 → 貴幾個量級
② 每個答案跑幾次1 次(離散,一問一答)數百~數千次(逐 token 自迴歸)
③ 觸發頻率 / 工時人偶爾、有邊界 → GPU 多半閒著agent 24/7 → GPU 幾乎全滿
相乘結果一張卡綽綽有餘一整排卡還不夠
所以不是「跑 node」造成爆炸 —— 是 大 node × 每個答案跑數百次 × 永不停 三者相乘。舊世界三項都小,乘起來還是小(甚至 GPU 多半在閒);新世界三項都頂到天花板,乘起來就爆。

還有一條:微調(調參數)從「一次性」變「持續性」

前面兩節講的是「推論」暴增。但你點出還有一條 —— 「調參數」這個動作本身也變了,而且這是新世界獨有的持續負擔。

舊 ML現在
何時調參數訓練一次 → 上線 → 收工持續微調:LoRA / RLHF / DPO / 對齊 / 每領域或客戶一個 adapter
在多大的模型上調小模型B 級模型 → 單次就吃很多卡
跟推論搶卡?幾乎不搶(推論便宜)搶 —— 兩頭吃同一批 GPU
新世界 GPU 被「兩頭吃」:一頭是無限推論(serving),一頭是持續微調(training),還互搶同一批卡。舊世界是「偶爾訓練一次 + 便宜推論」,兩頭都不重。把這條加進來,暴增的全貌才完整。
Part 二 — 算力怎麼被存取

舊模型:你直接對 GPU 程式

先回顧舊的那套(很多人的直覺仍停在這):你用 CUDA / PyTorch 寫 kernel 或訓練迴圈,把資料餵進去,GPU 把 FLOPS 算完吐結果。你擁有整條 pipeline、同步、你控制;算力好壞看吞吐與利用率。典型是訓練、或固定 batch 的推論。

新模型:Agent → 推論層 → GPU

AI Agent 這套完全不同 —— agent 不直接碰 GPU:

舊:你直接對 GPU 程式 你 / 程式 CUDA / PyTorchkernel / 訓練迴圈 GPU · 你擁有整條 pipeline(資料 → kernel → 輸出) · 算力 = FLOPS / 吞吐;同步、你控制 · 典型:訓練、固定 batch 推論 新:Agent → 推論層 → GPU Agent 推論層Ollama / vLLM GPU tokens 排程 · agent 不碰 GPU,只丟 token 給推論層 · 算力 = token 生成(prefill + decode) · 多請求共享一張卡,推論層排程

agent 只做一件事:把 prompt(一串 token)送給一個推論端點(Ollama / vLLM / 某個 API)。推論層負責 tokenize、批次、KV cache、量化,再把工作排上 GPU,逐 token 生成回傳。多個 agent / 請求共享同一張卡,靠推論層的排程器擠在一起算。模型該選多大,我在〈用甜蜜點階梯找剛好夠用的最小模型〉講過。

Part 三 — 算力路徑

算力路徑一次看懂

把三個節點與各自的旋鈕擺在一起 —— 右下虛框就是「配合的算力」,可插拔:

Agent送 prompt / tokens 推論層Ollama / vLLM批次 · KV cache · 量化 · 排程 GPU 算力VRAM + 運算 ① prompt ② 排上卡 ③ 逐 token 回傳 ① Agent 層能調 · 模型選型(甜蜜點,別動輒 120B) · context / prompt 長度(省 prefill + KV) · prompt 快取、max_tokens、平行工具 ② 推論層能調(Ollama / vLLM) · 量化 Q4 / AWQ / FP8(裝得下) · 批次 max_num_seqs / NUM_PARALLEL · KV / paged attention、prefix cache · num_gpu offload 層數、speculative ③ GPU / 硬體層能調 · VRAM 容量(定模型 + context + batch) · 卡數 / TP 並行 / NVLink · MIG 切片、FP8 / INT8 硬體 配合的算力(可插拔 = 虛框): 本地 GPU 雲端 GPU MIG 切片 多卡 TP

token 生成的兩個階段:prefill vs decode

要會調,先懂 GPU 到底在忙什麼。一次生成分兩階段,瓶頸不同:

階段在做什麼瓶頸影響誰
prefill(讀 prompt)把整段 prompt 一次算進 KV cache算力(compute-bound)、可平行prompt/context 越長越貴
decode(逐字生成)一次吐一個 token,反覆記憶體頻寬 + KV cache 大小輸出越長、batch 越大越吃 VRAM
關鍵直覺:context 長度同時推高 prefill 成本與 KV cache 佔用(VRAM);batch(並發)提升吞吐但吃更多 VRAM。VRAM 是這場的硬天花板 —— 模型權重 + KV cache 都得塞進去。
Part 四 — 每層能調什麼

Agent 層能調什麼

  • 模型選型:別動不動 120B。選「剛好夠用」的最小模型,VRAM、延遲、成本一起降。
  • context / prompt 長度:砍掉沒用的上下文 → prefill 更快、KV cache 更小。
  • prompt 快取:重複前綴重用 KV,省 prefill。
  • max_tokens:限制輸出長度 → decode 更短。
  • 平行 vs 序列工具呼叫:能平行就平行,但注意會同時佔更多並發。

推論層(Ollama / vLLM)能調什麼

這是你旋鈕最多的一層。兩個代表:

旋鈕OllamavLLM
量化(裝得下)GGUF `Q4_K_M`/`Q5`/`Q8`AWQ / GPTQ / FP8
context 上限`num_ctx``–max-model-len`
並發 / 批次`OLLAMA_NUM_PARALLEL``–max-num-seqs`(continuous batching)
VRAM 用量`num_gpu`(offload 層數)`–gpu-memory-utilization`
KV cachellama.cpp KVPagedAttention(分頁省記憶體)
共同前綴重用(較有限)`–enable-prefix-caching`
多卡較弱`–tensor-parallel-size`
加速speculative decoding / chunked prefill
最常見的雷:num_gpu / offload。VRAM 不夠時,Ollama 會把部分層 offload 到 CPU/RAM —— 模型「跑得動」但慢好幾倍。看到明明有 GPU 卻很慢,先查是不是層沒全上 GPU。

GPU / 硬體層能調什麼

  • VRAM 容量:最硬的天花板 —— 決定模型多大、context 多長、batch 多寬。
  • 卡數 + tensor parallel:單卡裝不下就切模型跨多卡(需 NVLink 才不被互連拖死)。
  • MIG 切片:A100/H100 可切成多個小 GPU 實例,給多個輕量服務。
  • FP8 / INT8 硬體:新卡原生支援低精度,量化才跑得快。
Part 五 — 配合算力・決策・FAQ

配合的算力:可插拔(所以畫成虛框)

前面路徑圖右下那個虛框就是重點:推論層把 GPU 當一個可替換的算力後端。同一套 agent + 推論層設定,底下的算力可以隨需求換:

算力來源適合代價
本地 GPU資料不出門、延遲低、可控要自己買卡、VRAM 有限
雲端 GPU彈性、要多少開多少成本、資料出門
MIG 切片一張大卡分給多個輕服務單片算力上限低
多卡 TP裝大模型 / 高吞吐要 NVLink、複雜度高

畫成虛框是因為:它不是綁死的。你先把 Agent 層與推論層調對,算力那塊再依預算/資料政策插上去。

決策樹:算力不夠時,先調哪裡

① 裝不下 / OOM?
量化(Q4/AWQ) · 換小模型(甜蜜點) · 降 context
② 單次太慢(latency)?
降 prompt/context · prompt/prefix 快取 · 確認層全上 GPU · speculative
③ 多請求吞吐不夠?
continuous batching · 調高 max_num_seqs · 加卡 TP
④ 上面都調到頂還不夠?
換更大 VRAM / 多卡 / 雲端(虛框那塊)

常見問題 FAQ

AI Agent 是直接呼叫 GPU 嗎?

不是。Agent 把 prompt(tokens)送給推論層(Ollama/vLLM/API),由推論層排程上 GPU。Agent 端看到的是一個推論端點,不是 GPU。

跟以前用 GPU 訓練/跑 batch 差在哪?

舊模型你直接寫 CUDA/訓練迴圈、擁有整條 pipeline,算力=FLOPS;新模型多了一層推論引擎,算力=token 生成(prefill+decode),多請求共享一張卡由引擎排程。

為什麼有 GPU 還是很慢?

最常見是模型層沒全上 GPU(VRAM 不夠被 offload 到 CPU),或 context 太長把 prefill+KV 撐爆。先查 offload 與 context。

該先花錢加卡,還是先調參數?

先調。多數情況「量化 + 選對模型 + 砍 context + 開 batch」就解決了;加卡(虛框那塊)是調到頂還不夠才上。

留言

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *