模型服务架构

模型服务不是把一次前向传播包装成网络函数。它需要在并发、取消、故障和版本变化下，持续保证请求使用正确模型，输出具有明确终止语义，资源最终被释放。部署架构的核心是将概率计算嵌入可解释的状态管理与变更流程。

第31章《批处理调度》讨论排队与批调度，本章讨论组件职责、制品身份和服务生命周期。第30章《增量解码》定义请求执行状态；这里进一步研究这些状态在网关、工作进程和控制面之间如何保持一致。

32.1制品身份及运行配置

模型制品构成

模型制品（Model Artifact）是共同定义模型计算行为的一组版本化对象，包括权重、结构配置、分词器、特殊词元、会话模板、适配器及量化参数。对于多模态模型，还包括处理器与相关编码器。模型名称或目录路径不足以唯一重建行为，因为它们可能指向不断变化的内容。

不可变制品（Immutable Artifact）以固定内容与摘要标识。一份清单将所有组成文件及其依赖关系绑定在一起；改变模板或适配器组合，也应形成新的身份。内容摘要保证比对字节一致，不自动证明来源真实性；来源验证可以由受控注册表、签名和构建记录补充。

运行配置描述制品怎样部署，例如精度、并行布局、内核、设备类型和最大资源预算。流量比例、副本数、租户配额与路由策略属于服务控制配置。三者分别版本化，可以让同一模型制品在不同环境晋级，而不把环境名称混进权重包。

制品兼容性

加载成功只说明当前运行时能够解释某种文件布局，不保证配置组合正确。张量并行需要检查查询头、键值头及层维度的分片方式；键值复制会改变每卡容量；量化格式需要对应内核；适配器需要匹配基座修订。设备总数满足并行度，并不证明这些关系成立。

服务修订可以表示为

\(a\) 是制品身份，\(e\) 是运行时环境身份，\(c\) 是执行配置，\(p\) 是接口与策略版本。请求进入执行前固定 \(\mathcal R\)，直到完成或明确终止。发布新修订影响后续路由，不应让正在解码的请求突然读取新权重或新模板。

符号及适用范围

服务分析的口径

容量与延迟均针对固定制品、硬件、运行时和请求长度分布。构造数例只演示计算关系，不代表压测结果。请求状态有明确所有者，网络消息可能延迟、重复或丢失；跨进程状态更新不被假定为天然原子。

32.2服务拓扑及组件分工

数据面及控制面

数据面（Data Plane）处理请求与输出；控制面（Control Plane）管理期望副本、修订、路由与生命周期。前者追求低延迟与局部故障可隔离，后者追求变更一致与最终收敛。把每次请求都同步绑定到注册表或配置中心，会把控制服务短暂不可用放大成全部推理不可用。

网关验证身份、请求大小、配额与协议；路由器解析模型别名并选择合法副本；调度器管理排队、执行批次和资源准入；工作进程加载模型、执行计算和维护缓存。它们可以在小规模系统中合并部署，但职责及状态所有权仍需清楚，不能因进程合并而混淆语义。

路由快照及请求粘性

路由器可以使用已校验、可原子替换的本地配置快照。快照包含修订、端点、健康与故障域信息。旧快照允许在控制面短暂故障时继续服务，但其可用期限、失效策略和撤销机制必须定义，不能无限信任过期授权或已退役副本。

一个请求固定模型修订和执行所有者；有状态的解码需要访问对应缓存。如果迁移，应采用显式状态转移协议，而不是每个词元重新随机选择副本。相同会话的不同请求是否需要粘性取决于状态是否可重建及前缀缓存策略，不能以用户身份直接绑定到永久单点。

故障域及共享依赖

故障域（Failure Domain）是可能共同失效的一组资源，如设备、节点、机架、可用区、修订或共享存储。两个副本若共享同一块故障存储或同一错误配置，不一定形成独立冗余。架构分析需要追踪共享依赖，而不只数进程数量。

租户或长短任务池的分隔可以限制资源争用；分池过细又会降低复用效率。合理边界由故障影响和工作负载差异决定。服务层不要求所有请求使用相同队列，跨池转移必须服从剩余容量和权限，不能让局部过载自动灌满健康池。

32.3请求状态及流式协议

能力协商及有效推理强度

推理强度进入服务接口后，既是模型行为参数，也是容量维度。网关应根据已经绑定的模型修订校验允许档位，并把请求值、默认值和最终生效值分别记录。模型别名切换后，支持集合或默认档位可能改变；因此缓存键、幂等摘要、审计记录和负载归类都应包含最终生效的推理强度。服务无法支持请求值时应在排队前返回明确错误，不能静默降档后仍保留原请求标签。

容量规划不能只按可见答案长度分组。内部推理会占用解码步骤，并与可见输出共享设备时间；某些接口还让二者共享输出词元上限。即使两次响应都只有相同长度的答案，不同推理强度也可能产生不同的服务时间、超时率和单位请求成本。单副本容量\(q\)应在固定模型、档位、输入长度、输出上限和工具配置的负载分布上测量，不能把低档位压测结果直接用于高档位流量。

对于会话式服务，运行中改变推理强度还可能影响前缀缓存或服务方保存的推理状态。是否能够复用已有前缀、参数从哪一轮开始生效，应由具体协议定义。OpenAI当前接口在Responses与Chat Completions中使用不同字段，并对部分模型提供会话内配置更新；这些行为属于版本化接口能力，不应被推断为所有OpenAI兼容服务都支持(OpenAI 2026)。

请求状态机

请求通常经历接收、等待、执行和终止。执行可包含预填充、状态传输和解码；终止原因至少区分正常完成、取消、超时和失败。状态应记录单调版本或更新序号，以拒绝迟到消息覆盖更晚状态。

取消和正常完成可能同时到达。系统应通过条件状态更新选择一个终止结果，例如只允许从非终止状态写入终止状态；输掉竞争的事件读取已经确定的结果。资源释放还需使用独立的幂等所有权记录，避免两个处理路径都递减缓存引用。

流事件及终止语义

服务端发送事件（Server-Sent Events，SSE）定义了单向文本事件流机制(WHATWG 2026)，适合服务器连续发送增量内容。应用仍需定义事件类型、请求身份、序号、修订、结束原因和用量。传输机制不自动提供生成任务的完整状态协议。

增量事件可能是多个词元形成的文本片段，也可能包含结构化调用字段。不能假定一个网络事件恰好对应一个模型词元，更不能假定分词字节片段已经构成完整字符。解码和协议组装应保证客户端看到合法的增量内容。

正常终止事件表示生成按指定原因结束；连接关闭或长时间无消息只表示传输状态不确定。响应头已经发出后，服务器通常不能再用一个新 HTTP 状态替换当前响应，因此应用流内错误与终止原因必须可识别。最终用量记录也要区别已计算、已发送和已确认消费的内容。

SSE 的事件身份与重连机制不能自动重放语言模型计算。若服务支持恢复，需要持久化事件序列或完整生成状态，并声明保留窗口；否则重连只能查询既有请求状态或发起新请求。¹

取消、期限及剩余预算

截止期限（Deadline）约束从请求开始到终止的总时间。若请求截止时刻为 \(d_r\)，当前时刻为 \(t\)，剩余预算为

进入队列、状态迁移、重试和执行前都应重新检查，不能为每一跳重新分配完整超时。跨机器绝对时钟存在偏差，需要统一时间约定与容差，或传播明确的剩余预算并计入传输开销；进程内计时宜使用单调时钟。

客户端断连不保证设备计算立即停止。取消信号需要抵达调度与执行所有者，阻止后续生成，并在设备安全边界释放资源。一个已启动的内核可能需要完成，故取消生效时间应区分“停止接收新工作”和“全部设备资源可回收”。

幂等及重试边界

幂等性（Idempotency）指重复执行具有相同预期效果，HTTP 对相关语义有明确区分(Fielding, Nottingham, 和 Reschke 2022)。随机生成使用同一请求内容，不天然给出相同输出；相同随机种子也不跨任意设备和执行顺序保证逐字一致。

应用幂等键可将同一逻辑请求映射到已有记录。该记录应绑定请求内容摘要、租户和修订：相同键但不同内容不能静默复用。幂等保留期过后，服务如何处理再次到来的键也应明确。

重试安全性取决于输出与副作用是否已经发生。尚未输出且旧执行可确认终止时，可以按预算重试；旧执行状态未知时，新的尝试可能形成重复计算。已经输出部分文本后静默重新生成，可能出现重复或分叉，通常应返回中断或按显式恢复协议续传。涉及工具写操作时，工具自身还需幂等或事务机制，模型请求幂等不能自动保护外部副作用。

32.4工作进程的生命周期

三类健康信号

模型工作进程会经历创建、加载、预热、就绪、排空和终止。启动探针（Startup Probe）判断初始化是否完成；存活探针（Liveness Probe）判断进程是否还能推进；就绪探针（Readiness Probe）判断是否可以承接新流量。Kubernetes 文档明确区分这些信号(Kubernetes Authors 2026)。

加载权重耗时较长，不应因尚未完成启动而反复触发存活重启。队列增长或暂时过载也不等于进程死亡；过敏的存活策略会在最需要容量时制造重启。就绪信号可以在排空、关键依赖失效或容量不可接受时撤销，而不必销毁进程。

预热不仅是调用一次模型。它应覆盖目标执行形状、缓存格式和关键内核路径，形成启动资源边界。预热成功证明特定路径可执行，不证明真实长度分布的容量或质量达标。

优雅下线

排空（Draining）先停止新流量，再处理已有请求，最后释放模型。路由更新存在传播延迟，因此工作进程本地也应拒绝新接纳或返回明确重选信号，避免只依赖远端端点更新。

排空期间保留已有请求的修订与缓存。宽限期不能无限延长；超过预定截止后取消剩余请求，并报告结束原因。关闭连接、释放设备缓存、写入最终用量和终止进程之间要有明确顺序。缩容控制器应将排空副本从未来容量中扣除，而不是等进程真正退出才发现容量已经减少。

算法32.1　工作进程的上线与下线

输入为不可变服务修订、目标资源与期限；输出为可接流量的实例或明确失败结果。

1. 校验制品与执行配置兼容性，拉取完整文件并验证身份；失败则保持流量隔离。

2. 加载权重与必要处理器，分配运行资源，完成指定路径预热；完成前不发布就绪状态。

3. 发布就绪并承接请求，持续区分存活、可用容量和关键依赖状态。

4. 收到维护或缩容指令后撤销就绪，本地停止新请求，保留在途执行与取消处理能力。

5. 等待在途请求完成或达到宽限期，终止剩余请求，确认设备资源释放并冲刷必要状态后退出。

不变量是未准备完成的副本不承接正常流量，进入排空后不扩大在途请求集合。

32.5预填充及解码分离

（选修）

分离的动机及条件

预填充—解码分离（Prefill–Decode Disaggregation，P/D 分离）把两个计算阶段分配到不同资源池。预填充处理较长输入，解码反复生成少量位置；二者对并行度、批次和带宽的需求不同。DistServe 研究了这一分离及其面向阶段延迟目标的资源分配(Zhong 等 2024)。

分离可以降低同一设备上阶段相互干扰，并独立调整资源比例，但新增了缓存传输、网络排队和状态所有权切换。小模型、短提示或有限网络下，新增成本可能超过收益。它是架构选择，不是所有服务必须采用的固定形态。

缓存传输代价

（选修）

从预填充节点传送 \(M_{KV}\) 字节到解码节点，有效带宽 \(u_{net}\)，则无重叠的传输时间至少为

\(T_{\mathrm{setup}}\) 包含必要连接、描述符与同步开销。协议、拥塞、布局转换和接收写入会增加实际时间。若部分传输与计算流水重叠，端到端新增时延不能简单等于二者相加，但总网络工作量仍然存在。

例如缓存每词元128 KiB、提示8192词元，则 \(M_{KV}=1\) GiB。有效带宽25 GiB/s时，仅字节传输下界为40毫秒；若每秒接收50条这种请求，就产生50 GiB/s缓存流量，单条25 GiB/s链路无法长期承载。缩短单请求传输延迟与满足总带宽预算是两个不同问题。

迁移所有权

需迁移的不只是缓存字节，还包括逻辑长度、页映射、模型修订、位置规则、已生成词元、采样状态和输出序号。若预填充端已经产生首词元，解码端必须知道该词元是否已经执行前向及是否已向客户端发送，避免重复生成或漏处理。

可以通过请求版本或租约令牌保证同一时刻只有一个合法输出所有者。接收端准备完成后再提交迁移；提交前失败仍由旧所有者处理，提交后旧端不得继续发送。跨故障域时“提交是否成功”的不确定性需要查询权威状态，不能靠双方同时重试解决。

P/D 两端可以使用不同并行布局，但必须有兼容的逻辑缓存表示和明确重分布路径。混合不同模型修订、适配器或位置配置不属于普通缓存搬迁。安全边界、网络加密与授权也要随状态转移保持，不能因为数据位于内部网络就忽略租户身份。

32.6扩缩容及启动提前量

分阶段容量模型

副本容量取决于输入、输出长度分布及阶段组合。将输入词元与输出词元相加，再除以一个吞吐常数，只能用于混合比例固定时的粗估；更稳妥的方法分别考虑预填充工作、解码工作和缓存占用，再映射到阶段池或共置实例。

在假定某个固定负载下单副本容量为 \(q\)、目标系数 \(u\) 时，粗略就绪副本需求为

这只是部署资源估计，批调度与尾延迟模型由第31章《批处理调度》展开。尚在加载、预热或排空的副本不能算作完整可用容量。

服务容量测算

设一个固定长度混合下，单副本容量假设为400请求/分钟，规划利用系数0.75，当前6个就绪副本提供1800请求/分钟。需求由1800突增到2400，粗略需要8个副本；新增副本从创建到就绪需要90秒。

这90秒内，即使扩容指令立即发出，仍有每分钟600个请求的容量缺口，累计约900个请求。如果排队预算只允许容纳300个请求，则剩余600个必须通过提前预热、流量分担或明确拒绝处理。扩容能解决未来容量，不能消除启动期间已发生的缺口。

一般地，启动窗口中的累计正容量缺口可写为

其中 \([x]_+=\max(x,0)\)。在无丢弃的流体队列中，期末积压增量满足 \(B(t+T_b)-B(t)\le C_{\mathrm{gap}}\)；只有整个窗口需求不低于容量等条件下，正缺口才等于积压增长。窗口内的富余容量可以消化先前积压，因此不能把正部积分一般地当成期末增量。上述900请求算例具有恒定正缺口，故满足该条件。这个模型忽略离散请求与批次耦合，不直接给出尾延迟达标概率。

控制环的滞后及抖动

自动扩缩容包括观测窗口、聚合、决策、资源配置和启动。过长观测窗口会延迟响应，过短窗口可能追随噪声。新增容量到达前重复发出扩容，又可能造成过量资源；控制器需把正在启动的容量计入预测，而不是计入当前供给。

缩容应比扩容更谨慎，使用稳定窗口和排空机制；同时保留必要热容量以覆盖突发与故障。若资源紧张，扩容请求本身可能等待调度，因此启动提前量应包含基础设施供给时间，而不只是模型加载时间。

32.7模型路由及服务降级

模型选择及副本选择

模型路由（Model Routing）依据请求特征、质量要求和资源状态，为一次请求选择执行模型。商业服务可以在统一入口后配置多个模型池，把适合的请求交给成本较低的模型，将较强模型的容量留给更需要它的任务。用户所说的服务“降智”可能指其中的跨模型降级，但回答质量下降本身不能证明模型被替换。

模型路由应与同一模型内部的副本选择分开。前者可能改变任务能力，后者主要改变执行位置；同名模型跨供应商运行，也需要核对实际修订、量化和模板。另一个维度是计算预算：同一模型减少推理词元、候选数量或工具调用，也可能改变成功率。因而执行决策应同时固定模型身份、供应商、运行配置和预算，而不能只记录一个产品名称。

这里的“较强”与“较弱”相对于具体任务和评估分布成立。较小模型可能在特定领域优于较大模型，价格与参数量都不能直接替代质量测量。IPR 研究采用质量估计和可调容忍度进行模型选择(Feng 等 2025)；它提供了公开的路由方法实例，其论文实验不能证明任意请求都保持原模型质量，也不能用来推断其他服务存在未披露替换。

带约束的路由决策

记请求为 \(x\)，当前服务状态为 \(s\)，候选模型为 \(m\)，配置预算为 \(b\)。先根据用户授权、数据驻留、模态、上下文长度、结构化输出和工具协议筛选合法集合 \(\mathcal A(x)\)。在此基础上，一种设计目标是

\(\widehat C\) 是预计总成本，\(\widehat Q\) 是同一评价口径下的预计质量，\(\widehat T\) 包含路由、排队、生成和必要验证的预计时延，\(\Delta\) 是剩余截止预算。该式是本节的工程建模，不是对某个产品算法的复现。预测约束只能作为决策依据，不能构成逐请求质量或期限保证；尾延迟要求还需使用相应分位数或超时风险估计。

质量估计器可以利用任务类型、完整上下文特征以及离线标注结果。训练数据应覆盖各候选模型在同类请求上的表现，并按来源或任务划分训练、验证和测试集合。只根据问题长度判断难度容易漏掉短问题中的复杂依赖；只把小模型的自信陈述当作可靠性，也无法识别自信错误。模型、模板或流量分布变化后，应重新验证估计器与阈值。

合法集合为空，或预测没有候选满足门槛时，应按契约排队、拒绝或显式请求调整服务等级。容量压力不能自动扩大数据访问权限或跨越用户限定的模型范围。

预先选择、级联及故障回退

请求前路由在生成之前选择模型，只承担一次选中模型的生成成本，但选择时看不到真实答案。级联调用（Model Cascade）先让低成本模型生成候选，再根据验证结果决定是否升级；检查可以包括可执行测试、结构约束、证据核验或经校准的质量评分。检查通过仅表示满足已检查条件，不能把格式正确当作事实正确。

设小模型生成成本为 \(C_s\)，验证成本为 \(C_v\)，升级比例为 \(p\)，升级后大模型调用的平均成本为 \(C_h\)。在固定请求分布及忽略其他开销的条件下，级联平均成本为

若直接调用大模型的平均成本为 \(C_0\)，级联节省成本的条件为

例如假设 \(C_s=1,C_v=0.5,C_h=C_0=10\)，升级比例为 \(0.3\)，平均成本为 \(4.5\) 个单位，相对基线降低55%。这是构造算例；升级时携带候选或额外证据会改变 \(C_h\)，而升级请求通常还需承担两次串行生成和验证的时延。级联中的小模型候选在验收前应保留在服务内部，避免先流出错误内容再静默替换。

服务降级（Service Degradation）是在资源不足或故障时按预定契约降低服务等级。过载降级依据队列、容量或期限风险触发；故障回退依据超时、限流或不可用等执行结果触发。备用模型可能同等或更强，回退不必然意味着能力下降。应限制尝试次数与总预算，并确认旧尝试状态，防止重复计算或重试流量继续压垮备用池。跨模型尝试需要重新序列化请求并建立匹配的新缓存，不能复用另一模型的 KV 状态。

容量约束下的模型路由

考虑提供固定模型与自动模型两种模式的服务。固定模式将用户指定修订作为约束；自动模式允许在事先公开的候选集合内选择。以下流程是一种设计案例，阈值应从实际负载与质量评估确定。

算法32.2　容量受限时的模型选择

输入为请求、服务契约、路由快照、质量门槛和剩余期限；输出为可追溯响应或明确失败。

1. 解析模式、授权候选和能力要求，筛选合法模型池；记录策略版本和原始请求身份。

2. 检查大模型队列与预计完成时间。固定模式只在允许的同模型部署间选择；容量不足时有界排队或报告不可用。

3. 自动模式下，若大模型拥堵，评估较低成本候选的质量和剩余容量；同时满足质量门槛、协议要求和时间预算才分流。

4. 没有合格替代时按契约排队或失败；选择级联时把首轮、验证和升级全部计入期限，并保留升级容量预算。

5. 为每次尝试固定模型修订与配置。已经对外发送文本或执行工具写操作后，不静默拼接另一模型的结果；采用明确中断或具有副作用保护的恢复流程。

6. 记录实际执行身份、降级原因、用量和终止结果。大模型恢复后，经过稳定窗口逐步恢复分配，避免阈值附近反复切换。

不变量是路由始终位于授权候选集合内，每次执行具有唯一身份，失败与降级对调用方可辨识。

分流减轻的是某个资源池的压力，并不创造总容量。备用池也需要接纳控制；若两个模型共享同一紧张设备，分流收益取决于实际计算与驻留开销。高峰期还应分别统计正常路由与过载降级的任务分布，判断质量变化来自策略、输入变化还是执行故障。

质量门槛及服务透明性

路由评估应在相同题集、上下文、评分规则和预算口径下，与固定模型基线比较。除平均质量、成本和尾延迟，还要按语言、任务难度、上下文长度与工具类型报告结果，并记录小模型覆盖率、升级比例和错误放行情况。错误放行可定义为“小模型候选被验收但最终判错”，其比例必须明确以放行请求还是全部请求为分母。高风险任务单独设门槛，不能由大量简单任务的正确答案抵消。

只观察已经路由到小模型的请求，无法直接知道同一请求在大模型上的结果。可以在合规抽样集上补做配对评估，但须计入额外成本并隔离工具副作用。第9章《模型评估》的抽样、不确定性和分层比较方法适用于这里；根据测试结果反复调路由阈值后，该测试集就需要作为开发数据处理。

服务契约应说明固定身份还是自动选择、可用候选、降级条件、计费口径和退出降级的方式。调用记录至少关联请求身份、尝试身份、请求模型、实际模型修订、供应商、策略版本、执行预算及降级原因；敏感上下文按最小必要原则保存。模型自报身份、单次回答文风与速度不足以证明实际执行模型，代理返回的模型字段也只是声明。较强证据来自可关联的网关、执行端和上游记录，并以访问控制及防篡改措施支持审计。

模型路由的收益应在授权与质量约束下计算，实际交付的模型和计算预算应当可追溯。

32.8发布及回滚

候选修订的暴露方式

金丝雀发布（Canary Release）让候选接收有限真实流量，观察质量与系统指标。影子流量（Shadow Traffic）复制请求到候选路径但不返回其结果，适合比较资源与离线质量；它不能完全代表真实用户体验，也会增加计算和数据处理成本。包含副作用的工具请求不能直接在影子路径重复执行。

蓝绿部署（Blue–Green Deployment）保留两套环境，通过路由切换晋级或回退；它需要额外驻留容量。滚动替换则逐步更新副本，节省部分双份资源但延长新旧共存时间。几种方式可以组合，选择依据是资源预算、回滚速度与协议兼容性。

质量及系统联合判断

候选可能更快却更容易错误，也可能质量提高但尾延迟超标。发布标准应分别约束任务质量、故障率、停止行为、延迟及资源；不能把所有维度压成一个分数后让速度抵消严重错误。

灰度样本的语言、租户和长度可能偏离整体流量，观察窗口应记录这些切片及样本量。新旧版本的随机生成比较还需固定评估设计，不能仅选择看起来较好的单次输出。指标异常时应能够追溯实际修订和配置，避免把同时发生的流量变化误归因于模型。

回滚恢复契约

回滚不只是恢复权重，还包括模板、运行配置、路由与兼容依赖。稳定修订若已被删除或冷却，路由回退也不会立刻恢复容量。发布计划应保留足够可用旧容量及可拉取制品。

新请求可以切回稳定修订，在途请求应按原修订完成或明确终止。若会话外部状态或工具协议已发生不兼容写入，模型回滚无法逆转这些变化，需要兼容读取或独立迁移策略。缓存也按修订隔离，不能在回滚时混用候选状态。

算法32.3　候选服务修订的晋级

输入为候选与稳定修订、评估标准和流量预算；输出为晋级结果或恢复稳定状态。

1. 固定候选制品与配置，完成兼容性准备，建立可追溯评估基线和稳定容量保留策略。

2. 加载候选并预热，在隔离路径验证真实请求生命周期、错误和资源释放。

3. 按允许的数据范围进行影子或小流量比较，记录模型、长度、任务与租户切片。

4. 仅在质量和服务指标同时满足预定条件时逐步扩大；任一关键条件失败即停止新增候选流量。

5. 回退时原子更新路由，新请求固定稳定修订，候选排空或按期限终止；保留失败证据与完整版本组合。

整个过程不修改已发布制品，也不在生成中途静默切换模型身份。

32.9遥测及关联

三种信号的用途

可观测性（Observability）通过外部信号推断系统状态。指标描述聚合趋势，日志记录状态变化，分布式追踪联系请求跨组件的时间路径；OpenTelemetry 将这些作为不同信号组织(OpenTelemetry Authors 2026)。

指标适合回答错误率和队列是否异常，追踪适合定位时间花在哪一跳，日志适合解释一次取消或迁移为何发生。请求身份、追踪身份、修订和工作进程身份应能够关联，但不必全部作为指标标签。遥测服务故障时，推理路径也应保持有界缓冲，不能无限积压日志耗尽内存。

时间测量边界

设 \(t_a\) 为请求进入约定入口，\(t_f\) 为首词元对观察者可见，\(t_l\) 为末词元可见，输出词元数 \(N_o>1\)。则

这里首词元延迟已经包括该边界内的排队；不能另加排队项。单词元输出没有相邻间隔，TPOT 不应人为记为零。客户端指标包含网络与刷新，工作进程指标则可只描述设备阶段；二者应分别命名。

分位数不能跨副本直接平均得到全局分位数，应合并适当分布信息后计算。小样本 P99 很不稳定，报告需要窗口与样本量。只统计成功请求也会产生选择偏差，超时、取消和失败应独立计入服务结果。

标签基数的乘法增长

标签基数（Label Cardinality）描述指标维度的不同取值数。若模型、区域、状态分别有 \(m,r,s\) 个取值，理论组合上限为 \(mrs\)；再加入每请求唯一身份，时序数量可能随请求总数增长。

例如20个模型、3个区域、6种状态形成最多360种组合，加入100万个请求身份后理论组合空间大幅扩大。不是所有组合都会出现，但唯一身份仍会使存储与查询成本失控。请求和用户信息更适合进入受控日志或追踪，指标保留有限集合标签。

提示、输出与缓存摘要也可能暴露敏感内容或形成可关联标识。通常记录计数、长度、错误类别与受控引用即可；调试原文需要单独的访问、采样和保留规则，不把普通遥测变成无界训练数据副本。

32.10故障、背压及重试放大

资源不足传播

背压（Backpressure）使下游容量约束反馈到上游，防止无界接纳。网关预算、有限队列、执行容量和流式发送缓冲是不同边界。慢客户端可能使发送缓冲增长，即使设备仍能生成；继续无界计算会同时占用缓存和网络内存。

过载拒绝需要稳定错误语义及有限重试提示。降低输出预算、切换模型或关闭某些功能属于行为变化，应向调用者明确，而不是静默改变服务承诺。扩容尚未完成时，保护已接纳请求往往需要主动限制新流量。

重试放大效应

假设每次尝试独立失败概率为 \(p\)，最多允许 \(k\) 次总尝试，则期望尝试数为

例如 \(p=0.5,k=3\)，平均尝试次数1.75，原始100请求/秒会形成175次尝试/秒。若故障来自过载，失败概率并不独立，额外尝试反而可能继续推高 \(p\)，形成正反馈。

若网关和客户端各自允许三次尝试，最坏可形成九次下游尝试。重试预算应跨层协调，并受同一个截止期限控制。退避和随机抖动减少同步冲击，但不能创造容量；不可恢复配置错误、权限错误或已部分输出请求不应按普通暂态失败重试。

故障恢复及状态重建

工作进程失联可能丢失设备缓存。若尚未输出，可以在合法条件下重新计算；已经输出时，重放需要保存精确前缀、采样状态和事件进度，仍受数值与执行兼容性约束。无法满足恢复协议时，应明确报告中断，而不是拼接另一条生成轨迹。

故障演练应观察检测、隔离、取消、容量转移和最终资源回收，而不只看进程重启成功。整个故障域失效后，入口应按剩余容量限流，不能把全部原流量瞬间压给幸存副本。恢复时间目标需要结合制品获取、预热和路由收敛，并预先定义可接受的数据或状态丢失边界。

服务正确性是状态一致性

制品身份决定计算含义，请求状态决定输出与资源所有权，副本状态决定可用容量。故障与发布都在改变这些状态。只有三者的迁移规则一致，模型计算才能持续构成可靠服务。

32.11推理服务基准测试

制品、请求和容量对象需要分别关联版本、执行状态与资源责任。构造记录只用于说明预算关系，不能代替线上压测。工作进程内部的缓存、批处理和算子优化属于可选择的引擎能力，单一内核优化并不等同于完成部署。

32.12推理引擎体系

引擎在服务系统中的位置

vLLM与SGLang将模型加载、缓存管理、调度和设备执行组织成推理运行时，并提供服务接口(vLLM contributors 不详b; SGLang contributors 不详)。TensorRT-LLM围绕NVIDIA平台提供推理优化及运行组件(NVIDIA 不详)。这些引擎位于工作进程及其调度路径中；完整服务还需要入口认证、流量控制、版本路由、监控和故障处理。

一条聊天请求通常经过协议解析、模板渲染与分词、调度接纳、预填充、逐步解码和流式返回。词元流决定模型实际接收的条件，调度器决定何时执行，缓存管理决定中间状态如何保存。应用层看到相似的HTTP接口，并不能说明三个环节使用了相同语义。

vLLM 缓存调度

vLLM的发展与PagedAttention工作有关，其分页思想将请求的逻辑序列与缓存物理块解耦(Kwon 等 2023)。实际引擎还需要协调批处理、模型执行、采样和缓存生命周期。应把算法论文中的机制与所用软件版本的实现分开核查；支持的模型、算子、量化和服务参数以相应版本为准(vLLM contributors 不详a)。

例如多个请求共享提示前缀时，复用已计算的缓存可以减少重复预填充；但解码仍要读取有效历史状态，缓存还占用内存。若改变模型、适配器或输入位置语义，原有缓存未必有效。前缀复用收益需要在真实共享比例和请求到达条件下测量，不能由缓存命中率单独推断端到端加速。

SGLang 结构化执行

SGLang的代表机制RadixAttention以基数树组织可复用的前缀缓存，使多次模型调用之间的共享前缀能够参与缓存匹配与回收(SGLang contributors 不详)。其运行时还涉及调度、并行和受约束输出等能力，实际组合需要核对版本、模型与后端支持。存在相同自然语言片段，不代表模板渲染后的词元前缀也相同。

比较SGLang与vLLM时，应固定权重、分词器、输入词元、生成限制和请求分布，再分别比较冷缓存与可复用缓存的条件。共享前缀占比不同、预热方式不同或默认生成配置不同，都可能改变结果。受约束输出还需独立检验格式通过率与内容正确性，格式合法并不保证答案满足任务。

平台约束及选型依据

TensorRT-LLM的部署选择需结合GPU架构、精度、模型实现和具体执行后端(NVIDIA 不详)。应核查所选路径的构建或加载成本、动态形状范围与版本绑定，而不把一种执行路径的要求推广到全部后端。模型更新频率和制品准备时间也会影响总成本。

选择引擎时，先确认模型及其模态、量化、上下文和适配器需求得到支持，再建立质量一致的负载对照。报告首词元延迟、逐词元延迟、端到端延迟、有效输出词元吞吐、峰值显存和失败比例，并保留尾延迟。吞吐最优配置可能突破交互延迟约束；最终选择应依据目标服务等级下的有效容量与运维成本。