運行經過訓練的模型以生成輸出的過程。訓練是學習；推論是應用所學到的知識。每次你向Claude發送提示或使用Stable Diffusion生成圖片時，這就是推論。這就是消耗服務提供商GPU小時數以及你按每個token支付費用的環節。
對於大型語言模型（LLM），推論過程分為兩個明顯的階段，理解這兩階段能解釋你所觀察到的大部分效能特徵。第一階段稱為「prefill」或「提示處理」—模型會讀取整個輸入提示，並建立其內部狀態（KV緩存）。此階段是計算密集型（compute-bound），能從GPU平行處理中受益，因為所有輸入token可以同時處理。第二階段稱為「decode」或「生成」—模型一次產生一個輸出token，每個token依賴所有先前的token。此階段是記憶體頻寬限制（memory-bandwidth-bound），因為模型需要從VRAM中讀取權重來處理每個token，但每次讀取的計算量相對較少。這就是為何「首次token時間（TTFT）」和「每秒token數」會被分開衡量：它們反映的是根本不同的瓶頸。
推論的經濟性主要由一個概念主導，稱為「吞吐量 vs. 延遲」。如果你正在服務一個聊天機器人，其中一位用戶正在等待回應，你希望有低延遲—盡快產生第一個token。但如果你正在執行批次處理（例如夜間總結10,000份文件），你希望有高吞吐量—盡可能每秒處理更多token，即使每個個別請求較慢。推論引擎如vLLM和TensorRT-LLM使用一種稱為「連續批次處理（continuous batching）」的技術，動態將多個請求分組，大幅提高吞吐量。單一H100可能對一個請求產生40 token/秒，但透過巧妙批次處理，相同的GPU可以在可接受的延遲下服務20個以上的同時用戶，因為記憶體頻寬被更有效率地共享。
推論服務生態已分裂為不同的方法。雲端API提供商（如Anthropic、OpenAI、Google）運行大型GPU叢集，將推論作為服務出售，按token計價。專注於推論的提供商如Groq則押注於客製化硬體—Groq的語言處理單元（LPU）專門設計用於序列解碼階段，實現驚人的token生成速度。在開源領域，llama.cpp透過激進的量化技術將LLM推論帶到CPU和消費者級GPU上，而Ollama等工具則將其打包成用戶友好的套件。對於生產環境的自托管，結合PagedAttention的vLLM已成為預設選擇，在正確調整後其吞吐量可與商業方案競爭。
一個常見的誤解是推論相較於訓練來說「便宜」。對單一請求而言，是的—產生回應的成本僅需幾分之一美分。但推論是持續進行的。一個受歡迎的聊天機器人每天會處理數百萬次請求，且無限期持續。據報導，OpenAI目前在推論上的支出已超過訓練。這就是為何推論優化成為熱門領域：預測解碼（使用小型「草稿」模型預測大型模型會說什麼）、KV緩存壓縮、前綴緩存（重複使用共享系統提示的計算）等技術，都旨在從相同硬體中擠出更多回應。每個百分比的效率提升，在規模化時都直接轉化為數百萬美元的節省。