11.5 生产部署最佳实践

将 LLM 从实验环境部署到生产环境需要关注延迟、吞吐量、成本和可靠性之间的平衡。完整的生产系统远不止一个推理引擎。

11.5.1 关键性能指标

生产环境中最重要的性能指标包括：

• 首词延迟（Time to First Token，TTFT）：从收到请求到返回第一个生成词元的时间，直接影响用户感知的响应速度。通常要求 < 500ms

• 每词延迟（Time Per Output Token，TPOT）：生成每个后续词元的平均时间，影响流式输出的流畅度。通常要求 < 50ms

• 吞吐量（Throughput）：单位时间内处理的请求数或生成的词元数

• 请求延迟 P99：99% 的请求在此时间内完成，衡量尾部延迟的可控性

11.5.2 AI 网关（LLM Gateway）

在真实的生产架构中，应用侧很少直接调用底层推理引擎的 API。两者之间通常会部署一层 AI 网关（如 LiteLLM、Kong 等），提供不可或缺的工程能力：

• 统一路由模型：屏蔽底层不同供应商或自建集群的 API 差异，提供统一的 OpenAI 兼容接口

• 降级与熔断：主模型集群故障或延迟激增时，自动降级请求到备用模型或云端 API

• A/B 测试与流量灰度：支持按百分比将流量切分到新版本的模型或系统上

• 成本与计费：统一记录 Token 计算消耗，支持多租户计费

11.5.3 流式输出

流式输出（Streaming）是提升用户体验的关键技术。不等整个回答生成完毕再返回，而是边生成边返回——用户看到文字逐步出现，感知延迟大幅降低。

实现上，推理引擎在每个解码步将新生成的词元通过 Server-Sent Events（SSE）或 WebSocket 实时推送到客户端。主流推理引擎（vLLM、SGLang 等）均原生支持流式输出。

11.5.4 负载均衡与调度

高可用的 LLM 服务需要将流量分散到多个推理实例上。传统的基于 CPU 利用率或连接数的负载均衡对 LLM 并不适用，因为请求的硬件资源消耗极度不均（例如 100 词 Prompt 与 100K 词 Prompt 的差距极大）。

生产环境需要感知 Token 的调度（Token-aware Routing）：

• 状态注入：网关感知各个后端实例当前的 KV Cache 占用率和请求队列长度

• 前缀路由：基于前缀缓存（见 11.2.4）的命中率来路由请求。将共享相同前缀（如长系统提示或同一份文档）的请求路由到同一个实例，最大化 KV 缓存的复用

11.5.5 可观测性（Observability）

LLM 部署的运维（LLMOps）高度依赖针对性的可观测体系：

• 微观延迟拆解：追踪请求在排队、Prefill 计算、Decode 循环以及网络传输等各个阶段的耗时

• 性能监控：实时监控显存使用率中的 KV Cache 占比、连续批处理的平均 Batch Size 等指标

• 漂移检测：监控请求输入分布和输出长度的变化趋势，及时发现模型表现衰减或异常访问

11.5.6 成本优化策略

LLM 推理的 GPU 成本是生产运营的主要支出。常见的优化策略包括：

• 模型量化：INT8/INT4/FP8 量化可大幅降低显存需求

• 合适的模型选择：并非所有任务都需要最大的模型，使用较小的专门模型（或蒸馏模型）在特定任务上可能以更低成本获得同等效果

• 请求优先级排队：根据请求优先级（如实时对话 vs 离线批处理数据清洗）分配资源，离线请求填补服务器空闲算力

• 语义缓存：利用 GPTCache 等工具缓存高频问题的结果，对语义相似的请求直接返回缓存

11.5.7 安全与合规

生产 LLM 服务还需引入护栏（Guardrails）机制：

• 输入输出护栏：部署如 NeMo Guardrails、Llama Guard 等轻量级模型或规则，检测并阻断有害的用户输入（提示注入攻击、越狱等）以及过滤敏感不当的输出

• 数据隐私：确保用户交互数据不被反向工程或误用于训练，对输入敏感信息（如 PII 数据）进行脱敏处理

• 速率限制：在网关层防范恶意的高并发 Token 消耗攻击

11.5.8 前沿部署挑战

随着模型架构的演进，部署层面正面临新的前沿挑战：

• 多模态推理：如 GPT-4o 或 Gemini 级别原生多模态模型的部署面临着图像/视频编码计算、跨模态 KV 缓存管理以及音频流式返回等复杂痛点。

• 超长上下文管理：支持 128K-1M Token 上下文窗口的开源模型（如 Llama 3）对长文本推理提出了极限要求，常常需要 Ring Attention 等跨节点张量并行技术，并将极大地考验底层网络通信。