部署一个约 1 万亿参数的混合专家（MoE）模型用于 API 推理，是一个经典的系统工程挑战。在完整的 FP16 或 BF16 精度下，其内存占用需要非常大的集群。标准的训练后量化（PTQ）方案能缩小这一占用，但可能降低模型质量，尤其是对非英语模型而言——常用的量化校准数据集无法捕捉语言语域或工具调用行为。

在发布之前Sakana Namazu这是一个约 1T 参数、针对日本商务语境、实时网络搜索和代码执行优化的模型，Modal 的前沿部署工程团队与 Sakana AI 直接合作，让他们的模型在 Modal 上运行。

我们针对日语保留调优了 NVFP4 量化，并在原始 token 流上训练了一个自定义的投机草稿模型。这一切运行在 Modal 的全球 GPU 池上，因此 Sakana 无需承诺预留容量即可发布其公开 API。

以下是我们如何将服务栈优化到内核级别的过程。

不妥协的量化

一个约 1T 参数的模型在完整精度下具有巨大的 GPU 内存占用。要在生产规模上经济地提供服务，基本上必须进行量化。然而，量化也带来风险。压缩方法通常是在英语基准测试上验证的，因此模型可能通过标准检查，却失去其与众不同的能力。

通过合作，Modal 得以在 NVFP4 上为 Sakana Namazu 提供服务，这是专为 NVIDIA Blackwell GPU 构建的低精度格式，可减少内存并提高吞吐量。

Modal 的前沿部署工程团队没有采用现成的量化方案，而是先测量 Sakana Namazu 的权重在 NVFP4 数值下对压缩的响应，然后围绕他们的发现构建方法：

  1. 选择性专家量化：只有承载大部分参数的路由专家被量化。注意力、路由器和共享专家保持更高精度（BF16）。
  2. 领域代表性校准数据：校准在遵循 Sakana Namazu 风格的对话上运行，并大幅偏向日语，以便模型的每一个23,040 个专家在规模参数固定之前，看到了具有代表性的流量。

结果是一个在日语指令遵循上匹配 Sakana 生产检查点的模型，差异处于噪声范围内，Sakana 自己发布的基准测试，同时以 NVFP4 的速度和内存运行。

一个基于 Sakana Namazu 代表性流量训练的草稿模型

投机解码是一种加速生成的技术：由一个小型草稿模型提前猜测若干个 token，主模型则在一个步骤中验证它们。主模型接受的猜测越多，每个请求的运行速度就越快。正如我们之前所说，投机就是你所需的一切。

通用草稿模型是在通用文本上训练的，因此它们对 Sakana Namazu 的日语商务语域猜测得很差（接受率低于 40%）。Modal 的团队改为在 Sakana Namazu 的代表性流量上训练了一个自定义 DFlash草稿模型。

关键的实现细节是：在模型产出的确切 token ID 上训练，而不是在已经解码并重新分词后的文本上训练。两者在页面上看起来完全相同，但重新分词会破坏工具调用、JSON schema 以及模型推理标记内部的确切 token 边界对齐。这一差距会损失 token 接受率。Modal 构建了捕获路径，使原始 token ID 直接从生产环境流入超过 300 亿 token 的训练语料库。以下是结果：

  • +25% 提升在投机 token 接受率上，相比通用草稿模型
  • 约 35% 下降在每 token 解码延迟上
  • 每个副本约 40% 更多的流量在队列延迟开始攀升之前，让 Sakana 用更少的 GPU 服务发布日的需求

自发布以来，草稿模型已经做了更多改进。第一个版本是在 Sakana Namazu 尚未服务过任何公开请求之前训练的，因此它从代表性流量而非真实流量中学习。一旦生产流量开始流动，Modal 的团队便基于约 100 万条真实请求从零训练了第二个草稿模型。

它使用了 DFlash2，这是一种更新的架构，在客户以非零温度采样时表现更好，而 Sakana Namazu 的大部分流量都属于这种情况。为了衡量它，我们运行了两套完全相同的 Sakana Namazu 服务配置，每套使用一个不同的草稿模型。然后我们用 Sakana 客户实际发送的采样设置，在两套配置上回放了 1,000 个留出请求。新的草稿模型在训练期间从未见过这些请求。平均接受长度（主模型每步接受多少个草稿 token）从 3.51 上升到 5.01，提升了 43%，p99 延迟从 68s 降至 52s。

新引擎版本上的性能工作

服务栈迭代很快，每个版本都会在内核、调度和数值计算方面带来变化，而这些变化只有在生产流量下才会显现。Modal 和 Sakana 合作测试并基准测试了这些变化，将它们安全地部署到 Sakana 的工作负载上，并在相同硬件和同一批请求上进行 A/B 测试。

最大的收益来自：

  • 消除推测解码循环中的 CPU–GPU 同步停顿。每个解码步骤都会暂停，等待 CPU 从 GPU 读回结果。消除这一等待后，每步的 GPU 空闲时间减少了 >90%。
  • 将 NVFP4 混合专家计算路由到更快的内核。用于专家矩阵乘法的新内核路径约占每个解码步骤的 60%，缩短了步骤时间，并且由于数值计算更紧凑的副作用，在相同草稿模型下将草稿接受率提高了 9%。
  • 缓存预填充调度和专家运行器设置。此前在每个请求上重复执行的工作现在只做一次并复用，这主要有利于首 token 时间。

跨 GPU 的正确性

Sakana Namazu 通过张量并行在四块 GPU 上运行，而推测解码增加了一个微妙之处：每块 GPU 都必须就哪些草稿 token 被接受达成一致。Modal 在各 rank 上对验证步骤进行了插桩，发现了一条可能导致它们不一致的罕见路径，并将接受决策改为单一共享决策。结果是彻底消除了一类罕见的停顿，且输出质量没有任何变化。

团队还将投机解码扩展到了结构化输出。Sakana Namazu 的 API 客户依赖 JSON-schema 响应来实现工具调用，Modal 让语法约束生成在投机路径内生效，因此这些请求也能获得同样的加速，且零 schema 违规。

跨副本与自动扩缩容的更智能路由器

上线后，Modal 在其内部启用了KV 感知路由器部署在 Sakana 的部署环境中，无需 Sakana 侧做任何代码改动。

路由器不会均匀分发请求，而是将每个请求发送到最有可能已缓存其提示词前缀的副本，同时在副本扩缩容时平衡负载。

对尾延迟的影响立竿见影。曾高达数分钟的首 token 时间（TTFT）尖峰消失了，每副本队列降至接近零，端到端尾延迟得到改善，而每 token 解码速度保持不变。

用按需 GPU 管理容量规划

将关键任务工作负载迁移到新基础设施上，对任何前沿 AI 实验室来说都很难接受。要获得所需数量的 GPU，通常需要长期合同或高额预留。

由于 Sakana Namazu 的新商业 API 服务尚未收到任何请求，这条路径本会有风险。Modal 让他们能够弹性扩缩容，以满足上线期间产生的需求，而无需担心过度配置或自动扩缩容过慢。

“对于 Sakana Namazu，我们需要在不牺牲模型质量的前提下灵活地扩缩 GPU 容量。Modal 给了我们这种灵活性，他们的工程师直接与我们合作，解决了量化带来的性能变化。”
Masaya Ohagi 应用研究工程师

这对 Sakana Namazu 之外意味着什么

Sakana Namazu 现已在围绕其共同优化的基础设施上投入生产运行：为日语保留调优的 NVFP4 量化、在 Sakana 原始 token 流上训练的投机草稿模型，以及随上线需求动态扩缩容而非提前数月签署预留的无服务器容量。

作为日本领先的 AI 实验室之一，Sakana 的研究团队现正在 Modal 上探索原始 API 之外的其他工作负载。

我们很期待看到 Sakana 接下来会发布什么！