邁入正式環境：服務框架與每詞元成本

這些你不必從零造起

這條軌裡的一切——預填充／解碼排程、KV 快取、分頁、連續批次處理、量化、推測解碼——都不容易做好。所以實務上你會用一個把這些全包起來的服務框架：你把它指向一組權重，它就對外提供一個快速、批次化、支援串流的 API。常見的開源引擎（如 vLLM、TGI、SGLang、TensorRT-LLM）在調校上各有不同，但共享這套核心功能。

# bring a model up with an OpenAI-compatible server (vLLM example)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --quantization awq \          # weight-only quantization
  --max-model-len 8192 \        # context length cap (bounds KV cache)
  --gpu-memory-utilization 0.9  # how much VRAM to use for weights + cache

一道指令就把權重變成正式環境端點，分頁與連續批次處理都已預設開啟。

先選定你的服務模式

在調校任何東西之前，先決定你落在批次與線上的哪一邊。線上：有真人在等，所以守護TTFT與每位使用者的速度、限制批次大小、接受較高的每詞元成本。批次：一百萬份文件要過夜摘要，所以拉滿批次大小、把 GPU 餵到飽，讓個別延遲膨脹也無妨。同一個框架兩者通吃；你是在吞吐量—延遲曲線上選一個點。

每詞元成本：最終的底線

把工程細節剝開，決定一個部署是否可行的就只有一個數字：每詞元成本。它幾乎是純算術——你每小時為 GPU 付多少錢，除以那張 GPU 每小時產出多少詞元。這條軌裡的一切，歸根結柢都是把這個分數往下壓的戰術。

\text{cost/token}=\frac{\text{GPU price per hour}}{\text{tokens per hour}}=\frac{p_{\$/\text{hr}}}{3600\cdot\text{throughput}_{\text{tok/s}}}

每词元成本几乎就是纯算术：GPU 每小时的价格，除以它在那一小时内生成的词元数量。

gpu_cost_per_hour      = 2.00        # USD for the GPU instance
aggregate_tokens_per_s = 3000        # all users combined, after batching
tokens_per_hour        = 3000 * 3600 # = 10,800,000

cost_per_million_tokens = gpu_cost_per_hour / (tokens_per_hour / 1_000_000)
#                       = 2.00 / 10.8  ->  about $0.19 per million output tokens

吞吐量是分母——把它翻倍（分頁、批次處理、量化），每詞元的價格就減半。

一次產能規劃的走查

先定下模型與脈絡長度。它們決定權重佔用與每個請求的 KV 快取大小——合起來就是你光是要容納一個使用者所需的GPU 記憶體。
算出並行上限：（顯示記憶體 − 權重）÷ 每請求快取 = 容納得下幾個使用者。把權重量化會騰出空間、拉高這個上限。
在那個並行數下做壓力測試，量出真實吞吐量與 p95 TTFT。跑分會騙人；用形狀像你自己流量的測試來量。
把 GPU 價格除以量到的吞吐量，得到每詞元成本。若太高，你的槓桿是：量化更狠、加大批次（在延遲允許下）、為互動流量加上推測解碼，或把模型切分到多張卡上。
估算機隊規模：每秒請求數 ÷ 每張 GPU 的產能 = GPU 數量，再依佇列深度自動擴縮，讓你為閒置的矽晶片付出越少越好。

N_{\text{concurrent}} \le \dfrac{\text{VRAM} - \text{weights}}{\text{KV cache per request}}

容量规划中的并发上限：显存装下权重后剩余的部分，除以单个请求的 KV 缓存，就是同时能容纳的用户数上限。

這條軌帶你抵達的地方

你現在握有服務一個大型語言模型的完整心智模型：一個答案由平行的預填充與循序的解碼生成；解碼是記憶體受限的，所以KV 快取與GPU 記憶體才是真正的預算；分頁與連續批次處理把這筆預算塞緊；量化與推測解碼把它再撐大；而一個服務框架把這一切藏在單一 API 之後交付，最終由一個誠實的數字評斷——每詞元成本。