# 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 切分成固定大小的物理块。此举可将显存浪费率从约 80% 压降至极低水平，使得单卡可同时承载数倍于以往的并发请求。
* **全局状态管理与 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)


---

# 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/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/14_practice/14.5_deployment_optimization.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.