LLM 应用交付的阻碍，通常不只在于模型能否回答特定问题，因为可以通过路由处理无法回答的请求。更常见的困难是达到 p95 延迟目标、保持成本可预测、发布时维持生产服务，以及提示模板意外变化后快速恢复。部署架构为处理这些问题提供基础。
本课将常见 LLM 工作负载与部署模式对应，讨论支持可靠交付的架构选择。
根据需求选择部署模式
系统通常受到服务等级目标（SLO）和其他条件限制，架构需要结合这些要求。
- 延迟目标：聊天界面通常希望首个 token 时间（Time To First Token，TTFT）低于一秒，并流式显示输出。后台任务可以等待数分钟或数小时。实时聊天与工单系统的要求不同，后者允许的答复时间可能是一小时到数天。
- 吞吐量与并发：需要判断系统处理的是少量复杂请求，还是大量小请求。
- 成本：使用厂商 API、自托管 GPU，或混合方式；每次请求、每个 token 或每项任务的成本是否足够可预测。
- 工作负载类型：交互聊天、频繁调用工具的智能体流程、以检索为主的任务，或者离线批处理。
- 变化频率：提示和工具更新多频繁，是否需要通过流量分配或功能开关支持持续交付。
评估下面的模式时，应始终结合这些要求。
部署模式
模式一：边缘流式服务连接无状态 API
交互界面通常重视首个 token 的出现时间。提供商开始输出后，浏览器应尽快接收内容。边缘函数可以接收 LLM 流式响应，再通过 Server-Sent Events（SSE）或流式 fetch 将数据块转发给客户端，减少等待完整回答的时间。
实现：浏览器连接边缘函数，函数以流式方式调用模型提供商，并转发 token。如果应用位于 NGINX 或 ingress 后面，需要检查流式路径的代理缓冲设置，使数据块能够及时发送。例如，OpenAI API 的 stream=true 使用 SSE，Cloudflare Workers 和 Vercel Edge 等运行环境支持 Web Streams。NGINX 中可能需要将 proxy_buffering 设置为 off。
适用情况：聊天或 copilot 类界面，用户感知速度主要取决于 TTFT。
SLO：有助于改善首个 token 时间和交互体验；模型自身的等待时间仍然存在，但用户可以看到生成进度。
扩展：边缘服务可以按 Point of Presence（PoP，服务部署节点）水平扩展。
成本：转发层计算成本通常较低，主要开销仍来自 token。
安全：模型提供商凭据保留在边缘服务中，并由服务执行认证，不应暴露给浏览器。
注意事项：
- 代理缓冲会影响流式输出，应针对实际流式路径检查 NGINX 和 ingress 配置。
- 区域选择会影响延迟及数据位置要求；需要限制地理范围时，应配置适当运行区域。
模式二：应用容器与可选 Sidecar
标准微服务架构可以统一处理 TLS、认证、速率限制、熔断和日志，让应用容器集中处理流程管理、工具调用及 RAG。可选 Sidecar 可以负责出口策略、重试和流式转发，将通用基础设施功能集中管理。
- AI 智能体
- 多个智能体读取低延迟存储中的外部上下文。
- 负载均衡器
- 通过 gRPC 与智能体双向通信，并连接后端服务。
实现：客户端经 API gateway 访问应用容器。Sidecar 处理 TLS、路由、熔断、认证和连接等通用功能。
适用情况：需要具备流式输出、重试、熔断及统一日志的微服务入口，应用调用一个或多个模型提供商、工具和向量存储。
SLO：适用于许多 SaaS 类 LLM 功能，gateway 和 Sidecar 会增加少量开销。
扩展：Kubernetes 的 Horizontal Pod Autoscaler（HPA）可以根据 CPU，以及正在处理的请求数或每秒 token 数等自定义指标水平扩展。
成本：应用服务资源较便于估算，主要成本仍可能来自下游 token 或 GPU 时间。
注意事项：
- 流式响应经过 gateway 时，应确认它能够转发分块响应或 SSE，并关闭不适当的缓冲。
模式三：采用队列分配负载的异步流程
这种模式在智能体流程中使用事件驱动处理：快速确认请求，再将工作写入持久队列。根据队列深度扩展执行者，为所有副作用操作设置幂等标识，并配置无法处理消息的隔离队列。它可以吸收突发流量，支持长时间智能体任务，并提高尾部延迟及成本的可管理性。
- AI 智能体
- 接收流式输入，并使用低延迟存储中的外部上下文。
- 推理结果存储
- 存储智能体输出的结果，供后端服务使用。
实现：入口 API 返回 HTTP 202 和任务 ID，请求写入 SQS、Kafka 等持久队列或日志。执行者读取任务并处理，通过状态端点、webhook 或另一队列通知完成。这是典型的队列负载分配模式。
适用情况：请求可以立即确认、稍后完成，例如长报告、多工具智能体执行、大量数据提取，或需要承受突发流量的应用。
SLO：适合提高吞吐量并平滑资源开销，用户接受较长完成时间，以获得可靠性和扩展能力。
扩展：调整连接工作队列的智能体执行者副本数量。
成本：不需要本地模型推理的执行者可以运行在较低成本 CPU 节点上，配合按需缩放，在有任务时分配资源。
注意事项：
- 重试可能导致消息重复处理，因此操作必须具备适当幂等性，并配置去重机制。
- 设置退避和无法处理消息的隔离队列，防止单项错误阻碍整个流程。
模式四：批处理与离线推理
大量历史数据处理，以及定期归纳、标注或重新计算 embedding，可以通过批处理端点或 DAG 从对象存储读取输入，再写回结果。输入应划分为可重复执行的分区，配合检查点使用 Spot 或可抢占节点，并设置重试及慢任务处理策略。这种模式重点优化吞吐量和可预测完成时间。
- AI 智能体
- 通过 Apache Airflow 调度，处理输入数据批次。
- 推理结果存储
- 结果写入批量存储，也可载入低延迟存储；两者均连接后端服务。
实现：智能体作为 ETL/ELT 的一部分定时运行，通常表现为 CLI 脚本，由 Apache Airflow 等工具调度。任务读取累积工作，按需连接外部上下文和工具，再将结果保存到批量存储。计算结果也可以加载到低延迟存储，供实时应用使用。
适用情况：按计划高吞吐量处理大型资料集合，例如夜间归纳、文档评分、日志或工单标注、客户线索资料补充、敏感内容遮盖，以及采用新提示重新处理历史数据。
SLO：任务可以持续数分钟至数小时，但需要可靠地预测完成时间。
扩展：使用任务队列，并将输入分区设置为适合执行者容量的大小。
成本：批量方式通常有利于降低大规模处理开销。非紧急任务可以使用 Spot 或可抢占节点，保存检查点以便恢复。
可靠性措施：
- 分区幂等：按分区 ID 重复执行，使用分区 ID 保存中间结果。
- 按至少一次执行设计：预期节点故障或抢占后任务会再次运行。
- 处理慢任务：减小过大的分区，并将执行过慢的任务重新排队。
选择部署模式的检查清单
- 交互聊天、重视感知速度：采用模式一，或支持流式响应的模式二。
- 突发流量或长时间步骤：采用模式三，结合队列负载分配及幂等处理。
- 夜间任务或历史数据处理：采用模式四，结合托管批处理端点、Airflow 或 Argo。
实际系统常组合两种或三种模式，例如聊天界面采用模式一，耗时工具任务交给模式三。