跳到主内容
@wquguru
精选90r/MachineLearning(Reddit)技巧与观点

RunAnywhere开源Trainium2上GLM-5.3-Flash推理引

[P] NKI layer megakernels for GLM-5.3-Flash on AWS Trainium2: where a decode step's time went, and what we changed [P]

原文
发到 X
推荐理由

Trainium2生态稀缺的一手工程复盘,给出了NKI Megakernel的具体设计原则与性能拆解,做国产芯片或特定硬件推理优化的同学值得收藏参考。

We wrote an inference engine for AWS Trainium2 that serves GLM-5.3-Flash (320B MoE, 1M-token context) on one trn2.48xlarge, and open-sourced it. Most of the work went into decode, and the part I found most interesting is how little of a decode step was the model's actual math.

我们为 AWS Trainium2 编写了一个推理引擎,在一台 trn2.48xlarge 上运行 GLM-5.3-Flash(320B MoE,1M-token 上下文),并已将其开源。大部分工作集中在解码(decode)阶段,而我觉得最有趣的部分是:模型的实际数学运算在解码步骤中所占的比例非常小。

In an early build, in one KDA (linear attention) layer at batch 1, the recurrence was 2% of the attention half. The rest was the mHC pre-projection (36%), XLA glue (33%), transposes (10%), the stream mix (10%) and other small ops (8%). A batch-8 decode step took 24.2 ms against a 6.1 ms memory floor, and the profile showed why: long chains of small vector-engine instructions at about 153 ns of fixed cost each, a write back to HBM at every kernel boundary, and 125 cross-chip collectives per step.

在一个早期构建版本中,在批次大小为 1 的一个 KDA(线性注意力)层里,循环计算仅占注意力机制一半时间的 2%。其余部分包括 mHC 预投影(36%)、XLA 胶水代码(33%)、转置操作(10%)、流混合(10%)以及其他小型操作(8%)。一个批次大小为 8 的解码步骤耗时 24.2 毫秒,而内存下限为 6.1 毫秒,性能分析揭示了原因:存在大量小型向量引擎指令链,每条固定成本约 153 纳秒;每个内核边界都向 HBM 写回数据;每步涉及 125 次跨芯片集合通信。

So we rewrote each layer half as one NKI kernel (each whole layer, for the sparse-attention layers). The kernels follow three rules:

因此,我们将每个层的一半重写为一个 NKI 内核(对于稀疏注意力层,则是整个层作为一个内核)。这些内核遵循三条规则:

  • Keep the working set on chip. Each physical NeuronCore has 28 MiB of SBUF, enough for a layer half's activations, its recurrent state and the weights in flight, so only the layer's inputs, outputs and streamed weights cross HBM.
  • Use both physical cores of a logical core. One program streams 340–400 GB/s of weights, the pair 672–708 GB/s, so the weight stream has to be split between them.
  • Move a collective into the kernel when it blocks the next one. Run by XLA, an all-reduce makes the next kernel wait for all of it. Inside the kernel, independent work can overlap it.
  • 将工作集保留在芯片内。每个物理 NeuronCore 拥有 28 MiB 的 SBUF,足以容纳一层激活值、其循环状态以及正在传输中的权重,因此只有该层的输入、输出和流式传输的权重需要穿越 HBM。
  • 使用逻辑核心的两个物理核心。一个程序以 340–400 GB/s 的速度流式传输权重,两个核心配对则达到 672–708 GB/s,因此权重流必须在它们之间拆分。
  • 当集合通信阻塞下一个内核时,将其移入内核内部执行。由 XLA 运行时调度时,all-reduce 操作会导致下一个内核等待其完成。而在内核内部,独立工作可以与之重叠执行。

On the same layout, a batch-8 decode step went from 32.2 ms on our 17 October build to 24.2 ms on 1 November. Two changes did most of it, each measured on the whole step: the fused sparse-attention layer saved 3.2 ms per batch-8 step, and the KDA and MoE kernels, which shipped together, saved another 3.2 ms. There's no stock-AWS baseline to compare against: the latest vLLM Neuron plugin release registers no GLM model, and NxD Inference is in maintenance mode. Of the remaining 24.2 ms, 6.1 ms is the memory floor, 10.0 ms is engines busy beyond it (mostly vector-engine instruction chains), 4.6 ms is waits inside kernels, 2.8 ms is exposed collectives and 0.7 ms is idle.

在相同的布局下,批次大小为 8 的解码步骤从我们 10 月 17 日构建版本的 32.2 毫秒优化至 11 月 1 日的 24.2 毫秒。两项更改贡献了大部分优化效果,每项均针对整个步骤测量:融合后的稀疏注意力层为每个批次大小为 8 的步骤节省了 3.2 毫秒;KDA 和 MoE 内核一同发布,又节省了另外 3.2 毫秒。没有标准的 AWS 基线可供比较:最新的 vLLM Neuron 插件版本未注册任何 GLM 模型,且 NxD Inference 已进入维护模式。在剩余的 24.2 毫秒中,6.1 毫秒为内存下限,10.0 毫秒为超出下限的引擎忙碌时间(主要是向量引擎指令链),4.6 毫秒为内核内部的等待时间,2.8 毫秒为暴露的集合通信时间,0.7 毫秒为空闲时间。

What didn't work:

未奏效的方法:

  • Fusing seams the compiler already overlapped. We priced it at 2 to 4 ms a step and it saved 0.85 ms at one batch size, because the step was already one compiled graph.
  • Trusting isolated benchmarks. A dense FFN kernel ran in 84 µs instead of 145 µs on its own, bit-identical, and then made the full step 55 µs slower at batch 2, because the compiler rescheduled everything around the new call.
  • Trusting the simulator. Three kernels passed NKI's simulator and gave wrong answers on the device: two matmul accumulation groups in slices of one PSUM tile, in-kernel collectives without fences, and one program reading shared HBM that the other program of its pair had just written.
  • 融合编译器已经重叠的部分。我们预估这会使每个步骤增加 2 到 4 毫秒的成本,但在某个批次大小下仅节省了 0.85 毫秒,因为该步骤本身就是一个已编译的计算图。
  • 盲目信任孤立基准测试。一个密集的 FFN 内核在单独运行时耗时 84 µs,而非 145 µs,结果完全一致;但在 batch size 为 2 时,它使整个步骤慢了 55 µs,因为编译器围绕这个新调用重新调度了所有操作。
  • 盲目信任模拟器。三个内核通过了 NKI 模拟器的测试,但在设备上给出了错误答案:包括一个 PSUM 图块切片中的两个 matmul 累加组、没有栅栏(fences)的内核内集体操作,以及一个程序读取共享 HBM,而其配对程序刚刚写入该位置。

Accuracy: every kernel is checked byte for byte where no bits should change, and otherwise against a high-precision reference, with its error capped at 1.05x the previous build's. One approximation remains in sparse-attention prefill, on 1.2% of selections: against an exact rerun it shifted next-token log-probabilities by 0.012 to 0.021 nats on average and changed the top token at 3 of 448 positions. We haven't run a task-level eval on this build.

精度:每个内核都逐字节检查那些不应发生变化的位,并在其他情况下与高精度参考值进行对比,其误差上限设定为上一版本构建的 1.05 倍。稀疏注意力预填充中仍保留一种近似方法,涉及 1.2% 的选择:与精确重跑相比,它在平均情况下将下一个 token 的对数概率偏移了 0.012 到 0.021 nats,并在 448 个位置中的 3 个位置上改变了最高概率的 token。我们尚未在此构建上运行任务级评估。

End to end, on SemiAnalysis's AgentX benchmark (self-run, one hour per point, not official InferenceX), we measured up to 28.9 agent requests a minute on one box, and at 16 agents the median request decoded at 35.9 tokens/s. We haven't run GPUs on the same traces, so there's no GPU comparison here.

端到端性能:在 SemiAnalysis 的 AgentX 基准测试(自行运行,每点耗时一小时,非官方 InferenceX)上,我们在单台机器上测得每分钟最多处理 28.9 个 agent 请求,当并发 16 个 agent 时,中位数请求的解码速度为 35.9 tokens/s。我们未在同一追踪数据上运行 GPU,因此此处无 GPU 对比。

Disclosure: I work at RunAnywhere, and the code is ours.

披露:我在 RunAnywhere 工作,代码由我们提供。

Code: https://github.com/RunanywhereAI/trnrt (commands to rerun every number are in docs/RESULTS.md) Write-up with the profiles and every number: https://runanywhere.ai/blog/glm-5-3-flash-trainium2-nki-megakernels

代码:https://github.com/RunanywhereAI/trnrt(重跑每个数字的命令见 docs/RESULTS.md)包含配置文件和所有数据的详细报告:https://runanywhere.ai/blog/glm-5-3-flash-trainium2-nki-megakernels

Our design drew on AMD's per-layer decode kernels in vLLM and on Hazy Research's and Mirage's megakernel work. Happy to hear criticism, especially from anyone who has fought NKI or XLA on Neuron.

我们的设计借鉴了 vLLM 中 AMD 的逐层解码内核,以及 Hazy Research 和 Mirage 的大内核(megakernel)工作。欢迎批评指正,特别是来自任何曾在 Neuron 上对抗过 NKI 或 XLA 的人。

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

关联信息,但可能不是同一事件