北京
Cloudflare最近发了篇技术博客，讲他们怎么在Workers AI平台上跑Kimi K2.5和Llama 4 Scout。文章里有p90首Token延迟曲线，有吞吐数字，坦承了背后的工程优化。但和所有这类平台方的技术分享一样，它只展示了能对外说的指标。
真正搞生产推理的人关心的另外三个维度——p90之后的尾延迟、多GPU卡间的速度差、以及按租户拆分的归因——这篇博客一个字没提。下面说说为什么这种缺失是常态，以及卡级可观测性到底能补什么。
先快速过一遍Cloudflare公开的数据：Kimi K2.5（1万亿参数以上）最少需要8张H100；Llama 4 Scout跑在2张H200上；Workers AI平台的p90 TTFT有 measurable 的改进。模型规模、GPU数量、 headline延迟——典型的推理平台发布三件套。
但生产环境不是这么运行的。
第一，p90之后的尾巴
p90是给客户看的摘要。真正的可靠性看p99或p99.9。那个等了8秒才收到回复的用户，前100次调用都是600毫秒——这种人才会写工单。尾巴的形状决定重试是救命还是雪上加霜。
尾巴由这些东西塑形：推测解码的接受率在负载下暴跌；batch边界切换时的内核启动开销尖峰；PCIe争抢——主机到GPU的流量和卡间集合通信打架；多卡prefill时某张卡走了慢路径。吞吐图拆不开这些。p99分布按根因拆分可以，但根因分类需要卡级、per-collective的数据打底。
第二，多GPU的速度差
8张H100切1T参数模型，意味着张量并行，意味着每次前向传播都以AllReduce屏障收尾。最慢的那张卡决定每个token边界的墙上时间。某张卡稳定慢5%——NUMA位置不对、主机侧有吵闹邻居、热节流——整体服务速率直接掉5%。
这是eBPF可观测性的主场：在libnccl的集合操作入口和出口符号上挂uprobe，采集ncclAllReduce、ncclBroadcast等调用的起止时间戳。DCGM只到主机级GPU计数器。内核侧的eBPF才能给出卡级、租户级的信号——平台方的技术博客永远不会发这些。
第三，按租户归因
多租户推理集群里，A用户的超长prompt把B用户的延迟顶高，这种交叉影响在主机级指标里完全隐身。需要per-rank的调度事件流才能还原。
想看点真实的？Echo AI放了一个多节点fan-in演示的DuckDB追踪文件（echo-fanin-demo.db，约1MB），包含2000个事件、跨网络的80条因果链、端到端检测出的18个straggler。不是NCCL卡级抓取，但足够验证跨节点聚合这件事长什么样。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
