> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/14_practice/14.5_deployment_optimization.md).

# 14.5 性能优化与部署

系统跑通只是第一步，能在生产环境稳定运行才是关键。

## 14.5.1 性能优化

### 语义缓存

对于相似的高频提问，可以优先复用经过权限校验的检索结果、文档 ID、摘要片段或模型响应。不能仅凭 query embedding 相似就绕过 RAG 和权限检查直接返回旧答案。

* 使用 `GPTCache` 或 Redis。
* **原理**：计算 query embedding，若与缓存中问题的相似度高于阈值，再确认租户、ACL、知识库版本、提示词版本、模型版本和输出策略一致；返回前仍需重新验证读权限和内容时效性。

### 流式输出

LLM 生成速度较慢，必须使用 Server-Sent Events (SSE) 或 WebSocket 实现流式响应，让用户立刻看到首字，降低心理延迟。

### 异步并发

Python 后端可使用 `FastAPI` + `uvicorn` 等异步框架，网络 I/O 密集型任务（如请求模型 API、查询数据库）尽量使用 `async/await`。

## 14.5.2 部署方案

编写 `Dockerfile`，将应用、依赖库打包。下面只展示骨架；真实部署还需要 `main.py`、依赖清单、锁文件、健康检查、非 root 用户和环境变量配置。建议使用 Multi-stage build 减小镜像体积。

```
FROM python:3.10-slim as builder
# ... install dependencies ...

FROM python:3.10-slim
COPY --from=builder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages
COPY . /app
WORKDIR /app
CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]
```

### 模型推理与基础设施优化

如果是私有化部署核心的语言模型引擎，系统级的底层优化对于降低延迟、提高吞吐（Goodput）并控制服务器成本（TCO）至关重要：

* **PagedAttention 与显存池化**：传统的静态连续显存分配会导致显存碎片化。现代推理引擎（以 vLLM 首创）引入了类似于操作系统虚拟内存分页的 PagedAttention 机制，将 KV Cache 切分成固定大小的物理块。此举可将显存浪费率从约 60%-80%（vLLM 论文口径）压降至极低水平，使得单卡可同时承载数倍于以往的并发请求。
* **全局状态管理与 Prompt Caching**：对于高频复用的系统设定、知识库模板或智能体的系统级工具定义，系统不需要每次从头计算。前沿框架（如 SGLang 的 Radix Attention）在显存中维护一棵全局并发的基数树（Radix Tree），匹配到历史前缀即可直接复用 KV Cache 物理块，显著减少 Prefill 阶段的计算开销。
* **分离式架构 (Disaggregated Serving)**：Prefill（计算密集型）和 Decode（访存密集型）在资源诉求上天然互斥。大规模生产集群常将两个阶段解耦：独立的 Prefill 集群负责计算输入，Decode 集群专职生成输出，借助高速 RDMA 网络实现 KV Cache 状态的跨节点传输。这是当前超大规模模型服务的主流部署范式。
* **推理引擎选型**：不同的框架在取向上有所差异，例如注重开箱即用及广泛生态兼容的 vLLM、代表 NVIDIA 算力天花板的 TensorRT-LLM、或是针对多轮复杂推理且深度优化状态机并行的 SGLang 等，建议结合具体的并发负载特征与 GPU 硬件资源进行压测选型。

### 开源模型与闭源模型的推理权衡

在生产部署中，选择自建模型还是托管 API 对上下文工程策略有直接影响。不要按固定百分比或可用性口号做判断，应基于业务 SLO、团队运维能力、合规要求、硬件折旧、事故响应和压测结果评估：

* **延迟控制**：托管 API 减少基础设施负担，但尾延迟受外部服务和网络影响；自建模型可针对实时应用优化，但需要稳定的容量管理
* **可用性**：托管 API 的可用性取决于供应商 SLA 和降级策略；自建部署的可用性取决于集群冗余、值班能力和故障演练
* **成本**：小规模或波动负载通常更适合托管 API；高吞吐、稳定负载需要把 GPU 利用率、工程人力、折旧、电力和备份容量一起纳入 TCO
* **上下文控制**：自建模型更容易实现自定义前缀缓存、KV 缓存量化和分离式推理；托管 API 更容易获得模型更新和安全补丁

对于需要极致延迟、强数据驻留或高度定制推理链路的场景，自建推理基础设施可能更合适。对于原型验证、峰谷明显或团队运维能力有限的场景，托管 API 往往更稳妥。

### 推理基础设施的自动扩缩容

当上下文工程系统投入生产后，自动扩缩容成为保障服务质量的关键。扩缩容决策可基于两类信号：

* **利用率信号**：根据 GPU 显存使用率或计算使用率进行扩缩。这是滞后指标，适合作为兜底策略
* **流量信号**：根据系统中正在处理的请求数量进行扩缩。流量信号可以主动预判，响应更及时

两者应结合使用。关键配置参数包括：最小副本数（保证冷启动响应）、最大副本数（控制成本上限）、扩缩窗口（衡量流量的滑动时间窗）、缩容延迟（防止流量抖动导致频繁缩容）和并发目标（每个副本可处理的同时请求数）。

***

**下一节**: [14.6 持续迭代与改进](/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/14_practice/14.6_optimization.md)