AI 系统的部署架构模式

在将 LLM 应用交付到生产环境时，真正的工程阻碍往往不在于模型能否回答某个特定问题（超出能力范围的请求可通过路由兜底处理），而在于如何稳定达到 p95 延迟目标、保持成本可预测、在版本发布期间维持服务不中断，以及在提示词模板发生意外变更后快速回滚恢复。合理的部署架构正是应对这些工程挑战的基础。本课将常见的 LLM 工作负载与四类标准部署架构模式一一对应，梳理支撑可靠交付的架构选型方法。

本课将常见 LLM 工作负载与部署模式对应，讨论支持可靠交付的架构选择。

根据需求选择部署模式

生产系统通常受服务等级目标（SLO）与业务约束限制，选型前需从以下五个维度明确需求：

延迟目标（Latency）：实时聊天界面通常要求首个 token 时间（Time To First Token，TTFT）低于 1 秒并流式展示输出；后台异步任务可容忍数分钟乃至数小时的处理耗时；而工单系统允许的答复时间则可能在 1 小时到数天之间。
吞吐量与并发（Throughput & Concurrency）：区分系统主要处理的是少量长链路复杂请求，还是高并发的短小请求。
成本结构（Cost）：评估采用第三方厂商 API、自托管 GPU 还是混合部署，确认单次请求、单个 token 或单次任务的成本是否足够可预测。
工作负载类型（Workload Type）：明确任务属于实时交互式聊天、高频调用工具的智能体流程、以检索为主的问答任务，还是离线批量数据处理。
变更与发布频率（Change Cadence）：评估提示词与工具的迭代频率，判断是否需要配合灰度流量切分或功能开关（Feature Flags）来支持持续交付。

评估下面的模式时，应始终结合这些要求。

四种核心部署架构模式

模式一：边缘流式服务连接无状态 API

实时交互界面极其看重首个 token 的出现时间（TTFT）。一旦模型服务商开始产出 token，浏览器端应尽快接收到内容。该模式通过边缘服务或无状态后端发起流式模型请求，再利用 Server-Sent Events（SSE） 或流式 fetch 将生成的数据块实时转发给客户端，大幅缩短用户面对空白屏幕的等待时间。

在课程实现中，流式模型请求由自有后端服务发起，经 Nginx 反向代理转发 SSE 流；需重点核查流式路径上的 proxy_buffering 配置、空闲连接超时及客户端主动断开后的上游取消逻辑。百炼的聊天流式接口通过设置 stream=true 启用，API Key 严格保留在服务端；若采用托管运行环境，还需单独验证其最大连接时限与流式传输支持能力。

适用情况：聊天助手或 Copilot 类实时交互界面，用户的主观速度感知主要取决于 TTFT。

SLO 表现：有助于改善 TTFT 与交互体验；模型自身的推理耗时虽客观存在，但用户可实时看到逐字生成的进度。

扩展方式：边缘转发层可按服务部署节点（Point of Presence，PoP）或无状态实例水平扩展。

成本特征：转发层自身的计算开销通常很低，主要成本仍取决于下游模型的 token 消耗。

安全：模型提供商凭据保留在边缘服务中，并由服务执行认证，不应暴露给浏览器。

注意事项：

反向代理缓冲会阻塞流式输出，必须针对实际流式路由核查 Nginx 与 Ingress 的缓冲配置。
部署地域的选择会同时影响网络延迟与数据驻留合规要求；有地理范围限制时，应固定配置合规的运行区域。

模式二：应用容器与可选 Sidecar（微服务网关架构）

在标准微服务架构中，由网关或可选的 Sidecar 容器统一接管 TLS 终止、身份认证、速率限制、熔断与访问日志等通用基础设施功能，让核心应用容器专注于工作流编排、工具调用及 RAG 逻辑；Sidecar 还可统一管理出站策略（Egress）、失败重试与流式响应转发。

企业知识应用的部署边界 — 业务后端查询模型和数据服务；独立摄取进程更新知识索引。

实现：客户端经 API gateway 访问应用容器。Sidecar 处理 TLS、路由、熔断、认证和连接等通用功能。

适用情况：需要具备流式输出、重试、熔断及统一日志的微服务入口，应用调用一个或多个模型提供商、工具和向量存储。

SLO：适用于许多 SaaS 类 LLM 功能，gateway 和 Sidecar 会增加少量开销。

扩展：Kubernetes 的 Horizontal Pod Autoscaler（HPA）可以根据 CPU，以及正在处理的请求数或每秒 token 数等自定义指标水平扩展。

成本：应用服务资源较便于估算，主要成本仍可能来自下游 token 或 GPU 时间。

注意事项：

流式响应经过 gateway 时，应确认它能够转发分块响应或 SSE，并关闭不适当的缓冲。

模式三：采用队列分配负载的异步流程（Queue-Based Load Leveling）

针对耗时较长或流量波动剧烈的智能体工作流，采用事件驱动的异步解耦架构：入口服务收到请求后立即落盘写入持久化队列并快速向客户端返回确认；后台工作进程（Workers）按队列积压深度弹性扩缩容，并为所有包含外部副作用的操作绑定幂等标识，同时配置死信隔离队列（DLQ）存放无法处理的异常消息。这种模式能够有效削峰填谷，支撑长耗时多步智能体任务，使长尾延迟与算力成本更加可控。

流式推理部署 — Agent消费流式输入并结合外部上下文，把推理结果写入流式存储供后端服务使用。

实现：入口 API 返回 HTTP 202 和任务 ID，请求写入 SQS、Kafka 等持久队列或日志。执行者读取任务并处理，通过状态端点、webhook 或另一队列通知完成。这是典型的队列负载分配模式。

适用情况：请求可以立即确认、稍后完成，例如长报告、多工具智能体执行、大量数据提取，或需要承受突发流量的应用。

SLO：适合提高吞吐量并平滑资源开销，用户接受较长完成时间，以获得可靠性和扩展能力。

扩展：调整连接工作队列的智能体执行者副本数量。

成本：不需要本地模型推理的执行者可以运行在较低成本 CPU 节点上，配合按需缩放，在有任务时分配资源。

注意事项：

重试可能导致消息重复处理，因此操作必须具备适当幂等性，并配置去重机制。
设置退避和无法处理消息的隔离队列，防止单项错误阻碍整个流程。

模式四：批处理与离线推理（Batch & Offline Inference）

面对海量历史数据处理、定期摘要归纳、离线数据标注或全量重算 embedding 等非实时任务，可通过专用批处理端点或由 DAG 调度器从对象存储批量读取输入、分片处理后再将结果写回存储。输入数据应切分为支持重复执行的独立分区（Partitions），配合检查点（Checkpoint）机制利用低成本的竞价实例（Spot / Preemptible Instances），并配置慢任务（Stragglers）重排策略，重点优化整体吞吐量与完成时间的可预测性。

Batch 作业与逐行结果 — 本地 JSONL → 上传与创建 → 查询状态 → 结果与错误文件 → 按 ID 合并 → 报告与恢复

实现：智能体作为 ETL/ELT 的一部分定时运行，通常表现为 CLI 脚本，由 Apache Airflow 等工具调度。任务读取累积工作，按需连接外部上下文和工具，再将结果保存到批量存储。计算结果也可以加载到低延迟存储，供实时应用使用。

适用情况：按计划高吞吐量处理大型资料集合，例如夜间归纳、文档评分、日志或工单标注、客户线索资料补充、敏感内容遮盖，以及采用新提示重新处理历史数据。

SLO：任务可以持续数分钟至数小时，但需要可靠地预测完成时间。

扩展：使用任务队列，并将输入分区设置为适合执行者容量的大小。

成本：批量方式通常有利于降低大规模处理开销。非紧急任务可以使用 Spot 或可抢占节点，保存检查点以便恢复。

可靠性措施：

分区幂等：按分区 ID 重复执行，使用分区 ID 保存中间结果。
按至少一次执行设计：预期节点故障或抢占后任务会再次运行。
处理慢任务：减小过大的分区，并将执行过慢的任务重新排队。

选择部署模式的检查清单

实时交互聊天、追求极致首字响应速度：选用模式一，或开启了全链路流式透传的模式二。
存在突发流量洪峰或包含耗时较长的多步工具调用：选用模式三，配合持久化队列削峰与幂等处理。
夜间定时作业或海量历史数据离线重跑：选用模式四，结合服务商原生 Batch API、Airflow 或 Argo Workflows。

在实际生产系统中，往往会将两到三种模式组合使用——例如前端聊天交互采用模式一/二保障低延迟体验，而将对话中触发的长耗时深度调研或批量导出任务异步卸载至模式三处理。

在国内服务器部署后端与服务边界

课程教学应用由 Nginx、FastAPI、独立摄取进程、Qdrant、PostgreSQL 与自托管 Langfuse 组成：数据库与模型 API 密钥严格保存在服务端内网，浏览器仅接收流式回答输出。若在生产环境中进一步引入托管计算、对象存储或托管 Kubernetes，则需对照下表分别核验阿里云各组件的网络隔离、RAM 身份与运维能力：

练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。

部署企业知识应用的服务边界

所需能力	国内运行方式	接入与验收内容
虚拟机计算	ECS	镜像、磁盘、网络、访问身份与服务管理
Kubernetes 管理	ACK	集群、命名空间、工作负载身份、资源与服务发现
镜像仓库	ACR	实例、地域、仓库路径、读写凭据和镜像 digest
对象存储	OSS	Bucket、endpoint、对象权限、加密和生命周期
数据库	RDS PostgreSQL	连接字符串、版本、账号权限、备份和迁移
云身份	RAM	角色、临时凭据与目标服务权限；授权模型独立配置
短时任务	函数计算	触发方式、执行时限、并发、重试和持久状态
教学自托管	Linux + Nginx + FastAPI + Qdrant + PostgreSQL	服务器本地服务端配置，数据库保持内网访问

在运行职责划分上，浏览器仅访问 Nginx 与 FastAPI 业务后端；业务后端统一完成用户身份认证、ACL 权限过滤、向量检索与模型调用。独立的摄取进程负责管理资料版本与同步状态，独立的通知工作进程负责消费 outbox 表发送告警。Qdrant、PostgreSQL 与 Langfuse 均按各自官方自托管规范部署（部署前需逐项验收资源容量、数据备份与恢复演练、访问身份及内网安全组范围）。

Langfuse 按官方自托管方案配置所需存储和运行服务。部署前验收资源容量、备份、恢复、身份与网络范围。

location /api/stream/ {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_read_timeout 120s;
}

其中 proxy_read_timeout 根据单次请求的最大时间预算设定，且显式设置 proxy_buffering off 以禁用响应缓冲。后端 FastAPI 服务同样需要监听客户端断连事件以取消上游未完成的生成请求，并准确记录最终消耗用量；若部署在 ACK Ingress 或函数计算上，则需按对应平台的流式网关配置逐一验证。离线 Batch 作业则使用独立的任务队列与结果文件，并将任务持久化状态保存在外部数据库中。

练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现；绘制包含浏览器、业务后端、独立摄取进程、向量索引、模型服务与通知服务的完整访问拓扑图，为每条调用路径标明身份凭据、资料权限范围与失败处理方式，并列出需要进行故障恢复演练验收的服务清单。