随着大型语言模型（LLM）从实验室走向生产环境，构建一个高吞吐、低延迟、可弹性伸缩的推理服务架构，已成为 AI 工程团队的核心命题。与传统的请求-响应式服务不同，LLM 推理具有内存占用高、计算密集、延迟不可预测等特点，这要求我们在架构设计时必须引入一套全新的技术范式。本文将从单机部署出发，逐步推演到分布式集群方案，系统梳理 LLM 推理服务的关键设计考量。
一、LLM 推理面临的核心挑战
在设计推理架构之前，必须先理解其与传统微服务的本质差异。
1. 极高的单实例内存占用
一个 70B 参数的 FP16 模型仅权重就需要约 140GB 显存，再加上 KV Cache、激活值等中间状态，单卡往往无法承载。这意味着模型实例天然具有"重资源"属性，无法像普通微服务那样高密度部署。
2. 输入输出长度高度可变，延迟非确定性
用户可能发送 50 tokens 的简短问题，也可能上传上万 tokens 的长文档。输出端同样如此——从几个字节的确认到数千 tokens 的代码生成。这种变长特性使得基于固定响应时间的 SLI（Service Level Indicator）难以定义，也给资源规划和负载均衡带来巨大挑战。
3. 有状态的推理过程
对话系统需要维护跨轮次的 KV Cache（Key-Value Cache），以避免每次重复计算前缀注意力。这种状态性打破了无状态服务的假设，使得简单的 round-robin 负载均衡可能导致 cache miss，严重浪费 GPU 资源。
4. 突发流量（Bursty Traffic）
LLM 服务常面临高度不均匀的请求分布：工作日白天的文档处理高峰、深夜的代码补全峰值、热门事件引发的瞬时流量激增。传统的基于 CPU/内存利用率的扩缩容策略，在 GPU 资源稀缺且冷启动时间长达数分钟甚至数十分钟的场景下，往往束手无策。
5. GPU 资源的稀缺与高昂成本
高性能 GPU 的供应紧张和价格高昂，决定了架构必须在性能和成本之间寻找最优解。每一秒的 GPU 空闲都是真金白银的浪费。
二、单机推理架构：请求调度与内存优化
在讨论分布式之前，先审视单节点内部的优化空间，这是所有扩展的基石。
2.1 模型加载与预热
模型权重文件通常以 GB 甚至 TB 计，从磁盘加载到 GPU 显存本身就是一个耗时的 I/O 密集型操作。生产环境中，应避免在请求到达时才进行模型加载。常见的做法是：
- 预加载（Preload）：服务启动时即加载模型，完成 warmup（发送若干个 dummy request 触发 CUDA kernel 编译和缓存）。
- 模型切片缓存：对于支持多 LoRA Adapter 的场景，将基础模型常驻显存，Adapter 按需加载。
- 权重量化：通过 AWQ、GPTQ、FP8 等量化技术，在不显著损失精度的前提下将显存占用降低 30%-75%。
2.2 请求队列与批处理策略
单 GPU 同时只能执行一个 kernel，但可以通过 Continuous Batching（持续批处理）技术，让 GPU 在每个 decoding step 动态地将新到达的请求加入当前 batch，同时移除已完成的请求。vLLM 采用的 PagedAttention 进一步将 KV Cache 管理粒度从"请求级别"细化到"block 级别"，借鉴操作系统的虚拟内存分页思想，消除了传统方案中因预分配最大长度导致的显存浪费，使得 batch size 提升 2-4 倍成为可能。
调度策略上，常见的选择包括：
| 策略 | 优点 | 缺点 |
|---|---|---|
| FCFS（先来先服务） | 公平、实现简单 | 短请求被长请求阻塞，尾部延迟差 |
| Shortest-Job-First | 平均等待时间最小 | 长请求饥饿风险，需预测输出长度 |
| Budget-based（预算调度） | 兼顾公平与效率 | 参数调优复杂 |
实践表明，基于预估输出长度和已等待时间的混合调度策略，能在公平性和系统吞吐量之间取得较好的平衡。
2.3 Token 流式输出 vs 完整响应
从用户体验角度，流式输出（Server-Sent Events / SSE）几乎已成为标配。它允许用户在前几个 token 生成后即可看到响应，极大降低了感知的"首 token 延迟"。但流式输出也增加了服务端连接管理的复杂度——需要维持长连接，并在中途处理客户端断连等情况。
三、分布式架构模式：突破单节点边界
当单节点的算力与显存无法支撑模型需求或吞吐量目标时，必须引入分布式策略。以下是四种经典并行范式。
3.1 Tensor Parallel（TP）：节点内切分
Tensor Parallel 将模型的单一 layer 沿着张量维度切分到同一节点内的多张 GPU 上。以 Transformer 为例，可以将 attention 头的计算分配到不同 GPU，每张卡只计算部分注意力结果，再通过 all-reduce 聚合。TP 的优势在于通信量相对可控（NVLink 带宽通常可达数百 GB/s），适合单节点内的多卡场景。例如，一台 8xA100 的机器通常将 TP 设为 8，让 70B 模型并行加载。
3.2 Pipeline Parallel（PP）：跨节点分层
Pipeline Parallel 将模型按层（layer）切分为多个 stage，每个 stage 部署在不同节点上。请求像流水线一样依次经过各 stage。PP 的优势是可以扩展到数十甚至上百张 GPU，但需要处理流水线气泡（pipeline bubble）——即某些 stage 在等待上下游数据时的空闲。通过 micro-batching（将一个 batch 拆分为更小的微批次交错送入流水线），可以显著降低气泡率。
3.3 Data Parallel（DP）：多副本吞吐
Data Parallel 是最直觉的扩展方式：部署多个完整的模型副本，由负载均衡器将请求分发到不同副本。DP 主要用于提升系统总吞吐量，而非降低单个请求的延迟。在请求量足够大的情况下，DP 几乎线性地扩展处理能力。
3.4 Expert Parallel（EP）：MoE 专用
对于 Mixture-of-Experts（MoE）架构的模型（如 Mixtral、GPT-4 rumored 架构），Expert Parallel 将不同的 expert 模块分布在不同节点上。Top-K routing 决定每个 token 激活哪些 expert，通信模式呈现 all-to-all 特征。EP 的设计需要特别考虑专家负载均衡和通信拓扑优化。
3.5 Disaggregated Serving：Prefill 与 Decode 分离
这是近年来学术界和工业界共同探索的前沿方向。LLM 的生成过程分为两个阶段：Prefill（处理输入 prompt，计算 KV Cache）和 Decode（逐 token 生成输出）。这两个阶段的计算特征截然不同——Prefill 是计算密集型（矩阵乘法占比高），Decode 是内存带宽密集型（受限于加载 KV Cache 和权重的速度）。
通过将 Prefill 集群和 Decode 集群物理分离，可以针对各自特性独立优化：
- Prefill Pool：使用高算力 GPU（如 H100），追求高吞吐和短 TTFT。
- Decode Pool：使用高带宽 GPU（或相同 GPU 但调度策略不同），batch 尽可能大以摊薄内存带宽开销。
这种"解耦"设计使得两个阶段的资源可以独立扩缩容，避免了传统方案中 Prefill 和 Decode 互相拖累的问题。
四、服务基础设施：连接模型与客户端
4.1 会话亲和性（Session Affinity）
前文提到 KV Cache 是有状态的。在多副本 DP 场景下，如果同一对话的后续请求被路由到不同实例，先前计算的 KV Cache 将全部作废，造成巨大的性能损耗。因此，负载均衡器必须支持 Session Affinity（会话亲和性），通常基于 session_id 或用户标识进行 Consistent Hashing，确保同一对话始终命中同一实例。
4.2 负载均衡策略
| 策略 | 适用场景 |
|---|---|
| Round-robin | 无状态、同质服务，不推荐用于有状态推理 |
| Least-latency | 实时选择当前响应最快的实例，适合延迟敏感场景 |
| Consistent Hashing | 有状态服务，保证 session 亲和性 |
| Queue-depth based | 基于各实例的请求队列长度分发，避免热点 |
生产环境中，通常会采用组合策略：先按 consistent hashing 保证亲和性，再在对应实例过载时触发限流或迁移。
4.3 自动扩缩容（Auto-scaling）
- Horizontal Scaling（水平扩展）：增加模型副本数。受制于 GPU 供应和启动时间（冷启动可达 5-15 分钟），需结合预测性扩缩容（基于历史流量模式预扩容）。
- Vertical Scaling（垂直扩展）：更换更强型号 GPU 或增加单节点 GPU 数量。适合长期稳定的负载增长，但不适合应对突发流量。
4.4 冷启动与模型预热
GPU 实例的冷启动是行业公认的痛点。缓解方案包括：
- 保持最低副本数（min replicas）：即使低峰时段也保留 1-2 个实例 warm。
- 模型权重预热池：提前将模型加载到处于"standby"状态的 Pod，收到流量后秒级激活。
- Checkpoint 快照恢复：利用快照技术将已加载的状态快速恢复到新实例。
4.5 限流与公平调度
API 服务需要防止单一用户耗尽系统资源。典型的限流策略包括：
- RPM / TPM 限制：每分钟请求数和每分钟 token 数双维度限制。
- Token Bucket：平滑突发流量，允许一定的瞬时峰值。
- 用户优先级队列：为付费高级用户保留 fast lane。
五、缓存策略：减少重复计算
5.1 Prefix Caching
如果不同的请求共享相同的前缀（例如系统 prompt、RAG 检索的固定上下文），可以将前缀部分的 KV Cache 计算一次并复用。vLLM 和 SGLang 等框架已原生支持 Prefix Caching，实测可将共享前缀场景下的首 token 延迟降低 50%-80%。
5.2 Semantic Cache
基于向量数据库，将历史请求的 embedding 存储起来。当新请求到来时，计算语义相似度，若找到足够相似的先前请求且答案仍有效，则直接返回缓存结果，无需调用模型。适用于 FAQ、客服等对精确一致性要求不高的场景。
5.3 Result Cache
对于完全确定性的 prompt（如固定模板的结构化数据提取），可以使用精确的哈希缓存。命中率虽低，但一旦命中收益极大。
5.4 缓存失效策略
LLM 缓存的失效是复杂问题，因为模型输出不仅取决于 prompt，还取决于 temperature、top_p 等采样参数，以及模型的版本。建议将采样参数和模型版本号纳入缓存 key，并为语义缓存设置 TTL（Time-To-Live）和手动 flush 机制。
六、可观测性：洞察系统状态
没有可观测性的系统如同盲人摸象。LLM 推理服务需要关注以下核心指标：
| 指标 | 含义 | 典型目标 |
|---|---|---|
| TTFT (Time To First Token) | 从请求发起到首 token 返回的时间 | < 200ms（小模型）/ < 1s（大模型） |
| TPOT (Time Per Output Token) | 每生成一个 output token 的平均时间 | < 50ms/token |
| Throughput | 每秒生成的 token 数（系统级） | 最大化 |
| Queue Depth | 等待处理的请求队列长度 | < 10，> 50 触发告警 |
| GPU 利用率 | 计算单元利用率 | 保持 > 70% |
| GPU 显存占用 | 显存使用率 | < 90%，预留余量给 KV Cache 增长 |
特别需要强调的是 Queue Buildup（队列堆积）告警。由于 GPU 资源弹性差，队列一旦开始堆积，恢复时间极长，必须在队列深度达到阈值时立即触发告警甚至自动扩容。
七、生产实践案例
7.1 OpenAI API 架构（基于公开信息推断）
从 OpenAI 公布的系统卡（System Card）和技术博客中，可以窥见其架构特征：
- 多模型池：GPT-4 系列可能包含多个不同规模的专家模型，通过 routing 层选择最合适的模型处理请求。
- 动态 batching：利用 continuous batching 最大化 GPU 利用率。
- 全局调度器：跨数据中心的全局负载均衡，结合用户地理位置和请求特性进行路由。
- 严格的限流和配额管理：不同 tier 的用户拥有不同的 TPM/RPM 上限。
7.2 云厂商 LLM 服务模式
主流云厂商（AWS Bedrock、Azure OpenAI、Google Vertex AI）的托管服务，普遍采用如下模式：
- Provisioned Throughput：用户购买固定吞吐配额，云厂商保证资源预留。
- On-Demand：按实际调用付费，适合探索性使用，但高峰期可能遭遇限流。
- Multi-tenant isolation：通过容器和虚拟化技术实现租户间的资源隔离。
7.3 成本优化实践
一家实际运营 LLM 服务的中型公司可以采取以下成本优化策略：
- 模型蒸馏（Distillation）：用大模型生成数据，训练小模型处理常见请求，只有复杂请求才落入大模型。
- 请求分类路由（Request Routing）：通过轻量级分类器判断请求复杂度，简单请求路由到 7B 模型，复杂请求路由到 70B 模型。
- Spot/Preemptible GPU 利用：对于可容忍中断的离线批处理任务，使用抢占式实例降低成本 60%-90%。
- KV Cache 压缩：通过量化（如 KV Cache INT8）和驱逐策略，在显存受限场景支持更大 batch size。
结语
LLM 推理服务架构是一个横跨模型系统、分布式计算和服务工程的交叉领域。从单机中的 PagedAttention 和 Continuous Batching，到分布式场景下的 TP/PP/DP 组合，再到 Prefill-Decode 解耦的前沿探索，每一个技术选择都深刻地影响着用户体验和运营成本。
对于正在建设 LLM 推理平台的团队，建议遵循"先优化单机效率，再按需扩展分布式，最后围绕业务特征定制调度策略"的路径演进。毕竟，再精妙的分布式架构，也无法弥补单机层面的资源浪费。
参考资料：vLLM 论文（PagedAttention）、SGLang 文档、NVIDIA TensorRT-LLM 最佳实践、OpenAI 系统卡、DistServe（Prefill-Decode 解耦论文）
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。