目录服务架构概述推理引擎服务网关负载均衡弹性伸缩高可用实践建议与最佳实践摘要本文以 Qwen2.5-7B 在单张 A100 80GB 上的部署为基准，拆解推理引擎、服务网关、负载均衡、弹性伸缩、高可用与最佳实践六层架构的量化设计。实测单副本在连续批处理下稳定支撑 50 QPS、P99 首 token 延迟 300ms、P99 生成速度 30 token/s，两权随机路由配合队列深度扩缩容可将 GPU 利用率从 40% 提升到 75% 以上。全文含 21 段可运行源码与 7 张 Mermaid 架构图，覆盖从请求入口到故障恢复的完整链路。1. 服务架构概述模型服务架构要回答三个问题：一条推理请求从客户端发出到完整回复返回经过哪些组件，流量增长或组件故障时系统如何保持可用，以及每层组件承担什么量化职责。与常规 Web 服务不同，LLM 请求的每个 token 都对应一次前向计算，单次请求可能消耗 10 秒级的 GPU 计算时间。服务架构的每一个设计决策都同时影响延迟、吞吐与成本三项目标。客户端层携带会话 ID健康检查通过健康检查通过健康检查失败队列深度 利用率扩容 缩容等待恢复Web 应用批处理任务API 网关 认证 限流负载均衡器推理引擎副本 1推理引擎副本 2副本摘除指标采集扩缩容控制器1.1 目标模型服务的架构目标不是单一指标，而是一组可以度量的服务等级目标，即 SLO。以 Qwen2.5-7B 在单张 A100 80GB 上部署为基准，一组经过压测验证的目标是可用性 99.9%、P99 首 token 延迟 300ms、P99 生成速度 30 token/s、端到端错误率低于 0.5%。这四个数字分别对应可用、响应快、输出稳定、可依赖四类业务诉求。延迟目标要分解到请求的各个阶段，才能定位真正的优化点。一条 512 token 输入的请求在 7B 模型上的典型耗时分布是网络传输 5ms、负载均衡排队 30ms 到 80ms、引擎调度 20ms、prefill 约 120ms、每生成一个 token 的 decode 约 25ms。若输出 512 token，端到端延迟约 13 秒，其中 decode 阶段占绝大部分。因此单纯优化首 token 延迟只能改善启动感知，总延迟的优化必须压在 decode 吞吐上。吞吐与延迟相互掣肘，架构目标必须写成在 P99 延迟不超限的前提下最大化吞吐。提高 batch 大小可以让 GPU 矩阵运算更饱和，单卡吞吐从 batch=1 的 300 token/s 提升到 batch=32 的 2500 token/s。代价是每个请求的 TTFT 会从 120ms 上升到 400ms。在 P99 TTFT 小于 500ms 的约束下，把单副本目标定为 50 QPS，是实测可以同时满足的折中点。成本目标同样要量化，因为 GPU 是模型服务最大的成本项。A100 80GB 在主流云厂商的按量价格约为每小时 2 美元到 3 美元，折合每月约 1500 美元到 2200 美元。若 GPU 利用率只有 40%，等于把一半以上的算力预算浪费在闲置上。架构上通过连续批处理、KV cache 复用与弹性伸缩，把利用率目标定在 70% 到 85% 之间。超过 85% 后排队延迟明显恶化，不足 70% 则说明副本冗余过多。多租户隔离也是目标的一部分，不同业务线共用一个推理池时必须保证一个租户的突发流量不拉高其他租户的延迟。常用手段是每租户设置独立的速率配额与优先级队列，这部分在 3.3 节展开。隔离的代价是资源不共享，租户越多单副本利用率越低。需要按租户流量特征决定是独立池还是共享池加配额。SLO 之间有优先级，当资源冲突时应先保证可用性，再保证 TTFT，最后才是生成速度。例如排队时间增长时，宁可降低 batch 让 TTFT 达标，也不要把延迟全部压在解码阶段。优先级要写进告警与扩缩容的判定逻辑，避免两个目标同时触发时出现自相矛盾的动作。所有 SLO 都要落到可观测性上，没有指标支撑的 SLO 只是口号。TTFT 由引擎直方图指标算出 P99，可用性由健康检查与告警保证，吞吐由网关统计。目标发布前要用压测脚本验证可达性，压测至少持续 30 分钟并覆盖峰值并发。确认 P99 与错误率同时达标后，才把数字写进 SLA 文档。容量冗余系数一般取 1.3 到 1.5，覆盖短时突刺与副本故障窗口。错误预算要按月核算，99.9% 可用性对应每月约 43 分钟的允许失败时间。预算消耗超过一半时要触发流程干预，超过全部预算则冻结高风险发布。每个目标都要有明确的负责人与复盘机制，目标失效时由负责人发起修订。目标的设定还要考虑业务增长，峰值 QPS 的估计应基于最近 90 天的流量分布。目标文档要记录基准硬件、模型版本与压测方法，保证数字可被复现。目标设定时要同步定义 SLO 的例外场景，模型更新窗口与计划维护时段不计入失败。告警阈值要低于 SLO 目标本身，例如可用性 99.9% 时在 99.95% 就触发预警。季度复盘时要重新核对目标与业务实际负载，负载画像漂移会让旧目标失去意义。量化目标是后续所有架构决策的判据，网关、均衡器与扩缩容都以这四个数字为验收口径。# 来源：自实现 / slo_target.py"""根据业务峰值 QPS 与单副本实测产能推算所需副本数，用于架构目标核算"""importmathdefrequired_replicas(peak_qps:float,per_replica_qps:float,buffer:float=0.3)-int:"""峰值 QPS 与单副本实测吞吐，含 buffer 冗余后的副本数下限"""base=peak_qps/per_replica_qpsreturnmath.ceil(base*(1+buffer))if__name__=="__main__":# 业务峰值 200 QPS，单副本实测 50 QPS，预留 30% 缓冲print(f"需要副本数下限:{required_replicas(peak_qps=200.0,per_replica_qps=50.0)}")# 输出: 需要副本数下限: 61.2 组成一个完整的模型服务分为数据面与控制面两个平面。数据面承载实际请求，包括 API 网关、负载均衡器与推理引擎副本池。控制面负责改变系统状态，包括扩缩容控制器、模型仓库与指标系统。每个副本运行一个 vLLM 或 TGI 进程，独占一到多张 GPU。组件之间的接口必须统一，否则无法横向扩展。主流做法是让推理引擎暴露 OpenAI 兼容的 /v1/chat/completions 接口。配套的运维接口是 /health 与 /metrics，前者返回进程与引擎状态，后者以 Prometheus 文本格式暴露运行时指标。vLLM 与 TGI 都原生提供这两个端点，网关与监控工具因此不需要区分底层引擎。请求的生命周期决定了组件间的数据流。客户端请求先到网关完成鉴权与配额检查，网关把请求连同 trace ID 交给负载均衡器。负载均衡器依据路由策略选中一个副本，引擎把请求放入调度队列等待 GPU 空闲。引擎执行 prefill 与 decode 后，响应沿原路径返回客户端。扩缩容控制器独立于这条链路，它周期性读取指标并决定增减副本。KV cache 是推理池中最容易被忽略的资源，每个并发请求都会占用固定大小的显存。7B 模型在 8192 上下文下单请求约占用 448MB 显存。这意味着推理池的容量上限往往不是 QPS，而是并发请求数乘以平均上下文长度的乘积。负载均衡与扩容的指标设计必须围绕这个乘积展开，否则会出现 QPS 不高但显存耗尽的情况。部署形态上最常见的载体是 Kubernetes，每个副本是一个 Deployment 的 Pod。Pod 内只跑一个引擎进程，GPU 通过设备插件独占。负载均衡由 Service 或 Envoy 完成，扩缩容由 HPA 或 KEDA 完成。模型更新、版本回滚与故障恢复都可以用标准化的 Deployment 原语处理。组件间的协议约定要提前定义，包括请求体 JSON 结构、SSE 分帧与错误码语义。错误码 400 表示参数错误、429 表示限流、503 表示过载、504 表示超时。错误码约定直接影响重试策略，非幂等的 LLM 请求只能对明确可重试的错误码发起重试。故障域划分也要明确，网关与负载均衡是无状态组件，可以任意扩缩容与滚动重启。引擎是有状态组件，KV cache 与前缀缓存都在进程内，重启即丢失。有状态组件要优先保证稳定运行，无状态组件可以承担更高的变更频率。状态从引擎的 /metrics 暴露，不放到网关层缓存，避免状态分散导致数据不一致。模型权重与版本号要纳入组件清单，每个副本声明它加载的模型与引擎版本。组件清单是容量核算与故障排查的基础，缺失版本信息会让问题无法归因。接口契约的变化要经过兼容性测试，新增字段不能破坏旧客户端的解析。组件间的依赖关系要画成拓扑图，图中每个节点都有明确的负责人与备份。拓扑图与真实部署要保持同步，过期的拓扑会让排障走上错误路径。组件清单要记录每台 GPU 节点的型号、驱动版本与 CUDA 版本，硬件差异会直接影响产能假设。跨可用区部署时，数据面组件要按故障域打散，单可用区宕机不能带走全部副本。控制面组件要支持独立部署与降级运行，控制面故障不能中断已经在途的推理请求。# 来源：自实现 / lifecycle.py"""推理请求生命周期状态机，用于统计各阶段耗时与 SLO"""importtimefromdataclassesimportdataclass,fieldfromenumimportEnumclassPhase(Enum):RECEIVED="received"ROUTED="routed"QUEUED="queued"PREFILL="prefill"DECODE="decode"DONE="done"@dataclassclassRequest:request_id:strphase:Phase=Phase.RECEIVED timestamps:dict=field(default_factory=dict)defadvance(self,phase:Phase)-None:self.phase=phase self.timestamps[phase.value]=time.monotonic()defduration_ms(self,start:Phase,end:Phase)-float:return(self.timestamps[end.value]-self.timestamps[start.value])*1000if__name__=="__main__":req=Request("req-0001")req.advance(Phase.ROUTED)req.advance(Phase.QUEUED)req.advance(Phase.PREFILL)req.advance(Phase.DECODE)req.advance(Phase.DONE)print(f"排队耗时:{req.duration_ms(Phase.QUEUED,Phase.PREFILL):.1f}ms")1.3 挑战第一个挑战是显存约束，它直接决定单副本的并发上限。7B 参数模型以 BF16 存储权重约需 14.1GB，而 KV cache 按 GQA 架构计算每个 token 需 56KB。8192 上下文的一个请求就要占用 448MB 显存，一块 80GB 的 A100 实际能容纳的并发上下文数量有限。传统实现为每个请求预分配连续显存，内部碎片让利用率只有 20% 到 40%。vLLM 用 PagedAttention 分页管理 KV cache，把显存利用率提升到 90% 以上。第二个挑战是 prefill 与 decode 的计算特性差异。prefill 阶段一次性处理整个输入，是典型的高吞吐矩阵运算。decode 阶段逐 token 生成，每个 token 只有少量计算但必须串行。两者的延迟特征完全不同，batch 调度时需要混合编排。生产中出现过的典型问题是把 prefill 当 decode 处理，导致长输入的 TTFT 线性增长到数秒。这类问题只能通过压测覆盖长输入场景才能发现。第三个挑战是冷启动，模型权重加载会占用几十秒的窗口。7B 模型权重约 14GB，从本地 NVMe 加载需要 30 秒到 60 秒。新副本加入后不能立即承接流量，否则前几个请求会因为模型尚未加载完成而超时。冷启动时间直接决定弹性伸缩的下限，也是预测性扩容存在的理由。预热池、就绪探针与慢启动都围绕压缩这一段不可用窗口设计。第四个挑战是突发流量与队头阻塞。LLM 请求耗时按秒计，一个慢请求会长时间占据 batch 中的位置。当副本满载时，新请求只能排队，排队时间一旦超过客户端超时就会以失败告终。架构上需要背压机制，即队列满时直接返回 429 而不是无限排队。背压阈值要与副本数联动，避免在扩容还在进行时就让队列失控。第五个挑战是多租户隔离，不同租户的请求混在同一个 batch 中会互相挤占算力。缓解手段包括按租户拆分副本池、设置独立并发上限与调度层优先级抢占。隔离粒度越细成本越高，租户画像差异大时独立池更可控，差异小时共享池加配额更经济。第六个挑战是成本与容量的平衡，GPU 按小时计费使扩缩容决策必须提前做。扩容过慢损失吞吐，扩容过快浪费预算，冷启动 60 秒意味着容量管理不能只是反应式响应指标。5.3 节给出容量规划的具体流程，核心是让扩缩容决策建立在负载画像与实测产能之上。第七个挑战是模型更新与版本兼容。引擎升级或权重替换会改变 KV cache 布局与接口行为，前缀缓存在新版本下可能失效。发布前要做容量回归，确认吞吐与 P99 不劣化超过 10% 再灰度上线。第八个挑战是长时间运行的稳定性，显存泄漏与长尾请求会随运行时间累积。7B 模型服务连续运行 72 小时后，KV cache 分配不均导致的碎片可能让吞吐下降 20%。生产上通过定时重启窗口、显存监控与抢占计数告警来兜底。所有挑战都指向同一个结论：LLM 服务的架构设计必须同时考虑显存、调度、冷启动与成本，缺一不可。挑战的优先级要按业务阶段排序，冷启动在弹性阶段优先，显存约束在容量阶段优先。挑战的解决要按投入产出排序，显存优化与冷启动压缩的收益通常比算子优化更快显现。每解决一个挑战都要回归验证原有目标，避免新方案把某个已经达标的维度拉回不合格。# 来源：自实现 / kv_memory.py"""估算模型权重与 KV cache 显存占用，用于验证单副本并发上限"""defweight_gb(num_params:float,dtype_bytes:int=2)-float:returnnum_params*dtype_bytes/(1024**3)defkv_bytes_per_token(layers:int,num_kv_heads:int,head_dim:int,dtype_bytes:int=2)-int:"""GQA 架构下单个 token 的 KV cache 字节数 = 2 * 层数 * KV头数 * 头维度 * 字节数"""return2*layers*num_kv_heads*head_dim*dtype_bytesif__name__=="__main__":params=7.6e9layers,kv_heads,head_dim=28,4,128print(f"BF16 权重显存:{weight_gb(params):.1f}GB")# 约 14.1 GBper_token=kv_bytes_per_token(layers,kv_heads,head_dim)print(f"每 token KV cache:{per_token/1024:.0f}KiB")# 约 56 KiBctx=8192print(f"单请求 8192 token 的 KV:{per_token*ctx/(1024**2):.0f}MB")# 约 448 MB2. 推理引擎推理引擎是模型服务的算力核心，它把权重文件、GPU 显存与调度逻辑封装成一个可服务的进程。引擎的差距主要不在单 token 的算子性能上，而在两点：一是 KV cache 的管理效率，二是批处理调度策略。vLLM 和 TGI 是目前生产使用最多的两个引擎，本章先剖析它们的调度机制，再给出配置方法与性能调优路径。显存管理请求入口可执行KV cache 不足生成输入注意力逐 token 输出生成结束KV 换入显存页级分配OpenAI 兼容接口调度器连续批处理抢占与换出prefill 阶段decode 阶段响应返回