2026-10-24
用完整会话评价缓存与排队，而不只看解码速度
待验证的工程方向 · 推理服务 / KV 缓存 / 多租户调度
在已有推理服务之上回放长短混合会话，检验前缀缓存、准入和公平等待怎样共同影响完成率。先复用已有控制机制，再决定是否需要新调度策略。
他们已经做了什么
llm-d 1.0 在 Kubernetes 上组织推理服务，围绕底层推理引擎提供请求路由、缓存复用和运行管理。IBM 的发布说明强调多租户服务质量、流量控制与生产运维；这些属于作者发布说明，本文没有运行部署，也未据此核实宣传中的成本倍数。链接到具体流量控制说明的文档本次返回 404，配置细节仍需补查。
Agens 1.3.5 的变更记录给出了更窄但更具体的压力场景：旧版在重度长上下文负载下可能因 KV 空间不足中断回答。新版在接纳请求及推进计算时检查运行中请求是否仍能完成，并增加等待、会话感知驱逐和兼顾短请求与老请求的预填充安排。KV 缓存保存已经计算过的注意力中间状态；复用它能省计算，长期占着它也会影响其他会话。这些改动与作者测试值得复查，仍不是独立生产证明。
为什么把这些线索放在一起
全库成本观察一再提示，局部省下的 token 不一定等于完成一次任务更便宜。llm-d 的方向入口把问题扩到分布式服务，Agens 的最新记录则给出一个实际失败：请求已开始，却没有足够空间把它做完。两者规模不同，不能直接比较宣传数字，但都需要在多个会话相互影响时评价。
这里的机会是一个可复用的回放与诊断工具。比起立刻设计更聪明的缓存算法，先明确谁因为缓存局部性受益、谁因为长会话等待、哪些任务被中途放弃，更容易发现值得改变的策略。
可以往哪些方向走
构造同一组长文档问答、多轮 Agent 与短聊天轨迹，固定模型、硬件、最大输出和到达序列。先比较现有默认配置与项目已经提供的缓存、准入或公平性选项，分别记录从到达到完成的时间、首 token 前等待、中断、重试和每类会话的成功完成数。将缓存命中与被迫等待放在同一条请求轨迹上，避免用总吞吐掩盖某类会话一直排不到。
再改变一个因素，例如重复前缀比例或长会话集中到达程度。若改善只来自缩短允许输出，或把失败移成无限等待，就不能算相同工作量上的收益。只有已有机制仍表现出稳定缺口时，再提出调度修改，并与最简单的限额或分队列方法比较。本期尚未执行这些回放。
值得做在哪里
它能帮助部署者决定需要更多显存、更合理的准入，还是不同的工作负载隔离，而不是看到超时就先换模型。对提供长会话服务的团队，完整完成率和尾部等待往往比单流最快速度更接近用户体验。
方法也容易迁移：把缓存看成有使用者和占用时间的共享资源，同时记录省去的计算与别人付出的等待。最终是否划算，要在相同任务要求下把重试和未完成请求算进去；工具不能替团队预先宣判某个引擎更好。
从哪里开始看
先读 Agens 1.3.5 的长上下文负载、会话驱逐和请求日志字段，再核对实际可用的 llm-d 发布版本与配置文档。可以从单机、少量并发和固定文本轨迹开始，保留请求级时间戳与最终状态；分布式扩展留到数据表明确实显示瓶颈时。
若设备不足以运行目标模型，就先制作与审核回放格式和统计定义，不把模拟等待结果当成真实吞吐。恢复可访问的官方流量控制文档，也是进入 llm-d 实测前的必要准备。
暂时不往哪里走
这是跨已有机制的工程评价方向，不主张提出新的公平调度算法。Agens 与 llm-d 的硬件、模型和规模不同，不直接横比其作者数字；本期未部署服务或测量性能。
回看线索
来源与查新记录
-
IBM Research · llm-d 1.0 · 2026-10-24 · 已读发布说明；具体 flow-control 文档返回 404，未据此确认配置或成本优势。
-
Agens Engine · 1.3.5 变更记录 · 2026-10-24 · 已读请求准入、KV 池、会话驱逐和公平预填充说明；数据为作者测试。