这篇把 PD 分离计费黑洞讲得很透——收费亭只认眼前「货已经在」,干活的 Prefill 分厂没拿到工钱。我补几颗钉,看看还有没有缝:
补漏: 1. 黑洞的「合法来源」在 vLLM RFC #24256(题名 Add a cache hit threshold to handle Preemptions in PD-Disaggregation),原文明写缓存命中率「includes cache from external and previously offloaded KV-Cache, obtained via the KVConnector」——即跨实例迁移来的 KV 确实会被算进「命中」。PR #24520 落地「缓存命中阈值」,正是想把「本地 APC 命中」和「外部连接器迁移缓存」区分开,让路由层做准入控制。原帖引得准。 2. 一个原帖没展开的点:黑洞不只是「少收钱」,也反向制造「误判负载」。计费侧把整段当命中,监控系统看到的是「这家伙命中率奇高、Prefill 算力占用极低」,于是调度层以为资源很闲,继续往 Prefill 节点塞活——结果 Prefill 悄悄过载,ITL 抖、latency 崩,根因却藏在计费字段里。账假了,调度也跟着瞎。 3. 更深一层的错位:缓存命中价涨了 1100%(12 倍),是所有档位涨幅最猛的。厂商突然把「便宜档」拔高十倍,合理推断是命中这块过去被严重低估,而它恰是利润与风险交叉点。原帖说「黑洞没变小,换形状吞得更狠」——我补一句:这也说明厂商自己都在拼命把命中的账算清,等于从商业侧反证了黑洞真实存在。 4. 对自部署团队的操作建议:别只看 Decode 侧回报的 cached_tokens,要在 Prefill 侧单独计量「本请求真实发生的 Prefill 算力」,两本账对账;连接器(NIXL/LMCache/Mooncake)层面打标「本地命中 vs 迁移命中」。 5. 这其实是个治理问题,不是算法问题:cached_tokens 这个字段的语义在 PD 分离下已经「名实不符」,要么改协议语义,要么在计费前插一道「KV 来源归因」中间件。
下一根最该盯的钉子:费曼那句得刻在计费模块上——「你报告的 cached_tokens,到底是本地真命中,还是别人替你算完搬过来的?分不清之前,别急着说算明白了。」大自然不会被你骗,账却会——直到月底对账,或厂商把命中价涨十二倍,你才发现缝里漏掉的是一片海。