Cloudflare 已经把一台自研的 LLM 推理引擎投入生产,跑在他们整张全球网络上。引擎叫 Infire,底下的架构选择是 prefill/decode 解耦 —— 把输入处理和输出生成分到针对各自优化的不同机器上 —— 结果是 Cloudflare 现在能在边缘托管像 Kimi K2.5(1T+ 参数,磁盘上 ~560GB)这种万亿参数级的开放模型,旁边还跑着 Llama 4 Scout。真正有意思的不是这次发布;而是其中一家最大的 CDN 加入了那个不靠 vLLM、不靠 SGLang、自己跑推理栈跑出规模的小群体。
P/D 拆分是承重的架构选择。Prefill 受算力限制:处理输入 prompt,填 KV 缓存。Decode 受内存带宽限制:读 KV 缓存,一次发一个 token。把这两个阶段放同一台机器,谁不是瓶颈,谁就在浪费硬件。Infire 把两阶段分到针对各自画像优化的机器上。在此之上,Infire 把流水并行(按模型层在 GPU 间切片)和张量并行(在层内按张量切片)联动起来,明确目标是防止某一阶段的 GPU 在另一阶段执行时挨饿。硬件占用很具体:Kimi K2.5 至少要 8 张 H100(模型本身 ~560GB,剩下的 HBM 给 KV 缓存);Llama 4 Scout 在 2 张 H200 上跑得开,还剩下相当多的上下文容量。
第二件东西是 Unweight,Cloudflare 自研的权重压缩系统,在不损失精度的前提下把模型权重缩 15-22%,减少推理时跨 GPU 的数据搬运量。在万亿参数尺度上,权重搬运是一个实打实的成本维度 —— 加载字节数每少一个百分点,都是真实的瓦数和真实的延迟。再往大看一层:Cloudflare 正在把自己定位成「以通用基础设施层的方式托管前沿规模开放模型」,跟它托管静态资源是同一种姿势。如果 Kimi K2.5 和 Llama 4 Scout 在 Cloudflare 上能拿出可信的冷启动和 TTFT 数字,那「自己租 H100 集群 vs 走 Cloudflare」的每 token 成本算式就会改写。包装层经济多了一块基础底,「我这 1T 参数模型放哪跑」也就不再是一个采购项目。
如果你基于前沿级开放权重模型出货、又不想自己运营一池 GPU,Workers AI / Infire 现在所处的竞争位置已经不是一年前那个了 —— 把同一份工作负载在那边和你当前供应商那边各跑一遍,看 TTFT 和每 token 成本(尤其是长上下文的编码代理 trace),那才是有意义的对比。如果你在自家跑推理栈,P/D 解耦这个模式是带回家的那一份;流水并行 + 张量并行联动(而不是二选一)是落地时的实现注记。就我目前看到的,Unweight 还没开源,所以权重压缩仍是一个 build-or-buy 抉择。给 vLLM 和 SGLang 「保持顶流」的竞争压力,刚刚变得更具体了。