LLM 请求路由应把缓存亲和性作为一等约束，再在可接受的失衡范围内做负载均衡。只追求 GPU 平均利用率看似能摊平算力，却可能把同一会话轮换到没有既有 KV 缓存的实例；后续请求需要重新预填充上下文，首 token 延迟随之放大，长上下文场景尤其明显。
先区分两类工作负载
路由前应按请求是否延续既有上下文分层。多轮对话、工具调用链、代理任务和流式续写通常具有明确的会话连续性，命中原实例的价值较高。一次性短问答、离线批处理和无状态嵌入请求则更适合按队列深度或可用容量调度。这里的缓存既可能是模型服务进程管理的 KV 缓存，也可能是上层应用维护的上下文复用信息；两者的生命周期、可迁移性和失效条件必须分别定义。
平均利用率为何会误导路由
GPU 利用率是滞后且聚合的信号，不能直接说明某个请求的完成时间。一个利用率较低的实例可能没有目标会话的缓存，接收请求后会产生额外预填充；一个利用率较高的实例若已保留该会话状态，反而可能更快给出首 token。更重要的是，平均值会掩盖尾部排队、显存碎片、长请求占用和批处理窗口差异。将所有请求机械迁向“更空闲”的 GPU，常会同时造成缓存抖动、跨实例状态查找增加，以及热点会话在短时间内反复冷启动。
建立可解释的路由优先级
建议按“精确亲和、受控亲和、通用均衡、降级处理”排序。精确亲和指会话标识映射到仍持有有效缓存的实例；受控亲和允许在该实例排队未超过阈值时保持粘性；超过阈值后，才在同一资源池内选择容量更合适的实例。无会话或缓存已失效的请求进入通用均衡。路由键应采用稳定、不可逆的会话标识或租户与会话组合键，避免把原始提示词、凭据或敏感业务字段写入调度日志。
- 为每个会话记录缓存归属、最近访问时间、模型版本和失效代次。
- 将队列等待、预计预填充成本、并发上限与取消率作为联动信号，而非只读取利用率。
- 模型版本、适配器、采样配置或上下文格式发生不兼容变化时，主动使亲和记录失效。
亲和策略的适用边界
缓存亲和并非越强越好。少数超长会话持续占据同一实例时，强粘性会形成局部热点，拖慢其他同池请求；实例故障、扩缩容、滚动升级和缓存逐出时，也不能承诺命中。若服务端不暴露可靠的缓存归属或缓存命中信号，路由器不应依据猜测构造“伪亲和”。跨节点迁移是否有收益，取决于服务框架、互连、并行方式和现场配置。多 GPU 通信的基本语义与运行要求应按 NCCL User Guide 复核；不要把通信库能力直接等同于应用缓存能够透明迁移。
把 GPU 利用率放回正确位置
利用率仍是必要的保护信号，但适合用于限制风险：拒绝将新会话送入持续拥塞的实例，发现异常空闲或异常饱和的分区，并触发扩缩容或排障。它不应覆盖已知的高价值缓存命中。实践中可为亲和实例设置排队上限、活跃请求上限和预填充预算；任一上限触发时才解除亲和。这样既避免单实例无限堆积，也避免因短暂利用率波动频繁迁移会话。集群拓扑、网络与计算资源的规划还应结合 NVIDIA DGX SuperPOD Reference Architecture 的适用范围审阅，并以部署版本和现场环境为准。
按小流量逐步落地
- 先补齐请求链路标识：生成会话键、模型代次、路由决策、缓存命中状态和最终实例标识。
- 选择一个上下文复用明显的业务池，保留现有均衡器作为对照，只对部分会话启用软亲和。
- 配置明确的解除条件，包括实例不健康、排队超限、缓存缺失、模型代次变化和人工熔断。
- 在流量扩大前演练实例下线、缓存清空、版本切换和路由存储不可用，确认请求可回到无状态路径。
用端到端指标验证取舍
验证不能只看集群平均利用率。应同时比较缓存命中率、首 token 延迟的分位数、全响应完成时间、排队时间、请求取消率、重试率、单实例活跃会话数以及实例间负载离散度。对长上下文与短请求分别统计，防止总体均值掩盖一类用户的退化。还应检查命中率上升是否真的带来首 token 改善；若没有，可能是缓存并未覆盖实际预填充成本，或排队和批处理策略抵消了收益。
明确回退而非固化绑定
回退路径应先保证可用性，再追求命中：亲和目标不可用时，删除或标记其归属记录，将请求路由到健康实例并按冷缓存处理；路由元数据异常时，切换为经过限流保护的无状态均衡；策略发布后指标恶化，则通过开关停止新会话的亲和分配，而不是强行迁移所有存量会话。这样可以在不依赖单一缓存假设的前提下，让路由策略随工作负载变化调整。
WeChat
Profile