推理服务怎样按请求长度设置超时预算

推理服务不适合给所有请求套一个固定的 30 秒超时。短输入可能主要耗在排队，长输入会增加 prefill，长输出又会拉长 decode；把这些请求混在一个 timeout 里，结果通常是短请求浪费等待时间，长请求频繁被提前取消。

更稳妥的做法是先拿到请求的 input_tokens，再结合允许生成的 max_new_tokens、历史吞吐和排队 P95，计算本次请求的预算。TGI 的官方地址是：https://huggingface.co/docs/text-generation-inference/。下面的数值只是策略示例，不是 TGI 的默认值。

总超时可以拆成“队列预算 + prefill 预算 + 生成预算 + 安全余量”。输入越长，预算可以增加，但必须同时受输入上限、总 token 上限和批次容量约束。

先把总超时拆成三段

先不要急着把网关 timeout 调大。把端到端时间记成四部分更容易定位问题：

• 队列预算：请求等待进入运行批次的最长时间。
• prefill 预算：模型处理输入 token 的时间。
• 生成预算：输出 token 数除以稳定的生成吞吐。
• 安全余量：网络抖动、调度切换和客户端读取的余量。

例如，策略可以写成：timeout = queue_budget + prefill_budget + output_tokens / decode_tps + safety_margin。这里的 decode_tps 要用本部署的历史 P95 或保守吞吐，不要直接照抄模型卡上的数字。

用输入与输出上限计算预算

请求预算至少要检查两个和 token 有关的量：输入 token 数，以及本次允许生成的 token 数。若输入是 1200 token，调用方要求最多生成 600 token，那么本次潜在总量就是 1800 token；如果服务的总 token 上限只有 1500，就应该在入口拒绝或收紧输出上限，而不是等到后端超时。

下面的策略把输入长度分成三个区间。生产环境应使用与模型一致的 tokenizer 计算 token；示例里的 count_tokens 只是接口位置，不能用字符数替代正式计费或限流。

from math import ceil

def build_budget(input_tokens: int, requested_output: int, decode_tps: float) -> dict:
    # 先限制输出，避免一个长提示词再叠加无限生成。
    output_tokens = min(requested_output, 768)
    # 这是单请求的总 token 边界，实际值要与服务端配置保持一致。
    if input_tokens + output_tokens > 4096:
        output_tokens = max(64, 4096 - input_tokens)
    # 长输入增加 prefill 预算；分段只是策略示例，不是 TGI 默认值。
    if input_tokens 

如果入口还要调用 TGI 的 /generate，就把返回的 output_tokens 映射到 parameters.max_new_tokens，把 timeout_seconds 用于 HTTP 客户端的总请求截止时间。不要只增加客户端 timeout，却保留一个更小的模型输出上限。

让 TGI 的 token 与队列边界配套

TGI 文档把 max_total_tokens 解释为每个客户端请求的内存预算；它同时约束输入和生成空间。max_input_tokens 限制输入长度，max_batch_total_tokens 则控制一个批次可能容纳的 token 总量。三者分别解决单请求上限、单次输入边界和批处理容量，不能用一个参数替代全部。

还要关注 max_concurrent_requests 与 max_waiting_tokens。并发上限太大，长请求会把排队拖长；等待 token 设置太大，等待中的请求可能很久才获得运行机会。对于已经超出服务容量的请求，快速返回繁忙或排队超限，往往比无限延长 timeout 更容易保护尾延迟。

# 下面是配置关系示例，数值必须按显存和压测结果调整。
text-generation-launcher \
  --max-input-tokens 2048 \
  --max-total-tokens 4096 \
  --max-batch-total-tokens 8192 \
  --max-concurrent-requests 32 \
  --max-waiting-tokens 20

这些参数是服务边界，不是用户请求的动态 timeout。应用层仍然要根据实际输入长度计算截止时间，并在超时后停止等待、释放连接和记录请求分类。

用分桶指标回调参数

不要只看一个全局平均延迟。TGI 暴露了 tgi_request_input_length、tgi_request_queue_duration、tgi_request_inference_duration 和 tgi_request_duration 等指标，可以按输入长度分桶，分别观察排队、推理和端到端延迟。

回归时至少保留三组输入样本：短输入看固定开销，中等输入看批处理竞争，长输入看 prefill 和显存边界。若队列 P95 上升而推理 P95 稳定，先降低并发或收紧排队预算；若推理 P95 随输入长度明显上升，则优先降低总 token 上限、分离长请求池或增加实例，别只把 timeout 调到更大。

迁移清单：从固定 timeout 改成长度分层

1. 记录每次请求的输入 token、请求的最大输出 token、队列时间、推理时间和总耗时。
2. 先固定服务端的输入与总 token 上限，再定义短、中、长三个输入桶。
3. 为每个桶分别设置队列预算、生成预算和安全余量。
4. 让 HTTP 客户端 timeout 大于桶内预算，但小于上游整体 SLA；超时必须可取消并记录原因。
5. 用 P95/P99 连续回归，确认长请求不会挤压短请求，再调整并发和批次容量。

常见误区是把“模型生成慢”和“请求排队久”当成同一个问题，也不要把 max_total_tokens 当成秒数。前者要看推理延迟，后者要看队列延迟；只有拆开后，超时预算才有可解释的调整方向。

相关问题

输入 token 越多，timeout 是否必须线性增加？

不一定。prefill、批处理竞争和模型实现都会影响曲线，应以分桶 P95/P99 拟合，先用分段策略，再用数据校准。

为什么把 max_concurrent_requests 调大后反而更慢？

并发上限变大可能让更多请求进入等待或争抢批次容量，队列延迟和尾延迟会一起上升；应结合队列指标设置背压。