Inference 是什麼:訓練之後,AI 真正開始工作

你在 ChatGPT 打一句話，按下送出，幾秒後答案一個字一個字出現。

那幾秒鐘發生的事，不是「模型正在學習」。模型沒有因為你這次提問就重新訓練。它是在做 inference。

Inference(推論)是已訓練模型接收新輸入，並產生預測、分類、文字、圖片或其他輸出的執行階段。Training 是把模型做出來;inference 是把模型拿來用。

理解 inference 很重要，因為 AI 產品真正上線後，使用者感受到的速度、穩定性、成本，多半都卡在這裡。

一句話定義

Inference 可以翻成「推論」，但不要把它想成哲學上的推理。它更接近工程上的「執行一次模型」。

你把資料丟進已訓練好的模型，模型根據它學到的參數，算出一個輸出。

輸入	模型輸出
一封 email	spam / not spam
一張商品照片	可能的分類標籤
一段客服對話	摘要與下一步建議
一句 prompt	一段文字回答
一份病歷影像	風險分數或候選判讀

在這個階段，模型通常不會改變自己的權重。它只是用已經學到的權重，對新資料做計算。

所以更精準的分工是：

Training 決定模型知道什麼、會什麼。Inference 決定你每次使用它時，答案怎麼被算出來。

Training、fine-tuning、inference、serving 差在哪

這四個詞常被混在一起，但其實是 AI lifecycle 的不同位置。

名稱	它在做什麼	是否改變模型權重	主要關注
Training	從大量資料學出模型	會	能力、準確率、訓練成本
Fine-tuning	用較小資料集調整既有模型	通常會	任務適配、風格、特定資料
Inference	用模型對新輸入產生輸出	通常不會	延遲、成本、輸出品質
Serving	把模型部署成可被呼叫的服務	不一定	API、擴展、監控、可靠性

Google Cloud 對這個分工的說法很直白：training 和 fine-tuning 是學習階段，inference 是執行階段，serving 則是部署與管理模型讓它能處理 inference request。

用餐廳比喻：

• Training 是訓練廚師。
• Fine-tuning 是讓廚師熟悉某家店的菜單。
• Inference 是客人點餐後，廚師真的做出那一道菜。
• Serving 是整間餐廳的排隊、出餐、外送、收銀與品管系統。

很多 AI 討論只看 training，因為訓練大模型很壯觀。但產品真的每天服務使用者時，成本是 inference 一筆一筆累積出來的。

LLM inference 實際怎麼跑

傳統分類模型的 inference 可能只是一個 forward pass:輸入資料進模型，輸出分數。

LLM 比較麻煩，因為它是逐 token 生成。

一個簡化流程是：

使用者 prompt
  ↓
tokenization:把文字切成 token
  ↓
prefill:模型讀完整段 prompt,建立上下文狀態
  ↓
decode:一次產生下一個 token,再把新 token 放回上下文
  ↓
detokenization:把 token 組回人能讀的文字

這裡有兩個關鍵階段。

Prefill 是模型讀 prompt 的階段。Prompt 很長、塞了大量文件、context window 很大時，prefill 會變重。

Decode 是模型逐步產生 output token 的階段。你看到答案一個字一個字 streaming 出來，就是 decode 在跑。回答越長，decode 越久。

這也是為什麼「同一個模型」在不同場景下速度差很多。短 prompt、短回答很快;長文件分析、長回答、multi-step agent 任務會慢很多。

為什麼 inference 會貴

AI 成本不只是「訓練一次花多少錢」。對產品公司來說，更常見的帳單是：

每次 request 成本
= input tokens 的 prefill 成本
+ output tokens 的 decode 成本
+ batching / waiting / infrastructure overhead
+ monitoring、retry、cache、storage 等服務成本

使用者越多，request 越多。回答越長，output token 越多。Agent 會自己查工具、讀文件、反覆修正，一個使用者任務可能變成十幾次模型呼叫。

這就是 inference 成本會失控的原因：它跟用量直接綁在一起。

訓練成本像買機器。Inference 成本像每次開機都要付電費、冷氣費、人力與維修費。產品成功後，後者才是長期帳。

Latency 跟 throughput 不是同一件事

談 inference performance 時，至少要分兩個指標。

Latency 是單一使用者等多久。例如你問一句話，第一個 token 幾秒出現，完整答案幾秒完成。

Throughput 是系統總共能處理多少量。例如同一台 GPU 每秒能產生多少 token，或同時服務多少使用者。

兩者常常拉扯。

優化方向	好處	代價
把多個 request batch 在一起	GPU 使用率提高、總吞吐量變好	某些使用者可能多等一下
讓答案 streaming	使用者較快看到第一段	後端仍要把整段 decode 完
用更小模型	latency 和成本下降	複雜任務品質可能下降
用 quantization	記憶體與成本下降	品質可能略降，需測試
cache 重複 prompt 或 prefix	重複任務變快	cache 命中率取決於產品型態

這也是為什麼 AI infrastructure 文章常講 batching、KV cache、PagedAttention、speculative decoding。這些不是冷門優化，而是直接決定使用者會不會覺得產品「卡」。

PagedAttention 那篇 vLLM 論文的重點，就是 LLM serving 時 KV cache 會吃掉大量 GPU memory;如果管理不好，就會限制 batch size，讓吞吐量上不去。

Online inference、offline inference、edge inference

Inference 不一定都是你打開聊天視窗後即時跑。

Online inference 是 on demand。使用者送出 request，系統立刻跑模型並回應。聊天機器人、即時客服、推薦排序、詐欺偵測，多半屬於這類。

Offline inference 是批次產生結果，再把結果存起來。Google 的機器學習詞彙表用天氣預報當例子：系統定期產生一批預測，app 之後從 cache 取用。電商每天凌晨重算商品推薦、媒體系統批次生成摘要，也可以是這類。

Edge inference 是在裝置端或靠近資料來源的地方跑模型。手機相機即時辨識、工廠感測器異常偵測、車載系統，可能不適合每次都把資料送到雲端。Edge inference 的好處是低延遲、較少資料外傳、離線也能工作;代價是裝置算力與模型大小受限。

選哪一種不是信仰問題，而是產品約束：

問題	影響選擇
使用者是否需要即時答案？	需要即時就偏 online
資料能不能離開裝置或廠區？	不能就評估 edge 或私有部署
任務是否可預先計算？	可預先算就偏 offline
用量是否尖峰明顯？	需要 serving / autoscaling 設計

Inference 跟「模型聰不聰明」的關係

模型能力很重要，但 inference layer 會放大或限制它。

同一個模型，如果 serving 做得差，可能出現：

• 第一個 token 很慢，使用者以為壞了
• 高峰期排隊太久，timeout 增加
• context 太長導致成本暴增
• batch 策略讓互動產品手感變差
• 沒有 retry / fallback，模型供應商一抖動整個產品掛掉
• 沒有 cache，重複問題一直燒 token

反過來，一個務實的 inference 設計會分層：

簡單任務用小模型。 分類、格式轉換、簡單摘要，不一定要用最大模型。

複雜任務 escalate。 需要多步推理、debug、長文件綜合時，再切到 reasoning model 或更強模型。

高重複內容 cache。 系統 prompt、常見文件 prefix、常見 query 結果，都可能降低成本。

把工具結果變短。 RAG 或 tool calling 回來的資料不要整包塞進 prompt，先過濾、摘要、重排。

這些選擇不會出現在模型榜單上，但會出現在你的月帳單與使用者留存裡。

對台灣團隊的實務判斷

台灣團隊談 AI 導入，常常先問「要用哪個模型」。這題當然重要，但下一題應該是：「每個月會跑多少 inference?」

如果你做內部知識庫，一天幾百次查詢，用 API 可能最省事。你真正要管的是資料權限、RAG 品質和回覆可信度。

如果你做客服 agent，一天幾萬次對話，成本和 latency 就會變成產品問題。你需要小模型 / 大模型 routing、FAQ cache、人工轉接、失敗重試。

如果你做製造現場的瑕疵偵測或設備異常判斷，edge inference 可能比雲端 inference 更合理。因為網路延遲、資料外流、產線停機成本，都比模型選型更硬。

如果你是新創，不要一開始就架一整套重 inference infra。先用 managed API 跑出真實 usage pattern，再決定哪些部分值得自架、哪些值得保留給雲端。

一句話： 模型選型是能力問題;inference 設計是營運問題。

收尾

Inference 是 AI 真正進入產品現場的那一刻。

Training 把模型訓練好;fine-tuning 讓模型更貼近任務;serving 把模型變成可被呼叫的服務;inference 則是每一次使用者按下送出後，模型真的開始算答案。

如果你只懂 training，你會低估 AI 產品的長期成本。如果你不懂 inference，你會看不懂為什麼同一個模型在 demo 很快，上線後卻變慢、變貴、變不穩。

AI 的下一個戰場不只在誰訓練出最大模型，也在誰能把 inference 做得便宜、快、穩，讓模型真的每天工作。

周詠晴（編輯：廖玄同），《Inference 是什麼:訓練之後,AI 真正開始工作》，矽基前沿 [Si]gnals，2026-04-26。https://signals.tw/articles/what-is-inference/