对于大型语言模型（LLM），推理过程分为两个截然不同的阶段，理解这两个阶段可以解释你观察到的大部分性能特征。第一阶段称为“预填充”（prefill）或“提示处理”（prompt processing）——模型会读取你的完整输入提示，并构建其内部状态（即KV缓存）。这一阶段是计算密集型的，能从GPU并行性中获益，因为所有输入token可以同时处理。第二阶段称为“解码”（decode）或“生成”（generation）——模型逐个生成输出token，每个token都依赖于所有之前的token。这一阶段是内存带宽密集型的，因为模型需要为每个token从显存（VRAM）中读取权重，但每次读取的计算量相对较少。这就是为什么首次生成token时间（TTFT）和每秒token数（tokens-per-second）需要分别测量：它们反映了根本不同的瓶颈。
推理的经济性由一个称为“吞吐量 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等工具则将其封装成用户友好的软件包。对于生产环境的自托管，vLLM配合PagedAttention已成为默认选择，当正确调优时，其吞吐量可与商业解决方案相媲美。
一个常见的误解是，与训练相比，推理是“便宜”的。对于单个请求来说，确实如此——生成一个响应的成本仅需几分之一美分。但推理是持续进行的。一个流行的聊天机器人每天要处理数百万次请求，且是无限期的。据报道，OpenAI目前在推理上的支出已超过训练。这就是为什么推理优化成为热门领域：投机解码（使用小型“草稿”模型预测大模型将要说什么）、KV缓存压缩和前缀缓存（重用共享系统提示的计算）等技术，都旨在从同一硬件中榨取更多响应。每个百分点的效率提升在规模上都直接转化为数百万美元的节省。