# 11.5 生产部署最佳实践

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

## 11.5.1 关键性能指标

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

* **首词延迟**（Time to First Token，TTFT）：从收到请求到返回第一个生成词元的时间，直接影响用户感知的响应速度。通常要求 < 500ms
* **每词延迟**（Time Per Output Token，TPOT）：生成每个后续词元的平均时间，影响流式输出的流畅度。通常要求 < 50ms
* **吞吐量**（Throughput）：单位时间内处理的请求数或生成的词元数
* **请求延迟 P99**：99% 的请求在此时间内完成，衡量尾部延迟的可控性
* **Goodput**（有效吞吐）：在满足 SLA 约束（如 TTFT < 200ms、TPOT < 50ms）的前提下，系统实际达成的吞吐量。与原始吞吐量不同，Goodput 反映了真实用户体验下的有效产出，是评估推理系统架构优化效果的更准确指标。

此外，**单词元成本**（Cost per 1K Tokens）是衡量不同架构整体经济效益的终极指标。它综合考虑了硬件成本、电费、网络、存储等全生命周期成本，与达成相同 Goodput 所需的 GPU 时长绑定，直接影响大规模推理集群的运营成本。

## 11.5.2 业界部署案例

**Moonshot AI Mooncake**：国内领先的 AI 推理基础设施，核心架构以 **KV Cache 为中心**（Cache-centric Architecture）。不同于标准的 Compute-centric 设计，Mooncake 将 KV 缓存存储与计算解耦：前端 API 网关维护全局的跨实例 KV Cache 索引，对每个请求进行缓存亲和性路由。通过这种设计，Mooncake 实现了 **525% 的吞吐量提升**相比单实例部署，同时保持了低延迟。

**xAI Colossus**：公开报道显示 xAI 构建了超大规模 GPU 集群，并采用以太网/RoCE 相关方案探索大规模训练与推理。公开材料不足以证明其所有集体通信场景都已达到与 InfiniBand 完全等价的性能，因此更适合把它视为“高速以太网路线正在进入超大规模 AI 集群”的案例，而不是通用结论。

**Meta / 开放模型基础设施**：Meta 在 Llama 系列训练中公开披露过大规模 GPU 集群、RoCE 网络和系统层优化经验。对于推理侧的前缀缓存、KV 缓存预热或跨域缓存服务，除非有明确公开资料支撑，应作为通用工程模式讨论，而不要直接写成某一公司的确定部署细节。

**Google Gemini 基础设施**：采用 TPU v5e/v6e 集群，创新之处是**光电混合动态交换网络**（Optical-Electrical Circuit Switching）。不同于固定的网络拓扑，Google 的拓扑在数秒级动态重配置，优化 All-Reduce 和点对点通信的路径。这使得在相同物理设备下，可根据工作负载特征动态调整网络连接，达到接近理论最优带宽利用率。

这些案例共同揭示的趋势是：**超大规模推理不再以单一框架或硬件为中心，而是整体系统优化**——网络拓扑的设计、缓存策略、调度算法、硬件选型、安全评估和可观测性等各层面的协同演化，才是达成稳定生产性能的关键。

## 11.5.3 AI 网关

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

* **统一路由模型**：屏蔽底层不同供应商或自建集群的 API 差异，提供统一的 OpenAI 兼容接口
* **降级与熔断**：主模型集群故障或延迟激增时，自动降级请求到备用模型或云端 API
* **A/B 测试与流量灰度**：支持按百分比将流量切分到新版本的模型或系统上
* **成本与计费**：统一记录 Token 计算消耗，支持多租户计费

## 11.5.4 流式输出

**流式输出**（Streaming）是提升用户体验的关键技术。不等整个回答生成完毕再返回，而是**边生成边返回**——用户看到文字逐步出现，感知延迟大幅降低。这对 TTFT（首词延迟）指标至关重要：虽然 Prefill 的总时间没有减少，但由于首个词元生成后立即返回用户，用户感知的 TTFT 只取决于 Prefill + 单步 Decode 的时间，通常在 500-1000 ms 内。

实现上，推理引擎在每个解码步将新生成的词元通过 Server-Sent Events（SSE）或 WebSocket 实时推送到客户端。关键工程细节：

* 在推理引擎确认第一个词元前，网关应维护连接但不建立 HTTP 响应体，避免重复握手延迟
* 后续词元以 1-50 ms 间隔批量推送（取决于 TPOT），平衡延迟和网络开销
* 服务间高 QPS、二进制协议和双向流场景可考虑 gRPC；面向浏览器的单向文本流通常 SSE 更简单。协议差异带来的 per-token 开销必须用本系统基准验证，不能写成固定毫秒数。

主流推理引擎（vLLM、SGLang 等）均原生支持流式输出，与 AI 网关（如 LiteLLM）集成时能将 TTFT 控制在目标范围内。

## 11.5.5 负载均衡与调度

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

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

* **状态注入**：网关感知各个后端实例当前的 KV Cache 占用率和请求队列长度
* **前缀路由**：基于前缀缓存（见 11.2.4）的命中率来路由请求。将共享相同前缀（如长系统提示或同一份文档）的请求路由到同一个实例，最大化 KV 缓存的复用

## 11.5.6 可观测性

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

* **微观延迟拆解**：追踪请求在排队、Prefill 计算、Decode 循环以及网络传输等各个阶段的耗时
* **性能监控**：实时监控显存使用率中的 KV Cache 占比、连续批处理的平均 Batch Size 等指标
* **漂移检测**：监控请求输入分布和输出长度的变化趋势，及时发现模型表现衰减或异常访问

## 11.5.7 成本优化策略

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

* **模型量化**：INT8/INT4/FP8 量化可大幅降低显存需求
* **合适的模型选择**：并非所有任务都需要最大的模型，使用较小的专门模型（或蒸馏模型）在特定任务上可能以更低成本获得同等效果
* **请求优先级排队**：根据请求优先级（如实时对话 vs 离线批处理数据清洗）分配资源，离线请求填补服务器空闲算力
* **语义缓存**：利用 GPTCache 等工具缓存高频问题的结果，对语义相似的请求直接返回缓存。缓存 key 和检索隔离边界必须纳入 tenant、auth scope、model/version、system prompt、tool state、PII 标记等上下文；包含私有文档、工具输出或 PII 的响应默认禁止跨用户语义缓存

## 11.5.8 安全与合规

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

* **输入输出护栏**：部署多层检测机制保护系统：
  * **规则层**：NeMo Guardrails（NVIDIA）使用 Colang DSL 定义意图和约束规则，轻量级快速，适合已知风险的防护
  * **分类层**：Llama Guard 应按版本选择。Llama Guard 3-8B 是轻量文本安全分类器；Llama Guard 4-12B 则面向多模态安全分类。生产选型需要按模态、延迟、成本、误报/漏报和本地策略覆盖范围做评估
  * **重排序层**：对高风险输出进行上下文重排序或过滤重新生成，增加安全成本但有效性更高
* **数据隐私**：确保用户交互数据不被反向工程或误用于训练，对输入敏感信息（如 PII 数据）进行脱敏处理
* **速率限制**：在网关层防范恶意的高并发 Token 消耗攻击（Token-level Rate Limiting），同时监控单用户、单 IP 的 token 消耗速率
* **上线前后评估闭环**：为越权工具调用、提示注入、数据外泄、拒答/误答和高风险领域输出建立回归集；新模型、新提示词、新工具或新检索源上线前必须跑安全评估，上线后持续监控漂移和真实事故样本

## 11.5.9 前沿部署挑战

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

* **多模态推理**：如 GPT-4o、Gemini 等原生多模态模型的部署面临多个新维度的挑战：
  * **编码计算分离**：图像编码（Vision Transformer）和视频帧提取计算量巨大，通常需要从 LLM 推理集群中物理分离为独立的多模态编码集群，然后将嵌入向量传递给 LLM
  * **不对齐的 KV 缓存**：视觉和文本信息的 Token 序列长度差异巨大（图像可能 1000+ tokens，文本仅数十），PagedAttention 的页面大小设置需要重新调优，可能降低显存利用率
  * **流式多模态输出**：除了文本流式输出，还需支持图像/视频的渐进式生成和流式返回，对网络带宽和客户端渲染能力要求高
  * **模态同步延迟**：多轮对话中视觉特征重新计算成本高，需要在推理引擎侧实现跨轮的多模态缓存管理，类似于文本的前缀缓存
* **超长上下文管理**：支持 128K-1M Token 上下文窗口的模型对长文本推理提出了极限要求。单卡显存通常无法容纳超长序列的 KV 缓存，需要结合跨设备并行、KV 缓存压缩和分级存储。**Ring Attention** 等序列维度分布式注意力方案可将长序列切分到多设备处理，但是否能以可接受延迟支撑 1M+ Token 生产流量，仍取决于模型结构、批量大小、网络带宽和服务 SLA。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/llm_internals/di-san-bu-fen-tui-li-yu-bu-shu-pian/11_serving/11.5_best_practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.