Cloudflare 小型模型服务降低内存占用，但安全性成为考验

Cloudflare 的小型模型服务如今可在 GPU 内存中容纳两倍的 Kimi 上下文，代价是在常规并发量下接受略慢的处理速度。该公司还压缩了 GLM 权重，并在受支持的解码操作读取共享缓存页之前对其进行检查。这些变化共同将 GPU 内存从固定上限转变为 Cloudflare 能够主动管理的资源。

这之所以重要，是因为 Moonshot AI 的 Kimi 模型和 Z.ai 的 GLM 模型并非推理目录中的普通新增选项。它们结合了庞大的参数规模、长上下文窗口以及混合专家架构。混合专家模型会针对每个 token 激活网络中的部分模块，从而减少计算量，但并不会让其存储的权重变小。

这种矛盾并不只是 Cloudflare 与另一家推理服务商之间的竞争，而是高密度利用率与共享硬件上安全隔离之间的较量。将更多请求装入一块 GPU 可改善经济性和总吞吐量，但也会放大缓存管理出错的后果。

Cloudflare 表示，新配置在保持模型准确性的同时提高了容量。不过，大部分支撑性测量数据来自 Cloudflare 自己的评估套件和基础设施。接下来的考验是，这些收益能否在不同工作负载、硬件世代和大得多的生产规模下保持稳定。

Cloudflare 为 Kimi 和 GLM 做了哪些调整

Cloudflare 结合了三种内存技术，因为没有单一优化能够解决前沿规模模型的服务问题。

该公司在 8 月 3 日的一篇技术说明中详细介绍了这些变化。它将 FP8 量化用于 Kimi 的 KV 缓存，将 INT4 压缩用于 GLM 的权重，并为共享缓存页加入完整性标签。每种技术都针对同一推理系统中的不同约束。

KV 缓存存储模型已处理 token 所生成的注意力键和值。它使模型能够继续进行对话，而无需在每次生成 token 前重新计算整个提示词。长提示词和并发请求会让该缓存迅速增长。

Cloudflare 将 Kimi K2.6 的缓存数据从 BF16 改为以 FP8 e4m3 存储。FP8 对每个浮点值使用八位，而 BF16 使用十六位。该转换使缓存的内存占用减半。

据 Cloudflare 称，测试部署中的可用内存上下文从约 686,000 个 token 提升至约 137 万个 token。这是该部署上的总容量，而不是单个用户新的上下文窗口上限。这一区别很重要，因为该优化主要提升的是并发能力。

Cloudflare 还对 GLM 5.2 进行了单独调整。它将模型权重从 FP8 压缩为 INT4，即四位整数表示。据称，检查点大小从 705 GB 缩减至 421 GB，约减少 40%。

八路张量并行部署会将模型分布到八块 GPU 上。在这一配置下，Cloudflare 表示每块 GPU 的内存使用量从约 88 GB 降至 52 GB。剩余空间可容纳约 118 万个 KV 缓存 token。

第三项改变用于保护这种更高密度打包所创建的共享缓存。每个物理缓存页都会获得一个标签，并会在该页面重新分配时发生变化。服务器会记录每个请求所预期的页面及其标签。

在受支持的解码操作读取这些页面之前，Cloudflare 会检查映射关系。若出现不匹配，受影响的请求将停止。因此，该系统应以安全失败的方式运行，而不是读取与另一请求相关的数据。

这些技术建立在 Cloudflare 更广泛的大模型架构之上。该公司此前将 Infire inference描述为专为其分布式 GPU 网络设计的 Rust 引擎。它还将预填充和解码划分到不同的资源池中。

预填充会处理传入的提示词并创建初始缓存状态。解码则逐个生成响应 token。这两个阶段对 GPU 施加的压力不同，因此 Cloudflare 可以分别优化每个资源池。

这种分离对新设计至关重要。Cloudflare 在计算占主导的场景中保留 BF16 缓存和 FP8 权重；在内存容量或带宽成为限制资源的场景中，则使用更小的表示格式。

结果并非一种统一压缩的模型配置，而是一套会根据工作负载改变格式、感知阶段的服务系统。这增加了运维复杂性，但避免了在整个请求过程中强行采用同一种折中方案。

为什么 Cloudflare 的小型缓存胜过单纯的速度

Kimi KV 缓存量化的优势在于接纳更多工作，而不是让每个请求单独运行得更快。

Cloudflare 在解耦式 H200 部署上测试了 Kimi K2.6 解码。单个并发请求时，BF16 缓存实现了每秒 137 个 token，而 FP8 版本为每秒 125 个 token，因此压缩缓存在线性负载下更慢。

随着并发量增加，这一模式仍在延续。八个请求时，BF16 达到每秒 731 个 token，FP8 为每秒 689 个。十六个请求时，测得结果分别为每秒 1,106 个和 1,028 个 token。

BF16 在 32 个并发请求时达到每秒 1,558 个 token，但随后耗尽可用内存。Cloudflare 表示，FP8 缓存可继续支持 64 个请求，并实现每秒 2,192 个 token。

这一最终数字比 BF16 测得的最高吞吐量高约 41%。Cloudflare 还报告称，每个 token 的成本约降低 30%。收益来自在同一部署上完成更多工作，而不是加速每个低负载请求。

这种区别避免了一个容易出现但具有误导性的标题。注意力内核读取缓存值时，量化会引入转换工作。在相同并发量下，Cloudflare 的 BF16 结果仍快了几个百分点。

只有当内存限制阻止更大格式接纳更多请求时，Kimi KV 缓存量化才会体现价值。它以适度的单请求效率换取大幅提升的总容量。当需求足以持续使用新增空间时，这是一种合理的权衡。

在流量稀疏时，其价值就较低。仅服务少量同时请求的部署会承受转换开销，却无法利用额外容量。因此，Cloudflare 的方法取决于能否将足够多的兼容工作路由至各个解码池。

这正是全球基础设施具有战略意义的地方。大型服务商能够汇聚众多客户的流量，让昂贵的加速器保持繁忙。较小的运营商则常常面临突发性需求，因而无法获得同样的利用率收益。

Cloudflare 已在 Workers AI 中使用会话亲和性和前缀缓存。前缀缓存会复用相同提示词开头的已计算状态。其大模型上线披露了缓存 token 的使用情况，并引入了会话亲和性请求头，以改善缓存路由。

较新的优化针对的是不同层面。前缀缓存避免重复的预填充工作，而 FP8 则扩展解码容量。两者结合可减少重复计算，并接纳更多活跃序列。

Cloudflare 比较了多项评估中的准确性。在 GSM8K 上，BF16 得分为 94.24，FP8 为 94.09；MMLU 的结果分别为 89.11 和 89.04。

FP8 缓存在 ARC-Challenge 上得分 67.49，而 BF16 为 66.72。在 MMLU-Pro 上，FP8 得分 79.29，BF16 达到 80.29。工具调用有效性方面，FP8 为 92.6%，BF16 为 92.2%。

Cloudflare 将这些结果描述为无差别。在所报告的评估套件中，这一结论是合理的，但这些分数并不能证明普遍等价。细微的数值变化可能影响罕见提示词、长代理轨迹或所选评估之外的任务。

若干测试还会产生非确定性输出。极小的分数差异可能反映采样、评估噪声或量化的影响。读者需要重复试验和置信区间，才能区分这些原因。

该公司的内部 mcxams 基准测试得出了相同结果，两种配置均通过了 63 项测试中的 61 项。内部评估可以很好地反映生产需求，但外部人士无法独立检查其覆盖范围。

因此，Kimi KV 缓存量化应被视为一项具有令人鼓舞的质量证据的运营成果。它并不意味着每个模型都能安全地使用 FP8 缓存值。不同架构的注意力分布和数值敏感性各不相同。

Cloudflare 真正的成就是找到了格式变化能够带来回报的位置。预填充仍受计算限制，因此公司将其缓存保留为 BF16。解码则受内存限制，使更小的 FP8 表示在较高并发下变得有用。

这一选择支撑了核心观点：更好的推理并不总是意味着让单个请求运行得更快。在大规模场景下，它往往意味着在硬件达到内存上限之前完成更多有用工作。

真正的竞争是每个有效 token 的内存占用

前沿模型托管越来越依赖内存效率，而不只是醒目的参数规模。

Kimi K2.6 属于一个结合了大规模存储权重、长上下文和代理功能的模型家族。Cloudflare 当前的模型文档列出了 262,144 个 token 的上下文窗口、视觉输入、工具调用和结构化输出。

这些能力带来了重叠的内存需求。模型权重必须在生成过程中保持可访问；每个活跃对话也会构建不断增长的 KV 缓存，而批处理要求服务器同时追踪大量序列。

模型可以装入 GPU 内存，却依然不具备经济的服务成本。如果其权重为缓存页留下的空间很少，每个部署就只能支持更少的活跃用户。空闲或未充分填充的批次随后会浪费昂贵的加速器容量。

这正是 Cloudflare 的小型表示格式旨在改变的竞争。相关指标变成了在可接受的延迟和质量限制内，每单位内存产出的有效 token 数量。单个请求下的原始速度只能揭示系统的一部分。

这种转变也给主要依赖标准推理栈的服务商带来压力。如果两项服务使用相似的硬件和模型权重，缓存管理更好的服务商就能接纳更多并发工作，也能将固定基础设施成本分摊到更多生成的 token 上。

不过，软件改进并不能消除硬件差异。H200 GPU 提供了大量高带宽内存，而较新的 Blackwell 系统增加了不同的低精度能力。一种加速器配置的结果不会自动迁移到另一种配置。

流量形态同样重要。编程代理可以提交大型提示词、复用前缀、调用工具，并在多轮交互中持续运行。面向消费者的聊天会话可能使用更短的提示词，后续交互模式也更难预测。

代理型工作负载可以让一个序列在内存中驻留更久。这提高了缓存容量的价值，但也使调度更困难。一个异常长的请求可能占用内存，而许多较小请求则在等待。

Cloudflare 的解耦式预填充和解码设计正是为了应对这种不平衡。计算密集型的提示词接收在一个资源池中运行，内存敏感的生成在另一个资源池中运行，从而使每个资源池都能独立扩展并使用不同的数值格式。

这一设计也带来了协调成本。缓存状态必须跨越阶段边界迁移，或始终保持可访问。路由决策必须考虑可用内存、既有前缀、队列深度以及每个响应的预期长度。

SGLang 项目提供了 Cloudflare 在实验和生产流量中使用的服务框架。Cloudflare 表示，它与该项目合作，将补丁和功能上游化。这使得部分改进不局限于单一服务商。

开放基础设施可以缩小大型平台与独立运营者之间的软件差距。但部署经验仍然至关重要。公开的内核或调度器功能，并不会自动带来 Cloudflare 的流量规模、遥测能力或容量规划能力。

这种差异使竞争压力呈现间接形式。Cloudflare 并未宣称 Kimi 或 GLM 是独家模型。它主张的是，其基础设施能够以足够高的效率运行开放权重前沿模型，从而提供共享式、无服务器访问。

模型开发者也能从这种安排中获益。Moonshot AI 和 Z.ai 可以触达那些不愿自行配置多 GPU 集群的用户。更广泛的托管支持能够提高采用率，并带来更多关于真实工作负载的反馈。

作为交换，服务商承担了更棘手的责任。它必须在转换数值格式时保持模型行为，同时还必须防止一个租户的缓存状态影响另一个租户的输出。

因此，最强的运营商将同时优化三个变量：内存容量、输出质量和隔离性。只改善其中两项会导致服务不稳定。更高密度而缺乏隔离会引发安全担忧，而未经过质量测试的压缩则可能带来隐蔽的性能退化。

对于采购方而言，基准测试领先地位依然重要，但并不完整。一个出色的模型，只有在服务层提供可预测的延迟和正确的工具调用时才有价值。漫长的排队时间可能抹去更强模型的实际价值。

开发者也应将模型质量与服务商质量区分开来。由于量化、采样默认值、缓存策略和服务软件不同，同一个 Kimi 或 GLM 检查点在不同托管方上可能表现不同。

生产环境评估应衡量完整任务，而不是孤立答案。有效信号包括工具调用有效性、超时率、长会话一致性，以及真实并发下的延迟。这些指标能揭示内存优化是否真正改善了应用。

GLM 权重压缩改变了阶段权衡

GLM 权重压缩能加快解码，因为更小的权重可减少内存流量；但它会拖慢计算密集型的预填充阶段。

Cloudflare 将 GLM 5.2 权重从 FP8 转换为 INT4。在解码期间，系统会反复从高带宽 GPU 内存中流式读取模型权重。当内存带宽成为瓶颈时，传输更少字节可以让每个 token 更快生成。

低并发结果最为明显。在单个请求下，FP8 每秒生成 60 个 token，而 INT4 达到 92 个。这相当于报告所称的 55% 提升。

在 8 个并发请求下，吞吐量从每秒 425 个 token 提升至 513 个，增幅为 21%。在 16 个请求下，INT4 每秒生成 825 个 token，而 FP8 为 683 个。

在更高负载下，改进依然可见。32 个请求时，INT4 达到每秒 1,267 个 token，而 FP8 为 994 个。64 个请求时，两者结果分别为 1,933 和 1,672 个。

GLM 权重压缩不会在预填充期间带来同样的收益。INT4 权重必须在矩阵乘法之前展开。Cloudflare 测得 INT4 的预填充吞吐量约为每秒 8,660 个 token，而 FP8 为每秒 10,160 个。

因此，处处使用 INT4 会牺牲提示词处理吞吐量。Cloudflare 转而在预填充阶段保留 FP8，并在解码阶段使用 INT4。这种拆分为每个阶段保留了实测表现最佳的格式。

这一发现呼应了 Cloudflare 早先关于无损权重压缩的工作。该项目探索了多种执行路径，因为批量大小和矩阵形状会改变解压缩与计算之间的平衡。

当前的 GLM 方法采用有损量化，而非此前的无损方法。将 FP8 权重转换为 INT4，会把更多数值映射到更少的可表示状态中。由于原始权重无法被精确重建，准确性测试变得不可或缺。

Cloudflare 报告称，在其评估的各项基准测试中，差异低于 0.8 分。MMLU 的平均分为：FP8 86.60，INT4 86.54。MMLU-Pro 的精确得分分别为 80.80 和 80.47。

在 ARC-Challenge 准确率方面，FP8 为 64.93%，INT4 为 64.85%。在 Cloudflare 内部的 mcxams 基准测试中，两种格式均通过了 63 个案例中的 62 个。

GSM8K 显示出稍大的差异。FP8 的精确匹配率为 94.39%，而 INT4 为 93.56%。采用灵活评分时，结果分别为 94.24% 和 93.48%。

Cloudflare 表示，压缩后模型的质量无法区分。公开数据支持平均差异较小这一结论，但仍留下若干未解问题。该公司并未公布所有智能体行为或多语言行为的结果。

GLM 常用于编程、工具使用和多语言任务。通用学术基准测试无法捕捉这些场景中的所有失效模式。格式错误的函数参数，可能比平均准确率的小幅变化更重要。

罕见的数值故障尤其难以检测。基准测试可能显示整体质量稳定，但压缩后的模型在不常见提示词上可能改变行为。长推理链条可能放大早期差异。

这并不意味着 INT4 不适用，而是说明部署决策需要针对具体工作负载进行测试，并持续监控。服务商应比较用户实际获得的精确模型配置，而不只是参考检查点。

同样的谨慎也适用于速度声明。每秒 token 数取决于输入长度、输出长度、批处理、硬件、内核和调度。Cloudflare 的测量结果描述的是其测试系统，而非通用的 GLM 性能水平。

尽管如此，这种阶段拆分提供了有用的架构经验。量化不应被视为一次静态的导出决策。服务商可以维护多种表示形式，并将计算路由到适合各阶段的格式。

这种灵活性也有成本。多种权重格式会占用存储空间，并增加部署复杂性。工程师必须验证兼容性、选择正确的内核，并防止 GPU 池之间出现配置漂移。

运营纪律决定这种复杂性能否带来回报。如果请求进入错误的资源池，或模型修订版改变了数值行为，理论吞吐量收益就意义不大。自动化和可观测性本身也成为优化的一部分。

Cloudflare 报告的结果说明了服务商为何接受这种复杂性。缩小 40% 的检查点为活跃序列留下了大量内存空间。更快的解码随后改善了用户实际看到 token 逐个到达时的延迟。

这种权衡是具体的，而非抽象的。GLM 权重压缩以增加数值风险和预填充开销为代价，换取了解码容量和速度。Cloudflare 通过将该格式限定在其占优的阶段，来管理这项权衡。

共享 KV 缓存安全性成为生产问题

更高的 GPU 密度提高了每个缓存页的价值，同时也让有缺陷的所有权追踪更加危险。

分页注意力将 KV 缓存存储划分为可复用的块，而不是要求每个请求都进行一次连续分配。连续批处理则在 GPU 保持忙碌的同时不断加入和移除序列。这些方法结合起来，可减少内存浪费。

但它们也带来了严苛的记账问题。物理缓存页会被持续分配、读取、释放和重新分配。服务系统必须保持每个逻辑序列与其物理页面之间的正确映射。

过期映射可能导致请求读取错误页面。这可能损坏响应、导致操作崩溃，或暴露与另一序列相关的状态。具体后果取决于故障形式及周边控制措施。

Cloudflare 表示，在其请求量级下，极其罕见的错误也具有运营意义。其文章将十亿分之一的错误作为说明性阈值。这一表述说明了防御的必要性，并非披露的事故率。

该公司的完整性机制会为每个物理页面关联一个不断变化的标签。请求会记录其预期标签。受支持的解码操作会在读取共享缓存前验证这些值。

标签不匹配会中止受影响的请求。这种设计倾向于显式失败，而不是基于错误状态返回输出。它类似于其他内存管理系统中使用的代际计数器。

Cloudflare 使用一个中等规模的生产模型，以两个预填充工作器和两个解码工作器评估了该检查机制。测试使用 8,192-token 输入和 1,000-token 输出。报告的并发度从 1 到 8 不等。

这些测试中的吞吐量下降幅度为 0.38% 至 0.79%。p95 延迟增幅为 0.42% 至 0.80%。Cloudflare 表示，即使是置信区间上限也仍接近 1%。

该公司将验证作为单独的批量检查运行。它避免将该操作融合进注意力内核，因为 GPU 线程组可能产生竞态条件。对于禁用检查的部署，仍可使用无操作追踪器。

这些结果使完整性检查看起来成本较低。不过，该评估并未覆盖所有模型规模、序列形状或并发水平。它还聚焦于受支持的解码操作，这是一个值得注意的限定条件。

读者不应将这一机制解读为租户隔离的完整证明。缓存完整性只是更大服务系统中的一层防御。路由、内存分配、内核正确性和进程隔离仍然相关。

该检查可以检测其追踪器所能理解的页面代际不匹配。它无法自动识别每一种数值错误或软件缺陷。有效标签并不能证明页面内容在语义上正确。

可选部署与普遍保护之间还存在张力。Cloudflare 表示，完整性检查按部署启用。其既定目标是让该功能成本足够低，从而可以在任何地方保持启用。

在此之前，客户不能假设每条模型路径都使用相同保护。关于覆盖范围的清晰文档将有助于开发者评估剩余风险。独立安全测试将提供比单纯性能测量更有力的证据。

尽管如此，这一安全论证反映了推理工程中的一个重要变化。性能功能如今需要对跨请求状态进行明确推理。内存优化不能再仅通过吞吐量图表来评估。

压缩进一步强化了这种需求。FP8 Kimi 缓存可让更多请求保持活跃。INT4 GLM 权重则为缓存页创造更多空间。这两项变化都会增加单个部署所处理的共享状态量。

因此，这一故事中的主要对手是不安全的高密度。目标并不是不惜代价实现最大化装载，而是在保持请求边界和可接受模型行为的同时提高利用率。

Cloudflare 的方法将安全检查置于共享资源附近。这能够在缓存数据进入注意力操作之前捕捉分配错误。提前终止也限制了受损状态的传播。

被中止的请求仍会影响可靠性。如果检查开始频繁触发，即使隔离机制按设计正常工作，用户也会看到错误或重试。运营者必须追踪不匹配率、调查原因，并防止重试风暴。

Cloudflare 尚未在文章中披露生产环境中的不匹配率。与单看合成开销相比，缺少这一指标更值得关注。低成本检查固然有用，但只有在报告实际检测结果时，其运营价值才会更加明确。

该公司也有动机将新的部署密度呈现为安全可靠。其证据应被视为系统运营方提供的技术披露。它具有参考价值，但不等同于独立审计。

对开发者而言，更广泛的启示很务实。共享推理隐藏了基础设施的复杂性，但并未消除它。评估服务提供商时，除延迟和模型质量外，还应纳入隔离控制、故障处理和事故透明度。

随着这些优化推广，需要关注什么

以下三个信号将显示 Cloudflare 更小模型的服务能力会成为持久优势，还是仍只是特定配置。

第一个信号是更广泛地部署 FP8 缓存。Cloudflare 表示，正在将 FP8 KV 缓存扩展至其更多服务器集群中。若覆盖更多模型和硬件，将表明 Kimi KV 缓存量化可推广到已测量的单一配置之外。

有价值的证据应包括不同序列长度下的并发、尾延迟和质量数据。这些维度上的稳定结果将强化 Cloudflare 的内存效率论点。频繁出现特定模型例外则会削弱这一论点。

第二个信号是在 Blackwell GPUs 上验证 NVFP4。NVFP4 是 Nvidia 面向较新硬件的四位浮点格式。Cloudflare 表示，正在测试这种表示方式，作为进一步缩小权重的另一条路径。

成功推出后，可能将 GLM 权重压缩扩展到 INT4 之外，并再次改变预填充与解码之间的平衡。这也将检验 Cloudflare 能否将其按阶段优化的策略迁移到不同代际的加速器上。

关键结果并非单一的峰值吞吐量数字。应关注端到端延迟、质量评估，以及生产批处理条件下的内存容量。这些测量将显示更低精度是否带来有价值的应用层收益。

第三个信号是普遍的缓存完整性覆盖。Cloudflare 希望以可忽略不计的成本，在所有地方启用检查。实现这一目标，将把更高密度与一致的默认安全控制连接起来。

覆盖范围披露应明确支持的模型、操作和硬件。如果 Cloudflare 说明不匹配发生的频率及其成因，检测指标将更具价值。

这些信号之所以重要，是因为该公司目前的证据很强，但仍有边界。它展示了在选定模型和部署上的显著收益，但并未证明每一种工作负载都能从相同格式中获益。

开发者应使用真实的提示词、工具链和并发条件测试托管的 Kimi 和 GLM 系统。追踪首个 token 时间、生成速度、超时率和完整任务成功率，并比较服务提供商侧模型更新后的表现。

团队还应保留自己的评估历史。一个可搜索的工程知识库可以关联基准测试结果、事故、配置变更和服务提供商公告。这些上下文有助于区分模型回归与基础设施变更。

Cloudflare 已将前沿模型的讨论从单纯的可用性转移开来。更难的问题是，服务提供商能否在真实并发下，让大型模型保持快速、经济、准确且相互隔离。关注这三个推广信号，然后依据完整工作负载而非单一基准或吞吐量图表来判断系统。