Daily Edition · 2026-08-23
本期关注模型服务控制面的关键盲区：前缀缓存如何转化为路由计划，配置测量如何围绕 SLO 收敛，延迟拉取怎样把启动成本转移到运行期，以及推测解码如何把候选选择下沉为专用 GPU 路径。
CacheRoute 针对前缀缓存与负载均衡的冲突，周期性生成 prefix-affinity 路由计划：高频 key 被分配到稳定 warm set，并按预期负载放置，过热 key 可拥有多个目的地。作者在 60 张 H100、Llama-3.3-70B FP8 和半合成负载上报告，在 3.5 秒 p99 SLO 下达到 176±11 QPS，为五个基线中最强者的 2.3 倍，同时将实际服务的 KV cache 命中率从 64.1±1.3% 提升到 93.2±0.5%；两组 32B 反例则显示，当可复用 KV 工作量不足时，亲和造成的负载偏斜会抵消收益。
为什么值得读：prefix-aware routing 不能只依据 key 热度静态启用；它同时是缓存放置、负载预测和尾延迟控制问题。论文明确给出反例并建议先做 shadow replay，为生产系统判断“复用收益是否大于负载偏斜”提供了比单看命中率更可靠的上线门槛。
该研究以 KServe 对比 eStargz/stargz-snapshotter、AWS SOCI 与 eager pulling，测试 2—140 GB 容器制品及真实 FP16 权重。作者报告 lazy pulling 将冷启动 time-to-first-prediction 收敛到 16.9—17.6 秒，而 eager 路径随制品大小为 24.5—573.0 秒；但 14 GB 模型经 lazy mount 完整读取需 105.3 秒，反而慢于被替代的 72.4 秒 eager pull。更关键的是，默认配置下节点级 snapshotter cache 耗尽可让运行中 Pod 的模型文件读取失败，而 Kubernetes 与应用健康检查曾持续 196 秒仍全部通过。
为什么值得读：延迟拉取不是消除成本，而是改变成本出现的时间和故障边界。对模型平台而言，Ready/Running 状态不足以代表权重可读；节点缓存容量、snapshotter 日志、真实文件读取探针和 daemon 重启语义都应进入调度、监控与故障演练。
FleetSieve 不追求完整刻画每个 tensor-parallel 与 replica 配置，而是优先测量最可能改变最终 fleet allocation 的点。方法联合建模容量与尾延迟，对比保守和乐观配置，并在决策差距低于容差时停止；作者在一个 31B 开放权重模型的固定 H100 测量网格上，以 22,200 GPU-seconds 达到 oracle 聚合决策，固定比较中比均匀随机 profiling 少 6.9%，200 个随机揭示顺序下平均节省 5.4%。实验也展示仅看容量会选中 completion p99 为 46.4 秒、违反 30 秒 SLO 的配置。
为什么值得读：服务配置搜索的目标不是得到一张漂亮的性能曲面，而是以最少测量成本做出正确资源决策。把 profiling budget 与下游 allocation 直接耦合，可减少昂贵 GPU 实验，也提醒团队必须联合测量吞吐和尾延迟，而不能假设更高 TP 或更多副本单调更优。
Dynamo v1.4.1 为前端加入 OpenAI-compatible `/v1/classify` 与 `/v1/pooling` 端点，并接通 vLLM pooling-family worker；响应覆盖 float、base64、bytes 与 bytes_only 格式。补丁还修复了一个路由恢复问题：请求路径将 worker 标记为 overloaded 后，在监控缓存指标集为空的特定状态下，健康负载观察不会重新发布权威集合，导致 worker 可能长期滞留在过载状态；同时修复 `logprob_token_ids` 被前端拒绝及 vLLM-Omni 的 NIXL 序列化对象传输失败。
为什么值得读：小型 patch release 暴露了 serving control plane 的重要事实：过载标记本身也是需要一致性与恢复语义的分布式状态。分类、pooling 和生成共享前端后，协议兼容、二进制响应、路由退避与后端版本锁定会共同决定系统是否可运营。
vLLM v0.28.0rc2 将 DFlash2 合入 V2 model runner：draft block 内加入 grouped dynamic depthwise convolution，让后续 proposal position 读取块内先前位置；candidate selector 则保留 target head 每个位置的 top-K，通过相邻 transition score 选择路径，并以单个 Triton program 在请求内完成 walk。合入 PR 的发布方自测使用单张 H200、Qwen3.8-27B、GSM8K、每步 7 个 draft token；在并发 1、8、32 下，DFlash2 相对 autoregressive 的输出吞吐分别为 3.51、2.91、2.20 倍，且这些数字只适用于 PR 所列模型、采样参数、请求规模和测量方法。
为什么值得读：推测解码正在从“一个更小的 draft model”演变为包含局部时序建模、候选路径选择与专用 GPU kernel 的子系统。PR 也量化了额外 selector/conv 开销，并显示 vocabulary top-k 才是 selector 的主要成本，为后续 fusion 与后端选择提供了明确优化目标；但这是 release candidate，生产升级仍应单独验证兼容性。
这个主题下今天没有条目。