编码智能体压垮自托管模型时，应尽早拒绝请求

Audible 的 Harshul Jain 和 SAP 的 Parv Khatri 介绍准入控制：当编码智能体向自托管语言模型突发大量请求时，决定哪些请求可以进入服务。

推理从提示词开始，模型逐个生成 token 形成回答。Jain 强调，系统在开始时不知道最终输出长度，因此很难预先判断一次请求会消耗多少资源。

请求依次经过应用、API 网关、路由器和 vLLM、SGLang 等推理引擎。引擎将模型权重加载到 GPU，批量处理请求，并为每个运行中的请求维护键值缓存。

Jain 描述了质量、延迟和吞吐量之间的权衡。交互式聊天可能更注重质量与响应速度；异步智能体可能愿意多等待一些以换取吞吐量；高流量自动补全则可能更重视速度，而非使用更大的模型。

每个部署都有一个上限，超过该负载便难以继续达到服务等级目标。演讲者引用 OpenAI 的 2023 年路由事故和 Anthropic 的一次容量事故，说明负载削减或提前发现容量极限的重要性。

他们建议在入口作出决定：立即准入、暂缓到稍后处理，或拒绝请求。这个决定应在请求消耗 GPU 内存之前作出。

预填充阶段，引擎读取提示词并建立缓存；解码阶段，缓存随着生成逐渐增长。接受请求意味着在其生命周期内承诺资源，因此接入一个长请求会影响已经运行的工作。

当 GPU 内存耗尽时，引擎可能抢占、交换或让任务失败。这些处理方式可能增加延迟并浪费计算。自托管服务需要保护自身容量，不能假设推理引擎能够吸收任意突发流量。

编码智能体可能并行展开大量文件读取、测试和模型调用，还会叠加重试。因此，一个用户任务可能在短时间内产生几十个模型请求，不同于人输入一条消息后停下来阅读。

Khatri 讨论准入决策应放在哪里：智能体知道自己的调用，网关知道密钥和配额，路由器看到副本，引擎看到批次和缓存。但这些层不一定能在接收工作之前同时结合请求详情与当前容量。

策略可以在入口、引擎队列边界或解码过程中执行。越靠后的决策能看到更多状态，但可能需要修改并长期维护调度器分支；演讲者聚焦入口，因为它可以配合未修改的引擎工作。

在入口，策略结合请求信息和系统状态，选择准入、暂缓或拒绝。请求被准入前不会消耗 GPU 内存，但前端基础设施仍然需要处理它。

有用的请求信号包括输入长度、租户、会话和截止时间；引擎信号包括缓存使用量、队列等待时间、缓存命中率和副本池负载。他们建议使用能在数秒内变化的指标，因为一分钟平均值可能掩盖短时并发。

他们的示例规则包括：提示词无法放入剩余空间或同一会话调用过多时暂缓；租户超额或任务已无法赶上截止时间时拒绝。引擎侧规则则考虑缓存余量、队列等待时间、已缓存前缀和资源池饱和程度。

HTTP 200 表示流开始，并不保证流一定完成。Khatri 建议客户端监视流、处理部分失败；放弃任务时应关闭连接，以便释放资源。

临时暂缓时，他们的示例返回带 Retry-After 的 503。客户端应等待指定时间，再加上随机抖动。如果没有协调延迟，大量重试可能同时回来，使最初的突发流量进一步扩大。

对于拒绝，他们区分调用方超额导致的 429，以及示例中用于提供方过载的 529。前者应降低自身并发；后者可以等待、切换提供商或稍后处理。两种情况都需要有限的重试预算和退避。

Jain 解释，统计请求数不等于衡量成本。固定的每客户端速率限制有助于公平，却不能反映 GPU 压力；固定的并发数则会把短请求和长请求视为相同。

设计策略时有四个选择：准入单位、观察的信号、把信号转成决定的规则，以及最终动作。例如，基于截止时间的规则要求请求确实携带有用的截止时间。

他们用示意图比较两个各有 20 次调用的会话，假设容量只够处理一半。每个会话各准入一半可能导致两个都无法完成；完整准入一个会话则能让它完成，另一个明确收到暂缓答复。这是示意场景，不是实测基准。

不同信号解决不同问题：缓存压力保护内存，缓存命中反映复用，队列深度显示等待，截止时间余量帮助满足延迟目标，输出长度估计则帮助规划长回答。每种信号都可能漏掉其他瓶颈。

演讲者比较了简单阈值、双信号门控、优化器和形式化截止时间界限。更复杂的决策可能耗时更长；如果几十个调用在两秒内到达，耗时数秒的优化器可能反应太慢。

他们总结了四篇研究策略及其报告的收益，同时提醒各论文使用不同模型、引擎和工作负载，数字不能当作排行榜。在他们看来，没有一种方案完全覆盖未修改引擎上的在线完整会话准入。

他们的决策树首先判断请求是否有截止时间；否则再看峰值负载时 KV 缓存是否会填满。内存是瓶颈时可考虑缓存及复用信号；队列增长但缓存未满时，队列阈值可能更有用。

Khatri 建议先测量集群基线，再对比启用和不启用策略的结果。应重放真实智能体轨迹，包括并行展开、重试和会话，并将负载从低于容量扫到高于容量。

他们建议的分数以满足延迟目标的请求数除以所有到达请求，包括被拒绝的请求。如果系统拒绝 95% 的流量并完美服务其余请求，只看准入流量会得到 100% 达标率；按这一有效吞吐量指标计算则是 5%。

一份有用的报告应披露相对容量的负载、相对空载延迟的截止时间、信号新鲜度、重复次数和波动、参数来源、是否计入被拒请求，以及完整模型、引擎、硬件、工作负载和基线配置。

团队制作了 AdmitPerf，既是入口准入库，也是基准测试框架。基准测试和部署使用同一个策略函数，因此可以在真实引擎和 GPU 上比较，而不改变被评估的策略。

他们的流程包括启动基础设施、检查服务是否可用、重复测试策略、比较结果，最后关闭基础设施。他们在比较不同策略时保持部署不变，避免重新配置带来干扰。

策略必须声明所需信号。如果缓存使用率不可用，基准测试应该停止，而不是悄悄把缺失值当成零，让缓存阈值策略变成接受所有请求。

在 Qwen 2.5 0.5B 和 A10G 的小型测试中，画面报告每秒 15 个请求、共 80 个请求，重复两次。最多允许两个请求等待时，63.1% 的请求被准入；在报告的有效吞吐量相同的情况下，p95 首 token 延迟从约 2.3 秒降至 0.95 秒。

在这次运行中，KV 缓存峰值约为 0.5%，但队列增长到 24 个请求。缓存压力策略会错过这个瓶颈。团队还提供一个模拟引擎，让用户无需 GPU 就能在笔记本上体验整个设置。