三个工程师在博客里写下一句话，解释了为什么你的AI对话有时会卡顿——"预填充阶段通常受限于计算，解码阶段则受限于内存。"这不是技术黑话，而是Cloudflare拆解千亿参数大模型的切入口。

一、把一台活拆成两台

打开网易新闻 查看精彩图片

Cloudflare最新发布的推理架构做了件反直觉的事：把原本跑在一台机器上的大模型，硬拆成两台各司其职。

一台机器只读输入。它接收你的提示词，快速处理成模型能理解的格式，同时把中间结果存进KV缓存（一种加速后续计算的记忆结构）。这叫预填充（Prefill）。

另一台机器只生成输出。它拿着缓存里的中间结果，一个字一个字地往外吐回答。这叫解码（Decode）。

「预填充受限于计算，解码受限于内存。」Michelle Chen、Kevin Flansburg和Vlad Krasnov三位Cloudflare工程师在博客中解释了这个设计的核心洞察。两种瓶颈，两种硬件性格，强行塞在同一台机器里，必然有一个在等资源。

拆开后，预填充机器可以堆计算单元，解码机器可以堆高带宽内存。Cloudflare给这套方案起了个名字：分离式预填充（Disaggregated Prefill）。

这听起来像工程上的自然选择，但背后是对大模型推理成本的精确拆解。当Kimi K2.5这种超过1万亿参数、体积约560GB的模型需要至少8块英伟达H100才能载入内存时，每一比特的利用率都直接换算成电费账单。

二、Infire：给GPU排班的自定义引擎

硬件拆完了，软件怎么调度？Cloudflare在2025年Birthday Week上发布了一个叫Infire的自定义推理引擎。

Infire的核心任务是解决一个分配难题：当模型大到必须横跨多块GPU时，如何让它们不互相拖累。

Cloudflare用了两种并行策略。流水线并行（Pipeline Parallelism）把模型按层切开，不同GPU负责不同层。Infire在这里做负载均衡，防止某些GPU干完活干等着，其他GPU还在忙。张量并行（Tensor Parallelism）则把同一层的计算拆到多块GPU，Infire优化的是跨GPU通信速度——数据在卡之间搬得越快，整体延迟越低。

「对大多数模型来说，两种并行策略一起用，能在吞吐量和延迟之间取得最佳平衡。」三位工程师写道。

Infire的另一项优化指向内存。大模型推理时，除了模型本身，KV缓存也会吃掉大量显存。Infire压缩了内部进程的GPU内存占用，让Llama 4 Scout能在两块H200上跑起来，同时留出空间给上下文token；Kimi K2.5在8块H100上运行时，也能给KV缓存腾地方。

启动速度是第三个战场。Infire让模型加载更快，用户等待首token的时间被压缩。

三、Unweight：给模型 weights 瘦身15-22%

Cloudflare还透露了一个叫Unweight的系统，声称能把大模型的权重压缩15%到22%。原文在此处截断，但结合上下文可以推断，这是针对模型存储和传输效率的进一步优化。

权重压缩不是新话题，但放在边缘计算场景里意义不同。Cloudflare的全球网络意味着模型需要在不同节点之间流动，更小的体积直接等于更快的部署和更低的带宽成本。

四、为什么选Kimi K2.5当首测模型

Cloudflare的测试清单里，Kimi K2.5和Llama 4 Scout是两个关键样本。选择它们有明确的工程指向。

Kimi K2.5代表极端规模：1万亿参数，560GB体积，8卡H100只是入门配置。这种模型测的是架构的承载上限——能不能在商用硬件上跑得起来，而不是沦为论文里的理论数字。

Llama 4 Scout则代表另一个极端：用两块H200就能跑，且保留大容量上下文窗口。这测的是架构的经济性——能不能把门槛打下来，让小规模部署也能用上长文本能力。

两个极端都罩住了，中间地带自然不在话下。Cloudflare在之前的文章中已经展示过如何在Workers AI上跑开源模型，这次的技术发布是把底层能力透明化。

五、边缘推理的硬件逻辑

把视角拉远，Cloudflare这套设计反映了一个行业趋势：大模型推理正在从"堆卡竞赛"转向"精算竞赛"。

预训练阶段确实需要万卡集群，但推理阶段的需求图谱更复杂。延迟敏感型应用（比如实时对话）需要解码快；吞吐敏感型应用（比如批量文档处理）需要预填充快；长上下文应用需要KV缓存大；多租户场景需要内存利用率高。

没有一种硬件配置能通吃所有场景。Cloudflare的解法是模块化：分离式预填充让计算和内存解耦，Infire让并行策略灵活组合，Unweight让模型体积弹性可调。

这种模块化的代价是复杂度。工程师需要理解不同模型的计算特征，需要调优流水线并行的切分点，需要权衡张量并行带来的通信开销。但收益也很实在：同样的硬件预算，能支撑更多用户或更大模型。

六、对开发者的实际影响

如果你在用Cloudflare Workers AI跑模型，这些底层优化最终会翻译成三个可感知的变化。

第一是成本结构。更高效的GPU利用意味着同样的调用量，账单数字可能往下走。或者同样的预算，能试探更大参数的模型。

第二是响应质量。首token延迟降低，流式输出的卡顿减少，长对话的上下文丢失概率下降。这些体验细节决定用户留存。

第三是模型选择自由度。当基础设施能弹性适配不同规模的模型，开发者选模型时少了一层"我的硬件跑不跑得动"的顾虑，可以更纯粹地从业务需求出发。

Cloudflare没有公布具体的性能基准数字，比如"比AWS快X%"或"成本降低Y%"。这种克制反而让技术细节更可信——他们展示的是架构设计思路，而非营销话术。

七、一个值得跟踪的信号

分离式预填充不是Cloudflare独创。Google、AWS、Azure都在探索类似的拆解方案。但Cloudflare的特殊性在于边缘网络的密度——他们在全球300多个城市有节点，这意味着推理可以离用户更近。

当模型被拆成预填充和解码两个阶段，一个自然的延伸问题是：能不能把预填充放在中心机房，解码推到边缘节点？这样既能利用中心化的计算密度处理复杂输入，又能让输出生成贴近用户降低延迟。

Cloudflare的博客没有明确说这个部署模式，但他们的网络拓扑理论上支持这种玩法。如果未来发布相关案例，将是边缘AI架构的重要进化。

另一个跟踪点是Unweight的完整技术细节。15-22%的压缩率如果能在精度损失可控的前提下实现，对模型分发和边缘缓存都是实质性改进。原文在此处中断，后续发布值得留意。

如果你正在评估AI基础设施选项，建议把这篇博客加入阅读清单。不是因为它给出了标准答案，而是因为它展示了问题拆解的精确性——从大模型的双重瓶颈，到GPU调度的并行策略，再到内存占用的毫米级优化。这种颗粒度的技术透明，在当前的市场环境里并不多见。