系统跑通只是第一步，能在生产环境稳定运行才是关键。
对于相似的高频提问，可以优先复用经过权限校验的检索结果、文档 ID、摘要片段或模型响应。不能仅凭 query embedding 相似就绕过 RAG 和权限检查直接返回旧答案。
- 使用
GPTCache或 Redis。 - 原理：计算 query embedding，若与缓存中问题的相似度高于阈值，再确认租户、ACL、知识库版本、提示词版本、模型版本和输出策略一致；返回前仍需重新验证读权限和内容时效性。
LLM 生成速度较慢，必须使用 Server-Sent Events (SSE) 或 WebSocket 实现流式响应，让用户立刻看到首字，降低心理延迟。
Python 后端可使用 FastAPI + uvicorn 等异步框架，网络 I/O 密集型任务（如请求模型 API、查询数据库）尽量使用 async/await。
编写 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 持续优化与迭代