部署模型需要机器学习工程师吗？

仅仅为了部署模型，并不需要机器学习工程师。推理主要是基础设施问题，涉及内存、队列、批处理和路由这些东西。需要机器学习专业知识的是训练和评估模型，而不是运行模型。

换一块更大的 GPU 会让推理更快吗？

只有在计算受限（compute-bound）时才会，这通常意味着以预填充为主的工作负载。解码受显存带宽限制，所以更多的 FLOPS 往往什么也改变不了；买之前先测量 TTFT 和 TPOT。

我们可以在生产环境运行 Ollama吗？

Ollama 在笔记本、边缘设备以及本文讨论的所有实验中都表现出色。但它并不是为多 GPU 或高并发服务设计的。生产环境请考虑改用 vLLM 或 SGLang。

一个模型需要多少 GPU 显存？

要估算 GPU 显存需求，先用参数量乘以每参数字节数得到权重占用，再加上一块随并发上下文增长的 KV 缓存。

LLM 推理详解：对外提供一个模型时到底发生了什么

随着在 ChatGPT、Claude、Gemini 这类前沿 AI 服务上的支出不断攀升、用量上限卡住开发者、开源模型日益流行，大多数平台团队最终都需要在自己的基础设施上部署并对外提供一个大语言模型（LLM）。乍一看，它就像负载均衡器后面通过 HTTP 运行的任何其他工作负载，但相似之处到此为止。模型本身只是一个装满浮点数的文件夹，没有任何可以执行的东西。API 是无状态的，要让对话延续下去，客户端每次都得把完整的对话历史重新发送一遍；通常几毫秒就能完成的 API 调用，现在要花上几秒甚至几分钟。

所有这些差异，都源自模型把提示词变成 token 的方式中的几个基本事实，并左右着每一个平台决策，从购买 GPU 到搭建网关和自动扩缩容。在这篇文章里，我们将走完整个过程：你要部署的文件、为它们提供服务的引擎，以及一个请求从原始文本到流式输出 token 的过程中都经历了什么。

模型：一个装满数字的文件夹

模型是一个文件（更常见的是一组文件），装着数十亿个被称为权重的数值，外加一个分词器和一些配置。它不是程序，没有任何可执行的东西。模型自己什么也做不了。举个例子，下面是 Qwen3-4B 的文件列表：

3.7G model-00002-of-00003.safetensors
3.7G model-00001-of-00003.safetensors
 95M model-00003-of-00003.safetensors
 11M tokenizer.json
2.6M vocab.json
1.6M merges.txt
 32K model.safetensors.index.json
 16K README.md
 11K LICENSE
9.5K tokenizer_config.json
726B config.json
239B generation_config.json

全部结构就集中在这一处：三个装着原始数字的分片占了数据的 99% 以上，配上几个解释如何使用它们的小 JSON 和文本文件。以下是主要文件，遵循标准的 Hugging Face 布局：

config.json 是蓝图。它携带着引擎排布权重、估算内存大小所需的架构信息。

{
  "architectures": [
    "Qwen3ForCausalLM"
  ],
  ...
  "max_window_layers": 36,
  "model_type": "qwen3",
  "num_attention_heads": 32,
  "num_hidden_layers": 36,
  "num_key_value_heads": 8,
  "torch_dtype": "bfloat16",
  "transformers_version": "4.51.0",
  "use_cache": true,
  "use_sliding_window": false,
  "vocab_size": 151936
}

tokenizer.json 扮演模型的字典。模型不直接阅读文本；这个文件包含把人类文本转换成模型所用整数 ID 所需的一切。

{
  "version": "1.0",
  "truncation": null,
  "padding": null,
  "added_tokens": [
    {
      "id": 151643,
      "content": "<|endoftext|>",
      "single_word": false,
      "lstrip": false,
      "rstrip": false,
      "normalized": false,
      "special": true
    },
    ...
  ],
  "normalizer": {...},
  "decoder": {...},
  "model": {
    "type": "BPE",
    "vocab": {
      "!": 0,
      "\"": 1,
      "#": 2,
      "$": 3,
      ...
    }
  },
  "merges": [...]
}

tokenizer_config.json 除了其他设置之外，还包含聊天模板。这个模板是一份配方，把结构化的对话（system、user、assistant 各轮，外加工具调用）变成模型在训练时学会理解的单一 token 流。

{
  "chat_template": "{%- if tools %}\n    {{- '<|im_start|>system\\n' }}\n    {%- if messages[0].role == 'system' %}\n        {{- messages[0].content + '\\n\\n' }}\n    {%- endif %}\n    {{- \"# Tools\\n\\nYou may call one or more functions to assist with the user query.\\n\\nYou are provided with function signatures within <tools></tools> XML tags:\\n<tools>\" }}\n    {%- for tool in tools %}\n        {{- \"\\n\" }}\n        {{- tool | tojson }}\n    {%- endfor %}\n    {{- \"\\n</tools>\\n\\nFor each function call, return a json object with function name and arguments within <tool_call></tool_call> XML tags:\\n<tool_call>\\n{\\\"name\\\": <function-name>, \\\"arguments\\\": <args-json-object>}\\n</tool_call><|im_end|>\\n\" }}\n{%- else %}\n    {%- if messages[0].role == 'system' %}\n        {{- '<|im_start|>system\\n' + messages[0].content + '<|im_end|>\\n' }}\n    {%- endif %}\n{%- endif %}\n{%- set ns = namespace(multi_step_tool=true, last_query_index=messages|length - 1) %}\n{%- for message in messages[::-1] %}\n    {%- set index = (messages|length - 1) - loop.index0 %}\n    {%- if ns.multi_step_tool and message.role == \"user\" and message.content is string and not(message.content.startswith('<tool_response>') and message.content.endswith('</tool_response>')) %}\n        {%- set ns.multi_step_tool = false %}\n        {%- set ns.last_query_index = index %}\n    {%- endif %}\n{%- endfor %}\n{%- for message in messages %}\n    {%- if message.content is string %}\n        {%- set content = message.content %}\n    {%- else %}\n        {%- set content = '' %}\n    {%- endif %}\n    {%- if (message.role == \"user\") or (message.role == \"system\" and not loop.first) %}\n        {{- '<|im_start|>' + message.role + '\\n' + content + '<|im_end|>' + '\\n' }}\n    {%- elif message.role == \"assistant\" %}\n        {%- set reasoning_content = '' %}\n        {%- if message.reasoning_content is string %}\n            {%- set reasoning_content = message.reasoning_content %}\n        {%- else %}\n            {%- if '</think>' in content %}\n                {%- set reasoning_content = content.split('</think>')[0].rstrip('\\n').split('<think>')[-1].lstrip('\\n') %}\n                {%- set content = content.split('</think>')[-1].lstrip('\\n') %}\n            {%- endif %}\n        {%- endif %}\n        {%- if loop.index0 > ns.last_query_index %}\n            {%- if loop.last or (not loop.last and reasoning_content) %}\n                {{- '<|im_start|>' + message.role + '\\n<think>\\n' + reasoning_content.strip('\\n') + '\\n</think>\\n\\n' + content.lstrip('\\n') }}\n            {%- else %}\n                {{- '<|im_start|>' + message.role + '\\n' + content }}\n            {%- endif %}\n        {%- else %}\n            {{- '<|im_start|>' + message.role + '\\n' + content }}\n        {%- endif %}\n        {%- if message.tool_calls %}\n            {%- for tool_call in message.tool_calls %}\n                {%- if (loop.first and content) or (not loop.first) %}\n                    {{- '\\n' }}\n                {%- endif %}\n                {%- if tool_call.function %}\n                    {%- set tool_call = tool_call.function %}\n                {%- endif %}\n                {{- '<tool_call>\\n{\"name\": \"' }}\n                {{- tool_call.name }}\n                {{- '\", \"arguments\": ' }}\n                {%- if tool_call.arguments is string %}\n                    {{- tool_call.arguments }}\n                {%- else %}\n                    {{- tool_call.arguments | tojson }}\n                {%- endif %}\n                {{- '}\\n</tool_call>' }}\n            {%- endfor %}\n        {%- endif %}\n        {{- '<|im_end|>\\n' }}\n    {%- elif message.role == \"tool\" %}\n        {%- if loop.first or (messages[loop.index0 - 1].role != \"tool\") %}\n            {{- '<|im_start|>user' }}\n        {%- endif %}\n        {{- '\\n<tool_response>\\n' }}\n        {{- content }}\n        {{- '\\n</tool_response>' }}\n        {%- if loop.last or (messages[loop.index0 + 1].role != \"tool\") %}\n            {{- '<|im_end|>\\n' }}\n        {%- endif %}\n    {%- endif %}\n{%- endfor %}\n{%- if add_generation_prompt %}\n    {{- '<|im_start|>assistant\\n' }}\n    {%- if enable_thinking is defined and enable_thinking is false %}\n        {{- '<think>\\n\\n</think>\\n\\n' }}\n    {%- endif %}\n{%- endif %}",
  ...
}

generation_config.json 给出模型作者推荐的运行设置。除非请求中另有指定，引擎会把它们用作默认设置。

{
    "bos_token_id": 151643,
    "do_sample": true,
    "eos_token_id": [
        151645,
        151643
    ],
    "pad_token_id": 151643,
    "temperature": 0.6,
    "top_k": 20,
    "top_p": 0.95,
    "transformers_version": "4.51.0"
}

最后是若干 model-*.safetensors 分片，以及充当它们目录的 model.safetensors.index.json。这个 JSON 文件把每个张量名映射到包含它的分片。每个分片的结构很简单：一个小小的 JSON 头列出张量名、数据类型、形状和字节偏移，后面跟着原始的张量字节。对 Qwen3-4B 来说，这意味着约 40 亿个 bfloat16 数值、每个 2 字节，总共 8 GB 左右。打开一个分片，你会看到一层又一层带名字的数字数组：

model.embed_tokens.weight
tensor([[-0.0287,  0.0117,  0.0104,  ..., -0.0055, -0.0270, -0.0096],
        [-0.0291, -0.0212,  0.0109,  ..., -0.0033, -0.0062, -0.0004],
        [ 0.0035,  0.0177,  0.0012,  ..., -0.0058,  0.0022,  0.0130],
        ...,
        [ 0.0060,  0.0131,  0.0190,  ...,  0.0068, -0.0049, -0.0040],
        [ 0.0060,  0.0131,  0.0190,  ...,  0.0068, -0.0049, -0.0040],
        [ 0.0060,  0.0131,  0.0190,  ...,  0.0068, -0.0049, -0.0040]],
       dtype=torch.bfloat16)
model.layers.0.input_layernorm.weight
tensor([0.0598, 0.0288, 0.0576,  ..., 0.0184, 0.0222, 0.0223],
       dtype=torch.bfloat16)
model.layers.0.mlp.down_proj.weight
tensor([[ 0.1396,  0.0056,  0.0054,  ..., -0.0084,  0.0781, -0.0693],
        [-0.0859, -0.0074, -0.0142,  ..., -0.0161, -0.0022, -0.0403],
        [ 0.0649, -0.0021,  0.0081,  ...,  0.0110,  0.0223,  0.0283],
        ...,
        [ 0.0106,  0.0208,  0.0176,  ...,  0.0060, -0.0349, -0.0060],
        [-0.0079, -0.0007, -0.0603,  ..., -0.0059, -0.0271,  0.0085],
        [-0.0221, -0.0306,  0.0121,  ..., -0.0089, -0.0233,  0.0089]],
       dtype=torch.bfloat16)
model.layers.0.mlp.gate_proj.weight
tensor([[ 0.0014,  0.0057, -0.0032,  ..., -0.0415, -0.0276, -0.0154],
        [-0.0178,  0.0078,  0.0043,  ..., -0.0186, -0.0028, -0.0018],
        [-0.0042, -0.0018, -0.0016,  ...,  0.0330, -0.0026,  0.0244],
        ...,
        [-0.0081, -0.0007, -0.0052,  ..., -0.0076, -0.0114,  0.0062],
        [-0.0061,  0.0118, -0.0116,  ..., -0.0164, -0.0015,  0.0237],
        [ 0.0130,  0.0046, -0.0036,  ..., -0.0105,  0.0297, -0.0347]],
       dtype=torch.bfloat16)
model.layers.0.mlp.up_proj.weight
tensor([[ 0.0137,  0.0089,  0.0046,  ..., -0.0339,  0.0061, -0.0117],
        [ 0.0077,  0.0078,  0.0036,  ...,  0.0134,  0.0216, -0.0040],
        [-0.0105,  0.0057,  0.0053,  ...,  0.0251,  0.0044,  0.0092],
        ...,
        [ 0.0067, -0.0003, -0.0082,  ..., -0.0049,  0.0247, -0.0181],
        [-0.0021,  0.0044, -0.0056,  ..., -0.0111,  0.0133,  0.0135],
        [ 0.0046, -0.0028,  0.0004,  ...,  0.0167,  0.0505,  0.0347]],
       dtype=torch.bfloat16)
model.layers.0.post_attention_layernorm.weight
tensor([-2.0862e-05,  2.7466e-04, -5.5313e-05,  ...,  2.1582e-01,
         2.3145e-01,  2.1484e-01], dtype=torch.bfloat16)
model.layers.0.self_attn.k_norm.weight
tensor([ 1.9453e+00,  1.1172e+00,  1.7031e+00,  1.7969e+00,  1.4688e+00,
         1.9141e+00,  1.9844e+00,  1.8281e+00,  1.8203e+00,  1.6406e+00,
         ...,
         6.4844e-01,  1.8203e+00,  2.3750e+00,  2.9062e+00,  4.0938e+00,
         2.0625e+00,  2.1094e+00,  3.0781e+00,  1.5234e+00,  2.3125e+00,
         1.9141e+00,  2.0469e+00,  2.0156e+00], dtype=torch.bfloat16)

稠密与混合专家 Transformer 架构

在继续之前，有一个重要差异需要点明，因为业界最大的那些开放模型最近变了。多年来，几乎所有能下载到的模型都共享同一种设计，如今称为稠密（dense）；而最新的旗舰模型采用了另一种：混合专家（Mixture-of-Experts，MoE）。两者的关键差异在于，每个 token 要经过其中多少个张量。

稠密模型：Llama 家族，以及你迄今为止部署过的大多数模型，都会把每个 token 与分片里的每一个张量相乘。回看上面 Qwen3-4B 的清单：每一层各有一个 mlp.gate_proj、mlp.up_proj 和 mlp.down_proj，每个 token 的向量都要穿过它们全部。没有任何机制可以跳过某个已存储的数字，所以每 token 的计算量随模型规模增长：一个 70B 的稠密模型每个 token 做的计算大约是 8B 模型的 9 倍。

混合专家（MoE）模型保持同样的文件结构，但在每一层里存放许多份那个前馈三件套的小副本（张量名类似 mlp.experts.0.gate_proj、mlp.experts.1.gate_proj 等等），外加一个很小的额外张量：一个学习出来的路由器。对每个 token，路由器给所有专家打分，只有得分最高的少数几个（在若干现代设计中，还要加上一个始终启用的共享专家）真正参与乘法；其余专家的张量对这个 token 而言原封不动。Mixtral-8x7B 带着 47B 参数出厂，但每个 token 只与其中约 13B 相乘；DeepSeek-R1 带着 671B，只用约 37B。你以小模型的每 token 计算成本，得到大模型的质量。这一点，加上压缩 KV 缓存（MLA，我们会在内存一节回头再谈）等推理层创新，正是 DeepSeek 能以如此低的成本提供前沿级质量的重要原因。

麻烦在于，内存需求并不取决于用到了哪些张量。所有参数都必须加载并可访问，即便每个 token 只用到其中大约 3–30%，具体取决于设计（Mixtral‑8x7B 约 28%，DeepSeek‑R1 约 5%）。MoE 模型运行起来便宜，存起来昂贵。要想高效地为这些模型提供服务，你往往需要把专家分布到许多 GPU 和主机上，并在它们之间快速路由 token，这就要求调度对网络和拓扑有感知。

推理引擎是你的新 Web 服务器

模型和网站的 HTML 文件一样被动。在 Web 服务器加载它并处理请求之前，它什么也不做。我们可以把推理引擎看作模型的 Web 服务器。它把权重加载到加速器上，提供 HTTP API，并在客户端的 JSON 与 GPU 矩阵运算之间来回翻译。它做的其余一切（把请求排进队列、为硬件把请求组成批次、每个 token 一就绪就流式发出）都服务于一个主要目标：让昂贵的加速器保持忙碌，同时不让任何单个请求等太久。

截至本文写作时的引擎版图：

引擎	维护者	要点
vLLM	开源	自托管部署的事实默认；开创了 PagedAttention，默认启用连续批处理。
SGLang	开源	vLLM 最强的开源竞争者；提供 RadixAttention 前缀缓存。
TGI	Hugging Face	成熟，与 Hub 深度集成。
NIM	NVIDIA	商业产品：引擎与特定模型预打包成容器。NVIDIA 发什么，你就运行什么。
Ray Serve	Anyscale / Ray	ML 生命周期框架；用于 LLM 时通常在底层包一层 vLLM。
Ollama	开源	对笔记本和边缘设备友好；非常适合本文的实验。不是为多 GPU 生产部署而设计的。

比引擎名字本身更重要的有两件事。引擎是与模型绑定的：新的模型架构只有在引擎加入支持之后才能运行。这就是每个引擎都会发布支持模型列表的原因，也是你在向业务方作出承诺之前，务必先确认能否部署该模型的原因。几乎所有引擎都使用 OpenAI API 规范（/v1/chat/completions、/v1/models），因此客户端、网关和基准测试工具可以跨引擎工作。

token 与上下文窗口

模型看不到单词；它看到的是 token，也就是我们在 tokenizer.json 里找到的分词器产出的整数 ID。下游的一切都以 token 计费、以 token 做基准测试、以 token 编制内存预算。下面是 Qwen3-4B 的分词器处理三个短句的结果：

from urllib.request import urlopen
from tokenizers import Tokenizer
TOK_URL = "https://huggingface.co/Qwen/Qwen3-4B/resolve/main/tokenizer.json"
tok = Tokenizer.from_buffer(urlopen(TOK_URL).read())
for text in ["Why is the sky blue?", "我喜欢吃火锅!", "김치찌개를 좋아해요!"]:
    enc = tok.encode(text)
    pieces = [tok.decode([i]) for i in enc.ids]
    print(f"{text!r}")
    print(f"  {len(enc.ids):>2} tokens -> {pieces}")
 
'Why is the sky blue?'
   6 tokens -> ['Why', ' is', ' the', ' sky', ' blue', '?']
 
'我喜欢吃火锅!'
   4 tokens -> ['我喜欢', '吃', '火锅', '!']
 
'김치찌개를 좋아해요!'
   9 tokens -> ['김', '치', '찌', '개', '를', ' 좋아', '해', '요', '!']

可以看到，字符数和 token 数之间没有固定比例：5 个英文单词可能得到 6 个 token，1 个韩语单词也可能得到 9 个。这一点之所以重要，是因为模型的主要限制是以 token 度量的。上下文窗口是模型在单个请求中能处理的最大 token 数（包括提示词和响应在内），托管模型宣传“百万 token 上下文”时，说的就是这个数字。

在分词之前还有一步。你的应用发送的是结构化的消息数组，而模型是在单一的扁平流上训练的，用特殊 token 标明谁在说话。tokenizer_config.json 里的聊天模板弥合了这道缝隙：把数组压平成一条流，然后再对这条流做分词。

预填充与解码：每个响应背后的两个阶段

推理就是把这些 token 变成新 token 的计算：提示词进去，补全（completion）出来。在引擎内部，它分两个阶段运行：

预填充（prefill）在一次大规模的并行处理中吞入整个提示词。它为每个提示词 token 计算键和值向量并存入 KV 缓存，也就是为该序列保存注意力状态的那块 GPU 显存。这一步的最终输出是对第一个响应 token 的预测，用户的首 token 时间（time-to-first-token，TTFT）到此为止。
解码（decode）逐个生成响应的其余 token。对每个 token，它计算键和值、追加进缓存，并对所有更早的 token 直接读取已存条目而不是重新计算。没有 KV 缓存，生成第 500 个 token 就得重新处理前面 499 个。有了缓存，每个 token 的注意力计算只做一次，即它首次进入序列的时候。

无状态与一次对话的成本

KV 缓存留在服务器上，但 API 是无状态的。没有模型可以使用的会话对象或对话 ID。如果用户先问“比利时的首都是哪里？”，接着追问“那座城市住着多少人？”，只有当你的应用在每次请求时把整个对话重新发送一遍，模型才能把这两个问题联系起来。

POST /v1/chat/completions HTTP/1.1
Host: localhost:11434
Content-Type: application/json
{
  "messages": [
    { "role": "user", "content": "What is the capital of Belgium?" },
    { "role": "assistant", "content": "The capital of Belgium is **Brussels**..." },
    { "role": "user", "content": "How many people live in that city?" }
  ],
  "model": "qwen3:8b"
}
 
HTTP/1.1 200 OK
Content-Type: application/json
{
  ...
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "As of 2023, the **Brussels-Capital Region** has a population
                    of approximately **1.2 million people**..."
      },
      ...
    }
  ],
  "usage": { "prompt_tokens": 134, "completion_tokens": 843, "total_tokens": 977 }
}

至于对话是否会花费越来越多的计算，则是个更微妙的问题，KV 缓存在这里再次登场。无状态意味着重放历史是应用的职责，并不意味着服务器每次都重新计算这段历史。如果引擎还保留着这场对话早前轮次的 KV 缓存，而重放的前缀又逐 token 完全一致，它就会跳过这些 token 的预填充，几乎直接进入解码。落在已经持有本对话缓存的副本上的请求，其服务成本可能比落在冷副本上的请求便宜一个数量级。

批处理：引擎的吞吐量从何而来

到目前为止，我们只跟踪了单个请求。然而生产环境很快就能达到每天数十万个请求。为了维持高利用率、减少浪费，引擎正在采用两种策略：

静态批处理先攒请求，攒满一批后一次性全部处理。这种方式吞吐量很好，但批次里的第一个请求必须等到最后一个请求到达，平添了延迟。这种取舍很适合离线任务，比如文档摘要、夜间的 embedding 作业或批量分类，也就是没有人在等即时响应的场景。

连续批处理让新请求在其他请求结束时随时加入正在运行的批次，按 token 逐个处理。这种方式大幅降低了单个请求的延迟，对聊天机器人这类交互式工作负载非常重要。

可观测性与四个关键数字

说到可观测性，上面的一切（阶段、缓存、批次）都会汇聚成四个指标：

TTFT（首 token 时间）是用户在看到任何内容之前等待的时长，由排队加预填充主导。
TPOT（每输出 token 时间）是生成开始之后的节奏，由解码主导。
每秒 token 数是吞吐量，可以按单个请求看，也可以按整个部署汇总看。
每秒请求数主要在你摸清典型 token 数之后的容量规划中才重要。

想快速用你的基础设施给模型做基准测试，可以使用官方的 vLLM 基准测试客户端 vllm bench serve，它能向任何 OpenAI 兼容端点施加受控负载。

vllm bench serve \
  --model Qwen/Qwen3-4B-AWQ \
  --base-url http://localhost:8000 \
  --dataset-name random \
  --random-input-len 512 --random-output-len 128 \
  --num-prompts 64 --max-concurrency 8

它的报告恰好就是围绕上述四个数字组织的（ITL 是逐个间隔测量的 TPOT）：

================= Serving Benchmark Result =================
Successful requests:                     64        
Failed requests:                         0         
Maximum request concurrency:             8         
Benchmark duration (s):                  38.83     
Total input tokens:                      32707     
Total generated tokens:                  8192      
Request throughput (req/s):              1.65      
Output token throughput (tok/s):         210.95    
Peak output token throughput (tok/s):    392.00    
Peak concurrent requests:                16.00     
Total token throughput (tok/s):          1053.20   
--------------------Time to First Token---------------------
Mean TTFT (ms):                          1632.54   
Median TTFT (ms):                        1355.88   
P99 TTFT (ms):                           5376.73   
P90 TTFT (ms):                           4301.80   
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          25.34     
Median TPOT (ms):                        24.11     
P99 TPOT (ms):                           40.39     
P90 TPOT (ms):                           32.41     
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           25.36     
Median ITL (ms):                         20.61     
P99 ITL (ms):                            29.10     
P90 ITL (ms):                            21.39     
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          4851.09   
Median E2EL (ms):                        4414.25   
P99 E2EL (ms):                           7989.19   
P90 E2EL (ms):                           7964.52   
============================================================

以不断增加的并发运行它，就能看到连续批处理在发挥作用：汇总的每秒 token 数成倍攀升，而每个请求自己的 TTFT 和 TPOT 只是温和地变差。

当批次超出硬件的承受能力，吞吐量进入平台期，TTFT 是第一个受害者（请求开始排队）。这正是对 LLM 后端而言，真正重要的路由信号是队列深度而不是 CPU 的原因。再注意这些指标忽略了什么：CPU 和内存利用率，恰恰是你现有的自动扩缩容懂得盯着看的那两个数字。这种错位破坏的不只是仪表盘；LLM 流量为什么会让标准的 Kubernetes 负载均衡和自动扩缩容失效，我们会用单独一篇文章来讲。

权重、量化与显存账单

现在是预算问题：把这一切装下需要什么？就权重而言，参数量乘以每参数字节数就是占用量。但对今天的大语言模型来说，这笔开销相当可观。在 16 位精度下，一个 70B 参数的模型在处理任何一个 token 之前就要占据约 141 GB，远超 H100 GPU 上可用的 80 GB。因此，挑战不在于随需求扩展，而在于先把模型塞进显存。这就是量化登场的地方。它以更低的精度存储权重，减少字节数和随之而来的显存占用，而现代 4 位方法把精度上的代价压得出奇地小。

KV 缓存在权重之外额外消耗显存，并随每个并发对话的每个 token 增长。引擎会为它预留很大一块 VRAM。例如 vLLM 在一个预算内工作，这个预算定义为总显存的一个可配置比例（自 v0.20 起默认 92%，此前是 90%）：先加载权重，再跑一次分析用的前向传播来测量激活值开销，然后把预算里剩下的全部预分配为 KV 缓存空间。KV 余量越大，批次越大、吞吐量越好；余量越小，排队来得越早。这一个数字决定了那份余量有多少。

下表对四个代表性模型做了这两项计算，每个模型的层数、KV 头数和头维度都取自它的 config.json（每 token KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 字节数）：

模型	权重 fp16	权重 int8	权重 int4	每 token KV 缓存	128K 上下文时的 KV 缓存
Llama-3.1-8B（稠密）	16 GB	8 GB	4 GB	128 KB	16 GB
Llama-3.3-70B（稠密）	141 GB	71 GB	35 GB	320 KB	40 GB
Qwen3-235B-A22B（MoE）	470 GB	235 GB	118 GB	188 KB	23.5 GB
Kimi K2.5（MoE）	2,080 GB*	1,040 GB	520 GB	~69 KB（MLA）†	~8.6 GB†

† Kimi K2.5 使用多头潜在注意力（Multi-head Latent Attention，继承自 DeepSeek-V3 谱系）。

一条务实的建议

如果你正考虑在自己的基础设施上运行模型（也许是因为 token 成本、用量限制或合规需求），在买 GPU 之前，先在笔记本上试一试。用 Ollama 下载一个小模型，比如 qwen3:8b 或 llama3.2:1b。然后用 Ollama 提供服务，把 vllm bench serve 指向它，并把 --max-concurrency 从 1 逐步加到 32，看看你的硬件如何应对负载。这会帮助你熟悉 TTFT、TPOT、KV 缓存以及其他重要的推理统计指标。这个实验不花一分钱，还能让你在学习整个流程如何运转的同时避开常见的错误。