From e96680828116e57a433eda876fdada09f8c57e42 Mon Sep 17 00:00:00 2001
From: Oseltamivir <58582368+Oseltamivir@users.noreply.github.com>
Date: Sun, 25 Oct 2026 17:42:12 +0800
Subject: [PATCH] fix(i18n): correct Chinese technical content and Markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

中文：修正中文技术文章中的语义、倍数表达和 Markdown 格式问题，统一 GPU kernel 用语，保留操作系统内核表述，并增加实际渲染回归测试。
---
 README_zh.md                                  | 30 ++++++-------
 ...gentic-benchmark-agent-benchmark-guide.mdx |  6 +--
 .../zh/agentx-inferencexv3-does-cuda-moat.mdx | 42 +++++++++---------
 ...nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx | 12 ++---
 ...vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx | 44 +++++++++----------
 ...h200-int4-kimi-k2-vllm-perf-per-dollar.mdx |  8 ++--
 ...pro-agentx-b200-vs-b300-kv-working-set.mdx |  2 +-
 ...ek-v4-pro-agentx-gb200-vs-gb300-disagg.mdx |  2 +-
 ...ek-v4-pro-agentx-mi355x-vs-b200-august.mdx |  4 +-
 ...seekv4-16t-day-0-to-day-43-performance.mdx | 16 +++----
 .../engrams-embedding-entendre-codesign.mdx   | 12 ++---
 ...vl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx | 10 ++---
 ...b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx |  4 +-
 ...nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx |  8 ++--
 ...-5-3-agentx-mi355x-atom-vs-gb300-nvl72.mdx |  2 +-
 ...max-open-source-inference-benchmarking.mdx | 44 +++++++++----------
 ...x-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx | 40 ++++++++---------
 ...i-k3-agentx-mi355x-atom-vs-gb300-nvl72.mdx |  6 +--
 .../zh/kimi-k3-the-manos-the-mythos-the.mdx   |  4 +-
 ...deepseek-v4-pro-sglang-110x-in-26-days.mdx | 34 +++++++-------
 ...x-glm5-fp8-sglang-40-cheaper-than-b200.mdx | 12 ++---
 ...mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx | 12 ++---
 ...i355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx | 16 +++----
 ...imax-m3-agentx-b200-b300-vs-rack-scale.mdx |  4 +-
 .../zh/openai-jalapeno-better-than-nvidia.mdx |  2 +-
 .../qwen3-5-397b-agentx-b300-fp4-vs-h100.mdx  |  2 +-
 ...-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx | 14 +++---
 ...savings-persistent-demand-inside-glm53.mdx |  4 +-
 .../blog/zh/tpu-inferencex-full-steam.mdx     | 20 ++++-----
 .../zh/ultra-high-interactivity-on-nvidia.mdx |  8 ++--
 ...a-rubin-nvl72-vs-gb200-nvl72-inference.mdx |  4 +-
 ...ironwood-vs-gb300-nvl72-agentx-results.mdx |  2 +-
 ...in-nvl72-vs-gb300-nvl72-agentx-results.mdx |  2 +-
 .../content/models/zh/deepseek-v41-flash.mdx  |  2 +-
 .../app/content/models/zh/muse-spark-open.mdx |  2 +-
 .../app/src/lib/blog/blog-content.test.ts     | 24 ++++++++++
 36 files changed, 242 insertions(+), 218 deletions(-)

diff --git a/README_zh.md b/README_zh.md
index 502586663..b8be19f96 100644
--- a/README_zh.md
+++ b/README_zh.md
@@ -12,7 +12,7 @@
 
 ## 概览
 
-LLM 推理性能是提供 AI 服务时的核心关注点，但准确的性能分析始终难以获得。软件开发与模型发布的快节奏使得不同配置之间的性能比较十分困难。现有的性能基准测试由于是静态的而迅速过时，参与者还会用不切实际、高度特化的配置来"刷榜"。InferenceX 通过每晚使用最新软件在主流硬件平台上对热门模型进行基准测试来解决这些问题。对于每个模型与硬件组合，InferenceX 会扫描不同的张量并行大小与最大并发请求数，以吞吐量-延迟曲线呈现完整图景。在软件配置方面，我们确保其在不同服务场景下具有普遍适用性，并开源整个仓库以欢迎社区贡献。我们希望 InferenceX 能为社区提供最新、真实的 LLM 推理性能信息。
+LLM 推理性能是提供 AI 服务时的核心关注点，但准确的性能分析始终难以获得。软件开发与模型发布的快节奏使得不同配置之间的性能比较十分困难。现有的性能基准测试由于是静态的而迅速过时，参与者还会用不切实际、高度特化的配置来“刷榜”。InferenceX 通过每晚使用最新软件在主流硬件平台上对热门模型进行基准测试来解决这些问题。对于每个模型与硬件组合，InferenceX 会扫描不同的张量并行大小与最大并发请求数，以吞吐量-延迟曲线呈现完整图景。在软件配置方面，我们确保其在不同服务场景下具有普遍适用性，并开源整个仓库以欢迎社区贡献。我们希望 InferenceX 能为社区提供最新、真实的 LLM 推理性能信息。
 
 ## 架构
 
@@ -64,7 +64,7 @@ bun install
 
 ### 2. 配置数据库
 
-仪表板需要实时 PostgreSQL 数据库。在 `.env` 中设置 `DATABASE_READONLY_URL`；应用同时支持标准 PostgreSQL 服务器和 Neon。
+仪表板需要一个运行中的 PostgreSQL 数据库。在 `.env` 中设置 `DATABASE_READONLY_URL`；应用同时支持标准 PostgreSQL 服务器和 Neon。
 
 #### 方式 A：标准 PostgreSQL
 
@@ -140,19 +140,19 @@ bun run dev
 
 合并到 `main` 或 `master` 的 `packages/db/src/etl/run-overrides.ts` 变更会由 CI 自动应用到生产数据库，随后执行数据库校验、缓存失效和缓存预热。覆盖命令仍可用于本地预览和手动恢复。
 
-| 脚本                                   | 说明                           |
-| -------------------------------------- | ------------------------------ |
-| `bun run admin:db:migrate`             | 运行数据库迁移                 |
-| `bun run admin:db:ingest:run`          | 从 GitHub 运行摄取基准测试数据 |
-| `bun run admin:db:ingest:ci`           | 摄取基准测试数据（CI 模式）    |
-| `bun run admin:db:ingest:gcs`          | 从 GCS 摄取基准测试数据        |
-| `bun run admin:db:ingest:supplemental` | 摄取补充数据                   |
-| `bun run admin:db:apply-overrides`     | 手动预览或应用数据覆盖         |
-| `bun run admin:db:reset`               | 重置数据库                     |
-| `bun run admin:db:verify`              | 校验数据库完整性               |
-| `bun run admin:cache:invalidate`       | 失效 API 缓存                  |
-| `bun run admin:cache:warmup`           | 预热 API 缓存                  |
+| 脚本                                   | 说明                                     |
+| -------------------------------------- | ---------------------------------------- |
+| `bun run admin:db:migrate`             | 运行数据库迁移                           |
+| `bun run admin:db:ingest:run`          | 从 GitHub Actions 运行中摄取基准测试数据 |
+| `bun run admin:db:ingest:ci`           | 摄取基准测试数据（CI 模式）              |
+| `bun run admin:db:ingest:gcs`          | 从 GCS 摄取基准测试数据                  |
+| `bun run admin:db:ingest:supplemental` | 摄取补充数据                             |
+| `bun run admin:db:apply-overrides`     | 手动预览或应用数据覆盖                   |
+| `bun run admin:db:reset`               | 重置数据库                               |
+| `bun run admin:db:verify`              | 校验数据库完整性                         |
+| `bun run admin:cache:invalidate`       | 失效 API 缓存                            |
+| `bun run admin:cache:warmup`           | 预热 API 缓存                            |
 
 ## 部署
 
-部署于 Vercel。所有必需的环境变量见 [`.env.example`](.env.example)。
+部署于 Vercel。核心环境变量见 [`.env.example`](.env.example)；各运行时变量的作用及是否必填、Vercel 项目设置、GitHub Actions 变量与 secret、预发布环境前提条件见 [`docs/deployment-configuration.md`](docs/deployment-configuration.md)。
diff --git a/packages/app/content/blog/zh/agentic-benchmark-agent-benchmark-guide.mdx b/packages/app/content/blog/zh/agentic-benchmark-agent-benchmark-guide.mdx
index 6d8bf31a0..5753f582a 100644
--- a/packages/app/content/blog/zh/agentic-benchmark-agent-benchmark-guide.mdx
+++ b/packages/app/content/blog/zh/agentic-benchmark-agent-benchmark-guide.mdx
@@ -15,9 +15,9 @@ tags:
 
 **面向 LLM 推理的 Agentic Benchmark** 衡量模型服务系统在 AI agent 流量下的表现。它不判断 agent 是否修复了 bug 或完成了工作流，而是测量承载每次模型调用的基础设施，包括延迟、吞吐量、cache 复用、并发能力与成本。
 
-这一目标会改变 workload。传统推理基准测试可以发送 input 和 output 长度固定的独立 prompt；Agent Benchmark 则必须表示完整会话，其中上下文随轮次增长，请求共享长 prefix，tool 执行带来停顿，subagent 产生并行分支。后续请求通常要等前序请求完成后才能开始。
+这一目标会改变 workload。传统推理基准测试可以发送 input 和 output 长度固定的独立 prompt；Agent Benchmark 则必须刻画完整会话，其中上下文随轮次增长，请求共享长 prefix，tool 执行带来停顿，subagent 产生并行分支。后续请求通常要等前序请求完成后才能开始。
 
-AgentX 是 InferenceX 面向这类 workload 的开放基准测试。它把自愿提供的编码 agent trace 转换为保护隐私的请求形状，再通过 AIPerf 进行确定性回放，用相同场景比较完整的软硬件推理配置。
+AgentX 是 InferenceX 面向这类 workload 的开放基准测试。它把自愿提供的编码 agent trace 转换为保护隐私的请求形状，再通过 AIPerf 进行确定性回放，并在多个并发 agent 客户端下比较完整的软硬件推理配置。
 
 <DashboardCTA href="/zh/inference?i_seq=agentic-traces">对比实时 AgentX 推理结果 →</DashboardCTA>
 
@@ -32,7 +32,7 @@ Agentic Inference Benchmark 是面向多轮 agent 流量的系统基准测试。
 - 每个活跃 agent 接收 output token 的速度是多少？
 - 在目标延迟下，每颗芯片能提供多少 output 吞吐量？
 - 重复 prefix 会命中 HBM、host memory，还是触发重新计算？
-- 在可用的响应速度下，每百万 token 的成本是多少？
+- 在可用的运行点上，每百万 token 的成本是多少？
 
 “Benchmark”也常用于 agent 任务评估，因此必须说明测试范围。这两类测试回答不同问题：
 
diff --git a/packages/app/content/blog/zh/agentx-inferencexv3-does-cuda-moat.mdx b/packages/app/content/blog/zh/agentx-inferencexv3-does-cuda-moat.mdx
index 2ca701034..887cd2dba 100644
--- a/packages/app/content/blog/zh/agentx-inferencexv3-does-cuda-moat.mdx
+++ b/packages/app/content/blog/zh/agentx-inferencexv3-does-cuda-moat.mdx
@@ -98,7 +98,7 @@ InferenceX 100% 坚持开源，这离不开开源伙伴的贡献与支持。我
 
 ## agentic 编码推理性能
 
-在评估编码推理性能时，OpenAI、Anthropic、xAI 等前沿实验室主要关注三点：每美元性能与交互性（TPOT）的关系、TTFT（首 token 延迟），以及端到端任务完成情况。每兆瓦性能同样重要，因为地面数据中心电力是关键约束（钱是社会构建物，而且看起来实验室们有的是钱；电力在当下则是实打实地难搞）。[我们的数据中心模型给出了逐季度的电力需求与供给爬坡估算。](https://semianalysis.com/datacenter-industry-model/)
+在评估编码推理性能时，OpenAI、Anthropic、xAI 等前沿实验室主要关注三点：每美元性能与交互性（TPOT）的关系、TTFT（首 token 延迟），以及端到端任务完成情况。每兆瓦性能同样重要，因为地面数据中心电力是关键约束（钱是一种社会建构，而且看起来实验室们有的是钱；电力在当下则是实打实地难搞）。[我们的数据中心模型给出了逐季度的电力需求与供给爬坡估算。](https://semianalysis.com/datacenter-industry-model/)
 
 本节我们梳理各前沿模型上 agentic 性能的整体规律。我们强烈建议读者把它当作一份导览，[自己去研究这些结果](https://inferencex.semianalysis.com/)。**所有数据都是开源的，社区完全可以就当下真实推理性能的现状得出自己的结论。**
 
@@ -415,7 +415,7 @@ AgentX 头几个月最有影响力的成果不是产出开源数据集，而是
   caption="来源：SemiAnalysis"
 />
 
-这项并行技术部分源自 NVIDIA Research。NVIDIA Research 在这类基础研究上很强，但在端到端训练研究上就相当难堪了——他们的 Nemotron3 Ultra 模型表现糟糕，如今连体量小得多的 Qwen3.8 27B 都能大幅胜过它。DCP/PCP 构成了 CUDA 护城河的一部分，因为 AMD 的 DCP/PCP 实现尚未优化。在 [vLLM 支持矩阵](https://docs.vllm.ai/en/latest/design/attention_backends/#standard-attention-mha-mqa-gqa-backends)里，AMD 的每一个后端都是不支持状态。
+这项并行技术部分源自 NVIDIA Research。NVIDIA Research 在这类基础研究上很强，但在端到端训练研究上就相当难堪了——他们的 Nemotron3 Ultra 模型表现糟糕，如今连体量小得多的 Qwen3.8 27B 都能大幅胜过它。DCP/PCP 构成了 CUDA 护城河的一部分，因为 AMD 的 DCP/PCP 实现尚未优化。在 [vLLM 支持矩阵](https://docs.vllm.ai/en/latest/design/attention_backends/#standard-attention-mha-mqa-gqa-backends)里，AMD 的每一个后端都标为不支持。
 
 接下来几节提到的部分改动就聚焦在 DCP/PCP 上。
 
@@ -454,28 +454,28 @@ load 路径则单独做了调优，因为查找发生在每次调度决策时，
 - 一个 Kimi-K3 的改动[把 KDA decode 结果直接写入层输出缓冲区](https://github.com/vllm-project/vllm/pull/51183)，为每个 KDA 层省下一次设备内拷贝；单看收益很小，但它会在每个解码 token 的每一层上重复发生。
 
 - 第二个改动[选用 AITER 的稀疏 MLA decode kernel](https://github.com/vllm-project/vllm/pull/51714) 替代通用路径，AgentX 输出吞吐量提高 5.22%，token 间延迟显著降低。
-- 第三个改动很好地说明了测量形态有多重要。配套改动[把 full-graph 注意力投影路由到调优过的 AITER GEMM](https://github.com/vllm-project/vllm/pull/51713)，在低并发的固定序列上取得 2.3% 提升。这说明 kernel 层面的改动可以在统一 shape 上拿到干净的收益，却在 agentic trace 上被缓存与调度带来的波动淹没。一个[待合入的改动](https://github.com/vllm-project/vllm/pull/52882)干脆把这种 shape 敏感性变成了分发依据：它用 gfx950 上的 AITER / native 混合路径取代 DeepSeek V4 C4A selector 的 ROCm top-k 瓶颈，短、中上下文走 AITER，长上下文走 graph-safe 的调优 native 回退路径。据报告，selector 的端到端加速为 1.21x 到 1.76x，在 84 种 shape 的矩阵上 decode kernel 的几何平均加速为 1.2x 到 2.9x。
+- 第三个改动很好地说明了测量形态有多重要。配套改动[把 full-graph 注意力投影路由到调优过的 AITER GEMM](https://github.com/vllm-project/vllm/pull/51713)，在低并发的固定序列上取得 2.3% 提升。这说明 kernel 层面的改动可以在统一 shape 上拿到干净的收益，却在 agentic trace 上被缓存与调度带来的波动淹没。一个[待合入的改动](https://github.com/vllm-project/vllm/pull/52882)干脆把这种 shape 敏感性变成了派发决策的依据：它用 gfx950 上的 AITER / native 混合路径取代 DeepSeek V4 C4A selector 的 ROCm top-k 瓶颈，短、中上下文走 AITER，长上下文走 graph-safe 的调优 native 回退路径。据报告，selector 的端到端加速为 1.21x 到 1.76x，在 84 种 shape 的矩阵上 decode kernel 的几何平均加速为 1.2x 到 2.9x。
 
 ## SGLang 的 agentic 优化
 
 AgentX 团队与来自 RadixArk、Meta、NVIDIA 和 AMD 的 SGLang 维护者密切合作，推动了 SGLang 上 agentic 工作负载的优化，使生产推理性能大幅提升。下面详细介绍这些优化。
 
-先从分配器一侧说起：SGLang 的滑动窗口工作解决的是与 vLLM 保留策略相同的冲突。窗口页和前缀页取自同一个池子，而窗口是更贪婪的一方——它不断翻转，前缀却静止不动，于是在压力之下，短暂的分配会把持久的分配挤出去。
+先从分配器一侧说起：SGLang 的滑动窗口工作解决的是与 vLLM 保留策略相同的冲突。窗口页和前缀页取自同一个池子，而窗口是更贪婪的一方——它不断周转，前缀却静止不动，于是在压力之下，短暂的分配会把持久的分配挤出去。
 
-有三处设计改进从不同角度攻击这个问题。其一是[在页离开窗口时主动释放](https://github.com/sgl-project/sglang/pull/26907)，而不是等淘汰压力来找它们，让失效的窗口状态不再争抢自己已经用不到的页。其二是[把 compute lock 限制在单个窗口内](https://github.com/sgl-project/sglang/pull/27210)，限定一条在途请求最多能同时钉住多少池容量。其三是[清除失去作用后仍然残留的 full-KV 条目](https://github.com/sgl-project/sglang/pull/29369)。
+有三处设计改进从不同角度解决这个问题。其一是[在页离开窗口时主动释放](https://github.com/sgl-project/sglang/pull/26907)，而不是等淘汰压力来找它们，让失效的窗口状态不再争抢自己已经用不到的页。其二是[把 compute lock 限制在单个窗口内](https://github.com/sgl-project/sglang/pull/27210)，限定一条在途请求最多能同时钉住多少池容量。其三是[清除失去作用后仍然残留的 full-KV 条目](https://github.com/sgl-project/sglang/pull/29369)。
 
-不过主动释放有一个与分叉相关的盲区：从共享前缀分叉出来的请求可能仍持有可复用的 full-KV，而分叉点处的窗口状态已被释放，结果为了缺失的那一半廉价数据，整个前缀都要重算。[进行中的工作](https://github.com/sgl-project/sglang/pull/34565)会在这些分叉点保留 SWA 状态，让分叉继承窗口而不是重建它。
+不过主动释放有一个与分叉相关的盲区：从共享前缀分叉出来的请求可能仍持有可复用的 full-KV，而分叉点处的窗口状态已被释放，结果仅因为缺少那一半廉价数据，整个前缀都要重算。[进行中的工作](https://github.com/sgl-project/sglang/pull/34565)会在这些分叉点保留 SWA 状态，让分叉继承窗口而不是重建它。
 
-与之并行的 [ROCm ring-cache 修复](https://github.com/sgl-project/sglang/pull/30339)属于正确性而非容量问题：环形缓冲区在设计上就会复用槽位，而复用一个旧内容仍被引用的槽位，产生的是错误输出，而不是变慢的输出。这些在单个 8k prompt 上都看不出来——窗口不会绕过前缀，池子也不会有争用。但在多轮混合注意力会话中，这些改动决定了昂贵的全注意力历史在下一轮是否还在。
+与之并行的 [ROCm ring-cache 修复](https://github.com/sgl-project/sglang/pull/30339)属于正确性而非容量问题：环形缓冲区在设计上就会复用槽位，而复用一个旧内容仍被引用的槽位，产生的是错误输出，而不是变慢的输出。这些在单个 8k prompt 上都看不出来——窗口不会回绕到仍被引用的前缀位置，池子也不会有争用。但在多轮混合注意力会话中，这些改动决定了昂贵的全注意力历史在下一轮是否还在。
 
-HiCache 是 SGLang 内置的一流 offload 机制。它面对与 vLLM connector 相同的混合模型问题，解法是一种不对称处理：[offload 全注意力缓存，回读时再重建那一小段滑动窗口尾部](https://github.com/sgl-project/sglang/pull/29417)。只有昂贵的那一半值得跨总线搬运，廉价的那一半重建比取回更快。在 AMD 上，[分阶段写回](https://github.com/sgl-project/sglang/pull/28534)让这种搬运不会在进行中阻塞引擎。剩下的缺口是循环状态，因为它无法像窗口尾部那样从相邻 token 重建；[FlashInfer GDN 检查点](https://github.com/sgl-project/sglang/pull/29735)让它得以参与前缀复用，在 92.4% 缓存命中率下把吞吐量从 47,771 提升到 53,004 tok/s/GPU。
+HiCache 是 SGLang 内置的 offload 机制，并作为核心功能获得支持。它面对与 vLLM connector 相同的混合模型问题，解法是一种不对称处理：[offload 全注意力缓存，回读时再重建那一小段滑动窗口尾部](https://github.com/sgl-project/sglang/pull/29417)。只有昂贵的那一半值得跨总线搬运，廉价的那一半重建比取回更快。在 AMD 上，[分阶段写回](https://github.com/sgl-project/sglang/pull/28534)让这种搬运不会在进行中阻塞引擎。剩下的缺口是循环状态，因为它无法像窗口尾部那样从相邻 token 重建；[FlashInfer GDN 检查点](https://github.com/sgl-project/sglang/pull/29735)让它得以参与前缀复用，在 92.4% 缓存命中率下把吞吐量从 47,771 提升到 53,004 tok/s/GPU。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/078ad449-7657-4468-9ff9-3480a7999d89_2048x720.png"
   caption="来源：SemiAnalysis"
 />
 
-另有两处改动针对变长流量对 kernel 流水线的影响。AgentX 的真实会话往往以持续变化的上下文长度到达，生产流量也是类似形态。一个按长度做特化的运行时，几乎会为看到的每个请求重新编译一份 kernel。SGLang 维护者的解法是[把上下文长度作为运行时标量传入](https://github.com/sgl-project/sglang/pull/30255)，而不是把它固化进某一次编译；这让 AgentX 并发 384 的输出吞吐量提升 26.75%、平均 TTFT 改善 36.25%，收益来自消除编译，而不是把计算做得更快。
+另有两处改动针对变长流量对 kernel 流水线的影响。AgentX 的真实会话往往以持续变化的上下文长度到达，生产流量也是类似形态。一个朴素的、按长度做特化的运行时，几乎会为看到的每个请求重新编译一份 kernel。SGLang 维护者的解法是[把上下文长度作为运行时标量传入](https://github.com/sgl-project/sglang/pull/30255)，而不是把它固化进某一次编译；这让 AgentX 并发 384 的输出吞吐量提升 26.75%、平均 TTFT 改善 36.25%，收益来自消除编译，而不是把计算做得更快。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/3a807d67-383b-4aa9-93af-e8f3a68313f4_855x634.png"
@@ -529,7 +529,7 @@ TRTLLM 实现了[边界感知的增量分词](https://github.com/NVIDIA/TensorRT
   caption="[来源：GitHub](https://github.com/NVIDIA/TensorRT-LLM/pull/17462)"
 />
 
-固定的 8k1k 请求没有可复用的上一轮渲染结果，因此这些开销根本不会出现。与之相关地，[chat template 渲染被移入输入处理线程池](https://github.com/NVIDIA/TensorRT-LLM/pull/16231)，长 template 不再让主请求循环排在它后面串行执行。
+固定的 8k1k 请求没有可复用的上一轮渲染结果，因此这些开销根本不会出现。与此相关，[chat template 渲染被移入输入处理线程池](https://github.com/NVIDIA/TensorRT-LLM/pull/16231)，长 template 不再让主请求循环排在它后面串行执行。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/00b459b8-9c4c-4c8c-8659-07e14bf5699f_2048x784.png"
@@ -543,7 +543,7 @@ MiniMax-M3 相关的工作聚焦在分离式 KV 搬运上，问题出在粒度
   caption="来源：[GitHub](https://github.com/NVIDIA/TensorRT-LLM/pull/17518)"
 />
 
-[非阻塞的上下文传输轮询](https://github.com/NVIDIA/TensorRT-LLM/pull/17428)保护了同一条路径，即使调度停滞也会回收已完成的传输，从而打破一个反馈环：已完成的 KV block 一直被钉住，阻止新请求准入。这些停滞本身也有[可以消除的原因](https://github.com/NVIDIA/TensorRT-LLM/pull/16734)：在 GB300 分离式 context worker 上，避免 DeepSeek-V4 上下文稀疏注意力元数据中的隐式 device 标量同步，消除了每步 18 次四字节 device 读取，而每一次都会强制触发 cudaStreamSynchronize。修复方式是把 host 侧计数以普通 Python int 传递，这样执行线程不再在一步的大部分时间里持有 GIL，让 KV 传输线程和响应线程排队等待。
+[非阻塞的上下文传输轮询](https://github.com/NVIDIA/TensorRT-LLM/pull/17428)保护了同一条路径，即使调度停滞也会回收已完成的传输，从而打破一个反馈环：已完成的 KV block 一直被钉住，阻止新请求准入。这些停滞本身也有[可以消除的原因](https://github.com/NVIDIA/TensorRT-LLM/pull/16734)：在 GB300 分离式 context worker 上，避免 DeepSeek-V4 上下文稀疏注意力元数据中的隐式 device 标量同步，消除了每步 18 次四字节 device 读取，而每一次都会强制触发 cudaStreamSynchronize。修复方式是把 host 侧计数以普通 Python int 传递，这样执行线程不再在一步的大部分时间里持有 GIL，KV 传输线程和响应线程也就不必再排在它后面等待。
 
 TensorRT-LLM 还把不规则的长上下文工作迁到了更高效的执行路径上。[MiniMax-M3 的 context graph producer](https://github.com/NVIDIA/TensorRT-LLM/pull/17473) 捕获稳定的稀疏 producer，同时让依赖请求的注意力保持 eager 执行，在其 AgentX 测试中每用户输出吞吐量提升 12.58%。一个进行中的[原生 KV 事件生成改动](https://github.com/NVIDIA/TensorRT-LLM/pull/16876)减少了 KV 感知路由路径上的分配与转换开销。
 
@@ -567,7 +567,7 @@ AgentX 还暴露出只有在规模和时长都够大时才会出现的 kernel 
 
 ## AMD ATOM 的 agentic 优化
 
-AMD 的 ATOM 引擎最初只面向单轮工作负载设计，而不是真实世界的 agentic 多轮生产工作负载，因此要让它较好地支持长上下文多轮场景，核心引擎和 kernel 都需要大量改动。相比 vLLM/SGLang 目前的水平，ATOM 在支持 agentic 工作负载上还有很长的路要走。AgentX 正被用作 ATOM 这轮重构的真实北极星目标。我们要讲的第一项 ATOM 优化，是对 DeepSeek-V4 分页滑动窗口注意力巧妙使用稀疏检查点保留。[已合入的实现](https://github.com/ROCm/ATOM/pull/1640)保留了选定的窗口尾部，让分叉和回放请求能够从有意义的边界处恢复。它的测量把两种效应分得很清楚：在并发 48 的同一条 AgentX trace 上，实际前缀命中率从 5.6% 升到 96.45%，滑动窗口关口处的损失从 91.35% 降到 0.16%。第二个数字是第一个数字背后的机制——十次前缀匹配里有九次是找到了却因为缺少窗口尾部而被丢弃，也就是说缓存并没有失配，而是被否决了。
+AMD 的 ATOM 引擎最初只面向单轮工作负载设计，而不是真实世界的 agentic 多轮生产工作负载，因此要让它较好地支持长上下文多轮场景，核心引擎和 kernel 都需要大量改动。相比 vLLM/SGLang 目前的水平，ATOM 在支持 agentic 工作负载上还有很长的路要走。AgentX 正被用作 ATOM 这轮重构的真实北极星目标。我们要讲的第一项 ATOM 优化，是巧妙地用稀疏检查点保留来支撑 DeepSeek-V4 的分页滑动窗口注意力。[已合入的实现](https://github.com/ROCm/ATOM/pull/1640)保留了选定的窗口尾部，让分叉和回放请求能够从有意义的边界处恢复。它的测量把两种效应分得很清楚：在并发 48 的同一条 AgentX trace 上，实际前缀命中率从 5.6% 升到 96.45%，滑动窗口关口处的损失从 91.35% 降到 0.16%。第二个数字是第一个数字背后的机制——十次前缀匹配里有九次是找到了却因为缺少窗口尾部而被丢弃，也就是说缓存并没有失配，而是被否决了。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/5c880335-e1e3-44d9-a123-8e316c9c3808_822x555.png"
@@ -619,14 +619,14 @@ DeepSeek-V4 的 decode 还获得了[面向 64 head 与 128 head MTP 打包的持
 
 ## Dynamo 的 agentic 工作负载优化
 
-NVIDIA 的相当一部分提交使用了 Dynamo 推理编排与 router 系统。Dynamo 的 AgentX 系列工作表明，一旦引擎 kernel 变快，分布式服务层就可能成为瓶颈。router 的工作量正比于在线前缀的数量和长度，而不是生成的 token 数，因此大量长、相互重叠、生命周期又长的会话给它带来的压力，是固定形状流量永远制造不出来的。第一组 PR 降低了每次路由决策的开销：[减少查找热路径上的工作](https://github.com/ai-dynamo/dynamo/pull/10540)、[消除冗余的后缀失效](https://github.com/ai-dynamo/dynamo/pull/10836)，最后是[批量化 KV 匹配、注册、归属和终止解引用](https://github.com/ai-dynamo/dynamo/pull/11095)，在并发 512 下报告输出吞吐量中位数提升 22.2%。批量化在这里奏效的原因和它在引擎里奏效的原因一样：每项开销已经盖过了项目本身。
+NVIDIA 的相当一部分提交使用了 Dynamo 推理编排与 router 系统。Dynamo 的 AgentX 系列工作表明，一旦引擎 kernel 变快，分布式服务层就可能成为瓶颈。router 的工作量正比于在线前缀的数量和长度，而不是生成的 token 数，因此大量长、相互重叠、生命周期又长的会话给它带来的压力，是固定形状流量永远制造不出来的。第一组 PR 降低了每次路由决策的开销：[减少查找热路径上的工作](https://github.com/ai-dynamo/dynamo/pull/10540)、[消除冗余的后缀失效](https://github.com/ai-dynamo/dynamo/pull/10836)，最后是[批量化 KV 匹配、注册、归属和终止解引用](https://github.com/ai-dynamo/dynamo/pull/11095)，在并发 512 下报告输出吞吐量中位数提升 22.2%。批量化在这里奏效的原因和它在引擎里奏效的原因一样：处理单项工作的额外开销已经超过了该项工作本身的开销。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/7af8faf5-300e-4ee5-bc0c-040b7630e923_1016x671.png"
   caption="来源：GitHub"
 />
 
-第二组 PR 改变了归属关系的表示方式，这是底下更难的问题。每个被缓存的 block 都要归属到依赖它的请求，既不能在仍被使用时释放，也不能在所有人用完后继续钉住。当数千条并发会话共享相互重叠的前缀时，记账本身就成了显著开销。Dynamo 从[共享 block 链](https://github.com/ai-dynamo/dynamo/pull/11503)转向[arena 级归属计数](https://github.com/ai-dynamo/dynamo/pull/11508)，最终走到[后端专属的请求租约](https://github.com/ai-dynamo/dynamo/pull/12329)，每一步都在放粗被追踪的粒度。租约设计让 vLLM 后端的 AgentX 回放时间缩短 23.7%、SGLang 缩短 22.0%，同时还降低了峰值内存——这说明问题出在此前的表示方式，而不是流量本身。
+第二组 PR 改变了归属关系的表示方式，这才是更深层的难题。每个被缓存的 block 都要归属到依赖它的请求，既不能在仍被使用时释放，也不能在所有人用完后继续钉住。当数千条并发会话共享相互重叠的前缀时，记账本身就成了显著开销。Dynamo 从[共享 block 链](https://github.com/ai-dynamo/dynamo/pull/11503)转向[arena 级归属计数](https://github.com/ai-dynamo/dynamo/pull/11508)，最终走到[后端专属的请求租约](https://github.com/ai-dynamo/dynamo/pull/12329)，每一步都在放粗被追踪的粒度。租约设计让 vLLM 后端的 AgentX 回放时间缩短 23.7%、SGLang 缩短 22.0%，同时还降低了峰值内存——这说明问题出在此前的表示方式，而不是流量本身。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/e3039950-98e0-4cd0-b7fe-929a120bd7d2_2048x576.png"
@@ -656,7 +656,7 @@ LMCache 是一个开源 KV cache 层，位于 vLLM 等推理引擎之下，按
 
 LMCache 的多进程路径针对 agentic 缓存搬运的量级与形态做了改造，起点是一个不是变慢、而是直接卡死的故障。当许多上下文超过 100,000 token 的请求各自在开始前就为整次加载预留 block 时，池子会被一群全在等待、谁也无法推进的请求耗尽。[分块的外部缓存加载](https://github.com/LMCache/LMCache/pull/3382)改为按分块预留，让加载可以交错进行并逐步排空。在并发 32 下，验证完成了 120 条请求，而旧路径在 28 条时就死锁；并发 48 时在 KV 池 98.5% 占满的情况下仍能继续运行。
 
-其余改动则减少搬运量以及运行时的干扰次数。只存储 DeepSeek-V4 混合分组中真正有用的部分，把[每 token 的存储量减少了近二十倍](https://github.com/LMCache/LMCache/pull/3635)；滑动窗口预取现在[只加载存活窗口](https://github.com/LMCache/LMCache/pull/3869)，而不是那些永远不会被读取的窗口状态——这与 vLLM 在 offload 上采用的可达性论证相同，只是换到存储一侧来看。[每个对象组一次原生传输调用](https://github.com/LMCache/LMCache/pull/3908)随后消除了暂存拷贝与 kernel 启动之间反复的 Python 锁交接，这类开销正比于分片数量而不是字节数。
+其余改动则减少搬运量以及运行时的干扰次数。只存储 DeepSeek-V4 混合分组中真正有用的部分，把[每 token 的存储量降到原来的近二十分之一](https://github.com/LMCache/LMCache/pull/3635)；滑动窗口预取现在[只加载存活窗口](https://github.com/LMCache/LMCache/pull/3869)，而不是那些永远不会被读取的窗口状态——这与 vLLM 在 offload 上采用的可达性论证相同，只是换到存储一侧来看。[每个对象组一次原生传输调用](https://github.com/LMCache/LMCache/pull/3908)随后消除了暂存拷贝与 kernel 启动之间反复的 Python 锁交接，这类开销正比于分片数量而不是字节数。
 
 有两项 LMCache 改动与 AgentX 尤其相关，但目前仍未合入。[混合锁记账修复](https://github.com/LMCache/LMCache/pull/4524)阻止一条请求释放另一条请求在共享滑动窗口分块或循环状态分块上的读锁。要触发它需要三个条件同时成立：多条请求共享同一批分块、记账必须按分块而非按持有者进行、并且淘汰确实开始发生。带 DRAM offload 的长时间 Kimi-K3 运行同时满足了三者，产生了数万条告警、生成内容损坏，并在淘汰开始后最终导致 GPU 崩溃。只要不是长时间、共享且内存吃紧的运行，这个 bug 就一直潜伏着。
 
@@ -682,7 +682,7 @@ Mooncake 承载着月之暗面 Kimi 的生产流量以及多家实验室的生
 
 在 NVIDIA 上为 RDMA 注册 GPU 显存，要么用 nvidia-peermem 内核模块，要么导出 dmabuf 文件描述符。AMD 没有 nvidia-peermem 的对应物，因此 GPU-direct RDMA 完全无路可走，部署只能把 KV 经主机 DRAM 中转。[一个 HIP dmabuf 注册分支](https://github.com/kvcache-ai/Mooncake/pull/2225)加入了与现有 CUDA dmabuf 路径对应的实现，改为通过 ROCm 导出，并先解析出真实的分配基址——因为缓存型分配器会把张量打包在更大一块分配内部的某个偏移处。主机内存仍然直接注册。
 
-装不上的支持等于没有支持。Mooncake 发布过 CUDA 和 MUSA 的 wheel，但没有 ROCm 包，因此 AMD 用户只能在每个镜像里从源码构建引擎。[ROCm wheel、CI 与发布流程](https://github.com/kvcache-ai/Mooncake/pull/3184)把 mooncake-transfer-engine-rocm 一并发布到 PyPI。这项工作来自 AMD 工程师 Andy Luo，他在用 AgentX 试用 agentic 工作负载时注意到一个规律：在 ROCm 上从源码构建 MoonCake 并不是一流公民的做法。
+装不上的支持等于没有支持。Mooncake 发布过 CUDA 和 MUSA 的 wheel，但没有 ROCm 包，因此 AMD 用户只能在每个镜像里从源码构建引擎。[ROCm wheel、CI 与发布流程](https://github.com/kvcache-ai/Mooncake/pull/3184)把 mooncake-transfer-engine-rocm 一并发布到 PyPI。这项工作来自 AMD 工程师 Andy Luo，他在用 AgentX 试用 agentic 工作负载时注意到一个规律：在 ROCm 上从源码构建 MoonCake 并未获得一等公民待遇。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/12cd94ca-2aa7-4e06-a4bd-3153982234c5_1220x680.png"
@@ -713,13 +713,13 @@ MiniMax-M3 检验了这些 ROCm 工作能否累积成 day-0 就绪能力，而 [
 
 ## AgentX 测试方法深入解析
 
-AgentX 在开源的真实世界长上下文多轮 agentic trace 回放上是一次重大转变。我们采集了价值超过 300 万美元 token 的 trace，构成自有数据集，内容来自 Claude Code、OpenAI Codex 等真实流量。除数据集外，我们还建立了一套公平回放这些流量模式的完整方法，目标是在尽可能忠实于真实流量的同时，对 GPU 资源需求保持公平。
+AgentX 为开源的真实世界长上下文多轮 agentic trace 回放带来了重大转变。我们采集的 trace 对应超过 300 万美元的 token 支出，构成自有数据集，内容来自 Claude Code、OpenAI Codex 等真实流量。除数据集外，我们还建立了一套公平回放这些流量模式的完整方法，目标是在尽可能忠实于真实流量的同时，对 GPU 资源需求保持公平。
 
 下面我们会深入介绍 agentic trace 数据集、回放方法以及 agentic 行为本身。希望更好理解 agentic 工作负载整体形态、以及各类 harness 在底层如何编排请求的读者，值得读一读这部分。
 
 ## 价值 300 万美元的 agentic 流量 trace 采集器
 
-在最初设计 AgentX 时，我们的北极星目标是让基准测试在 KV 工作负载形态和 KV 复用模式上尽可能真实。我们先尝试回放了一些现有数据集，例如 SWE-bench、Qwen-Bailian 以及 HuggingFace 上的一些 Claude Code trace。当时这些数据集都没有大量使用子智能体、1M 上下文、上下文压缩、动态工作流等近来定义 agentic trace 的特征。在 SemiAnalysis，团队里大多数人都是 AI 重度用户，会用 agent 做各种事情：写代码、分析师研究、Excel 建模、社交媒体运营等等。因此我们判断，最可行也最真实的 trace 只能自己采集。
+在最初设计 AgentX 时，我们的北极星目标是让基准测试在 KV 工作负载形态和 KV 复用模式上尽可能真实。我们先尝试回放了一些现有数据集，例如 SWE-bench、Qwen-Bailian 以及 HuggingFace 上的一些 Claude Code trace。当时这些数据集都没有大量使用子智能体、1M 上下文、上下文压缩、动态工作流等近来定义 agentic trace 的特征。在 SemiAnalysis，团队里大多数人都是 AI 重度用户，会用 agent 做各种事情：写代码、开展分析研究、Excel 建模、社交媒体运营等等。因此我们判断，最可行也最真实的 trace 只能自己采集。
 
 为了采集足够多的 trace，我们做了一个代理来拦截发往 Claude / Codex 的 HTTP 请求。愿意上传 trace 的用户只需把 Claude / Codex 配置中的 base URL 指向这个代理即可。截至撰稿时，我们已采集超过 8,000 个会话、340 万条请求、6,100 亿 token，合计支出超过 300 万美元。[我们为 AgentX v1.0 基准测试开源了其中具有代表性的一个子集。](https://huggingface.co/datasets/semianalysisai/cc-traces-weka-062126)
 
@@ -727,9 +727,9 @@ agentic harness 看起来复杂，但归根结底就是在编排一串 HTTP 请
 
 我们的代理会实时记录这些请求和响应，同时提取时间戳、conversation ID、subagent ID 等元数据 / HTTP 头，从而还原对话的*结构*（请求顺序、并发分支，以及每个会话大致的父子关系）。正是这些元数据，让我们能够按照原始 Anthropic API 服务端所看到的样子近似回放这些 trace。
 
-为保护员工隐私，回放数据集不包含任何原始 prompt、源代码、工具参数或工具返回结果。我们的做法是先对每条请求的内容分词，再按 64 个 token 分块，最后把每一块替换成一个会话内链式哈希。这样，相同的 prompt 前缀会产生相同的哈希前缀，同时不暴露内容（[这篇论文](https://arxiv.org/abs/2506.02634)对该策略有更多讨论）。回放时，这些哈希块可以替换成来自比如某个编码数据集的 token。由此我们保留了原始工作负载中大致的上下文增长曲线和会话 KV 复用模式。
+为保护员工隐私，回放数据集不包含任何原始 prompt、源代码、工具参数或工具返回结果。我们的做法是先对每条请求的内容分词，再按 64 个 token 分块，最后把每一块替换成一个会话内链式哈希。这样，相同的 prompt 前缀会产生相同的哈希前缀，同时不暴露内容（[这篇论文](https://arxiv.org/abs/2506.02634)对该策略有更多讨论）。回放时，这些哈希块可以替换成比如某个编码数据集里的 token。由此我们保留了原始工作负载中大致的上下文增长曲线和会话 KV 复用模式。
 
-需要说明的是，这个过程必然不完美，主要原因是使用前沿模型厂商 API 时，末端 LLM 服务器实际看到的内容有很大一部分是隐藏的。例如 SOTA 模型的思考 / 推理内容如今在 HTTP 请求中是加密的，并被替换成确定性哈希，以阻止蒸馏攻击。不过看起来[这招的效果并不像大实验室预期的那么好……](https://arxiv.org/html/2608.09867v1)
+需要说明的是，这个过程必然不完美，主要原因是使用前沿模型厂商 API 时，实际处理请求的 LLM 服务器所看到的内容有很大一部分是隐藏的。例如 SOTA 模型的思考 / 推理内容如今在 HTTP 请求中是加密的，并被替换成确定性哈希，以阻止蒸馏攻击。不过看起来[这招的效果并不像大实验室预期的那么好……](https://arxiv.org/html/2608.09867v1)
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/767f2f58-fa9d-40d3-8711-751d243cae9a_500x487.png"
@@ -834,7 +834,7 @@ AIPerf 还能识别“辅助（auxiliary）”请求，即与流中其他请求
 
 ### Pareto 前沿扫描
 
-在 AgentX 工作负载中，为了生成 Pareto 前沿，我们针对单套部署扫描并发 Claude Code 会话数。由于每个对话都带有真实的轮次间延迟和子智能体使用，得到的流量模式更尖锐、也更真实。下面这个例子是对运行 MiniMax M3 的 B200 TP4 vLLM 服务端回放 40 个并发客户端。
+在 AgentX 工作负载中，为了生成 Pareto 前沿，我们针对单套部署扫描并发 Claude Code 会话数。由于每个对话都带有真实的轮次间延迟和子智能体使用，得到的流量模式突发性更强、也更真实。下面这个例子是对运行 MiniMax M3 的 B200 TP4 vLLM 服务端回放 40 个并发客户端。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/058757ed-531f-4cfb-a1ad-a06b1499ecbd_1360x612.png"
diff --git a/packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx b/packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx
index 5131c240b..a500638e4 100644
--- a/packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx
+++ b/packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx
@@ -18,7 +18,7 @@ tags:
 
 在 GLM-5 8K/1K 工作负载下，H200 和 B200 均运行 SGLang 时，NVIDIA 的 GLM-5-NVFP4 检查点在 B200 上实现了**等交互性（iso-interactivity）下性价比最高达 H200 SGLang FP8 的 3.65 倍**——在 80 tok/s/user 时，H200 的成本为 $1.06/M tokens，而 B200 NVFP4 仅为 $0.29/M tokens。该优势在 H200 的整个 25–84 tok/s/user 运行区间内保持在 3.24x–3.65x 范围。数据基于 2026-05-25 InferenceX 基准测试（benchmark），使用 SGLang v0.5.12。
 
-这 3.65 倍的提升在峰值处可清晰分解。在 80 tok/s/user 时，**B200 SGLang FP8 + MTP 的性价比是 H200 SGLang FP8 + MTP 的 1.22 倍**——这是在相同精度和相同 EAGLE 方案下，仅靠 Blackwell 世代硬件 + 软件带来的提升。**将 B200 的权重从 `zai-org/GLM-5-FP8` 切换为 `nvidia/GLM-5-NVFP4` 再叠加 2.98 倍**——这是仅靠精度切换带来的提升，得益于 FlashInfer 的 TRT-LLM 稀疏 MLA 内核——该内核已在 [sgl-project/sglang #21783](https://github.com/sgl-project/sglang/pull/21783) 中被设为 sm100/sm103 的默认后端。1.22 × 2.98 ≈ 3.65。在不同运行区间，两个因素的贡献比例会互换——世代因素在低交互性时贡献更大（50 tok/s/user 时为 1.36x），精度因素在高交互性时贡献更大（84 tok/s/user 时为 3.07x）——但组合提升始终保持稳定。
+这 3.65 倍的提升在峰值处可清晰分解。在 80 tok/s/user 时，**B200 SGLang FP8 + MTP 的性价比是 H200 SGLang FP8 + MTP 的 1.22 倍**——这是在相同精度和相同 EAGLE 方案下，仅靠 Blackwell 世代硬件 + 软件带来的提升。**将 B200 的权重从 `zai-org/GLM-5-FP8` 切换为 `nvidia/GLM-5-NVFP4` 再叠加 2.98 倍**——这是仅靠精度切换带来的提升，得益于 FlashInfer 的 TRT-LLM 稀疏 MLA kernel——该 kernel 已在 [sgl-project/sglang #21783](https://github.com/sgl-project/sglang/pull/21783) 中被设为 sm100/sm103 的默认后端。1.22 × 2.98 ≈ 3.65。在不同运行区间，两个因素的贡献比例会互换——世代因素在低交互性时贡献更大（50 tok/s/user 时为 1.36x），精度因素在高交互性时贡献更大（84 tok/s/user 时为 3.07x）——但组合提升始终保持稳定。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_rundate=2026-05-25&g_model=GLM-5&g_runid=26381101926&i_prec=fp4%2Cfp8&i_active=b200_sglang_mtp%2Ch200_sglang_mtp&i_linelabel=1">
   点击查看完整 InferenceX 仪表板 →
@@ -65,10 +65,10 @@ NVIDIA 还发布了量化权重版本 [`nvidia/GLM-5-NVFP4`](https://huggingface
 
 ## 促成此结果的上游变更
 
-**上游软件栈。** SGLang [v0.5.10](https://github.com/sgl-project/sglang/releases/tag/v0.5.10)（2026-04-07）是 GLM-5 首次在 Blackwell 上跨所有四个精度/MTP/分离式推理变体完整端到端运行的稳定版本——[跟踪 issue #19380](https://github.com/sgl-project/sglang/issues/19380) 在同日将每个 Functional 和 Baseline Perf 行标记为 DONE。本文的基准测试运行于 [v0.5.12](https://github.com/sgl-project/sglang/releases/tag/v0.5.12)（发布于 2026-05-16），它继承了相同的 Blackwell 默认配置并增加了第一轮性能优化。关键内核变更：
+**上游软件栈。** SGLang [v0.5.10](https://github.com/sgl-project/sglang/releases/tag/v0.5.10)（2026-04-07）是 GLM-5 首次在 Blackwell 上跨所有四个精度/MTP/分离式推理变体完整端到端运行的稳定版本——[跟踪 issue #19380](https://github.com/sgl-project/sglang/issues/19380) 在同日将每个 Functional 和 Baseline Perf 行标记为 DONE。本文的基准测试运行于 [v0.5.12](https://github.com/sgl-project/sglang/releases/tag/v0.5.12)（发布于 2026-05-16），它继承了相同的 Blackwell 默认配置并增加了第一轮性能优化。关键 kernel 变更：
 
-- [sgl-project/sglang #21783](https://github.com/sgl-project/sglang/pull/21783) 将 **FlashInfer TRT-LLM 稀疏 MLA 内核设为 sm100/sm103**（B200/B300）**的默认注意力后端**。DSA prefill 和 decode 现在运行在 GLM-5/V3.2 所针对调优的内核上，而非曾在 B200 上引发 [GLM-5 精度回归](https://github.com/sgl-project/sglang/issues/21291) 的旧 `flashmla_kv` 路径。
-- [sgl-project/sglang #21405](https://github.com/sgl-project/sglang/pull/21405) 为稀疏 MLA 启用了 **IndexCache**，在连续 decode 步骤间复用索引张量，在相同内核调用序列上带来 >10% 的 decode 吞吐量提升。
+- [sgl-project/sglang #21783](https://github.com/sgl-project/sglang/pull/21783) 将 **FlashInfer TRT-LLM 稀疏 MLA kernel 设为 sm100/sm103**（B200/B300）**的默认注意力后端**。DSA prefill 和 decode 现在运行在 GLM-5/V3.2 所针对调优的 kernel 上，而非曾在 B200 上引发 [GLM-5 精度回归](https://github.com/sgl-project/sglang/issues/21291) 的旧 `flashmla_kv` 路径。
+- [sgl-project/sglang #21405](https://github.com/sgl-project/sglang/pull/21405) 为稀疏 MLA 启用了 **IndexCache**，在连续 decode 步骤间复用索引张量，在相同 kernel 调用序列上带来 >10% 的 decode 吞吐量提升。
 - [flashinfer-ai/flashinfer #2726](https://github.com/flashinfer-ai/flashinfer/pull/2726)（FlashInfer v0.6.6.post1）修复了一个间歇性 NVFP4 非法内存访问 bug，此前一直[阻塞](https://github.com/sgl-project/sglang/issues/19081) NVFP4 的功能验证签核；[flashinfer-ai/flashinfer #2836](https://github.com/flashinfer-ai/flashinfer/pull/2836)（v0.6.7）提升了 trtllm-gen 稀疏 MLA 的性能上限。
 
 **MTP。** GLM-5 复用了 SGLang 为 DeepSeek V3.2 实现的 EAGLE 投机解码机制（`--speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4`），并通过 `SGLANG_ENABLE_SPEC_V2=1` 启用 overlap 调度器。H200 与 B200 使用完全相同的一组启动参数；在下述测试配置中，两款 SKU 之间仅模型检查点和注意力后端不同。
@@ -193,7 +193,7 @@ B200 NVFP4 相对 H200 的性价比提升在 **80 tok/s/user 时达到峰值 3.6
       "name": "SGLang v0.5.10 / v0.5.12 中的哪些变更使 GLM-5 NVFP4 + MTP 得以在 Blackwell 上运行？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "SGLang v0.5.10（发布于 2026-04-07）是 GLM-5 (G)B200 跟踪 issue（sgl-project/sglang #19380）的所有 Functional 和 Baseline Perf 行在 no-MTP/MTP 和 Agg/Disagg 全组合、FP8 和 NVFP4 两种精度下均标记为 DONE 的首个稳定版本。v0.5.12（发布于 2026-05-16）是 InferenceX 基准测试实际运行的版本。关键内核变更：sgl-project/sglang #21783 将 FlashInfer TRT-LLM 稀疏 MLA 内核设为 sm100/sm103（B200/B300）的默认后端；sgl-project/sglang #21405 启用 IndexCache 实现 >10% 的 decode 吞吐量提升；flashinfer-ai/flashinfer #2726 修复了一个间歇性 NVFP4 非法内存访问 bug，此前一直阻塞 NVFP4 的功能验证签核；flashinfer-ai/flashinfer #2836 提升了 trtllm-gen 稀疏 MLA 的性能上限。MTP 使用 EAGLE，参数为 --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4，并通过 SGLANG_ENABLE_SPEC_V2=1 启用 overlap 调度器。"
+        "text": "SGLang v0.5.10（发布于 2026-04-07）是 GLM-5 (G)B200 跟踪 issue（sgl-project/sglang #19380）的所有 Functional 和 Baseline Perf 行在 no-MTP/MTP 和 Agg/Disagg 全组合、FP8 和 NVFP4 两种精度下均标记为 DONE 的首个稳定版本。v0.5.12（发布于 2026-05-16）是 InferenceX 基准测试实际运行的版本。关键 kernel 变更：sgl-project/sglang #21783 将 FlashInfer TRT-LLM 稀疏 MLA kernel 设为 sm100/sm103（B200/B300）的默认后端；sgl-project/sglang #21405 启用 IndexCache 实现 >10% 的 decode 吞吐量提升；flashinfer-ai/flashinfer #2726 修复了一个间歇性 NVFP4 非法内存访问 bug，此前一直阻塞 NVFP4 的功能验证签核；flashinfer-ai/flashinfer #2836 提升了 trtllm-gen 稀疏 MLA 的性能上限。MTP 使用 EAGLE，参数为 --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4，并通过 SGLANG_ENABLE_SPEC_V2=1 启用 overlap 调度器。"
       }
     },
     {
@@ -209,7 +209,7 @@ B200 NVFP4 相对 H200 的性价比提升在 **80 tok/s/user 时达到峰值 3.6
       "name": "这次 B200 NVFP4 vs H200 FP8 的 GLM-5 对比中未涵盖哪些内容？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "还有三个方向未覆盖。（1）NVL72 上的分离式推理：本次对比均为单节点聚合方式；SGLang 跟踪 issue #19380 正在积极推进 FP8 B200 分离式 8K/1K 和 GB300 分离式 MTP 的工作，宽 Expert Parallelism 在 NVL72 上已在 Kimi K2.5 上展示了约 3 倍的每 GPU 吞吐量提升。（2）B200 FP8 聚合方式的分段 CUDA graph（sgl-project/sglang #23351 审核中，#24276 后续跟进），预计对 B200 FP8 曲线的提升大于 B200 NVFP4 曲线，将在高交互性端缩小仅精度差异的比值。（3）H200 SGLang MTP 方案（InferenceX PR #1480）在本次测试前一周才上线；H200 分离式推理、trtllm-mha 注意力或 H200 上的 KV FP8 都将在宣布世代对比完结之前进一步推高 H200 曲线。"
+        "text": "还有三个方向未覆盖。（1）NVL72 上的分离式推理：本次对比均为单节点聚合方式；SGLang 跟踪 issue #19380 正在积极推进 FP8 B200 分离式 8K/1K 和 GB300 分离式 MTP 的工作，宽 Expert Parallelism 在 NVL72 上已在 Kimi K2.5 上展示了约 3 倍的每 GPU 吞吐量提升。（2）B200 FP8 聚合式 prefill 的分段 CUDA graph（sgl-project/sglang #23351 审核中，#24276 后续跟进），预计对 B200 FP8 曲线的提升大于 B200 NVFP4 曲线，将在高交互性端缩小仅精度差异的比值。（3）H200 SGLang MTP 方案（InferenceX PR #1480）在本次测试前一周才上线；H200 分离式推理、trtllm-mha 注意力或 H200 上的 KV FP8 都将在宣布世代对比完结之前进一步推高 H200 曲线。"
       }
     }
   ]
diff --git a/packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx b/packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx
index a889133cd..01dc0bf97 100644
--- a/packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx
+++ b/packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx
@@ -1,6 +1,6 @@
 ---
 title: 'B200 NVFP4 vs H100 FP8 运行 MiniMax-M2.5：vLLM 下每美元性能最高提升 8.2 倍'
-subtitle: 'vLLM PR #36307 为 MiniMax 在 B200 上解锁了 trtllm-gen FP8 MoE 模块化内核；结合 NVFP4，在 8K/1K 负载下性能/成本从 22 tok/s/user 时的 4.0 倍扩大到 110 tok/s/user 时的 8.2 倍'
+subtitle: 'vLLM PR #36307 为 MiniMax 在 B200 上解锁了 trtllm-gen FP8 MoE 模块化 kernel；结合 NVFP4，在 8K/1K 负载下性能/成本从 22 tok/s/user 时的 4.0 倍扩大到 110 tok/s/user 时的 8.2 倍'
 seoDescription: 'B200 NVFP4 在 vLLM 下运行 MiniMax-M2.5，每美元性能比 H100 FP8 最高提升 8.2 倍——trtllm-gen FP8 MoE 结合 NVFP4（8K/1K）。'
 date: '2026-05-26'
 publishDate: '2026-05-26'
@@ -18,7 +18,7 @@ tags:
 
 在 MiniMax-M2.5 8K/1K 负载下使用 vLLM，NVIDIA 的 NVFP4 量化版 MiniMax-M2.5 在 B200 上实现了**等交互性下相比 H100 vLLM FP8 最高 8.2 倍的每美元性能提升**——110 tok/s/user 时 H100 为 $0.74/M tokens，B200 NVFP4 为 $0.09/M tokens。提升幅度在 H100 的 21–111 tok/s/user 工作区间内单调递增，从低端的 4.0 倍（22 tok/s/user，$0.12 vs $0.031）增长到高端的 8.2 倍。测量于 2026-05-22 的 InferenceX。
 
-这 8.2 倍在峰值处可以清晰分解。在 110 tok/s/user 时，**B200 vLLM FP8 相比 H100 vLLM FP8 实现了 2.94 倍的每美元性能提升**——这是纯硬件代际提升，两个 SKU 上使用相同的 `MiniMaxAI/MiniMax-M2.5` 权重和相同的 vLLM 构建。**将 B200 权重切换为 `nvidia/MiniMax-M2.5-NVFP4` 后又叠加了 2.77 倍**——这是纯精度提升，由 [vllm-project/vllm #36307](https://github.com/vllm-project/vllm/pull/36307) 解锁——该 PR 添加了 trtllm-gen FP8 MoE 内核的**模块化变体**，使 MiniMax 的非标准路由方法得以使用该内核。2.94 × 2.77 ≈ 8.14。精度提升随交互性增长而扩大（22 tok/s/user 时 1.65 倍 → 110 时 2.77 倍），这是因为 trtllm-gen 内核相比旧版 triton 路径的优势在 GEMM 天花板成为瓶颈时更为突出。
+这 8.2 倍在峰值处可以清晰分解。在 110 tok/s/user 时，**B200 vLLM FP8 相比 H100 vLLM FP8 实现了 2.94 倍的每美元性能提升**——这是纯硬件代际提升，两个 SKU 上使用相同的 `MiniMaxAI/MiniMax-M2.5` 权重和相同的 vLLM 构建。**将 B200 权重切换为 `nvidia/MiniMax-M2.5-NVFP4` 后又叠加了 2.77 倍**——这是纯精度提升，由 [vllm-project/vllm #36307](https://github.com/vllm-project/vllm/pull/36307) 解锁——该 PR 添加了 trtllm-gen FP8 MoE kernel 的**模块化变体**，使 MiniMax 的非标准路由方法得以使用该 kernel。2.94 × 2.77 ≈ 8.14。精度提升随交互性增长而扩大（22 tok/s/user 时 1.65 倍 → 110 时 2.77 倍），这是因为 trtllm-gen kernel 相比旧版 triton 路径的优势在 GEMM 天花板成为瓶颈时更为突出。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_rundate=2026-05-22&g_runid=26306422380&g_model=MiniMax-M2.5&i_prec=fp4%2Cfp8&i_active=b200_vllm%2Ch100_vllm&i_linelabel=1&i_advlabel=1">
   点击查看完整的 InferenceX 仪表板 →
@@ -33,7 +33,7 @@ tags:
 
 MiniMax-M2.5 是 MiniMax AI 的旗舰 MoE 模型：**总参数 230B，每 token 激活 10B**，采用 256 个小专家（架构不同于早期 MiniMax-Text-01 的 32 个大专家）。公开权重发布于 [`MiniMaxAI/MiniMax-M2.5`](https://huggingface.co/MiniMaxAI/MiniMax-M2.5)，NVIDIA 发布了量化版 [`nvidia/MiniMax-M2.5-NVFP4`](https://huggingface.co/nvidia/MiniMax-M2.5-NVFP4)，将所有 MoE GEMM 权重从 BF16/FP8 重新量化为 NVFP4（16 元素分组、FP8 逐组缩放因子、FP32 逐张量缩放因子）。KV cache 保持 FP8。图表中 B200 NVFP4 曲线加载 NVIDIA 量化权重；B200 FP8 和 H100 FP8 曲线加载原始 MiniMaxAI 权重。
 
-本文涉及的关键架构细节是**路由方法**。MiniMax M2 的专家路由层生成的 routing logits 使用的数据类型不被原始（"单体式"）trtllm-gen FP8 MoE 内核接受——这就是为何 MiniMax 在 B200 上一直被限制在较慢的 triton MoE 路径上，直到 vLLM PR #36307 添加了在外部处理路由的模块化内核变体。我们将在"关键技术贡献"部分详细展开。
+本文涉及的关键架构细节是**路由方法**。MiniMax M2 的专家路由层生成的 routing logits 使用的数据类型不被原始（“单体式”）trtllm-gen FP8 MoE kernel 接受——这就是为何 MiniMax 在 B200 上一直被限制在较慢的 triton MoE 路径上，直到 vLLM PR #36307 添加了在外部处理路由的模块化 kernel 变体。我们将在"关键技术贡献"部分详细展开。
 
 ## 为何 MiniMax-M2.5 值得投入优化
 
@@ -43,19 +43,19 @@ MiniMax-M2.5 是 M2 系列中面向编码和智能体的开源权重模型。其
   srcLight="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/quality-benchmarks-light.png"
   srcDark="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/quality-benchmarks-dark.png"
   alt="六个柱状图对比 MiniMax M2.5（红色）和 MiniMax M2.1（浅红色）与 Claude Opus 4.5、Claude Opus 4.6、Gemini 3 Pro 和 GPT-5.2 在 SWE-Bench Verified、SWE-Bench Pro、Terminal Bench 2、Multi-SWE-Bench、SWE-Bench Multilingual 和 VIBE-Pro (AVG) 上的表现。MiniMax M2.5 在每项基准测试上与 Claude Opus 的差距仅几分，在 Multi-SWE-Bench（51.3 vs 50.3）上领先，在与 Gemini 3 Pro 的对比中在 Multi-SWE-Bench 和 VIBE-Pro 上领先。"
-  caption="MiniMax-M2.5 与前沿编码模型在智能体和软件工程基准测试上的对比（MiniMax 发布的得分）。M2.5 在 SWE-Bench 系列和 Terminal Bench 上与 Claude Opus 4.5/4.6 持平或差距 0–4 分，在 Multi-SWE-Bench 上领先，在已报告的项目中与 GPT-5.2 持平或领先，在六项中的三项上领先 Gemini 3 Pro。M2.7（相同的 230B / 10B 激活架构，经过后训练优化）继承了这些结果并继续使用相同的 vLLM 内核路径。"
+  caption="MiniMax-M2.5 与前沿编码模型在智能体和软件工程基准测试上的对比（MiniMax 发布的得分）。M2.5 在 SWE-Bench 系列和 Terminal Bench 上与 Claude Opus 4.5/4.6 持平或差距 0–4 分，在 Multi-SWE-Bench 上领先，在已报告的项目中与 GPT-5.2 持平或领先，在六项中的三项上领先 Gemini 3 Pro。M2.7（相同的 230B / 10B 激活架构，经过后训练优化）继承了这些结果并继续使用相同的 vLLM kernel 路径。"
 />
 
 质量水准是服务成本故事的前提。一个**激活参数仅 10B** 的开源 MoE 模型，在前沿专有编码模型的射程范围内——在 B200 NVFP4 的吞吐量锚点处仅需 **$0.031/M tokens**——相比将同样的工作负载路由到闭源 API 前沿模型，完全是不同的部署成本量级。下文介绍的 vLLM PR + NVFP4 + B200 技术栈，将这类智能体/SWE 循环工作负载的推理成本从"连续运行成本高昂"压缩到了可以让自主编码智能体持续运行数小时而不至于账单本身成为架构约束的区间。
 
 ## H100 vs B200 纸面规格对比
 
-在介绍具体配方之前，先看硬件。H100 SXM（Hopper，2023）和 B200 SXM（Blackwell，2025）相隔两代。下方雷达图将每个轴归一化到 [`/gpu-specs`](/gpu-specs) 中所有 NVIDIA + AMD SKU 的最大值——因此 H100 和 B200 的可见多边形在 GB200/GB300 NVL72 设定天花板的轴上（特别是扩展域显存容量和扩展域显存带宽，按 72-GPU NVLink 域扩展）被压缩。
+在介绍具体配方之前，先看硬件。H100 SXM（Hopper，2023）和 B200 SXM（Blackwell，2025）相隔两代。下方雷达图将每个轴归一化到 [`/gpu-specs`](/gpu-specs) 中所有 NVIDIA + AMD SKU 的最大值——因此 H100 和 B200 的可见多边形在 GB200/GB300 NVL72 设定天花板的轴上（特别是 scale-up 域的显存容量和显存带宽，按 72-GPU NVLink 域扩展）被压缩。
 
 <Figure
   srcLight="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/specs-radar-light.png"
   srcDark="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/specs-radar-dark.png"
-  alt="雷达图对比 H100 SXM 和 B200 SXM 在显存容量、显存带宽、FP4/FP8/BF16 TFLOP/s、扩展带宽、扩展域显存容量和扩展域显存带宽上的表现。各轴按 /gpu-specs 中所有 GPU 的最大值归一化。"
+  alt="雷达图对比 H100 SXM 和 B200 SXM 在显存容量、显存带宽、FP4/FP8/BF16 TFLOP/s、scale-up 带宽、scale-up 域的显存容量和显存带宽上的表现。各轴按 /gpu-specs 中所有 GPU 的最大值归一化。"
   caption="H100 SXM vs B200 SXM 在 InferenceX /gpu-specs 雷达图上的对比。各轴按每个指标的跨厂商最大值归一化（例如 FP4 最大值为 GB300 NVL72 的 15 PFLOP/s/GPU，因此 B200 的 9 PFLOP/s 读数约 60%；扩展域显存和带宽最大值由 GB200/GB300 NVL72 的 72-GPU NVLink 域设定，因此 H100 和 B200 的 8-GPU 域读数都较低）。H100 的 FP4 读数为 0%，因为 Hopper 没有 FP4 张量核心。"
 />
 
@@ -68,27 +68,27 @@ MiniMax-M2.5 是 M2 系列中面向编码和智能体的开源权重模型。其
 | 密集 FP4 (TFLOP/s)                | —                   | 9,000               | —           |
 | 密集 FP8 (TFLOP/s)                | 1,979               | 4,500               | 2.27x       |
 | 密集 BF16 (TFLOP/s)               | 989                 | 2,250               | 2.28x       |
-| 每 GPU 扩展带宽（单向）           | 450 GB/s (NVLink 4) | 900 GB/s (NVLink 5) | 2.00x       |
-| 扩展域 GPU 数                     | 8                   | 8                   | 1.00x       |
-| 扩展域 HBM 容量                   | 640 GB              | 1,440 GB            | 2.25x       |
-| 扩展域 HBM 带宽（聚合）           | 26.8 TB/s           | 64.0 TB/s           | 2.39x       |
+| 每 GPU scale-up 带宽（单向）      | 450 GB/s (NVLink 4) | 900 GB/s (NVLink 5) | 2.00x       |
+| scale-up 域 GPU 数                | 8                   | 8                   | 1.00x       |
+| scale-up 域 HBM 容量              | 640 GB              | 1,440 GB            | 2.25x       |
+| scale-up 域 HBM 带宽（聚合）      | 26.8 TB/s           | 64.0 TB/s           | 2.39x       |
 | TCO（SemiAnalysis AI Cloud 模型） | $1.30/GPU/hr        | $1.95/GPU/hr        | 1.50x       |
 
 硅片本身带来了什么？**B200 的 FP8 算力是 H100 的 2.27 倍**（4,500 vs 1,979 TFLOP/s），**B200 的 FP4 算力是 H100 FP8 算力的 4.55 倍**（9,000 vs 1,979 TFLOP/s——Hopper 没有 FP4 张量核心，因此精度步骤是跨精度算力提升，而非同精度对比），**HBM 带宽提升 2.39 倍**（8.0 vs 3.35 TB/s），TCO 仅为 1.50 倍。这些原始比率限定了性能/成本的天花板：**FP8 vs FP8 计算瓶颈下为 1.51 倍**（`2.27 / 1.50`），**HBM 带宽瓶颈下为 1.59 倍**（`2.39 / 1.50`），或者 **B200 NVFP4 vs H100 FP8 跨精度算力轴下为 3.03 倍**（`4.55 / 1.50`）。
 
-实测数据更为出色。2.94 倍的 FP8 代际提升**几乎是 FP8 硅片天花板的 2 倍**，8.16 倍的综合提升**约为跨精度 FP4 硅片天花板的 2.7 倍**——超出硅片天花板的部分来自 trtllm-gen 模块化 FP8 MoE 内核（vLLM PR #36307），实现了旧版 triton MoE 路径无法做到的优化。H100 上的 vLLM 技术栈在运行 MiniMax-M2.5 时相比 B200 上 trtllm-gen 内核路径的发挥还留有大量空间。NVFP4 在此基础上叠加了精度步骤的提升，因为 B200 拥有 9 PFLOP/s 的 FP4 算力，而 H100 为零。
+实测数据更为出色。2.94 倍的 FP8 代际提升**几乎是 FP8 硅片天花板的 2 倍**，8.16 倍的综合提升**约为跨精度 FP4 硅片天花板的 2.7 倍**——超出硅片天花板的部分来自 trtllm-gen 模块化 FP8 MoE kernel（vLLM PR #36307），实现了旧版 triton MoE 路径无法做到的优化。H100 上的 vLLM 技术栈在运行 MiniMax-M2.5 时相比 B200 上 trtllm-gen kernel 路径的发挥还留有大量空间。NVFP4 在此基础上叠加了精度步骤的提升，因为 B200 拥有 9 PFLOP/s 的 FP4 算力，而 H100 为零。
 
-## TensorRT-LLM MoE 内核集成至 vLLM
+## TensorRT-LLM MoE kernel 集成至 vLLM
 
-**上游：vLLM PR #36307——TRTLLM FP8 MoE 模块化内核。** [vllm-project/vllm #36307](https://github.com/vllm-project/vllm/pull/36307)，由 [Wei Zhao](https://github.com/wzhao18) 提交，2026-03-12 合入，为 Blackwell 添加了 trtllm-gen FP8 MoE 内核的**模块化**变体。此前的"单体式"trtllm-gen 内核仅接受特定数据类型的 routing logits，这排除了 MiniMax M2 等路由层输出不同数据类型的模型。模块化内核在外部完成路由，从而消除了数据类型约束——MiniMax M2（及更广泛的 MoE 模型）现在可以使用 DeepSeek/Kimi/GLM-5 在 B200 上已有的快速 attention + MoE 内核路径。该 PR 的测试计划在 `MiniMaxAI/MiniMax-M2.5` 上以 TP=2 + 专家并行运行，与下方 B200 前沿使用的配方形状相同。
+**上游：vLLM PR #36307——TRTLLM FP8 MoE 模块化 kernel。** [vllm-project/vllm #36307](https://github.com/vllm-project/vllm/pull/36307)，由 [Wei Zhao](https://github.com/wzhao18) 提交，2026-03-12 合入，为 Blackwell 添加了 trtllm-gen FP8 MoE kernel 的**模块化**变体。此前的"单体式"trtllm-gen kernel 仅接受特定数据类型的 routing logits，这排除了 MiniMax M2 等路由层输出不同数据类型的模型。模块化 kernel 在外部完成路由，从而消除了数据类型约束——MiniMax M2（及更广泛的 MoE 模型）现在可以使用 DeepSeek/Kimi/GLM-5 在 B200 上已有的快速 attention + MoE kernel 路径。该 PR 的测试计划在 `MiniMaxAI/MiniMax-M2.5` 上以 TP=2 + 专家并行运行，与下方 B200 前沿使用的配方形状相同。
 
-内核的选择至关重要。以下是 MiniMax-M2.5 上的逐内核对比（1K/1K——_不是_ 8K/1K，但内核排序一致），展示了 vLLM 中各 MoE 后端的表现：
+kernel 的选择至关重要。以下是 MiniMax-M2.5 上的逐 kernel 对比（1K/1K——_不是_ 8K/1K，但 kernel 排序一致），展示了 vLLM 中各 MoE 后端的表现：
 
 <Figure
   srcLight="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/moe-kernel-comparison-light.png"
   srcDark="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/moe-kernel-comparison-dark.png"
-  alt="两个并排散点图对比 trtllm（蓝色）、deep_gemm（橙色）和 triton（绿色虚线）MoE 内核在 MiniMax-M2.5 ISL=1024 OSL=1024 下的表现。左图：生成 TPS vs 交互性 TPS。右图：总 TPS vs 交互性 TPS。trtllm 在全曲线上位于 triton 之上，且远超 deep_gemm（后者坍缩至约 250 gen TPS）。"
-  caption="vLLM MoE 后端在 B200 上运行 MiniMax-M2.5 ISL=1024 / OSL=1024 的对比。trtllm-gen 模块化（蓝色）是 vLLM PR #36307 解锁的内核；triton（绿色虚线）是此前的回退路径；deep_gemm（橙色）在此路由方法下无法产生有竞争力的工作点。1K/1K 负载相比本文其他部分使用的 8K/1K 放大了内核间差距（8K/1K 将每步内核时间分摊到更多的 prefill 带宽中），但排序相同。"
+  alt="两个并排散点图对比 trtllm（蓝色）、deep_gemm（橙色）和 triton（绿色虚线）MoE kernel 在 MiniMax-M2.5 ISL=1024 OSL=1024 下的表现。左图：生成 TPS vs 交互性 TPS。右图：总 TPS vs 交互性 TPS。trtllm 在全曲线上位于 triton 之上，且远超 deep_gemm（后者坍缩至约 250 gen TPS）。"
+  caption="vLLM MoE 后端在 B200 上运行 MiniMax-M2.5 ISL=1024 / OSL=1024 的对比。trtllm-gen 模块化（蓝色）是 vLLM PR #36307 解锁的 kernel；triton（绿色虚线）是此前的回退路径；deep_gemm（橙色）在此路由方法下无法产生有竞争力的工作点。1K/1K 负载相比本文其他部分使用的 8K/1K 放大了 kernel 间差距（8K/1K 将每步 kernel 时间分摊到更多的 prefill 带宽中），但排序相同。"
 />
 
 ## 数据详情
@@ -174,7 +174,7 @@ NVFP4 组合帕累托前沿从 21 tok/s/user 时的 $0.031/M（TP=2，conc=512
 | 150                 | _unreachable_ | _unreachable_ | $0.250         | _∞_                       |
 | 175                 | _unreachable_ | _unreachable_ | $0.569         | _∞_                       |
 
-B200 NVFP4 相对于 H100 的性能/成本优势**从 22 tok/s/user 时的 3.96 倍单调递增至 110 tok/s/user 时的 8.16 倍**，峰值 8.23 倍出现在 110.8 tok/s/user——H100 可测量范围的右端。与同代对比中提升基本恒定不同，此处提升增长迅速：H100 的前沿在右端急剧下降（其 conc=4 点仅为 476 tok/s/GPU、$0.76/M），而 B200 NVFP4 在相同交互性下仍有 4–5 倍的吞吐量。纯精度提升（B200 FP8 → B200 NVFP4）从 22 tok/s/user 时的 1.65 倍扩大到 110 时的 2.77 倍——随着批量缩小，trtllm-gen 内核的 GEMM 优势相比 triton 路径成为主导约束。在 110 tok/s/user 以上，对比不再成立：H100 没有任何配方能再提供一个 tok/s/user，而 B200 NVFP4 将可用范围延伸至 TP=8 下的 180 tok/s/user。
+B200 NVFP4 相对于 H100 的性能/成本优势**从 22 tok/s/user 时的 3.96 倍单调递增至 110 tok/s/user 时的 8.16 倍**，峰值 8.23 倍出现在 110.8 tok/s/user——H100 可测量范围的右端。与同代对比中提升基本恒定不同，此处提升增长迅速：H100 的前沿在右端急剧下降（其 conc=4 点仅为 476 tok/s/GPU、$0.76/M），而 B200 NVFP4 在相同交互性下仍有 4–5 倍的吞吐量。纯精度提升（B200 FP8 → B200 NVFP4）从 22 tok/s/user 时的 1.65 倍扩大到 110 时的 2.77 倍——随着批量缩小，trtllm-gen kernel 的 GEMM 优势相比 triton 路径成为主导约束。在 110 tok/s/user 以上，对比不再成立：H100 没有任何配方能再提供一个 tok/s/user，而 B200 NVFP4 将可用范围延伸至 TP=8 下的 180 tok/s/user。
 
 <Figure
   srcLight="/images/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar/benchmark-light.png"
@@ -195,7 +195,7 @@ B200 NVFP4 相对于 H100 的性能/成本优势**从 22 tok/s/user 时的 3.96
 
 ## 致谢
 
-NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合入了 [trtllm FP8 MoE 模块化内核](https://github.com/vllm-project/vllm/pull/36307)。感谢 Wei Zhao 和 vLLM TRT-LLM 内核协作者、InferenceX 配方维护者以及 MiniMax AI 团队发布的开源权重。
+NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合入了 [trtllm FP8 MoE 模块化 kernel](https://github.com/vllm-project/vllm/pull/36307)。感谢 Wei Zhao 和 vLLM TRT-LLM kernel 协作者、InferenceX 配方维护者以及 MiniMax AI 团队发布的开源权重。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_rundate=2026-05-22&g_runid=26306422380&g_model=MiniMax-M2.5&i_prec=fp4%2Cfp8&i_active=b200_vllm%2Ch100_vllm&i_linelabel=1&i_advlabel=1">
   点击查看完整的 InferenceX 仪表板 →
@@ -218,7 +218,7 @@ NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合
       "name": "vLLM PR #36307 做了什么？为什么对 B200 上的 MiniMax-M2.5 至关重要？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "vllm-project/vllm PR #36307 由 Wei Zhao 提交（2026-03-12 合入），为 Blackwell 添加了 trtllm-gen FP8 MoE 内核的模块化变体。此前的单体式 trtllm-gen 内核有 routing logits 数据类型约束，排除了 MiniMax M2 等路由器输出不同数据类型的模型。模块化内核在外部完成路由，消除了约束。有了 #36307，B200 上的 MiniMax M2 vLLM 终于可以使用 DeepSeek、Kimi 和 GLM-5 已有的快速 attention + MoE 内核路径。在 1K/1K 的补充逐内核对比中，trtllm-gen 模块化内核在低交互性时生成 TPS 比 triton MoE 回退路径高约 1.4 倍，总 TPS 高约 2 倍；deep_gemm 在此路由方法下无竞争力。"
+        "text": "vllm-project/vllm PR #36307 由 Wei Zhao 提交（2026-03-12 合入），为 Blackwell 添加了 trtllm-gen FP8 MoE kernel 的模块化变体。此前的单体式 trtllm-gen kernel 有 routing logits 数据类型约束，排除了 MiniMax M2 等路由器输出不同数据类型的模型。模块化 kernel 在外部完成路由，消除了约束。有了 #36307，B200 上的 MiniMax M2 vLLM 终于可以使用 DeepSeek、Kimi 和 GLM-5 已有的快速 attention + MoE kernel 路径。在 1K/1K 的补充逐 kernel 对比中，trtllm-gen 模块化 kernel 在低交互性时生成 TPS 比 triton MoE 回退路径高约 1.4 倍，总 TPS 高约 2 倍；deep_gemm 在此路由方法下无竞争力。"
       }
     },
     {
@@ -226,7 +226,7 @@ NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合
       "name": "B200 NVFP4 vs H100 FP8 的 8.2 倍每美元性能提升中，代际和精度各贡献了多少？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "提升在峰值处可以清晰分解。保持精度不变，B200 vLLM FP8 在 110 tok/s/user 时相比 H100 vLLM FP8 实现约 2.94 倍的每美元性能提升——这是 Blackwell 代际加软件步骤，两个 SKU 使用相同的 MiniMaxAI/MiniMax-M2.5 权重和相同的 vLLM 构建。将 B200 权重切换为 nvidia/MiniMax-M2.5-NVFP4 后在 110 时又叠加了 2.77 倍——纯精度步骤，依赖 vLLM PR #36307 解锁的 trtllm-gen FP8 MoE 模块化内核。2.94 乘以 2.77 约为 8.14。在 H100 的工作区间内，代际贡献在 2.40 倍（22 tok/s/user）到 2.99 倍（103）之间，精度贡献在 1.65 倍（22）到 2.81 倍（110）之间；两个步骤在更高交互性下都扩大，这就是综合提升从 3.96 倍增长到 8.16 倍而非保持恒定的原因。"
+        "text": "提升在峰值处可以清晰分解。保持精度不变，B200 vLLM FP8 在 110 tok/s/user 时相比 H100 vLLM FP8 实现约 2.94 倍的每美元性能提升——这是 Blackwell 代际加软件步骤，两个 SKU 使用相同的 MiniMaxAI/MiniMax-M2.5 权重和相同的 vLLM 构建。将 B200 权重切换为 nvidia/MiniMax-M2.5-NVFP4 后在 110 时又叠加了 2.77 倍——纯精度步骤，依赖 vLLM PR #36307 解锁的 trtllm-gen FP8 MoE 模块化 kernel。2.94 乘以 2.77 约为 8.14。在 H100 的工作区间内，代际贡献在 2.40 倍（22 tok/s/user）到 2.99 倍（103）之间，精度贡献在 1.65 倍（22）到 2.81 倍（110）之间；两个步骤在更高交互性下都扩大，这就是综合提升从 3.96 倍增长到 8.16 倍而非保持恒定的原因。"
       }
     },
     {
@@ -234,7 +234,7 @@ NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合
       "name": "为什么 B200 vs H100 的代际提升（2.94 倍）几乎是纸面 FP8 天花板（1.51 倍）的 2 倍？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "从原始硅片看，B200 的密集 FP8 吞吐量是 H100 的 2.27 倍，TCO 为 1.50 倍，在计算瓶颈下的纸面 FP8 性能/成本天花板为 1.51 倍，在显存带宽瓶颈下为 1.59 倍。实测 110 tok/s/user 时 2.94 倍几乎是该天花板的 2 倍，这意味着对比不受硅片能力限制——H100 上的 vLLM 技术栈在运行 MiniMax-M2.5 时相比 B200 通过 PR #36307 获得的 trtllm-gen 内核路径还留有大量性能空间。如果 H100 技术栈采用 FP8 KV cache、FlashInfer 注意力升级或类似的快速 MoE 内核，代际步骤将向其纸面天花板收窄。"
+        "text": "从原始硅片看，B200 的密集 FP8 吞吐量是 H100 的 2.27 倍，TCO 为 1.50 倍，在计算瓶颈下的纸面 FP8 性能/成本天花板为 1.51 倍，在显存带宽瓶颈下为 1.59 倍。实测 110 tok/s/user 时 2.94 倍几乎是该天花板的 2 倍，这意味着对比不受硅片能力限制——H100 上的 vLLM 技术栈在运行 MiniMax-M2.5 时相比 B200 通过 PR #36307 获得的 trtllm-gen kernel 路径还留有大量性能空间。如果 H100 技术栈采用 FP8 KV cache、FlashInfer 注意力升级或类似的快速 MoE kernel，代际步骤将向其纸面天花板收窄。"
       }
     },
     {
@@ -242,7 +242,7 @@ NVIDIA 的 [Wei Zhao](https://github.com/wzhao18) 于 2026-03-12 在 vLLM 中合
       "name": "B200 NVFP4 vs H100 FP8 的 MiniMax-M2.5 对比中还有哪些未覆盖的领域？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "仍有三处差距。（1）投机解码：两个配方均未在 MiniMax-M2.5 上运行 MTP 或 EAGLE，因为 vLLM 对 MiniMax M2 路由层的 MTP 支持落后于 DeepSeek/Kimi/GLM-5；一旦实现，高交互性下的精度步骤应收窄，低交互性下的绝对下限应进一步降低。（2）NVL72 上的分离式服务：本次对比为单节点聚合；NVL72 上的宽专家并行在 Kimi K2.5 上已展示约 3 倍的每 GPU 吞吐量提升，将进一步提升 MiniMax-M2.5 的性能/成本。（3）H100 vLLM 技术栈仍有提升空间：当前运行 vllm/vllm-openai v0.18.0；FlashInfer 注意力升级和 H100 上的 FP8 KV 路径均可推高 H100 曲线。"
+        "text": "仍有三处差距。（1）投机解码：两个配方均未在 MiniMax-M2.5 上运行 MTP 或 EAGLE，因为 vLLM 对 MiniMax M2 路由层的 MTP 支持落后于 DeepSeek/Kimi/GLM-5；一旦实现，高交互性下的精度步骤应收窄，低交互性下的绝对下限应进一步降低。（2）NVL72 上的分离式推理：本次对比为单节点聚合；NVL72 上的宽专家并行在 Kimi K2.5 上已展示约 3 倍的每 GPU 吞吐量提升，将进一步提升 MiniMax-M2.5 的性能/成本。（3）H100 vLLM 技术栈仍有提升空间：当前运行 vllm/vllm-openai v0.18.0；FlashInfer 注意力升级和 H100 上的 FP8 KV 路径均可推高 H100 曲线。"
       }
     }
   ]
diff --git a/packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx b/packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx
index f8b122b4e..1bba161a1 100644
--- a/packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx
+++ b/packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx
@@ -1,6 +1,6 @@
 ---
 title: 'B200 NVFP4 对比 H200 INT4 运行 Kimi K2.5/K2.6：每美元性能最高达 2.95 倍'
-subtitle: '在 vLLM 8K/1K 工作负载下，B200 NVFP4 路径在 30–90 tok/s/user 推理区间内每百万 tokens 成本比 H200 INT4 低 2.71x–2.95x，比同一 B200 硬件上的 INT4 低 2.45x–2.74x。三个因素——B200 的 HBM 带宽、HBM 容量和 NVFP4 张量核心——可清晰分解该优势'
+subtitle: '在 vLLM 8K/1K 工作负载下，B200 NVFP4 路径在 30–90 tok/s/user 推理区间内每百万 tokens 成本比 H200 INT4 低 2.71x–2.95x，比同一 B200 硬件上的 INT4 低 2.45x–2.74x。该优势可清晰分解为三个因素——B200 的 HBM 带宽、HBM 容量和 NVFP4 张量核心'
 seoDescription: '在 vLLM 8K/1K 下，B200 NVFP4 运行 Kimi K2.5/K2.6 每 token 成本比 H200 INT4 最多低 2.95 倍，覆盖 30–90 tok/s/user 全区间。'
 date: '2026-05-26'
 publishDate: '2026-05-26'
@@ -33,7 +33,7 @@ Kimi K2.5 和 K2.6 是 xAI Cursor Composer 2 和 Composer 2.5 背后的开源权
 
 ## Kimi K2.5 / K2.6 模型架构及下游 Cursor Composer 2.5 模型
 
-[Kimi K2.5](https://huggingface.co/moonshotai/Kimi-K2.5)（发布于 2026-01-27）和 [Kimi K2.6](https://huggingface.co/moonshotai/Kimi-K2.6)（发布于 2026-04-20）共享原始 Kimi K2 骨干网络：**1.0T 参数的 MoE，每个 token 激活 32B 参数**，**DeepSeek 风格的 top-8-of-385 专家路由，跨 61 个 Transformer 层（1 个 dense 块 + 60 个 MoE 块）**，**Multi-head Latent Attention（MLA）**、SwiGLU、**YaRN RoPE**，163,840 词汇量，以及 **256K 上下文窗口**（262,144 tokens）。HF 检查点为 [`moonshotai/Kimi-K2.5`](https://huggingface.co/moonshotai/Kimi-K2.5) 和 [`moonshotai/Kimi-K2.6`](https://huggingface.co/moonshotai/Kimi-K2.6)——两者是在同一预训练架构上的后训练优化，因此**本文中的每一个推理结果都同样适用于这两个版本**。
+[Kimi K2.5](https://huggingface.co/moonshotai/Kimi-K2.5)（发布于 2026-01-27）和 [Kimi K2.6](https://huggingface.co/moonshotai/Kimi-K2.6)（发布于 2026-04-20）共享原始 Kimi K2 骨干网络：**1.0T 参数的 MoE，每个 token 激活 32B 参数**，**DeepSeek 风格的 top-8-of-385 专家路由，跨 61 个 Transformer 层（1 个 dense 块 + 60 个 MoE 块）**，**Multi-head Latent Attention（MLA）**、SwiGLU、**YaRN RoPE**，163,840 token 的词表，以及 **256K 上下文窗口**（262,144 tokens）。HF 检查点为 [`moonshotai/Kimi-K2.5`](https://huggingface.co/moonshotai/Kimi-K2.5) 和 [`moonshotai/Kimi-K2.6`](https://huggingface.co/moonshotai/Kimi-K2.6)——两者是在同一预训练架构上的后训练优化，因此**本文中的每一个推理结果都同样适用于这两个版本**。
 
 <Figure
   srcLight="/images/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar/kimi-k2-architecture-light.png"
@@ -148,7 +148,7 @@ NVIDIA B200 SXM（Blackwell，2025）vs NVIDIA H200 SXM（Hopper，2024）——
 
 ## 致谢
 
-Kimi K2.5 和 K2.6 是 [Moonshot AI](https://www.moonshot.ai/) 的工作成果，权重发布于 [`moonshotai/Kimi-K2.5`](https://huggingface.co/moonshotai/Kimi-K2.5) 和 [`moonshotai/Kimi-K2.6`](https://huggingface.co/moonshotai/Kimi-K2.6)。Blackwell 上的 vLLM NVFP4 路径是 [vLLM 项目](https://github.com/vllm-project/vllm)以及 NVIDIA TensorRT-LLM / AITER 内核团队的工作成果，vLLM 链接了他们的 FP4 MoE 内核。持续基准测试由 SemiAnalysis 在 InferenceX 上执行。速度就是护城河。
+Kimi K2.5 和 K2.6 是 [Moonshot AI](https://www.moonshot.ai/) 的工作成果，权重发布于 [`moonshotai/Kimi-K2.5`](https://huggingface.co/moonshotai/Kimi-K2.5) 和 [`moonshotai/Kimi-K2.6`](https://huggingface.co/moonshotai/Kimi-K2.6)。Blackwell 上的 vLLM NVFP4 路径是 [vLLM 项目](https://github.com/vllm-project/vllm)以及 NVIDIA TensorRT-LLM / AITER kernel 团队的工作成果，vLLM 链接了他们的 FP4 MoE kernel。持续基准测试由 SemiAnalysis 在 InferenceX 上执行。速度就是护城河。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_rundate=2026-05-19&g_runid=26118912054&g_model=Kimi-K2.5&i_prec=fp4%2Cint4&i_active=b200_vllm%2Ch200_vllm">
   点击查看完整 InferenceX 仪表板 →
@@ -195,7 +195,7 @@ Kimi K2.5 和 K2.6 是 [Moonshot AI](https://www.moonshot.ai/) 的工作成果
       "name": "Kimi K2.5 / K2.6 推理还有哪些未覆盖的方向？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "四个方向。第一，AMD MI355X 目前还没有 K2.5 / K2.6 的 InferenceX 方案；一旦内核覆盖到位，相同的精度解锁论证应同样适用（MI355X 有 10,066 TFLOP/s FP4 张量核心，略高于 B200）。第二，PD 分离式推理（AMD 上的 mori-sglang、NVIDIA Dynamo）是下一个约 1.5 倍的提升杠杆，目前 InferenceX 循环中还没有 K2 的方案。第三，GB200 NVL72 和 GB300 NVL72 的机架级宽 Expert Parallelism 路径尚未为 K2.5 / K2.6 接入，尽管 384 专家的架构天然适配。第四，本文测量的是 8K / 1K；32K / 2K 和 128K / 2K 的 agentic 工具调用工作负载会在 KV 缓存压力开始对 256K 上下文窗口模型产生影响后重新排列曲线。"
+        "text": "四个方向。第一，AMD MI355X 目前还没有 K2.5 / K2.6 的 InferenceX 方案；一旦 kernel 覆盖到位，相同的精度解锁论证应同样适用（MI355X 有 10,066 TFLOP/s FP4 张量核心，略高于 B200）。第二，PD 分离式推理（AMD 上的 mori-sglang、NVIDIA Dynamo）是下一个约 1.5 倍的提升杠杆，目前 InferenceX 循环中还没有 K2 的方案。第三，GB200 NVL72 和 GB300 NVL72 的机架级宽 Expert Parallelism 路径尚未为 K2.5 / K2.6 接入，尽管 384 专家的架构天然适配。第四，本文测量的是 8K / 1K；32K / 2K 和 128K / 2K 的 agentic 工具调用工作负载会在 KV 缓存压力开始对 256K 上下文窗口模型产生影响后重新排列曲线。"
       }
     }
   ]
diff --git a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-b200-vs-b300-kv-working-set.mdx b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-b200-vs-b300-kv-working-set.mdx
index 8af550d2b..9e2a74400 100644
--- a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-b200-vs-b300-kv-working-set.mdx
+++ b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-b200-vs-b300-kv-working-set.mdx
@@ -43,7 +43,7 @@ tags:
 
 ## offload 层为什么需要余量
 
-DRAM KV offload 通常实现为写穿缓存，也就是写入 HBM 缓存的每个前缀同时也会写入 DRAM 缓存。因此，只有当可用于 offload 的 DRAM 显著大于 HBM 中 KV cache 的容量时（大约 1.5 到 3 倍）它才最有效。
+DRAM KV offload 通常实现为写穿缓存，也就是写入 HBM 缓存的每个前缀同时也会写入 DRAM 缓存。因此，只有当可用于 offload 的 DRAM 容量显著大于 HBM 中 KV cache 的容量（约为其 1.5 到 3 倍）时，它才最有效。
 
 正是这一性质，让 B300 额外的 HBM 产生的是叠加效应而不只是简单相加：更大的常驻工作集把更多会话状态留在快速层，慢速层因此只需服务真正的剩余部分，而不必不断吸收被淘汰的数据。
 
diff --git a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-gb200-vs-gb300-disagg.mdx b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-gb200-vs-gb300-disagg.mdx
index 81e1985ff..e09634b63 100644
--- a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-gb200-vs-gb300-disagg.mdx
+++ b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-gb200-vs-gb300-disagg.mdx
@@ -27,7 +27,7 @@ tags:
 
 ## 两个点在 token 速率上比在首 token 延迟上更接近
 
-以每用户每秒 token 数衡量时，2xDEP8+1xDEP12 的 GB200 点与 3xDEP8+1xDEP16 的 GB300 点相当接近；但以首 token 延迟衡量时，两者差距明显更大。因此只看交互性坐标轴，会低估这两种配置行为上的差异。
+以每用户每秒 token 数衡量时，2xDEP8+1xDEP12 的 GB200 点与 3xDEP8+1xDEP16 的 GB300 点明显更接近；但以首 token 延迟衡量时，两者差距明显更大。因此只看交互性坐标轴，会低估这两种配置行为上的差异。
 
 总体而言，TTFT 对工作负载的「突发性」更敏感。GB300 那个点的总并发要高得多，因而会遇到更多子智能体流量，也就有更多冷 prefill。[子智能体](/zh/glossary/subagent)带着全新上下文启动，没有可复用的前缀，因此它的第一条请求是完整 prefill 而不是缓存命中；当足够多这样的请求同时到达时，[尾部延迟](/zh/glossary/tail-latency)就会被推高。
 
diff --git a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-mi355x-vs-b200-august.mdx b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-mi355x-vs-b200-august.mdx
index 1b2b14dca..65b7bd6c1 100644
--- a/packages/app/content/blog/zh/deepseek-v4-pro-agentx-mi355x-vs-b200-august.mdx
+++ b/packages/app/content/blog/zh/deepseek-v4-pro-agentx-mi355x-vs-b200-august.mdx
@@ -36,9 +36,9 @@ DeepSeek V4 Pro 0813 是一款来自中国、极受欢迎的前沿开放权重
 
 8 月 21 日之后，来自 Inferact 和 NVIDIA 的 vLLM 优化让 B200 的每美元性能超过了 MI355X。这仍是一场胶着的竞赛，而不是已成定局；[AMD 也公布了自己的 DeepSeek V4 vLLM 优化清单](https://github.com/vllm-project/vllm/issues/52911)，上面还有不少待办事项。
 
-## ATOM 这个前提
+## 关于 ATOM 的附加说明
 
-在端到端延迟上，MI355X 上的 ATOM 胜过 B200 vLLM，但没有胜过 B300 或 B200 SGLang。更重要的前提在于部署：中国和西方的多数 AI 实验室都不愿在生产中使用 ATOM，因此只在厂商引擎下成立的优势，并不能代表使用上游软件栈的客户实际拿到的性能。在单节点上，MI355X 的开源方案（vLLM）依然落后于 ATOM。
+在端到端延迟上，MI355X 上的 ATOM 胜过 B200 vLLM，但没有胜过 B300 或 B200 SGLang。更重要的限定条件在于部署：中国和西方的多数 AI 实验室都不愿在生产中使用 ATOM，因此只在厂商引擎下成立的优势，并不能代表使用上游软件栈的客户实际拿到的性能。在单节点上，MI355X 的开源方案（vLLM）依然落后于 ATOM。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/e8d915c0-c962-4277-b62c-a1b08b8e7179_1924x1262.png"
diff --git a/packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx b/packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx
index 6b6234c34..b70b5c3ce 100644
--- a/packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx
+++ b/packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx
@@ -146,7 +146,7 @@ vLLM 和 Nvidia 非常快速地在 [srt-slurm](https://github.com/NVIDIA/srt-slu
 
 这是 CUDA 护城河的一个典型案例：借助 CUDA，分布式推理通常能在最新开源模型发布的第 0 天附近即获得支持。
 
-### 第 3 天 多 token 预测（MTP）推测性解码
+### 第 3 天 多 token 预测（MTP）投机解码
 
 <Figure
   src="/images/deepseekv4-16t-day-0-to-day-43-performance/day3-sglang-mtp.png"
@@ -278,7 +278,7 @@ _GB300 NVL72 DeepSeek V4 Pro 性能随时间的改进。来源：SemiAnalysis In
 
 [实时图表](https://inferencex.semianalysis.com/inference?i_hc=1&g_model=DeepSeek-V4-Pro&g_rundate=2026-06-08&g_runid=27099659001&i_prec=fp4%2Cfp8&i_gpus=gb300_dynamo-sglang%2Cgb300_dynamo-sglang_mtp&i_active=gb300_dynamo-sglang&i_dates=2026-04-30%2C2026-05-07%2C2026-05-11%2C2026-05-20%2C2026-05-22%2C2026-05-28%2C2026-06-02%2C2026-06-03%2C2026-06-08&i_dstart=2026-04-30&i_dend=2026-06-08)
 
-GB300 SGLang MTP 最显著的改进出现在 6 月 2 日，源自 W4A4 (MXFP4) MegaMoE 的实现。相比 5 月 7 日使用的非 MTP 实现，6 月 2 日版本的主要改进完全来自 GB300 解码拓扑的重构，而非触及 kernel 或精度。第 0 天的配方大多数点以窄 EP=8 运行，由一到两个 prefill worker 供给，并发上限为 16,384；5 月 20 日的运行将解码扩展到 EP=16，prefill 扩展到每个解码 worker 对应四到十二个 prefill worker，并将并发推到了 21,504。
+GB300 SGLang MTP 最显著的改进出现在 6 月 2 日，源自 W4A4 (MXFP4) MegaMoE 的实现。相比 5 月 7 日使用的非 MTP 实现，6 月 2 日版本的主要改进完全来自 GB300 解码拓扑的重构，而非触及 kernel 或精度。第 0 天的测试配置在多数数据点上以窄 EP=8 运行，由一到两个 prefill worker 供给，并发上限为 16,384；5 月 20 日的运行将解码扩展到 EP=16，prefill 扩展到每个解码 worker 对应四到十二个 prefill worker，并将并发推到了 21,504。
 
 根据上述图表和分析，我们可以看到，正如预期的那样，对于更大 world size 的推理系统，宽专家并行（Wide EP）是 GB300 卓越性能的主要杠杆，这通过在更多 GPU 之间分摊权重加载来实现。阅读 [InferenceX V2](https://newsletter.semianalysis.com/p/inferencex-v2-nvidia-blackwell-vs) 文章了解更多关于 Wide EP 的内容。
 
@@ -389,7 +389,7 @@ CANN（Compute Architecture for Neural Networks）是 Huawei 为在自家 Ascend
 
 在第 0 天，CANN 发布了 Ascend 芯片的优化指南和基准测试数据。通过这些信息，我们可以看到 Huawei 的 CANN 策略：通过面向中国国产模型发布的全栈推理优化，使 Ascend 具备竞争力。Huawei 试图向中国生态系统表明，如果 DeepSeek 发布新架构，CANN 能够交付 kernel、graph 路径、量化、服务集成和部署配方。
 
-我们在基准测试 MTP 时观察到 CANN 团队的一个有趣方法论，不得不在此提及：他们如何处理 MTP 草稿 token 的 AR（acceptance rate，接受率）或 AL（acceptance length，接受长度）。基准测试 MTP 并非易事，因为基准测试的 AR/AL 可能与用户的实际用例不同。例如，基准测试平均每三个草稿 token 可能接受两个，但在极其多样化的实际部署场景中，可能平均只能接受 1.5 个。
+我们在基准测试 MTP 时观察到 CANN 团队的一个有趣的做法，不得不在此提及：他们如何处理 MTP 草稿 token 的 AR（acceptance rate，接受率）或 AL（acceptance length，接受长度）。基准测试 MTP 并非易事，因为基准测试的 AR/AL 可能与用户的实际用例不同。例如，基准测试平均每三个草稿 token 可能接受两个，但在极其多样化的实际部署场景中，可能平均只能接受 1.5 个。
 
 这意味着用户可能看到的性能低于基准测试，从而错误地认为他们的设置有问题。我们在 [InferenceX v2 文章](https://newsletter.semianalysis.com/i/188090866/multi-token-prediction-mtp)中通过与 MTBench 的 AR 对比来解决这个问题。我们基准测试的未来迭代将通过使用真实 trace 来全面解决这一差距。
 
@@ -427,7 +427,7 @@ SIMT/SIMD 950 芯片有两个型号：950PR 和 950DT。PR 代表 Prefill and Re
 
 这与 TPU 的 MXU 类似。不过 Ascend 将两种功能更直接地暴露为独立的分离核心，每个核心都能加载自己的代码段，并且支持"双主模式"——AIC 和 AIV 独立运行代码，而非由 AIV 通过消息驱动 AIC。
 
-AI CPU 是一个具有直接设备内存访问权限的设备端 ARM64 执行单元。它作为 AI Core 的补充，处理不适合在 SIMD/SIMT 核心上执行的工作：分支密集的控制流、标量逻辑、动态形状处理，以及 kernel 运行前需要的值依赖的调度/分块元数据。由于 AI CPU 位于设备上，Ascend 可以将这些不规则的控制型工作保留在本地，而非在主机 CPU 之间来回传输——后者是延迟（latency）和流水线气泡的主要来源。AI CPU 也是在专用 CCU 分担通信编排之前，历史上位于旧有 AICore → AICPU → SDMA 路径上的单元。
+AI CPU 是一个具有直接设备内存访问权限的设备端 ARM64 执行单元。它作为 AI Core 的补充，处理不适合在 SIMD/SIMT 核心上执行的工作：分支密集的控制流、标量逻辑、动态形状处理，以及 kernel 运行前需要的值依赖的调度/分块元数据。由于 AI CPU 位于设备上，Ascend 可以将这些不规则的控制型工作保留在本地，而非往返传输到主机 CPU——后者是延迟（latency）和流水线气泡的主要来源。AI CPU 也是在专用 CCU 分担通信编排之前，历史上位于旧有 AICore → AICPU → SDMA 路径上的单元。
 
 与 TPU 和 Trainium 类似，Ascend 950 增加了专用的 CCU 通信引擎。该引擎与计算 die 并列，处理集合通信工作而不消耗 AI Core 的计算容量，支持远程读取 + 规约 + 本地写入，以及本地读取 + 远程写入。其优势在于更低的通信延迟、更少的 HBM 流量、更少的用户缓冲区拷贝，以及将计算核心从通信编排中解放出来，避免走旧有的 AICore → AICPU → SDMA 路径。
 
@@ -441,7 +441,7 @@ AI CPU 是一个具有直接设备内存访问权限的设备端 ARM64 执行单
 
 上图展示了 DeepSeek flash v4 在 Ascend 950DT 上的三步 profile，使用 16 rank DP/EP 部署配置运行。它显示了 16 rank 集合通信参与以及活跃的 MoE dispatch/combine 流量。
 
-与大多数栈目前的标准做法一样，CANN 也使用可在多个流上运行的独立计算和通信算子——通过控制 Cube 和 Vector 核心分配来避免资源争用从而提升性能。Prolog、Compressor 和 LightningIndexer 等操作可以重叠执行，C4A Compressor 可以完全隐藏，shared expert 计算可以隐藏在 routed expert 执行之下而不降低 routed expert 性能。
+与大多数栈目前的标准做法一样，CANN 也使用可在多个流上运行的独立计算和通信算子；通过控制 Cube 和 Vector 核心的分配来避免资源争用，从而提升性能。Prolog、Compressor 和 LightningIndexer 等操作可以重叠执行，C4A Compressor 可以完全隐藏，shared expert 计算可以隐藏在 routed expert 执行之下而不降低 routed expert 性能。
 
 <Figure
   src="/images/deepseekv4-16t-day-0-to-day-43-performance/ascend-950dt-decode-streams.png"
@@ -453,7 +453,7 @@ AI CPU 是一个具有直接设备内存访问权限的设备端 ARM64 执行单
 
 上图中的 Streams 145-148 对应元数据流。这些算子每次解码步骤触发一次，预计算后续 kernel 复用的值依赖调度/分块元数据。它们是解码步骤中唯一的 AI CPU 操作，占总时间的极小比例，且完全被 AI Core 计算重叠。其影响在更长上下文的基准测试中可能更显著，因为需要提前解析更多序列长度和掩码相关的分区。
 
-在 DeepSeek v4 中，Huawei 将稀疏注意力和 LightningIndexer 的值依赖调度阶段移到了 AI CPU 上，而非回弹到主机。这些元数据操作根据运行时序列长度、掩码和分页 KV 信息构建可复用的每核心分区张量；`SparseAttnSharedkv` 和 `QuantLightningIndexer` 随后使用它们来决定每个 cube 核心处理哪些 Batch/Head/Q-block/K-block 工作，以及相应的 vector 核心规约任务。从概念上讲，这类似于 FlashInfer 在主机端为分页 attention 所做的 planning 阶段：一个低成本、动态形状感知的设置步骤，只运行一次因此在各层间摊销——唯一区别是 Huawei 将同样的 planning 工作推到了设备端 AI CPU 上而非主机端。
+在 DeepSeek v4 中，Huawei 将稀疏注意力和 LightningIndexer 的值依赖调度阶段移到了 AI CPU 上，而非退回主机端。这些元数据操作根据运行时序列长度、掩码和分页 KV 信息构建可复用的每核心分区张量；`SparseAttnSharedkv` 和 `QuantLightningIndexer` 随后使用它们来决定每个 cube 核心处理哪些 Batch/Head/Q-block/K-block 工作，以及相应的 vector 核心规约任务。从概念上讲，这类似于 FlashInfer 在主机端为分页 attention 所做的 planning 阶段：一个低成本、动态形状感知的设置步骤，只运行一次因此在各层间摊销——唯一区别是 Huawei 将同样的 planning 工作推到了设备端 AI CPU 上而非主机端。
 
 上图中的 Stream 152 包含 LM head、最后一层，以及倒数第二层的 `o_proj` 和 MoE。这是 `npugraph_ex` 图编译器的决策，可能是为了让 `npugraph_ex` 运行时将 stream 144 上的主图视为"完成"，同时尾部工作继续异步执行。
 
@@ -489,7 +489,7 @@ CANN 早在 2024 年就引入了 MC²（merged compute-communication，计算-
 
 DeepSeek v4 引入了压缩稀疏注意力（Compressed Sparse Attention, CSA）和高度压缩注意力（Heavily Compressed Attention, HCA），告别了多头潜在注意力（Multi-head Latent Attention, MLA）。该设计的核心动机是减小 KV cache 大小。
 
-本质上，HCA 的 KV cache 由 KV embedding 的滑动窗口和一组压缩 KV 条目组成，其中每个条目将 key/value 压缩为一个并跨越 m′ 个 token（DeepSeek V4 Pro 中 m′ = 128）。
+本质上，HCA 的 KV cache 由 KV embedding 的滑动窗口和一组压缩 KV 条目组成，其中每个条目将 m′ 个 token 的 key/value 压缩为一项（DeepSeek V4 Pro 中 m′ = 128）。
 
 <Figure
   src="/images/deepseekv4-16t-day-0-to-day-43-performance/dsv4-hca-compression.png"
@@ -558,7 +558,7 @@ _本文后续包含 H200 和 GB200 NVL72 的完整总拥有成本和每 token 
       "name": "DeepSeek V4 的注意力架构是什么？CSA / HCA 如何减少 KV cache？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "DeepSeek V4 用压缩稀疏注意力（CSA）和高度压缩注意力（HCA）取代了多头潜在注意力（MLA）。HCA 的 KV cache 由 KV embedding 的滑动窗口和压缩 KV 条目组成，每个条目跨越 128 个 token（DeepSeek V4 Pro 中 m'=128）压缩 key 和 value。CSA 使用相同的压缩机制但压缩率更低（m=4），并通过 lightning indexer 对压缩后的条目应用稀疏注意力，继承自 DeepSeek V3.2 的稀疏注意力模式。交错使用 CSA 和 HCA 在 1M 上下文长度下实现了约 50 倍的 KV cache 缩减。"
+        "text": "DeepSeek V4 用压缩稀疏注意力（CSA）和高度压缩注意力（HCA）取代了多头潜在注意力（MLA）。HCA 的 KV cache 由 KV embedding 的滑动窗口和压缩 KV 条目组成，每个条目将 128 个 token（DeepSeek V4 Pro 中 m'=128）的 key 和 value 压缩为一项。CSA 使用相同的压缩机制但压缩率更低（m=4），并通过 lightning indexer 对压缩后的条目应用稀疏注意力，继承自 DeepSeek V3.2 的稀疏注意力模式。交错使用 CSA 和 HCA 在 1M 上下文长度下实现了约 50 倍的 KV cache 缩减。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/engrams-embedding-entendre-codesign.mdx b/packages/app/content/blog/zh/engrams-embedding-entendre-codesign.mdx
index 5e5bcf425..1240dd531 100644
--- a/packages/app/content/blog/zh/engrams-embedding-entendre-codesign.mdx
+++ b/packages/app/content/blog/zh/engrams-embedding-entendre-codesign.mdx
@@ -84,7 +84,7 @@ Engram 的表现优于纯 MoE 基线。我们也复现了 DeepSeek 的另一项
 
 这些例子说明，可学习记忆优化的是训练目标，而不是判断哪些事实值得保存。许可证、参考文献片段、API 框架代码和网页固定元素都能提供预测捷径，因此增加 Engram 容量的价值可能取决于数据准备后保留了什么。这不说明表容量被“浪费”：对评估语料的扫描既不能确定训练时见过什么，也不能确定每类内容占据多少容量。
 
-对于 offload，强 gate 并不能识别缓存热行。低 gate 也不会自动省掉读取：计算 gate 需要已经取回的 key，并会抵消融合内核的性能收益。若要跳过读取，需要另一个在检索之前运行的有用性预测器。
+对于 offload，强 gate 并不能识别缓存热行。低 gate 也不会自动省掉读取：计算 gate 需要已经取回的 key，并会抵消融合 kernel 的性能收益。若要跳过读取，需要另一个在检索之前运行的有用性预测器。
 
 ## 移除 Engram
 
@@ -154,7 +154,7 @@ DeepSeekv4.1 Flash 发布当天，NVIDIA vLLM 在 H100、H200、B200、B300、GB
   caption="来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)"
 />
 
-AMD 的 vLLM 文档要求使用 vllm/vllm-openai-rocm:deepseekv41-flash-0909，但从模型发布第 0 小时到第 23 小时，AMD 都没有公开该镜像。AMD 宣称“SPEED IS THE MOAT”，却直到第 23 小时仍未发布。我们希望 AMD 团队今后改善模型发布首小时的支持流程。
+AMD 的 vLLM 文档建议使用 vllm/vllm-openai-rocm:deepseekv41-flash-0909，但从模型发布第 0 小时到第 23 小时，AMD 都没有公开该镜像。AMD 宣称“SPEED IS THE MOAT”，却直到第 23 小时仍未发布。我们希望 AMD 团队今后改善模型发布首小时的支持流程。
 
 <Figure
   src="/images/engrams-embedding-entendre-codesign/figure-14.png"
@@ -188,7 +188,7 @@ CUDA 护城河的力量来自 NVIDIA 与庞大的 600 万开发者社区生态
 
 ## AgentX 中 Engram DRAM offload 带来的性能提升
 
-HBM 与 DRAM offload 使用同一个 GPU 内核选择和反量化行。HBM 版本读取 GPU 内存；统一虚拟寻址（UVA）版本则直接读取固定页主机内存。
+HBM 与 DRAM offload 使用同一个 GPU kernel 来完成行选择与反量化。HBM 版本读取 GPU 内存；统一虚拟寻址（UVA）版本则直接读取固定页主机内存。
 
 两者都支持完整 decode graph。把表移入 HBM 只加速稀疏查表，并不改变 decoder 的计算和通信，因此整体收益很小，却占用了原本可供 KV cache 使用的内存。
 
@@ -210,11 +210,11 @@ HBM 与 DRAM offload 使用同一个 GPU 内核选择和反量化行。HBM 版
 
 我们在 B200 上创建了一个未经优化的 vLLM fork，把 Engram 表放入本地 SSD 上的内存映射文件。当其他应用需要 RAM 时，文件支持的映射允许操作系统回收表页面。已经缓存在内存中的页面可以直接提供数据，无需再次读取 SSD。还需要说明，我们未能启用 GDS。
 
-这个未经优化的 SSD 实现改变了行抵达 GPU 的路径：先把行 ID 复制到 CPU，去重后将所需行收集到固定页缓冲区，再把这些行复制回 GPU 并反量化。这些工作在 GPU 执行 graph 的片段之间运行。原生 UVA 则直接在 GPU 上选择并反量化行，避免 CPU 往返。
+这个未经优化的 SSD 实现改变了行抵达 GPU 的路径：先把行 ID 复制到 CPU，去重后将所需行收集到固定页缓冲区，再把这些行复制回 GPU 并反量化。这些工作穿插在 GPU 执行图（execution graph）的各个片段之间运行。原生 UVA 则直接在 GPU 上选择并反量化行，避免 CPU 往返。
 
-Warm 文件系统缓存可以消除物理 SSD 读取，但协调、行收集和传输仍然存在。因此，即使文件已经缓存在 RAM 中，也可能比固定页 DRAM 表更慢。这里比较的是完整服务路径，并未单独拆分各项操作耗时。
+处于 warm 状态的文件系统缓存可以消除物理 SSD 读取，但协调、行收集和传输仍然存在。因此，即使文件已经缓存在 RAM 中，也可能比固定页 DRAM 表更慢。这里比较的是完整服务路径，并未单独拆分各项操作耗时。
 
-在 total tokens per dollar 和 P90 interactivity 两项指标上，B200 DRAM 都优于两条实测 SSD 服务曲线。在约 125 tokens/s/user 时，DRAM 每美元提供 1.21 亿 total tokens，SSD 为 5200 万。
+在每美元总 token 数与 P90 交互性两项指标上，B200 DRAM 都优于两条实测 SSD 服务曲线。在约 125 tokens/s/user 时，DRAM 每美元提供 1.21 亿 total tokens，SSD 为 5200 万。
 
 <Figure
   src="/images/engrams-embedding-entendre-codesign/figure-19.png"
diff --git a/packages/app/content/blog/zh/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx b/packages/app/content/blog/zh/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx
index 2abb029ca..047edee74 100644
--- a/packages/app/content/blog/zh/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx
+++ b/packages/app/content/blog/zh/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx
@@ -22,11 +22,11 @@ NVIDIA GB200 NVL72 运行 Dynamo vLLM 在 Kimi K2.5 NVFP4 8k/1k 上峰值达到
   点击查看完整 InferenceX 仪表板 →
 </DashboardCTA>
 
-Kimi K2.5 是一个 1T 参数的 MoE 模型，拥有 384 个路由专家加 1 个共享专家，每 token 激活 8 个专家，共 60 层 MoE 层。每个 MoE 层执行一次路由式 all-to-all 分发加一次 all-to-all 汇聚，因此单次前向传播在 60 层中总共约有 120 次 all-to-all 操作。在 NVL72 上，这些流量始终运行在 NVLink 5 上，每 GPU 1.8 TB/s，聚合互联带宽达 130 TB/s。而在 B200 上，宽 EP 超过 8 GPU 后就离开了 NVLink 域，退回到 ConnectX 7 InfiniBand 的每 GPU 400 Gb/s，约为 NVL72 NVLink 带宽的 1/36。稀疏度为 48 的 MoE（如 K2.5）无法在规模化时容忍这种差距。
+Kimi K2.5 是一个 1T 参数的 MoE 模型，拥有 384 个路由专家加 1 个共享专家，每 token 激活 8 个专家，共 60 个 MoE 层。每个 MoE 层执行一次路由式 all-to-all 分发加一次 all-to-all 汇聚，因此单次前向传播在 60 层中总共约有 120 次 all-to-all 操作。在 NVL72 上，这些流量始终运行在 NVLink 5 上，每 GPU 1.8 TB/s，聚合互联带宽达 130 TB/s。而在 B200 上，宽 EP 超过 8 GPU 后就离开了 NVLink 域，退回到 ConnectX 7 InfiniBand 的每 GPU 400 Gb/s，约为 NVL72 NVLink 带宽的 1/36。稀疏度为 48 的 MoE（如 K2.5）在大规模部署时无法承受这种差距。
 
 ## 宽 EP 对 Kimi K2.5 为何重要
 
-在 EP 4 下，每个 GPU 持有 Kimi K2.5 384 个专家中的 96 个。解码受限于每步从 HBM 重新加载这些专家权重所需的显存带宽。将 EP 扩展到 16 会将每 GPU 的专家占用降至 24 个。每次专家权重读取被摊销到更大的有效批次上——更多对等 GPU 通过该 rank 分发 token。这使解码从权重带宽受限转向算力和通信受限。在这种模式下，Blackwell 的 FP4 tensor core 和 NVLink 带宽都能发挥优势。
+在 EP 4 下，每个 GPU 持有 Kimi K2.5 的 384 个专家中的 96 个。解码受限于每步从 HBM 重新加载这些专家权重所需的显存带宽。将 EP 扩展到 16 会将每 GPU 的专家占用降至 24 个。每次专家权重读取被摊销到更大的有效批次上——更多对等 GPU 通过该 rank 分发 token。这使解码从权重带宽受限转向算力和通信受限。在这种模式下，Blackwell 的 FP4 tensor core 和 NVLink 带宽都能发挥优势。
 
 扩宽 EP 的代价是每个 MoE 层增加一次 all-to-all 集合通信。如果该集合通信命中 scale-out 互联，交互性预算在吞吐量收益回本之前就会崩溃。NVL72 的 scale-up 域使得 EP 8 到 EP 16 的宽 EP 在 K2.5 解码池上可行。B200 的 8 GPU NVLink 域使得跨两个节点的 Decode EP 4 成为 scale-out 接管前的天花板。
 
@@ -82,7 +82,7 @@ GB200 NVL72 在 23 到 36 tok/s/user 区间内维持约 12,580 tok/s/GPU 的平
 
 ## NVL72 上的 vLLM 宽 EP
 
-vLLM 在 v0.9 中推出了 PPLX all-to-all 后端，随后添加了 DeepEP。v0.11 完成了 V1 引擎迁移，并通过 PR [#24845](https://github.com/vllm-project/vllm/pull/24845) 扩展了双批重叠（DBO，Dual Batch Overlap）路径，添加了 DeepEP 高吞吐量内核以及 DBO 的预填充支持，使 all-to-all 通信可以隐藏在计算之后。上述基准测试运行的是 v0.18.0，未启用投机解码。
+vLLM 在 v0.9 中推出了 PPLX all-to-all 后端，随后添加了 DeepEP。v0.11 完成了 V1 引擎迁移，并通过 PR [#24845](https://github.com/vllm-project/vllm/pull/24845) 扩展了双批重叠（DBO，Dual Batch Overlap）路径，添加了 DeepEP 高吞吐量 kernel 以及 DBO 的预填充支持，使 all-to-all 通信可以隐藏在计算之后。上述基准测试运行的是 v0.18.0，未启用投机解码。
 
 GB200 NVL72 配置在 NVIDIA Dynamo 中以 vLLM 作为 worker 运行时，在 InferenceX 数据集中标记为 dynamo-vllm。Dynamo 将预填充（4 GPU、TP 4、EP 4）与解码（8 到 16 GPU，TP 和 EP 均扩展至 16）分离，并通过 NVL72 互联在两者之间路由请求。SGLang 和 TRT-LLM 在 NVL72 上也有类似的分离式 + 宽 EP 路径，其中 SGLang 公开的 GB200 结果目前最为成熟。
 
@@ -113,7 +113,7 @@ GB200 NVL72 在并发 2,048 到 4,096 范围内以 23 到 36 tok/s/user 的交
       "name": "为什么 GB200 NVL72 在 MoE 模型上能扩展比 B200 更宽的专家并行？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "NVL72 是一个 72 GPU 的 NVLink scale-up 域。每个 GPU 可以 1.8 TB/s 的速率访问其他所有 GPU，聚合互联带宽达 130 TB/s。B200 每个 NVLink 域最多 8 GPU。更宽的专家并行必须跨越 InfiniBand，每 GPU 400 Gb/s，约为 NVL72 NVLink 带宽的 1/36。Kimi K2.5 有 384 个路由专家和 60 层 MoE 层，每层 MoE 执行一次 all-to-all 分发加汇聚，单次前向传播约 120 次 all-to-all。该集合通信仅在互联端到端均为 NVLink 时才能在 EP 16 或更高级别实际运行。在 NVL72 上流量保持在 scale-up 域内；B200 超过 8 GPU 后就不再如此。"
+        "text": "NVL72 是一个 72 GPU 的 NVLink scale-up 域。每个 GPU 可以以 1.8 TB/s 的速率访问其他所有 GPU，聚合互联带宽达 130 TB/s。B200 每个 NVLink 域最多 8 GPU。更宽的专家并行必须跨越 InfiniBand，每 GPU 400 Gb/s，约为 NVL72 NVLink 带宽的 1/36。Kimi K2.5 有 384 个路由专家和 60 个 MoE 层，每层执行一次 all-to-all 分发加汇聚，单次前向传播约 120 次 all-to-all。该集合通信仅在互联端到端均为 NVLink 时才能在 EP 16 或更高级别实际运行。在 NVL72 上流量保持在 scale-up 域内；B200 超过 8 GPU 后就不再如此。"
       }
     },
     {
@@ -121,7 +121,7 @@ GB200 NVL72 在并发 2,048 到 4,096 范围内以 23 到 36 tok/s/user 的交
       "name": "在 GB200 NVL72 上运行 Kimi K2.5 宽 EP 需要什么版本的 vLLM 和配方？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "Kimi K2.5 配方需要 vLLM 0.18 或更高版本，该版本依赖 Eagle3 投机解码支持。PPLX all-to-all 后端在 vLLM 0.9 中推出，随后是 DeepEP，v0.11 完成了 V1 引擎迁移并通过 PR #24845 扩展了双批重叠（DBO）路径（添加 DeepEP 高吞吐量内核和 DBO 预填充支持）。InferenceX GB200 基准测试在预填充池上使用 TP 4，在 NVL72 解码池上将 TP 和 EP 扩展至 16。上游 vLLM 配方使用 DP 4 / DP 16 形态，两侧均为 TP 1 加专家并行。"
+        "text": "Kimi K2.5 配方需要 vLLM 0.18 或更高版本，该版本依赖 Eagle3 投机解码支持。PPLX all-to-all 后端在 vLLM 0.9 中推出，随后是 DeepEP，v0.11 完成了 V1 引擎迁移并通过 PR #24845 扩展了双批重叠（DBO）路径（添加 DeepEP 高吞吐量 kernel 和 DBO 预填充支持）。InferenceX GB200 基准测试在预填充池上使用 TP 4，在 NVL72 解码池上将 TP 和 EP 扩展至 16。上游 vLLM 配方使用 DP 4 / DP 16 形态，两侧均为 TP 1 加专家并行。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/gb200-nvl72-vs-b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx b/packages/app/content/blog/zh/gb200-nvl72-vs-b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx
index e70a66208..dfd06c70c 100644
--- a/packages/app/content/blog/zh/gb200-nvl72-vs-b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx
+++ b/packages/app/content/blog/zh/gb200-nvl72-vs-b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx
@@ -104,7 +104,7 @@ DeepSeek R1 0528 是 DeepSeek 于 2025 年 5 月发布的 671B 参数 MoE 模型
 | 275                 | 103                   | 126            | 0.82x              |
 | 300                 | _不可达_              | 67             | _∞_（B200 胜出）   |
 
-以及同一对比按每百万 token 成本归一化的结果，GB200 NVL72 每 GPU 小时 TCO 高 13%（$2.21 vs $1.95）削弱了其吞吐量优势：
+下面将同一对比按每百万 token 成本归一化：GB200 NVL72 每 GPU 小时 TCO 高 13%（$2.21 vs $1.95），这在一定程度上抵消了其吞吐量优势：
 
 | 交互性 (tok/s/user) | GB200 NVL72 $/M tok | B200 $/M tok | B200 / GB200 NVL72 |
 | ------------------- | ------------------- | ------------ | ------------------ |
@@ -170,7 +170,7 @@ NVIDIA 的 [SGLang GB200 NVL72 结果](https://lmsys.org/blog/2025-09-25-gb200-p
       "name": "GB200 NVL72 在此对比中每百万 token 成本也低于 B200 吗？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "在 75–175 tok/s/user 区间内是的，在两端基本持平。GB200 NVL72 每 GPU 小时 TCO 高约 13%（$2.21 vs $1.95，数据来源 SemiAnalysis AI Cloud TCO 模型），这在成本维度上削弱了吞吐量优势。在峰值吞吐量端（25 至 60 tok/s/user）成本基本持平：GB200 NVL72 便宜 1.01 至 1.06 倍。在 125 tok/s/user 时成本差距为 3.87 倍（B200 每百万 token $0.58，GB200 NVL72 $0.15）。在 225 tok/s/user 以上成本差距反转：B200 在 225 tok/s/user 时便宜 5%，在 250 tok/s/user 时便宜 15%，在 275 tok/s/user 时便宜 27%。"
+        "text": "在 75–175 tok/s/user 区间内是的，在两端基本持平。GB200 NVL72 每 GPU 小时 TCO 高约 13%（$2.21 vs $1.95，数据来源 SemiAnalysis AI Cloud TCO 模型），这在成本维度上削弱了吞吐量优势。在峰值吞吐量端（25 至 60 tok/s/user）成本基本持平：B200 的成本是 GB200 NVL72 的 1.01 至 1.06 倍。在 125 tok/s/user 时成本差距为 3.87 倍（B200 每百万 token $0.58，GB200 NVL72 $0.15）。在 225 tok/s/user 以上成本差距反转：B200 在 225 tok/s/user 时便宜 5%，在 250 tok/s/user 时便宜 15%，在 275 tok/s/user 时便宜 27%。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx b/packages/app/content/blog/zh/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx
index 7cc9580b3..a1344cb3f 100644
--- a/packages/app/content/blog/zh/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx
+++ b/packages/app/content/blog/zh/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx
@@ -1,7 +1,7 @@
 ---
 title: 'GB300 NVL72 对比 GB200 NVL72 的推理性能与每美元性能 — DeepSeek-V4-Pro 1.6T：吞吐量最高达 2.83 倍'
 subtitle: 'DSv4-Pro FP4 8K/1K，Dynamo+vLLM，两套机架均采用分离式部署。GB300 多出 50% 的 HBM（每 GPU 288 GB vs 192 GB）解锁了 GB200 无法容纳的更宽预填充+解码配方——尽管单 GPU TCO 溢价 20%，曲线中段性价比仍提升 2.31 倍。'
-seoDescription: 'GB300 NVL72 多出的 50% HBM 使 DeepSeek-V4-Pro 性价比比 GB200 NVL72 最高提升 2.31 倍（vLLM FP4 8K/1K），每 GPU 吞吐量最高提升 2.83 倍。'
+seoDescription: 'GB300 NVL72 多出的 50% HBM 使 DeepSeek-V4-Pro 的性价比最高可达 GB200 NVL72 的 2.31 倍（vLLM FP4 8K/1K），每 GPU 吞吐量最高提升 2.83 倍。'
 date: '2026-05-27'
 publishDate: '2026-05-27'
 tags:
@@ -19,7 +19,7 @@ tags:
   - disagg
 ---
 
-在 DeepSeek-V4-Pro FP4、8K/1K 输入输出长度、Dynamo vLLM 框架以及两套机架均启用分离式预填充/解码的条件下，GB300 NVL72 在等交互性下**每 GPU 吞吐量最高达 GB200 NVL72 的 2.83 倍**，峰值出现在 27 tok/s/user（GB300 为 6,182 tok/s/GPU，GB200 为 2,189 tok/s/GPU）。纸面上两者的硅片差异看似不大——相同的显存带宽、相同的 NVLink 互联、相同的 scale-up 规模，仅多出 1.5 倍 HBM 容量和 1.5 倍 FP4 算力——但曲线中段的差距远超任何静态比率，因为 GB300 额外的 HBM 消除了 GB200 必须为之付出代价的一个软件约束。
+在 DeepSeek-V4-Pro FP4、8K/1K 输入输出长度、Dynamo vLLM 框架以及两套机架均启用分离式预填充/解码的条件下，GB300 NVL72 在等交互性下**每 GPU 吞吐量最高达 GB200 NVL72 的 2.83 倍**，峰值出现在 27 tok/s/user（GB300 为 6,182 tok/s/GPU，GB200 为 2,189 tok/s/GPU）。纸面上两者的硅片差异看似不大——相同的显存带宽、相同的 NVLink 互联、相同的 scale-up 规模，HBM 容量和 FP4 算力都只有 GB200 的 1.5 倍——但曲线中段的差距远超任何静态比率，因为 GB300 额外的 HBM 消除了 GB200 必须为之付出代价的一个软件约束。
 
 其机制在于 **HBM 余量**。DSv4-Pro 1.6T 参数量下，仅 FP4 权重就约占 800 GB，GB200 在窄预填充形态下可用 HBM 相当紧张，配方不得不在批大小上做出妥协以将模型装入显存。GB300 的 1.5 倍 HBM 容量（每 GPU 288 GB vs 192 GB）在相同形态下仍有数百 GB 的余量，使得预填充可以运行更大的批次来保持更宽解码池的饱和。在每 GPU TCO 溢价 20%（$2.65 vs $2.21/GPU/hr，数据来自 [SemiAnalysis AI Cloud TCO 模型](https://semianalysis.com/ai-cloud-tco-model/)）之后，GB300 在 27 tok/s/user 下**每百万 token 的成本仍便宜 2.31 倍**。更多 HBM，更多节省。
 
@@ -45,7 +45,7 @@ GB300 NVL72（Blackwell Ultra）和 GB200 NVL72（Blackwell）共享相同的 NV
 <Figure
   srcLight="/images/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4/specs-radar-light.png"
   srcDark="/images/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4/specs-radar-dark.png"
-  alt="GPU 规格雷达图，对比 GB200 NVL72（浅绿色）和 GB300 NVL72（深绿色）在 7 个维度上的表现：显存、显存带宽、FP4/FP8/BF16 TFLOP/s、Scale Up 带宽、Scale Up 域显存、Scale Up 域显存带宽。GB300 在显存和 FP4 两项上为 100%（设定天花板）；GB200 在这两项上约 67%，因为少了 1.5 倍。两者在显存带宽、Scale Up 带宽、Scale Up 域显存带宽、FP8、BF16 上持平。"
+  alt="GPU 规格雷达图，对比 GB200 NVL72（浅绿色）和 GB300 NVL72（深绿色）在 7 个维度上的表现：显存、显存带宽、FP4/FP8/BF16 TFLOP/s、Scale Up 带宽、Scale Up 域显存、Scale Up 域显存带宽。GB300 在显存和 FP4 两项上为 100%（设定天花板）；GB200 在这两项上约 67%，因为只有 GB300 的约三分之二。两者在显存带宽、Scale Up 带宽、Scale Up 域显存带宽、FP8、BF16 上持平。"
   caption="GB200 NVL72（浅绿色）vs GB300 NVL72（深绿色），来自 /gpu-specs。各轴数值按面板中所有 SKU 的跨供应商最大值归一化。唯一的显著差异在于显存（GB300 设定 288 GB 天花板，GB200 约为 67%）和 FP4（GB300 设定 15 PFLOP/s 天花板，GB200 约为 67%）。其余——HBM 带宽、NVLink scale-up 带宽、规模、FP8、BF16——均相同。"
 />
 
@@ -123,7 +123,7 @@ GB200 的每 GPU 峰值吞吐量为 8,933，交互性为 15.3 tok/s/user。GB300
 
 标题中的每 GPU 吞吐量 2.83 倍优势，出现在曲线中段的 27 tok/s/user（此时性价比为 2.31 倍），而不是吞吐量最高点。低于 20 tok/s/user 时，两套机架的预填充批次都足够大，GB300 的 HBM 容量余量优势在结果取整后不再明显；高于 36 tok/s/user 时，两者的批次都较小，也都没有能让宽 EP 得到充分利用的测试配置。22–32 tok/s/user 区间最能体现 GB300 的 1.5 倍 HBM 容量优势：它可以落在更高的 Pareto 节点上（`conc=3072, 28 GPU prefill, 32 GPU decode EP=16, 6,812 tok/s/GPU at 25.9 tok/s/user`），而 GB200 在相同交互性下没有对应的测试配置。GB200 最接近的方案使用 32 GPU 解码池，conc=256/512，但只能达到 1,614–2,005 tok/s/GPU。
 
-50 tok/s/user 行显示成本比率（3.03x）再次扩大，因为两条曲线都进入了右侧的陡峭衰减区。这里的解读需要更谨慎——两套机架在该区域的 Pareto 覆盖都很薄（GB200 在约 33 tok/s/user 处各有一个节点，GB300 在约 37 tok/s/user 处各有一个节点，然后是到约 73 tok/s/user 的长尾），因此插值是在两个间隔较大的实测节点之间读取差距。22–32 tok/s/user 区间才是 GB300 优势的可靠甜蜜点；将 50 tok/s/user 行视为方向性参考。
+50 tok/s/user 行显示成本比率（3.03x）再次扩大，因为两条曲线都进入了右侧的陡峭衰减区。这里的解读需要更谨慎——两套机架在该区域的 Pareto 覆盖都很薄（GB200 在约 33 tok/s/user 处有一个节点，GB300 在约 37 tok/s/user 处有一个节点，然后是到约 73 tok/s/user 的长尾），因此插值是在两个间隔较大的实测节点之间读取差距。22–32 tok/s/user 区间才是 GB300 优势最稳定的区间；将 50 tok/s/user 行视为方向性参考。
 
 <Figure
   srcLight="/images/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4/benchmark-light.png"
diff --git a/packages/app/content/blog/zh/glm-5-3-agentx-mi355x-atom-vs-gb300-nvl72.mdx b/packages/app/content/blog/zh/glm-5-3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
index d61a5be8c..f7e983938 100644
--- a/packages/app/content/blog/zh/glm-5-3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
+++ b/packages/app/content/blog/zh/glm-5-3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
@@ -45,7 +45,7 @@ tags:
 
 需要说明的是，该指标是实验性的，并不完美。例如它对高 TTFT 的惩罚很重，也无法体现 prefill-decode [分离](/zh/glossary/disaggregated-inference)等优化的全部细节。AgentX v1.0 的所有提交仍然分别针对常规交互性和 TTFT 做优化；我们也会继续打磨能反映现代 agentic 推理各种细节的新北极星指标。
 
-这个前提在这里对双方都成立。一套用首 token 延迟换取流式速度的配置，在这条坐标轴上一定会被惩罚，无论这种取舍是否契合具体产品；因此仅凭端到端归一化交互性得出的胜负，应当再对照独立的交互性曲线和 TTFT 曲线核实，然后才能作为采购论据。
+这一限定条件在这里对双方同样适用。一套用首 token 延迟换取流式速度的配置，在这条坐标轴上一定会被惩罚，无论这种取舍是否契合具体产品；因此仅凭端到端归一化交互性得出的胜负，应当再对照独立的交互性曲线和 TTFT 曲线核实，然后才能作为采购论据。
 
 ---
 
diff --git a/packages/app/content/blog/zh/inferencemax-open-source-inference-benchmarking.mdx b/packages/app/content/blog/zh/inferencemax-open-source-inference-benchmarking.mdx
index 4958133b9..56411a02a 100644
--- a/packages/app/content/blog/zh/inferencemax-open-source-inference-benchmarking.mdx
+++ b/packages/app/content/blog/zh/inferencemax-open-source-inference-benchmarking.mdx
@@ -13,7 +13,7 @@ tags:
 
 LLM 推理性能取决于两大支柱：硬件和软件。硬件创新通过每年发布新型 GPU/XPU 和新系统来驱动性能的阶跃式提升，而软件则每天都在演进，在这些硬件跃升之上持续带来性能增益。
 
-SGLang、vLLM、TensorRT-LLM、CUDA 和 ROCm 等 AI 软件通过内核级优化、分布式推理策略和调度创新实现持续的性能改进，以仅相隔数天的增量更新不断推高性能的帕累托前沿。
+SGLang、vLLM、TensorRT-LLM、CUDA 和 ROCm 等 AI 软件通过 kernel 级优化、分布式推理策略和调度创新实现持续的性能改进，以仅相隔数天的增量更新不断推高性能的帕累托前沿。
 
 这种软件进步的速度带来了一个挑战：在某个固定时间点进行的基准测试很快就会过时，无法反映使用最新软件包所能达到的真实性能。
 
@@ -104,7 +104,7 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
 >
 > -- Saurabh Dighe，Azure 战略规划与架构公司副总裁
 
-> _"理论峰值与真实推理吞吐量之间的差距往往取决于系统软件：推理引擎、分布式策略和底层内核。InferenceMAX 的价值在于它对最新软件进行基准测试，展示了 FP4、MTP、投机解码和 wide-EP 等优化在不同硬件上的实际表现。这样的开放、可复现结果有助于整个社区更快前进。"_
+> _"理论峰值与真实推理吞吐量之间的差距往往取决于系统软件：推理引擎、分布式策略和底层 kernel。InferenceMAX 的价值在于它对最新软件进行基准测试，展示了 FP4、MTP、投机解码和 wide-EP 等优化在不同硬件上的实际表现。这样的开放、可复现结果有助于整个社区更快前进。"_
 >
 > -- Tri Dao，Together AI 首席科学家、Flash Attention 发明者
 
@@ -120,7 +120,7 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
 >
 > -- Kaichao You，vLLM 项目联合负责人
 
-> _"InferenceMAX 展示了开放生态系统在实践中的运作方式。vLLM、SGLang 和 TensorRT-LLM 等许多领先的推理栈都构建在 PyTorch 之上，而这样的基准测试展示了内核、运行时和框架层面的创新如何转化为在包括 NVIDIA 和 AMD GPU 在内的各种硬件平台上的可量化性能。通过开源和每夜运行，InferenceMAX 为追踪进展和为 PyTorch 用户提供数据驱动的洞察提供了一种透明的、社区驱动的方法。"_
+> _"InferenceMAX 展示了开放生态系统在实践中的运作方式。vLLM、SGLang 和 TensorRT-LLM 等许多领先的推理栈都构建在 PyTorch 之上，而这样的基准测试展示了 kernel、运行时和框架层面的创新如何转化为在包括 NVIDIA 和 AMD GPU 在内的各种硬件平台上的可量化性能。通过开源和每夜运行，InferenceMAX 为追踪进展和为 PyTorch 用户提供数据驱动的洞察提供了一种透明的、社区驱动的方法。"_
 >
 > -- Matt White，PyTorch Foundation 执行总监
 
@@ -136,7 +136,7 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
 >
 > -- Roman Chernin，Nebius 联合创始人兼首席商务官
 
-> _"在 Crusoe，我们相信成为一个出色的合作伙伴意味着赋予客户选择权和清晰度。这就是我们自豪地支持 InferenceMAX 的原因——它为整个 AI 社区提供了针对最新硬件的开源、可复现的基准测试。通过提供关于吞吐量、效率和成本的透明、真实的数据，InferenceMAX 穿透了炒作，帮助客户自信地为其独特工作负载选择最佳平台。"_
+> _"在 Crusoe，我们相信成为一个出色的合作伙伴意味着赋予客户选择权和清晰度。这就是我们自豪地支持 InferenceMAX 的原因——它为整个 AI 社区提供了针对最新硬件的开源、可复现的基准测试。通过提供关于吞吐量、效率和成本的透明、真实的数据，InferenceMAX 拨开了炒作迷雾，帮助客户自信地为其独特工作负载选择最佳平台。"_
 >
 > -- Chase Lochmiller，Crusoe 联合创始人兼 CEO
 
@@ -144,7 +144,7 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
 >
 > -- Charles Liang，Supermicro 创始人兼 CEO
 
-> _"在 TensorWave，我们正在 AMD GPU 上构建下一代云，因为我们相信当客户拥有强有力的替代选择时，创新才会蓬勃发展。InferenceMAX 通过提供开源、可复现的基准测试来支持这一愿景，这些测试追踪最新硬件和软件上的吞吐量、效率和成本。通过穿透合成数字并凸显真实推理性能，它帮助客户看到 AMD 平台在大规模 AI 方面的全部潜力。"_
+> _"在 TensorWave，我们正在 AMD GPU 上构建下一代云，因为我们相信当客户拥有强有力的替代选择时，创新才会蓬勃发展。InferenceMAX 通过提供开源、可复现的基准测试来支持这一愿景，这些测试追踪最新硬件和软件上的吞吐量、效率和成本。通过剔除合成数字的干扰并凸显真实推理性能，它帮助客户看到 AMD 平台在大规模 AI 方面的全部潜力。"_
 >
 > -- Darrick Horton，TensorWave CEO
 
@@ -176,7 +176,7 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
   caption="来源：SemiAnalysis"
 />
 
-## InferenceMAX v1 基准测试方法论
+## InferenceMAX v1 基准测试方法
 
 提供反映不同 GPU、推理引擎和工作负载在多种交互性水平下全部可能性的基准测试，是 InferenceMAX 的核心目标。本节将介绍基准测试方法论如何被设计来实现这一目标。
 
@@ -205,13 +205,13 @@ InferenceMAX 项目得到了许多大型计算资源买家和 ML 社区知名成
 
 为了防止 [SGLang 与 vLLM 基准测试大战的重演](https://x.com/dylan522p/status/1920638653677596836)并节省计算时间，我们决定首先为每个模型只选择 vLLM 或 SGLang 中的一个作为默认引擎。早在 7 月份，我们就告知 AMD 和 Nvidia，我们将使用 SGLang 作为 DeepSeek 670B 的引擎，使用 vLLM 作为 Llama3 70B 和 Llama4 的引擎。后来我们用 GPT-OSS 120B 替换了 Llama4，因为没有人使用 Llama4，而 GPT-OSS 120B 更接近较小的 "mini" 前沿模型。
 
-我们希望服务器配置尽可能反映真实部署情况，因此要求 AMD 和 Nvidia 提交与其文档指南中讨论如何在其硬件上部署这些模型时相当接近的配置：
+我们希望服务器配置尽可能反映真实部署情况，因此要求 AMD 和 Nvidia 提交尽量贴近其官方文档中模型部署指南的配置：
 
 - [https://docs.nvidia.com/llm-inference-quick-start-recipes/index.html](https://docs.nvidia.com/llm-inference-quick-start-recipes/index.html)
 - [recipes.vllm.ai](https://docs.vllm.ai/projects/recipes/en/latest/)
 - [https://rocm.docs.amd.com/en/docs-7.0-docker/benchmark-docker/inference-vllm-gpt-oss-120b.html](https://rocm.docs.amd.com/en/docs-7.0-docker/benchmark-docker/inference-vllm-gpt-oss-120b.html)
 
-我们之前没有明确说明 InferenceMAX 是否允许预热（warmup），所以 Nvidia 在其 SGLang DeepSeek 提交中包含了一个预热阶段来处理某些 JIT 编译的内核。在基准测试开发接近尾声时，AMD 注意到了上述关于 Nvidia 提交的情况，并询问是否允许预热，因为他们没有意识到自己也可以这样做。经过 AMD、Nvidia 和 SemiAnalysis AI 工程团队之间的讨论，各方同意目前禁止预热，并将 DeepSeek 基准测试的时长延长最多 5 倍以确保公平。这次沟通混乱是我们的失误，因为从一开始就没有明确预热规则。我们计划在发布后重新审视这一议题，因为在真实生产推理中，预热通常在 Kubernetes 控制平面将 Pod 报告为健康之前发生。
+我们之前没有明确说明 InferenceMAX 是否允许预热（warmup），所以 Nvidia 在其 SGLang DeepSeek 提交中包含了一个预热阶段来处理某些 JIT 编译的 kernel。在基准测试开发接近尾声时，AMD 注意到了上述关于 Nvidia 提交的情况，并询问是否允许预热，因为他们没有意识到自己也可以这样做。经过 AMD、Nvidia 和 SemiAnalysis AI 工程团队之间的讨论，各方同意目前禁止预热，并将 DeepSeek 基准测试的时长延长最多 5 倍以确保公平。这次沟通混乱是我们的失误，因为从一开始就没有明确预热规则。我们计划在发布后重新审视这一议题，因为在真实生产推理中，预热通常在 Kubernetes 控制平面将 Pod 报告为健康之前发生。
 
 ## 讨论：DeepSeek R1 服务策略
 
@@ -266,7 +266,7 @@ InferenceMAX 使用 GitHub Actions 来编排基准测试运行。一个 GitHub A
 
 在解读吞吐量 vs 延迟/交互性图表时，请记住大多数实际应用运行在两个极端之间的某个位置。仅测量单一或有限吞吐量或交互性水平的基准测试结果有时可能具有误导性。
 
-例如，如果 GPU A 在给定交互性水平下——以面向人类的 AI 聊天机器人应用为例取 5 tokens/s/user——提供了 GPU B 4 倍的吞吐量，但这个交互性水平实际上太慢而不实用的事实意味着这种性能差异几乎没有真实的实际意义。相反——应该为给定应用选择一个现实的交互性水平。
+例如，如果 GPU A 在给定交互性水平下——以面向人类的 AI 聊天机器人应用为例，取 5 tokens/s/user——提供了 GPU B 4 倍的吞吐量，但这个交互性水平实际上太慢而不实用的事实意味着这种性能差异几乎没有真实的实际意义。相反——应该为给定应用选择一个现实的交互性水平。
 
 在本报告的后续部分，我们还将按 GPU 的总拥有成本（TCO）对吞吐量进行归一化。
 
@@ -274,7 +274,7 @@ InferenceMAX 使用 GitHub Actions 来编排基准测试运行。一个 GitHub A
 
 让我们逐步分析几个基准测试示例来解释如何分析结果。
 
-在我们的第一个结果中，H100 vLLM 与 MI300X ROCm 7.0 vLLM 在 Llama 3.3 70B FP8 推理场景（1k in/ 8k out）的对比显示了 MI300X 的强劲性能，尤其在低交互性水平（20 到 30 tok/s/user）下，这得益于 MI300X 在 TP1 运行时更好的内存带宽和内存容量优势。
+在我们的第一个结果中，H100 vLLM 与 MI300X ROCm 7.0 vLLM 在 Llama 3.3 70B FP8 推理（reasoning）场景（1k in/ 8k out）的对比显示了 MI300X 的强劲性能，尤其在低交互性水平（20 到 30 tok/s/user）下，这得益于 MI300X 在 TP1 运行时更好的内存带宽和内存容量优势。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/471369b0-e290-4560-a348-b3079c8b6e88_2329x1393.png"
@@ -303,7 +303,7 @@ InferenceMAX 使用 GitHub Actions 来编排基准测试运行。一个 GitHub A
   caption="来源：SemiAnalysis"
 />
 
-在 LLaMA 70B FP4 方面，B200 在所有三种工作负载类型上的吞吐量性能都大幅超越 MI355X。这表明 AMD 的 FP4 内核仍有改进空间。
+在 LLaMA 70B FP4 方面，B200 在所有三种工作负载类型上的吞吐量性能都大幅超越 MI355X。这表明 AMD 的 FP4 kernel 仍有改进空间。
 
 转到 B200（vLLM 和 TRT-LLM）vs. MI355X vLLM 运行 GPT-OSS 120B 的对比，我们可以看到 MI355X 在按 TCO 归一化后与 B200 vLLM 具有竞争力。在下一节中，我们将看到 MI355X 在某些交互性范围内的 TCO 性价比优于 Nvidia。吞吐量-延迟图表显示竞争更为激烈，MI355X 在给定 tok/s/gpu 吞吐量下比 B200 慢不超过约 15 秒。我们在现实中看到的 GPT-OSS 120B 最实用的交互性范围约为 150-200 tok/s/user。
 
@@ -454,23 +454,23 @@ SemiAnalysis GPU 云市场租赁价格报告基于对 70 多家 GPU 云和 100 
   caption="来源：SemiAnalysis"
 />
 
-## 每全额配置公用事业兆瓦估计 Token 吞吐量 vs 交互性（tok/s/user）
+## 每兆瓦全额配置市电的估计 Token 吞吐量 vs 交互性（tok/s/user）
 
 电力是 AI 基础设施的终极约束。每个数据中心都在有限的功率范围内运行，通常以兆瓦（MW）为单位衡量。这直接决定了给定数据中心可以产生多少有用计算——以及最终可以产生多少 token。
 
-推理经济不仅可以通过 GPU 性能（吞吐量/GPU vs TCO）的视角来分析，还可以通过每功率吞吐量来分析——以每全额配置公用事业 MW 的 token/s 来衡量。全额公用事业功率涵盖 GPU、CPU、网络设备、其他相关集群 IT 设备以及设施开销的功率需求。设施开销包括电力分配损耗以及用于冷却设备（如冷水机组、CDU 和冷却塔等）的功率消耗。每 MW 处理的 token 数越多，每单位能源的潜在收入和利润就越大。请注意，对于 InferenceMAX，我们使用的是全额配置公用事业 MW，它考虑了上述设施开销，而不是每全额关键 IT MW 的 token 数（后者不考虑设施开销）。这些指标在不同站点之间有所不同，但我们根据我们的 [AI TCO 模型](https://semianalysis.com/ai-cloud-tco-model/)和[数据中心模型](https://semianalysis.com/datacenter-industry-model/)选择了行业代表性数值。
+推理经济不仅可以通过 GPU 性能（吞吐量/GPU vs TCO）的视角来分析，还可以通过每功率吞吐量来分析——以每全额配置市电 MW 的 token/s 来衡量。全额市电功率涵盖 GPU、CPU、网络设备、其他相关集群 IT 设备以及设施开销的功率需求。设施开销包括电力分配损耗以及用于冷却设备（如冷水机组、CDU 和冷却塔等）的功率消耗。每 MW 处理的 token 数越多，每单位能源的潜在收入和利润就越大。请注意，对于 InferenceMAX，我们使用的是全额配置市电 MW，它考虑了上述设施开销，而不是每全额关键 IT MW 的 token 数（后者不考虑设施开销）。这些指标在不同站点之间有所不同，但我们根据我们的 [AI TCO 模型](https://semianalysis.com/ai-cloud-tco-model/)和[数据中心模型](https://semianalysis.com/datacenter-industry-model/)选择了行业代表性数值。
 
-请注意，托管租金和电力成本通常占总拥有成本的不到 20%。这意味着如果给定 GPU 与另一块 GPU 相比每 MW token 数低 20%，这仅会转化为不到 4% 的总拥有成本差异（即 20% \* 20% = 4%）。TCO 贡献的大头来自各 GPU 硬件供应商收取的毛利率。一些厂商收取高达 75% 的毛利率（即售出成本的 4 倍加价），而其他厂商低于 50% 的毛利率（即不到售出成本的 2 倍）。
+请注意，托管租金和电力成本通常占总拥有成本的不到 20%。这意味着如果给定 GPU 与另一块 GPU 相比每 MW token 数低 20%，这仅会转化为不到 4% 的总拥有成本差异（即 20% \* 20% = 4%）。TCO 贡献的大头来自各 GPU 硬件供应商收取的毛利率。一些厂商收取高达 75% 的毛利率（即销货成本的 4 倍加价），而其他厂商低于 50% 的毛利率（即不到销货成本的 2 倍）。
 
 我们使用速率单位——即 token/s per MW——而非累积的每 token 能量单位（如焦耳每 token）。这是因为数据中心容量以兆瓦（MW）为单位来规划，这是一个速率单位，等同于每秒 1 兆焦耳（MJ）。如果我们将速率单位在给定时间段内积分，就得到该时间段内消耗的绝对能量值。
 
 目前，我们通过加总数据中心中各组件的热设计功耗（TDP）来估算给定集群所需的 MW。TDP 与预期平均功率不同。举例说明：对于内存带宽受限的解码工作负载，系统功耗永远不会达到 TDP，而是会在较低的功率水平——即预期平均功率附近波动。未来，我们将通过 ipmitool 对每个系统（和网络设备）的实际功耗进行基准测试。届时我们将转向每 token 的累积能量单位。
 
-我们基于 InferenceMAX 原始结果结合来自我们 [AI 数据中心行业模型](https://semianalysis.com/datacenter-industry-model/)的 AI 集群全额公用事业功率数据来估算每配置功率的吞吐量。该模型通过跨供应商、架构和推理栈的功率归一化估算来量化全额公用事业功率。完整的估算和持续的每夜基准测试可在 [InferenceMAX.ai](https://inferencemax.semianalysis.com/) 上获取。
+我们基于 InferenceMAX 原始结果结合来自我们 [AI 数据中心行业模型](https://semianalysis.com/datacenter-industry-model/)的 AI 集群全额市电功率数据来估算每配置功率的吞吐量。该模型通过跨供应商、架构和推理栈的功率归一化估算来量化全额市电功率。完整的估算和持续的每夜基准测试可在 [InferenceMAX.ai](https://inferencemax.semianalysis.com/) 上获取。
 
 ## 每 MW 性能结果
 
-我们看到，对于 gpt-oss 120B 使用 MX4 weights 的推理场景（1K 输入 token / 8K 输出 token），在 90 tok/s/user 交互性水平下，MI300X 每全额配置公用事业 MW 可处理 750,000 token/s（再次强调，这是按公用事业 MW 衡量的，而非按关键 IT 功率 MW），而 MI355X 每全额配置公用事业 MW 可处理 2,550,000 token/s。这代表了从 CDNA3 代到 CDNA4 代约 3 倍的能效提升。
+我们看到，对于 gpt-oss 120B 使用 MX4 weights 的推理（reasoning）场景（1K 输入 token / 8K 输出 token），在 90 tok/s/user 交互性水平下，MI300X 每全额配置市电 MW 可处理 750,000 token/s（再次强调，这是按公用事业 MW 衡量的，而非按关键 IT 功率 MW），而 MI355X 每全额配置市电 MW 可处理 2,550,000 token/s。这代表了从 CDNA3 代到 CDNA4 代约 3 倍的能效提升。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/0aa98f63-d0f8-4666-85fd-47a1bbf78c7a_1645x1121.png"
@@ -491,14 +491,14 @@ SemiAnalysis GPU 云市场租赁价格报告基于对 70 多家 GPU 云和 100 
   caption="来源：SemiAnalysis"
 />
 
-在下一个基准测试中，我们以 30 tok/s/user 交互性水平来看 DeepSeek R1 的每功率 token 数。比较单节点 H200 FP8 与 GB200 NVL72 FP4（不含多 token 预测），GB200 NVL72 在每全额配置公用事业 MW 处理的 token/s 方面提供了约 8 倍的提升。请注意，H200 和 B200 的结果都来自单节点。我们将探索 B200 和 H200 通过在 SpectrumX 以及 InfiniBand 上实现分离式预填充和 wide 专家并行所能释放的更大每 MW token 吞吐量潜力。SGLang 的 [GB200 NVL72 分析](https://lmsys.org/blog/2025-09-25-gb200-part-2/)显示，8-GPU 系统确实可以通过实现 wide 专家并行获得强劲的性能提升。然而，SGLang 的博客也表明，即使 Hopper 同样实现了分离式预填充和 wide EP，GB200 NVL72 仍然胜出。
+在下一个基准测试中，我们以 30 tok/s/user 交互性水平来看 DeepSeek R1 的每功率 token 数。比较单节点 H200 FP8 与 GB200 NVL72 FP4（不含多 token 预测），GB200 NVL72 在每全额配置市电 MW 处理的 token/s 方面提供了约 8 倍的提升。请注意，H200 和 B200 的结果都来自单节点。我们将探索 B200 和 H200 通过在 SpectrumX 以及 InfiniBand 上实现分离式预填充和 wide 专家并行所能释放的更大每 MW token 吞吐量潜力。SGLang 的 [GB200 NVL72 分析](https://lmsys.org/blog/2025-09-25-gb200-part-2/)显示，8-GPU 系统确实可以通过实现 wide 专家并行获得强劲的性能提升。然而，SGLang 的博客也表明，即使 Hopper 同样实现了分离式预填充和 wide EP，GB200 NVL72 仍然胜出。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/e17e8c63-bc2a-4ce2-a9c9-0d00a586de3a_1566x1121.png"
   caption="来源：SemiAnalysis"
 />
 
-继续 DeepSeek 但转到 FP8，我们看到 GB200 在 tok/s/gpu vs tok/s/user 上也主导了所有单节点系统。我们注意到这里有一些细微差别——B200 和 MI355X 都在运行单节点 SGLang，尽管对于 DeepSeek 而言，vLLM 可能在 MI355X 上比 SGLang 能提供更好的结果。我们将探索为 MI355X 添加 DeepSeek vLLM 支持和/或为所有 8-GPU 服务器添加 SGLang 多节点 wideEP。此外，如前所述，Dynamo 团队目前只有时间实现足以在约 30 tok/s/user 附近实现并行帕累托前沿下移的优化。进一步的优化可以将帕累托前沿进一步推低，从而在更高交互性水平下提升 GB200 NVL72 FP8 的每功率吞吐量。
+继续 DeepSeek 但转到 FP8，我们看到 GB200 在 tok/s/gpu vs tok/s/user 上也主导了所有单节点系统。我们注意到这里有一些细微差别——B200 和 MI355X 都在运行单节点 SGLang，尽管对于 DeepSeek 而言，vLLM 可能在 MI355X 上比 SGLang 能提供更好的结果。我们将探索为 MI355X 添加 DeepSeek vLLM 支持和/或为所有 8-GPU 服务器添加 SGLang 多节点 wideEP。此外，如前所述，Dynamo 团队目前只来得及实现部分优化，使并行帕累托前沿下移到约 30 tok/s/user 附近。进一步的优化可以将帕累托前沿进一步推低，从而在更高交互性水平下提升 GB200 NVL72 FP8 的每功率吞吐量。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/129e616b-82d6-413b-ae0c-e28f07b27d84_1661x1121.png"
@@ -516,9 +516,9 @@ SemiAnalysis GPU 云市场租赁价格报告基于对 70 多家 GPU 云和 100 
   caption="来源：SemiAnalysis"
 />
 
-在阅读了 vLLM 的 NCCL 绑定代码后，我们并不认为 FFI 绑定是问题的根本原因。运行 nvidia-smi 时，我们看到 GPU_UTIL 不是 100% 而是 0%——表明没有内核在 GPU 上运行，由此我们得出结论这不是设备端的 NCCL 死锁。
+在阅读了 vLLM 的 NCCL 绑定代码后，我们并不认为 FFI 绑定是问题的根本原因。运行 nvidia-smi 时，我们看到 GPU_UTIL 不是 100% 而是 0%——表明没有 kernel 在 GPU 上运行，由此我们得出结论这不是设备端的 NCCL 死锁。
 
-接下来，我们使用 Linux [perf](https://perfwiki.github.io/main/) top 分析器查看 Python 层之下，试图更深入地了解具体是哪个共享库触发了这个问题。我们注意到该进程（及子进程）的大部分 CPU 周期都花在 "libnvidia-ptxjitcompiler.so" 上。查阅 "libnvidia-ptxjitcompiler" 文档后，我们找到了这样的描述：_"PTX JIT Compiler 库（/usr/lib/libnvidia-ptxjitcompiler.so.575.57.08）是一个 JIT 编译器，将 PTX 编译为 GPU 机器码，由 CUDA 驱动使用"_。这非常奇怪，因为我们不确定为什么初始化时要调用 PTX 编译器——通常所有 NCCL 内核都是在构建时预编译好的，不应该有需要即时编译的内核。
+接下来，我们使用 Linux [perf](https://perfwiki.github.io/main/) top 分析器查看 Python 层之下，试图更深入地了解具体是哪个共享库触发了这个问题。我们注意到该进程（及子进程）的大部分 CPU 周期都花在 "libnvidia-ptxjitcompiler.so" 上。查阅 "libnvidia-ptxjitcompiler" 文档后，我们找到了这样的描述：_"PTX JIT Compiler 库（/usr/lib/libnvidia-ptxjitcompiler.so.575.57.08）是一个 JIT 编译器，将 PTX 编译为 GPU 机器码，由 CUDA 驱动使用"_。这非常奇怪，因为我们不确定为什么初始化时要调用 PTX 编译器——通常所有 NCCL kernel 都是在构建时预编译好的，不应该有需要即时编译的 kernel。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/a8a1c7d6-51e3-4b5f-85ea-41568792ac21_1937x1121.png"
@@ -541,7 +541,7 @@ SemiAnalysis GPU 云市场租赁价格报告基于对 70 多家 GPU 云和 100 
   caption="来源：SemiAnalysis"
 />
 
-我们遇到的另一个 Blackwell 问题是 vLLM/SGLang 的子依赖 Flashinfer 存在文件锁竞态条件（race condition）。出于某种原因，Nvidia 决定不将编译好的内核打包到容器镜像中，而是在服务器启动时下载它们。由于我们每个节点最多有 8 个进程（每个 GPU 1 个进程），如果代码不是进程安全的，我们在下载这些编译内核时就会遇到竞态条件。
+我们遇到的另一个 Blackwell 问题是 vLLM/SGLang 的子依赖 Flashinfer 存在文件锁竞态条件（race condition）。出于某种原因，Nvidia 决定不将编译好的 kernel 打包到容器镜像中，而是在服务器启动时下载它们。由于我们每个节点最多有 8 个进程（每个 GPU 1 个进程），如果代码不是进程安全的，我们在下载这些编译 kernel 时就会遇到竞态条件。
 
 实际上，这个竞态条件是由于[一次旨在防止竞态条件的尝试](https://github.com/flashinfer-ai/flashinfer/pull/1779)而引入的！Flashinfer 没有依赖内置 FileLock Python 包的锁清理，而是手动清理锁，这反而导致了竞态条件。[这已在 Flashinfer 中修补](https://github.com/flashinfer-ai/flashinfer/pull/1779)，但尚未上游到 vLLM/SGLang Blackwell 发布容器镜像。非常感谢 Flashinfer 团队和 Kedar Potar 迅速介入，在与团队对接后仅 4 小时内就完成了调试和修补。
 
@@ -571,7 +571,7 @@ GitHub Actions 的[自托管 runner](https://docs.github.com/en/actions/how-tos/
 
 每个基准测试变体作为一个单独的 job 运行。对于每个模型，我们对以下不同组合进行基准测试：不同的 GPU、输入/输出序列长度、精度、张量并行度和并发数。这在添加更多配置时导致每个 workflow 的 job 数量产生[组合爆炸](https://en.wikipedia.org/wiki/Combinatorial_explosion)。
 
-具体来说：InferenceMAX 目前在最多 7 种 GPU 类型上对 3 个模型进行基准测试，涵盖 3 种不同的 ISL/OSL 对、2 种精度设置，以及大约 4 种并发数和张量并行选项。并非每个模型都使用所有可能的配置，但这个最坏情况估算给出 3 _ 7 _ 3 _ 2 _ 4 \* 4 = 2016 个不同的 job。在这种规模下，GitHub Actions 工作流可视化遇到了限制：服务器在尝试渲染 DAG 时在十秒后超时，导致[错误消息](https://github.com/503.html)。这使得调试运行变得极其困难。我们的解决方法是将单个每夜 workflow 拆分为三个，按 ISL/OSL 对分拆。这将每个 workflow 的 job 数从大约 1500 减少到 500，服务器似乎可以可靠地处理。
+具体来说：InferenceMAX 目前在最多 7 种 GPU 类型上对 3 个模型进行基准测试，涵盖 3 种不同的 ISL/OSL 对、2 种精度设置，以及大约 4 种并发数和张量并行选项。并非每个模型都使用所有可能的配置，但这个最坏情况估算给出 3 \* 7 \* 3 \* 2 \* 4 \* 4 = 2016 个不同的 job。在这种规模下，GitHub Actions 工作流可视化遇到了限制：服务器在尝试渲染 DAG 时在十秒后超时，导致[错误消息](https://github.com/503.html)。这使得调试运行变得极其困难。我们的解决方法是将单个每夜 workflow 拆分为三个，按 ISL/OSL 对分拆。这将每个 workflow 的 job 数从大约 1500 减少到 500，服务器似乎可以可靠地处理。
 
 另一个 Bug 涉及使用 [download-artifacts@v5](https://github.com/actions/download-artifact) action 时的硬限制。在每次完整扫描 workflow 结束时，会运行一个 job 来收集和汇总所有 job 的性能结果，这些结果作为 workflow 的 artifact 存储。作为收集过程的一部分，会调用 download-artifacts@v5 action。它初始化一个 [artifact client](https://github.com/actions/toolkit/blob/main/packages/artifact/src/internal/client.ts)，该 client 反过来调用一个 [list artifacts 函数](https://github.com/actions/toolkit/blob/main/packages/artifact/src/internal/find/list-artifacts.ts)（需要列出所有 artifact 然后通过模式匹配找到请求的那个），该函数出于"性能原因"强制执行了 1000 的硬限制。据称当 client 尝试列出超过 1000 个 artifact 时应该会打印一个警告，但我们从未观察到这种行为。
 
diff --git a/packages/app/content/blog/zh/inferencex-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx b/packages/app/content/blog/zh/inferencex-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx
index 93630c370..d7c623e4e 100644
--- a/packages/app/content/blog/zh/inferencex-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx
+++ b/packages/app/content/blog/zh/inferencex-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx
@@ -136,7 +136,7 @@ MI300X 和 MI325X 有了一些改进，主要来自最新的 SGLang 版本。请
   caption="来源：SemiAnalysis InferenceX"
 />
 
-GB200 Dynamo TRT-LLM disagg 也有了显著改进，最大吞吐量在一个多月内提升了 20%。我们还看到中等交互性水平的改进，这部分采用了宽 EP。这可能归因于 GB200 上日趋成熟的宽 EP 内核。
+GB200 Dynamo TRT-LLM disagg 也有了显著改进，最大吞吐量在一个多月内提升了 20%。我们还看到中等交互性水平的改进，这部分采用了宽 EP。这可能归因于 GB200 上日趋成熟的宽 EP kernel。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/db4fa8dc-176c-4224-9ab5-6ebfe8f6af9c_1493x1280.png"
@@ -167,7 +167,7 @@ B200 SGLang 自我们去年 10 月首次发布以来，FP4 和 FP8 场景均呈
 />
 
 就 MI325X 而言，下游 ROCm 分支镜像（2025 年 10 月 5 日运行时使用）中存在的性能优化似乎并非全部都已合入官方 vLLM ROCm 镜像。
-遗憾的是，MI355X 目前仍在使用 vLLM 0.10.1 版本的分支构建 `rocm/7.0:rocm7.0_ubuntu_22.04_vllm_0.10.1_instinct_20250927_rc1`。我们本希望现在已经更新了，但不幸的是，当前的官方镜像（撰写本文时为 0.15.1）尚未针对 MI355X 进行优化，并且会遇到硬错误。我们在 MI355X 上运行 vLLM 0.14 时也曾遇到硬错误崩溃。业界消息是 vLLM 0.16.0 将最终提供 MI355X 所需的全部改进。
+遗憾的是，MI355X 目前仍在使用 vLLM 0.10.1 版本的分支构建 `rocm/7.0:rocm7.0_ubuntu_22.04_vllm_0.10.1_instinct_20250927_rc1`。我们本希望现在已经更新了，但不幸的是，当前的官方镜像（撰写本文时为 0.15.1）尚未针对 MI355X 进行优化，并且会遇到硬错误。我们在 MI355X 上运行 vLLM 0.14 时也曾遇到硬错误崩溃。业界消息是 vLLM 0.16.0 最终将提供 MI355X 所需的全部改进。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/1755b498-ab4d-4c02-b6fd-152ee538a34d_2126x1788.png"
@@ -188,7 +188,7 @@ B200 SGLang 自我们去年 10 月首次发布以来，FP4 和 FP8 场景均呈
 
 ## 分离式推理框架
 
-NVIDIA 使用 Dynamo 作为其分离式推理方案。[Dynamo](https://docs.nvidia.com/dynamo/design-docs/overall-architecture) 是一个专为多节点分布式推理设计的推理框架，具备预填充-解码分离、请求路由和 KV 缓存 offload 等技术。它与推理引擎无关，允许我们在基准测试中使用 SGLang 和 TRT-LLM 作为后端。对于 AMD，我们使用 SGLang 配合两种不同的 KV 缓存传输框架：MoRI 和 Mooncake。[MoRI](https://github.com/rocm/mori) 是一个高性能通信接口，专注于 RDMA 和 GPU 集成，提供网络集合操作和专家并行内核等应用。Mooncake [最近加入了 PyTorch 生态系统](https://pytorch.org/blog/mooncake-joins-pytorch-ecosystem/)，支持预填充-解码分离以及多种容错多节点功能。
+NVIDIA 使用 Dynamo 作为其分离式推理方案。[Dynamo](https://docs.nvidia.com/dynamo/design-docs/overall-architecture) 是一个专为多节点分布式推理设计的推理框架，具备预填充-解码分离、请求路由和 KV 缓存 offload 等技术。它与推理引擎无关，允许我们在基准测试中使用 SGLang 和 TRT-LLM 作为后端。对于 AMD，我们使用 SGLang 配合两种不同的 KV 缓存传输框架：MoRI 和 Mooncake。[MoRI](https://github.com/rocm/mori) 是一个高性能通信接口，专注于 RDMA 和 GPU 集成，提供网络集合操作和专家并行 kernel 等应用。Mooncake [最近加入了 PyTorch 生态系统](https://pytorch.org/blog/mooncake-joins-pytorch-ecosystem/)，支持预填充-解码分离以及多种容错多节点功能。
 
 ## DeepSeek Disagg + WideEP 结果深入分析
 
@@ -199,14 +199,14 @@ NVIDIA 使用 Dynamo 作为其分离式推理方案。[Dynamo](https://docs.nvid
   caption="来源：SemiAnalysis InferenceX"
 />
 
-NVIDIA 持续为 B200/GB200 FP8 推送新更新。最新数据展示了 DeepSeek FP8 B200 TRT 单节点（MTP 启用/禁用）vs GB200 Dynamo+TRT disagg（MTP 启用/禁用）的对比。这表明在改进机架规模推理软件和 wideEP 内核方面持续投入了工程力量。
+NVIDIA 持续为 B200/GB200 FP8 推送新更新。最新数据展示了 DeepSeek FP8 B200 TRT 单节点（MTP 启用/禁用）vs GB200 Dynamo+TRT disagg（MTP 启用/禁用）的对比。这表明在改进机架规模推理软件和 wideEP kernel 方面持续投入了工程力量。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/29485790-238d-4e1d-aa48-0559c79c9855_2132x1247.png"
   caption="来源：SemiAnalysis InferenceX"
 />
 
-在比较 MI355X 分离式推理与聚合推理时，我们注意到了类似的模式。分离式推理仅在低交互性、高批次的情况下超过聚合推理。这在 FP4 下尤为明显，可能源于优化不够充分的内核。
+在比较 MI355X 分离式推理与聚合推理时，我们注意到了类似的模式。分离式推理仅在低交互性、高批次的情况下超过聚合推理。这在 FP4 下尤为明显，可能源于优化不够充分的 kernel。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/25a7c41e-fa99-4117-8e49-ac121a22bf0f_2092x1241.png"
@@ -215,7 +215,7 @@ NVIDIA 持续为 B200/GB200 FP8 推送新更新。最新数据展示了 DeepSeek
 
 在 MI355X 上将 disagg 预填充+wideEP 与 FP4 组合使用时，我们观察到性能表现不佳。
 
-虽然理论建模显示 MI355X 上的 disagg 推理应该远优于单节点，但由于 ROCm 软件栈在组合多种 SOTA 推理优化时缺乏内核和集合通信优化，disagg 在较高交互性水平下的实际表现反而更差。
+虽然理论建模显示 MI355X 上的 disagg 推理应该远优于单节点，但由于 ROCm 软件栈在组合多种 SOTA 推理优化时缺乏 kernel 和集合通信优化，disagg 在较高交互性水平下的实际表现反而更差。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/2d82d32f-089b-405d-b4ef-94b4956676ed_2078x1233.png"
@@ -236,7 +236,7 @@ TensorRT-LLM 已在全球范围内为 TogetherAI 等服务商每小时处理数
   caption="来源：SemiAnalysis InferenceX"
 />
 
-NVL72 系列更大世界规模带来的优势也体现在成本图表上。在固定 60 tok/s/user 交互性水平下，每块 GB200 NVL GPU 产出的 token/s 略低于 B200 的三倍。
+NVL72 系列更大的并行域（world size）带来的优势也体现在成本图表上。在固定 60 tok/s/user 交互性水平下，每块 GB200 NVL GPU 产出的 token/s 略低于 B200 的三倍。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/36087d46-94e1-4629-90cb-4b0dfad1a8c1_1856x827.png"
@@ -338,7 +338,7 @@ NVL72 系列更大世界规模带来的优势也体现在成本图表上。在
   caption="来源：SemiAnalysis InferenceX"
 />
 
-让我们利用上述发现深入分析大规模 LLM 服务的单元经济学。从上面的 OpenRouter 数据可以看到，Crusoe 以 36 tok/sec/user 的交互性提供服务，输入 token 价格为 $1.35/M，输出 token 价格为 $5.40/M。如果我们假设没有缓存命中，并且 Crusoe 至少使用了配备 MTP、disagg 和宽 EP 等 SOTA 推理技术的 H200，上述数据表明他们的成本*不超过* $0.226/M 输入 token 和 $2.955/M 输出 token，输入 token 的利润率高达 83% 毛利率（折旧计入销售成本），输出 token 的毛利率为 45%。
+让我们利用上述发现深入分析大规模 LLM 服务的单元经济学。从上面的 OpenRouter 数据可以看到，Crusoe 以 36 tok/sec/user 的交互性提供服务，输入 token 价格为 $1.35/M，输出 token 价格为 $5.40/M。如果我们假设没有缓存命中，并且 Crusoe 至少使用了配备 MTP、disagg 和宽 EP 等 SOTA 推理技术的 H200，上述数据表明他们的成本*不超过* $0.226/M 输入 token 和 $2.955/M 输出 token，输入 token 的毛利率高达 83%（折旧计入销售成本），输出 token 的毛利率为 45%。
 
 当然，这些假设可能不*完全*正确，且这些计算没有考虑停机时间或利用率不足的情况，但这展示了使用 InferenceX 数据可以进行的一些有趣分析。更多关于推理经济学的分析可以在 [SemiAnalysis Tokenomics Model](https://semianalysis.com/tokenomics-model/) 中找到。
 
@@ -390,7 +390,7 @@ TP 将每一层的权重矩阵分片到各 GPU 上。这意味着每一层的每
 
 在更高并发度下，这种权衡发生变化。较大的批次使专家激活分布更加均匀，EP 的通信和权重加载优势开始主导 TP 昂贵的逐层 all-reduce。在曲线中段，混合 TP+EP 配置在两方面取得平衡——在每个专家内使用小规模 TP 组实现负载均衡，同时在更大范围的 GPU 上使用 EP 来分摊权重并减少通信。
 
-对于更高的交互性水平（小批次），大规模扩展世界往往不能带来更强的性能。B300 通过 IB 的 disagg 与 GB300 NVL72 的性能相同，因为工作负载受延迟限制而非带宽限制。NVL72 巨大的 NVLink 带宽优势并不重要，因为即使是慢得多的 IB 链路也不会被微小的 token 批次流量所饱和。
+对于更高的交互性水平（小批次），较大的 scale-up 域往往不能带来更强的性能。B300 通过 IB 的 disagg 与 GB300 NVL72 的性能相同，因为工作负载受延迟限制而非带宽限制。NVL72 巨大的 NVLink 带宽优势并不重要，因为即使是慢得多的 IB 链路也不会被微小的 token 批次流量所饱和。
 
 预填充/解码分离也发挥了重要作用。预填充是计算密集且突发的；解码是内存带宽受限且稳态的。当它们共享同一 GPU 时，会相互干扰，导致延迟抖动和容量浪费。将它们分离到专用 GPU 池，使每个阶段运行与其特性匹配的工作负载，从而提高有效利用率。这就是为什么分离式 B200 配置在吞吐量-交互性曲线中段优于单节点 B200。PD 分离结合跨更多 GPU 通过 IB 的更宽 EP 能比将两个阶段塞入单个 8-GPU 节点更高效地分摊权重。
 
@@ -410,7 +410,7 @@ TP 将每一层的权重矩阵分片到各 GPU 上。这意味着每一层的每
   caption="来源：Nvidia GTC 2024"
 />
 
-但事实证明，笑话在他们自己身上。快进将近两年后，我们现在可以看到这并非营销炒作，Jensen 实际上一直在低调承诺 Blackwell 的性能。根据我们的测试，相比强劲的 H100 disagg+wideEP FP8 基线，Blackwell 在大规模 MoE 推理上表现出色，在 116 toks/s/user 下，GB200 NVL72 FP4 达到了高达 98x 的性能提升，GB300 NVL72 FP4 更是达到了高达 100x！也许新的 Jensen 数学法则就是：在 token 吞吐量方面，他兑现的是承诺值的两倍。买得越多，省得越多！
+但事实证明，可笑的反而是他们自己。快进将近两年后，我们现在可以看到这并非营销炒作，Jensen 实际上一直在低调承诺 Blackwell 的性能。根据我们的测试，相比强劲的 H100 disagg+wideEP FP8 基线，Blackwell 在大规模 MoE 推理上表现出色，在 116 toks/s/user 下，GB200 NVL72 FP4 达到了高达 98x 的性能提升，GB300 NVL72 FP4 更是达到了高达 100x！也许新的 Jensen 数学法则就是：在 token 吞吐量方面，他兑现的是承诺值的两倍。买得越多，省得越多！
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/70638c7e-69a6-43f2-96a4-23766bcabbd2_2121x1248.png"
@@ -482,7 +482,7 @@ TP 将每一层的权重矩阵分片到各 GPU 上。这意味着每一层的每
 
 虽然 AMD 在单节点 FP4 上表现尚可，在 FP8 分布式推理上与 B200 SGLang 具有竞争力，但当前 AMD 开源推理栈的问题在于：虽然各个推理优化单独表现良好，但实际客户部署时会将多种优化组合使用。顶级 AI 实验室都同时启用 FP4 **配合**分离式推理**配合**宽专家并行，问题正出在这里。
 
-AMD 软件仍未达标，SemiAnalysis 和 AMD 内部的理论极限建模都表明，对于 FP4，分离式推理配合宽专家并行应该优于 MI355X 单节点推理。遗憾的是，软件仍然是 AMD GPU 的巨大瓶颈。AMD 管理层需要继续优化工程人才的资源配置——例如，将工程资源从无人使用的单节点宠物项目（如 ATOM）转移到修复上述推理优化可组合性问题上。当前不佳的软件表现源于缺乏聚焦和优先级设置不当。所有顶级实验室已在使用分离式推理和宽专家并行；AMD 需要停止专注于单节点，大力投入多节点推理的开源方案。
+AMD 软件仍未达标，SemiAnalysis 和 AMD 内部的理论极限建模都表明，对于 FP4，分离式推理配合宽专家并行应该优于 MI355X 单节点推理。遗憾的是，软件仍然是 AMD GPU 的巨大瓶颈。AMD 管理层需要继续优化工程人才的资源配置——例如，将工程资源从无人使用、却备受偏爱的单节点项目（如 ATOM）转移到修复上述推理优化可组合性问题上。当前不佳的软件表现源于缺乏聚焦和优先级设置不当。所有顶级实验室已在使用分离式推理和宽专家并行；AMD 需要停止专注于单节点，大力投入多节点推理的开源方案。
 
 AMD 在开源分布式推理、宽专家并行和 FP4 可组合性方面落后超过六个月，[NVIDIA 和 SGLang 团队六个月前就已展示了他们在 DeepSeek 上的 NVFP4 性能。](https://lmsys.org/blog/2025-09-25-gb200-part-2/)
 
@@ -493,20 +493,20 @@ AMD 在开源分布式推理、宽专家并行和 FP4 可组合性方面落后
 
 ## AMD ATOM 引擎
 
-AMD 推出了名为 ATOM 的新推理引擎。ATOM 能提供略好的单节点性能，但在许多关键功能上完全缺失，导致无法用于真实工作负载。例如，它不支持 NVMe 或 CPU KV cache offload、工具解析、宽专家并行或分离式服务。这导致生产环境中没有任何客户使用它。与 NVIDIA 的 TRTLLM 不同——后者在 TogetherAI 等公司全球范围内每小时生成数十亿 token，[并且支持工具解析和其他功能](https://nvidia.github.io/TensorRT-LLM/commands/trtllm-serve/trtllm-serve.html#cmdoption-trtllm-serve-serve-tool_parser)——由于上述功能缺失，目前没有任何 token 工厂在使用 ATOM。
+AMD 推出了名为 ATOM 的新推理引擎。ATOM 能提供略好的单节点性能，但在许多关键功能上完全缺失，导致无法用于真实工作负载。例如，它不支持 NVMe 或 CPU KV cache offload、工具解析、宽专家并行或分离式服务。这导致生产环境中没有任何客户使用它。与 NVIDIA 的 TRTLLM 不同——后者在全球范围内为 TogetherAI 等公司每小时生成数十亿 token，[并且支持工具解析和其他功能](https://nvidia.github.io/TensorRT-LLM/commands/trtllm-serve/trtllm-serve.html#cmdoption-trtllm-serve-serve-tool_parser)——由于上述功能缺失，目前没有任何 token 工厂在使用 ATOM。
 
 此外，vLLM 等开源推理引擎的维护者对 AMD 感到失望，原因是 AMD 提供的工程和 GPU 资源不足。例如，vLLM 首席维护者 Simon Mo 在 GitHub RFC 中表示，他仍然没有可用的 MI355X 来添加到 vLLM CI 中，因此用户体验不佳。vLLM 上目前没有任何 MI355X 测试，而 NVIDIA 的 B200 在 vLLM 上有大量测试。同样，vLLM 上的 MI300X CI 机器数量仍然不够。上游 vLLM 至少还需要 20 台 MI300 机器、20 台 MI325 机器和 20 台 MI355X 机器才能达到与 CUDA 相同的可用性水平。
 
 在 SemiAnalysis，我们一直在推动 AMD 为 vLLM 贡献更多计算资源，并在最近几周取得了一些成果。vLLM 将开始获得几台 MI355X 机器，使其 CI 测试覆盖率从 0% 提升到非零水平。我们将在即将发布的"AMD 现状"文章中详细讨论 AMD 此前对 vLLM、SGLang、PyTorch CI 机器贡献不足的情况，以及 Anush 如何开始着手解决这一问题。在 SemiAnalysis，我们将建立内部仪表板来跟踪 AMD 和 NVIDIA 在 vLLM、SGLang、PyTorch 和 JAX 上运行的测试数量和质量。
 
-此外，vLLM 维护者表示，由于机器资源不足，他们无法为 ROCm 提供首日 vLLM 支持。这一巨大的上市时间差距导致 ROCm 持续落后，给 NVIDIA 留下了继续收取高达 75% 毛利率（4 倍成本加价）的巨大空间。
+此外，vLLM 维护者表示，由于机器资源不足，他们无法为 ROCm 提供首日 vLLM 支持。这一巨大的上市时间差距导致 ROCm 持续落后，给 NVIDIA 留下了继续维持高达 75% 的毛利率（4 倍成本加价）的巨大空间。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/96fd0617-347d-49a1-a971-19e42faeab25_1435x1289.png"
   caption="来源：Github"
 />
 
-最后，AMD 没有足够的提交者"通过功能引导和代码所有权展示持续的上游参与"，并且缺乏能审核自身代码的审稿人。这就是为什么 ROCm vLLM 的开发速度远慢于 CUDA vLLM。
+最后，AMD 没有足够的提交者"通过主导功能推进和代码所有权展示持续的上游参与"，并且缺乏能审核自身代码的审稿人。这就是为什么 ROCm vLLM 的开发速度远慢于 CUDA vLLM。
 
 AMD 有许多才华横溢的优秀工程师在 ATOM 上工作，我们鼓励 AMD 管理层考虑将这些优秀工程师重新部署到人们实际使用的库和框架上，如 vLLM 和 SGLang。
 
@@ -558,7 +558,7 @@ AMD 有许多才华横溢的优秀工程师在 ATOM 上工作，我们鼓励 AMD
   caption="来源：SemiAnalysis InferenceX"
 />
 
-关于 MTP 性能数据的有效性，有人可能会认为合成数据集的分布不能代表真实数据。然而，比较 MTBench 和我们的 1k1k 基准测试之间的 MTP 接受行为，我们发现分布非常相似，这证实了我们的 InferenceX 基准测试是真实世界生产性能的良好代理。话虽如此，InferenceX 并非完美，我们始终在寻求改进。如果您想加入我们的使命，[请在此申请加入我们的特别项目团队](https://app.dover.com/apply/semianalysis/2a9c8da5-6d59-4ac8-8302-3877345dbce1)。
+关于 MTP 性能数据的有效性，有人可能会认为合成数据集的分布不能代表真实数据。然而，对比 MTBench 与我们的 1k1k 基准测试的 MTP 接受行为，我们发现分布非常相似，这证实了我们的 InferenceX 基准测试是真实世界生产性能的良好代理。话虽如此，InferenceX 并非完美，我们始终在寻求改进。如果您想加入我们的使命，[请在此申请加入我们的特别项目团队](https://app.dover.com/apply/semianalysis/2a9c8da5-6d59-4ac8-8302-3877345dbce1)。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/6c4a7c01-3d56-486d-b959-cb4b6468f56f_2408x1390.png"
@@ -567,7 +567,7 @@ AMD 有许多才华横溢的优秀工程师在 ATOM 上工作，我们鼓励 AMD
 
 ## 精度评估
 
-吞吐量优化有时会悄然牺牲精度（例如通过过于激进的接受率放松、解码调整、数值不稳定的内核或端点配置错误）。如果没有评估，一个配置错误的服务器（截断、错误的解码、错误的端点参数）仍然可以产生很好的吞吐量数字，但输出的答案却是垃圾。例如，这一额外的检查层帮助我们发现了 GPT-OSS 的某些 DP 注意力实现的问题。
+吞吐量优化有时会悄然牺牲精度（例如通过过于激进的接受率放松、解码调整、数值不稳定的 kernel 或端点配置错误）。如果没有评估，一个配置错误的服务器（截断、错误的解码、错误的端点参数）仍然可以产生很好的吞吐量数字，但输出的答案却是垃圾。例如，这一额外的检查层帮助我们发现了 GPT-OSS 的某些 DP 注意力实现的问题。
 
 现在，每个代表性吞吐量配置都附带了数值精度检查。目前我们仅使用 GSM8k，但由于这是一个非常简单的基准测试，评估分数可能不会因数值计算差异而有太大变化，更难的基准测试可能会在数值精度方面产生更大的差异。因此，我们计划在未来扩展到更难的测试，如 GPQA、HLE、MATH-500、SWE-Bench verified。
 
@@ -582,7 +582,7 @@ AMD 有许多才华横溢的优秀工程师在 ATOM 上工作，我们鼓励 AMD
 
 Anthropic 最近伴随 Opus 4.6 发布了"[fast mode](https://code.claude.com/docs/en/fast-mode)"。其价值主张是：相同的模型质量，约 2.5 倍的速度提升，约 6-12 倍的价格。这两个数字可能都令人意外，一些用户推测[这一定需要新硬件](https://x.com/Yuchenj_UW/status/2020214926133063705)。实际上并不需要。这本质上就是那个根本性权衡在起作用。任何模型都可以在广泛的交互性水平（每用户 token/s）范围内提供服务，每百万 token 的成本（CPMT）会相应变化。用我们的类比来说，梅赛德斯既造公交车也造跑车。
 
-精打细算的人可能认为 fast mode 更贵，但如果从总拥有成本的角度来看，fast mode 在某些情况下实际上要便宜得多。例如，一个 GB200 NVL72 机架可以花费 330 万美元，因此，如果 Claude Code 的智能体循环（在生产中运行在 Trainium 上）通过工具调用使用 NVL72 机架，而这些机架的推理速度慢了 2.5x，您就需要 2.5x 更多的机架来提供推理服务，这意味着不启用 fast mode 将额外花费近 500 万美元。
+精打细算的人可能认为 fast mode 更贵，但如果从总拥有成本的角度来看，fast mode 在某些情况下实际上要便宜得多。例如，一台 GB200 NVL72 机架的成本可达 330 万美元，因此，如果 Claude Code 的智能体循环（在生产中运行在 Trainium 上）通过工具调用使用 NVL72 机架，而这些机架的推理速度慢了 2.5x，您就需要 2.5x 更多的机架来提供推理服务，这意味着不启用 fast mode 将额外花费近 500 万美元。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/cad37655-7b9a-4c86-81a8-3314ad0526fe_1694x348.png"
@@ -776,7 +776,7 @@ Anthropic 最近伴随 Opus 4.6 发布了"[fast mode](https://code.claude.com/do
 
 MI300X、MI325X、H200 和 H100 集中在吞吐量 vs 交互性图的左下方，表明它们之间的权衡大致相似，NVIDIA 通常保持适度领先。下一个层级是 MI355X，在给定交互性水平下每 GPU 的 token 吞吐量大约提升 2 倍以上。在 MI355X 中，ATOM 将曲线向低交互性高吞吐量方向移动，表明它优先考虑峰值吞吐量而非每用户响应速度。
 
-在这一层级之上是 NVIDIA 的 B200 和 GB200，它们在整个前沿线上都优于 MI355X。虽然 B200 和 GB200 共享相同的 Blackwell 计算核心，但 GB200 实现了更高的吞吐量-交互性曲线，因为该平台和服务栈减少了大规模部署中的非计算瓶颈（互连/拓扑、CPU-GPU 耦合和运行时调度），从而实现了有效的横向扩展和更低的每 token 开销。
+在这一层级之上是 NVIDIA 的 B200 和 GB200，它们在整个前沿线上都优于 MI355X。虽然 B200 和 GB200 共享相同的 Blackwell 计算 die，但 GB200 实现了更高的吞吐量-交互性曲线，因为该平台和服务栈减少了大规模部署中的非计算瓶颈（互连/拓扑、CPU-GPU 耦合和运行时调度），从而实现了有效的横向扩展和更低的每 token 开销。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/478b3a9a-c57d-4766-bde1-c3ee1fef550a_2068x1178.png"
@@ -790,7 +790,7 @@ MI300X、MI325X、H200 和 H100 集中在吞吐量 vs 交互性图的左下方
   caption="来源：SemiAnalysis InferenceX"
 />
 
-再次回到 B200 与 GB200 NVL72 的比较，NVL72 的影响显而易见。我们在本文前面讨论了 GB200 NVL72 的 72 GPU 扩展世界规模与 B200 的 8 GPU 扩展世界规模的影响。在约 100 tok/s/user 的交互性范围内，每 GPU 的输出 token 吞吐量翻了一倍以上，展示了 NVL72 更大扩展域的影响。
+再次回到 B200 与 GB200 NVL72 的比较，NVL72 的影响显而易见。我们在本文前面讨论了 GB200 NVL72 的 72 GPU scale-up 域与 B200 的 8 GPU scale-up 域的影响。在约 100 tok/s/user 的交互性范围内，每 GPU 的输出 token 吞吐量翻了一倍以上，展示了 NVL72 更大 scale-up 域的影响。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/0186cfbc-1b42-46ae-ae1a-0d7791afcb20_2081x1306.png"
@@ -815,7 +815,7 @@ MI300X、MI325X、H200 和 H100 集中在吞吐量 vs 交互性图的左下方
 
 在 InferenceX v1 发布后不久，我们意识到不充分利用 AI 会让多少开发吞吐量白白浪费。因此，我们卷起袖子决定拥抱 Claude Code，开始一次一个 token 地吸收智能，达到了目前每天 $6,000 的消费速率。如果您想为我们年化吸收 300 万美元 Claude 智能的 KPI 做贡献，[请在此申请加入使命。](https://app.dover.com/apply/semianalysis/2a9c8da5-6d59-4ac8-8302-3877345dbce1) 我们的启蒙之旅始于发现 GitHub Copilot agent 是免费的——起初我们简直不敢相信这个功能居然不收费！很快我们意识到 Copilot 很糟糕，也就明白了为什么 GitHub 要免费赠送。要让我们继续用它，恐怕*得倒贴钱*给我们才行。
 
-自 Claude Code 发布以来，我们一直在本地使用它。但最近，我们将 Claude Code 集成到了 InferenceX 的开发中，除了常规的 PR 审查等任务外，还赋予了它在集群上执行扫描的能力。通过我们搭建的工作流，Claude 可以手动启动运行、查看结果并进行迭代。这使我们能够通过 GitHub 应用轻松地在移动中部署快速修复。
+自 Claude Code 发布以来，我们一直在本地使用它。但最近，我们将 Claude Code 集成到了 InferenceX 的开发中，除了常规的 PR 审查等任务外，还赋予了它在集群上执行扫描的能力。通过我们搭建的工作流，Claude 可以手动启动运行、查看结果并进行迭代。这使我们能够通过 GitHub 应用随时随地轻松部署快速修复。
 
 另一个酷炫的用例是使用 Claude 为新的 vLLM/SGLang 镜像寻找配方。当新镜像发布时，配方有时需要更新以实现最佳性能（新环境变量、修改的引擎参数等）。通过我们的 Claude Code 集成，我们只需打开一个 issue 并要求 Claude 搜索镜像 changelog 中的所有提交，以找到需要添加到配方中的必要变更。这效果相当好，虽然不*完美*，但通常能提供一个良好的起点。
 
diff --git a/packages/app/content/blog/zh/kimi-k3-agentx-mi355x-atom-vs-gb300-nvl72.mdx b/packages/app/content/blog/zh/kimi-k3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
index 1e0a4651a..d4f617990 100644
--- a/packages/app/content/blog/zh/kimi-k3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
+++ b/packages/app/content/blog/zh/kimi-k3-agentx-mi355x-atom-vs-gb300-nvl72.mdx
@@ -1,7 +1,7 @@
 ---
 title: 'Kimi K3 的 AgentX 结果：MI355X ATOM 在部分曲线上胜过 GB300 NVL72'
 subtitle: 'AMD 的厂商引擎在每美元性能前沿上赢下了实打实的一段，而 Hopper 连服务 K3 都很吃力'
-seoDescription: '在 Kimi K3 的 AgentX 运行中，端到端延迟 40 到 60 秒的区间内，MI355X ATOM 在每美元性能上胜过 GB300 NVL72 vLLM；而 Hopper 表现吃力，因为 K3 需要定制的 SM90 kernel 以及调优过的 TP32、EP32 形状。'
+seoDescription: '在 Kimi K3 的 AgentX 运行中，端到端延迟 40 到 60 秒的区间内，MI355X ATOM 在每美元性能上胜过 GB300 NVL72 vLLM；而 Hopper 表现吃力，因为 K3 需要定制的 SM90 kernel 以及调优过的 TP32、EP32 配置。'
 date: '2026-08-25'
 publishDate: '2026-08-25'
 tags:
@@ -25,7 +25,7 @@ tags:
   caption="来源：SemiAnalysis InferenceX"
 />
 
-## 上游这个前提
+## 关于上游的限定条件
 
 AMD 用 [ATOM](/zh/glossary/atom) 快速推进 K3 性能是件好事。与之相伴的建议是：优先把这些改进上游到 vLLM。ATOM 目前是 AMD 性能最好的引擎，但对使用上游开源服务栈的客户来说，vLLM 才是更有参考价值的对比对象；只在厂商运行时下成立的曲线，并不能代表这些客户实际能部署的性能。
 
@@ -63,7 +63,7 @@ _本文结果只是 AgentX 1.0 的一个切面。完整分析、回放方法，
       "name": "Hopper 在 Kimi K3 上为什么吃力？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "Kimi K3 体量巨大，而 vLLM 维护者和 NVIDIA 都没有把精力放在为它优化 Hopper 上。要在 SM90 上以高交互性服务 K3，需要定制调优的 kernel 以及调优过的 TP32、EP32 形状，而这些工作尚未完成。"
+        "text": "Kimi K3 体量巨大，而 vLLM 维护者和 NVIDIA 都没有把精力放在为它优化 Hopper 上。要在 SM90 上以高交互性服务 K3，需要定制调优的 kernel 以及调优过的 TP32、EP32 配置，而这些工作尚未完成。"
       }
     }
   ]
diff --git a/packages/app/content/blog/zh/kimi-k3-the-manos-the-mythos-the.mdx b/packages/app/content/blog/zh/kimi-k3-the-manos-the-mythos-the.mdx
index 2dac3c1c3..fbca54290 100644
--- a/packages/app/content/blog/zh/kimi-k3-the-manos-the-mythos-the.mdx
+++ b/packages/app/content/blog/zh/kimi-k3-the-manos-the-mythos-the.mdx
@@ -296,7 +296,7 @@ Kimi Linear 把 KDA 与全注意力的 Multi-head Latent Attention（MLA）交
 
 ### KV 吞吐量
 
-KV 吞吐量定义为：在给定序列长度下，KV cache 大小除以 prefill 时间（首 token 时延，Time to First Token）。KV 吞吐量代表了以 PD 分离（PD disaggregation）方式稳定服务一个模型所需的最低带宽，同时也是理解 KV cache 效率的良好代理指标。prefill 时间浓缩了模型架构的效率，随着序列长度增加，我们能分别观察到访存受限与计算受限两种情形。如下表所示，序列长度越长，混合线性注意力的收益越明显。
+KV 吞吐量定义为：在给定序列长度下，KV cache 大小除以 prefill 时间（首 token 时延，Time to First Token）。KV 吞吐量代表了以 PD 分离（PD disaggregation）方式稳定服务一个模型所需的最低带宽，同时也是理解 KV cache 效率的良好代理指标。prefill 时间集中体现了模型架构的效率，随着序列长度增加，我们能分别观察到访存受限与计算受限两种情形。如下表所示，序列长度越长，混合线性注意力的收益越明显。
 
 <Figure
   src="/images/kimi-k3-the-manos-the-mythos-the/kv-throughput-by-sequence-length.png"
@@ -665,7 +665,7 @@ QB 的基本原理与 aux-free 负载均衡一致：根据系统负载动态更
 
 QB 的做法是：在当前批次的截断阈值和路由结果下，求出一个能让负载近似均衡的偏置，通过求解带约束的优化问题，并把这次更新应用到下一批次。第一个约束是每个 token 恰好被路由到 k 个专家。第二个约束是：一批 m 个 token、每个挑 k 个专家，总共产生 (mk) 次分配；要让负载在 n 个专家间均匀分布，每个专家应处理 _q=mk/n_ 个 token。
 
-每个 token 把加过偏置的 router 分数中第 (k+1) 高的那个作为截断阈值，并据此计算为均衡各专家负载所需的偏置更新量。对每个专家，QB 会把它的 router 分数与所有 token 截断阈值之间的 margin 排序，并把负偏置设为第 q+1 大的 margin，从而恰好留下 q 个 margin 高于阈值。由于 q/m=k/n，这正好是 margin 的 (1-k/n) 分位数，这也是"分位数均衡"名称的由来。
+每个 token 把加过偏置的 router 分数中第 (k+1) 高的那个作为截断阈值，并据此计算为均衡各专家负载所需的偏置更新量。对每个专家，QB 会把它的 router 分数与所有 token 截断阈值之间的 margin 排序，并把负偏置设为第 q+1 大的 margin，从而恰好留下 q 个 margin 高于阈值。由于 q/m=k/n，这正好是 margin 的 (1-k/n) 分位数，这也是“分位数负载均衡”名称的由来。
 
 ## 推理性能
 
diff --git a/packages/app/content/blog/zh/mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx b/packages/app/content/blog/zh/mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx
index a95695ad5..8a0345fca 100644
--- a/packages/app/content/blog/zh/mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx
+++ b/packages/app/content/blog/zh/mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx
@@ -16,9 +16,9 @@ tags:
   - fp4
 ---
 
-DeepSeek-V4-Pro 于 [2026-04-24](https://api-docs.deepseek.com/news/news260424) 发布后仅 26 天，AMD MI355X 上基于 SGLang [sgl-project/sglang `amd/deepseek_v4` 分支](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4) 的服务在 8K/1K 负载下达到 **2,256 tok/s/GPU、9.4 tok/s/user**——相比 2026-04-25 首次点亮时 20.4 tok/s/GPU、2.4 tok/s/user 的水平，**每 GPU 吞吐量提升 110.5 倍**，而且是罕见的双轴同步提升：每 GPU 吞吐量提升 110.5 倍的*同时*，交互性也提升了 3.85 倍。SemiAnalysis 此前在 [推文中](https://x.com/SemiAnalysis_/status/2053520440589451720)指出 14 天内核心级别的提升约为 75 倍；仪表板现在又记录了此后 12 天的持续优化。
+DeepSeek-V4-Pro 于 [2026-04-24](https://api-docs.deepseek.com/news/news260424) 发布后仅 26 天，AMD MI355X 上基于 SGLang [sgl-project/sglang `amd/deepseek_v4` 分支](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4) 的服务在 8K/1K 负载下达到 **2,256 tok/s/GPU、9.4 tok/s/user**——相比 2026-04-25 首次点亮时 20.4 tok/s/GPU、2.4 tok/s/user 的水平，**每 GPU 吞吐量提升 110.5 倍**，而且是罕见的双轴同步提升：每 GPU 吞吐量提升 110.5 倍的*同时*，交互性也提升了 3.85 倍。SemiAnalysis 此前在 [推文中](https://x.com/SemiAnalysis_/status/2053520440589451720)指出 14 天内 kernel 级别的提升约为 75 倍；仪表板现在又记录了此后 12 天的持续优化。
 
-**31 个性能优化 PR** 在 AMD 分支上紧密接力完成了这些核心工作：FP4 权重启用（[#24031](https://github.com/sgl-project/sglang/pull/24031)）、用于 DeepSeek Sparse Attention 的 TileLang 注意力索引器（[#24033](https://github.com/sgl-project/sglang/pull/24033)、[#24050](https://github.com/sgl-project/sglang/pull/24050)）、Triton 稀疏 MLA 内核及后续融合调度优化（[#24930](https://github.com/sgl-project/sglang/pull/24930)、[#25878](https://github.com/sgl-project/sglang/pull/25878)、[#25977](https://github.com/sgl-project/sglang/pull/25977)）、融合的多头压缩 / RoPE / Hadamard（[#24355](https://github.com/sgl-project/sglang/pull/24355)、[#24727](https://github.com/sgl-project/sglang/pull/24727)、[#26014](https://github.com/sgl-project/sglang/pull/26014)）、FlyDSL MoE（[#24971](https://github.com/sgl-project/sglang/pull/24971)）、融合 hash topk（[#24728](https://github.com/sgl-project/sglang/pull/24728)）、AITER MHC 前处理/后处理，以及六余个压缩器逐元素内核融合。速度就是护城河。
+**31 个性能优化 PR** 在 AMD 分支上紧密接力完成了这些核心工作：FP4 权重启用（[#24031](https://github.com/sgl-project/sglang/pull/24031)）、用于 DeepSeek Sparse Attention 的 TileLang 注意力索引器（[#24033](https://github.com/sgl-project/sglang/pull/24033)、[#24050](https://github.com/sgl-project/sglang/pull/24050)）、Triton 稀疏 MLA kernel 及后续融合调度优化（[#24930](https://github.com/sgl-project/sglang/pull/24930)、[#25878](https://github.com/sgl-project/sglang/pull/25878)、[#25977](https://github.com/sgl-project/sglang/pull/25977)）、融合的多头压缩 / RoPE / Hadamard（[#24355](https://github.com/sgl-project/sglang/pull/24355)、[#24727](https://github.com/sgl-project/sglang/pull/24727)、[#26014](https://github.com/sgl-project/sglang/pull/26014)）、FlyDSL MoE（[#24971](https://github.com/sgl-project/sglang/pull/24971)）、融合 hash topk（[#24728](https://github.com/sgl-project/sglang/pull/24728)）、AITER MHC 前处理/后处理，以及约六个压缩器逐元素 kernel 融合。速度就是护城河。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_rundate=2026-05-22&g_runid=26306422380&g_model=DeepSeek-V4-Pro&i_gpus=mi355x_sglang&i_dates=2026-05-03%2C2026-05-04%2C2026-05-08%2C2026-05-19%2C2026-05-21%2C2026-04-25&i_prec=fp4%2Cfp8&i_dstart=2026-04-25&i_dend=2026-05-21&i_linelabel=1">
   点击查看完整的 InferenceX 仪表板 →
@@ -35,7 +35,7 @@ DeepSeek-V4-Pro 于 [2026-04-24](https://api-docs.deepseek.com/news/news260424)
 
 DeepSeek-V4-Pro 是 DeepSeek 的旗舰 MoE 模型：**总参数 1.6T，每 token 激活 49B**（据 [DeepSeek V4 预览公告](https://api-docs.deepseek.com/news/news260424)）。该架构将新颖的**逐 token 压缩**路径与 **DSA（DeepSeek Sparse Attention）** 相结合——这是 DeepSeek 在 V3.2 中引入的稀疏注意力模式，现扩展至更长的上下文（官方服务默认在 **1M 上下文**下运行 DSv4）。V4-Pro 的官方定位是"极致效率：世界领先的长上下文能力，大幅降低计算和显存开销"；开源权重发布于 [`deepseek-ai/DeepSeek-V4-Pro`](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro)。
 
-注意力机制是 SGLang AMD 分支需要编写大量内核的根本原因。逐 token 压缩引入了围绕注意力块的**多头压缩（mHC）前/后处理对**——运行时将其与 RoPE 和 Hadamard 变换融合——而解码路径上的 DSA 需要单独的**注意力索引器**以及一个**稀疏 MLA 内核**来仅遍历被路由到的位置。整个技术栈足够新，以至于上游 `main` 分支在发布时无法在 Blackwell 或 ROCm 上运行 DeepSeek-V4-Pro；AMD 分支正是在 MI355X 上弥合了这一差距。
+注意力机制是 SGLang AMD 分支需要编写大量 kernel 的根本原因。逐 token 压缩引入了围绕注意力块的**多头压缩（mHC）前/后处理对**——运行时将其与 RoPE 和 Hadamard 变换融合——而解码路径上的 DSA 需要单独的**注意力索引器**以及一个**稀疏 MLA kernel**来仅遍历被路由到的位置。整个技术栈足够新，以至于上游 `main` 分支在发布时无法在 Blackwell 或 ROCm 上运行 DeepSeek-V4-Pro；AMD 分支正是在 MI355X 上弥合了这一差距。
 
 **MI355X 上的 FP4 权重支持在发布时同样不存在。** 2026-04-25 的首次点亮测量使用的是 FP8——并且需要 `SGLANG_HACK_FLASHMLA_BACKEND=torch` 加上 `--time=300` 的 SLURM 扩展才能在不触及 3 小时 CI 上限的情况下通过约 30 分钟的 MoE JIT 编译——因为 [PR #24031](https://github.com/sgl-project/sglang/pull/24031)（kk，2026-04-29）尚未在 ROCm 上启用 FP4 模型路径。一旦该 PR 合入（加上 2026-05-02 的 InferenceX 配方更新——启用 `SGLANG_DSV4_FP4_EXPERTS=True` 并拉取了 `deepseek-ai/DeepSeek-V4-Pro` 的 FP4 权重），曲线就进入了可量测的服务区间。本文从 2026-05-02 起的所有日期均使用 FP4；仅 2026-04-25 使用 FP8。
 
@@ -54,13 +54,13 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
 
 ## 实现这一切的关键贡献
 
-**上游技术栈：`amd/deepseek_v4` SGLang 分支。** [sgl-project/sglang `amd/deepseek_v4`](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4) 是一个持续 rebase 的分支，以编号的性能优化 PR 形式合入 AMD 专用的 DeepSeek-V4-Pro 内核。截至 2026-05-22 共 31 个 PR，四位主要贡献者。本文中的每一次测量均基于该分支的镜像，而非 SGLang main（关于上游合并的情况请参见[后续计划](#mi355x-deepseek-v4-pro-的后续计划)）。按机制分组的关键优化：
+**上游技术栈：`amd/deepseek_v4` SGLang 分支。** [sgl-project/sglang `amd/deepseek_v4`](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4) 是一个持续 rebase 的分支，以编号的性能优化 PR 形式合入 AMD 专用的 DeepSeek-V4-Pro kernel。截至 2026-05-22 共 31 个 PR，四位主要贡献者。本文中的每一次测量均基于该分支的镜像，而非 SGLang main（关于上游合并的情况请参见[后续计划](#mi355x-deepseek-v4-pro-的后续计划)）。按机制分组的关键优化：
 
-- **DSA 注意力（TileLang 索引器 + Triton 稀疏 MLA）。** [#24033](https://github.com/sgl-project/sglang/pull/24033)（Thomas Wang，04-29）将 TileLang 注意力路径移植至 ROCm；[#24050](https://github.com/sgl-project/sglang/pull/24050)（Thomas Wang，04-29）在 TileLang 中添加了**注意力索引器**；[#24930](https://github.com/sgl-project/sglang/pull/24930)（amd-danli103，05-11）引入了 **Triton 稀疏 MLA 内核**；[#25878](https://github.com/sgl-project/sglang/pull/25878)（05-20）和 [#25977](https://github.com/sgl-project/sglang/pull/25977)（jacky.cheng，05-22）分别将 prefill 和 extend 的 gather + attention 路径融合为单次调度。
-- **mHC 融合（多头压缩，逐 token 压缩路径）。** [#24355](https://github.com/sgl-project/sglang/pull/24355)（kk，05-04）"优化 mhc 性能"；[#24424](https://github.com/sgl-project/sglang/pull/24424)（Thomas Wang，05-05）**压缩器逐元素内核融合**；[#25020](https://github.com/sgl-project/sglang/pull/25020)（Xinyi Song，05-12）压缩器优化；[#25245](https://github.com/sgl-project/sglang/pull/25245)（jacky.cheng，05-15）**融合 softmax pool Triton 内核用于压缩器**；[#25353](https://github.com/sgl-project/sglang/pull/25353)（Xinyi Song，05-15）"启用新压缩器路径"；[#26014](https://github.com/sgl-project/sglang/pull/26014)（Xinyi Song，05-22）**低并发下的 Triton 融合 mhc_post_pre**。
-- **RoPE + Hadamard 融合。** [#24727](https://github.com/sgl-project/sglang/pull/24727)（Xinyi Song，05-09）**使用 `rope_rotate_activation` 融合 RoPE Hadamard**——消除了 CPU 侧的一次 launch 调用，改善了每步解码循环的 HBM 利用率。[#24249](https://github.com/sgl-project/sglang/pull/24249)（Xinyi Song，05-02）完成了类似的**融合 compress-decode** 内核。
+- **DSA 注意力（TileLang 索引器 + Triton 稀疏 MLA）。** [#24033](https://github.com/sgl-project/sglang/pull/24033)（Thomas Wang，04-29）将 TileLang 注意力路径移植至 ROCm；[#24050](https://github.com/sgl-project/sglang/pull/24050)（Thomas Wang，04-29）在 TileLang 中添加了**注意力索引器**；[#24930](https://github.com/sgl-project/sglang/pull/24930)（amd-danli103，05-11）引入了 **Triton 稀疏 MLA kernel**；[#25878](https://github.com/sgl-project/sglang/pull/25878)（05-20）和 [#25977](https://github.com/sgl-project/sglang/pull/25977)（jacky.cheng，05-22）分别将 prefill 和 extend 的 gather + attention 路径融合为单次调度。
+- **mHC 融合（多头压缩，逐 token 压缩路径）。** [#24355](https://github.com/sgl-project/sglang/pull/24355)（kk，05-04）"优化 mhc 性能"；[#24424](https://github.com/sgl-project/sglang/pull/24424)（Thomas Wang，05-05）**压缩器逐元素 kernel 融合**；[#25020](https://github.com/sgl-project/sglang/pull/25020)（Xinyi Song，05-12）压缩器优化；[#25245](https://github.com/sgl-project/sglang/pull/25245)（jacky.cheng，05-15）**融合 softmax pool Triton kernel 用于压缩器**；[#25353](https://github.com/sgl-project/sglang/pull/25353)（Xinyi Song，05-15）"启用新压缩器路径"；[#26014](https://github.com/sgl-project/sglang/pull/26014)（Xinyi Song，05-22）**低并发下的 Triton 融合 mhc_post_pre**。
+- **RoPE + Hadamard 融合。** [#24727](https://github.com/sgl-project/sglang/pull/24727)（Xinyi Song，05-09）**使用 `rope_rotate_activation` 融合 RoPE Hadamard**——消除了 CPU 侧的一次 launch 调用，改善了每步解码循环的 HBM 利用率。[#24249](https://github.com/sgl-project/sglang/pull/24249)（Xinyi Song，05-02）完成了类似的**融合 compress-decode** kernel。
 - **MoE：FlyDSL + FP4 + 融合 hash topk。** [#24031](https://github.com/sgl-project/sglang/pull/24031)（kk，04-29）启用 **FP4 模型路径**；[#24728](https://github.com/sgl-project/sglang/pull/24728)（Xinyi Song，05-09）**融合 hash topk** 路由步骤；[#24971](https://github.com/sgl-project/sglang/pull/24971)（Thomas Wang，05-11）合入 **FlyDSL MoE 后端**用于 ROCm；[#25070](https://github.com/sgl-project/sglang/pull/25070)（Thomas Wang，05-12）添加了 swiglu-limit 密集 MoE / shared expert 路径。
-- **AITER 内核 + 其他融合。** 05-07 cherry-pick 了 AITER MHC 前/后处理修复（[commit b639cb6](https://github.com/sgl-project/sglang/commit/b639cb6)）；[#25043](https://github.com/sgl-project/sglang/pull/25043)（jacky.cheng，05-12）**将注意力路径上的 input_layernorm 与 FP8 per-128 group 量化融合**；[#25251](https://github.com/sgl-project/sglang/pull/25251)（jacky.cheng，05-19）为全 greedy 采样使用 **AITER `greedy_sample`**；[#25097](https://github.com/sgl-project/sglang/pull/25097)（Raiden Makoto，05-13）**ROCm 上的 Triton 融合 store cache**；[#25375](https://github.com/sgl-project/sglang/pull/25375)（Thomas Wang，05-18）wqb 输入的 **rmsnorm_quant 融合**。
+- **AITER kernel + 其他融合。** 05-07 cherry-pick 了 AITER MHC 前/后处理修复（[commit b639cb6](https://github.com/sgl-project/sglang/commit/b639cb6)）；[#25043](https://github.com/sgl-project/sglang/pull/25043)（jacky.cheng，05-12）**将注意力路径上的 input_layernorm 与 FP8 per-128 group 量化融合**；[#25251](https://github.com/sgl-project/sglang/pull/25251)（jacky.cheng，05-19）为全 greedy 采样使用 **AITER `greedy_sample`**；[#25097](https://github.com/sgl-project/sglang/pull/25097)（Raiden Makoto，05-13）**ROCm 上的 Triton 融合 store cache**；[#25375](https://github.com/sgl-project/sglang/pull/25375)（Thomas Wang，05-18）wqb 输入的 **rmsnorm_quant 融合**。
 
 **InferenceX 配方迭代循环。** InferenceX 基准测试（benchmark）配方通过大约每 2–3 天一次的镜像更新吸收每一波上游改进：容器镜像从 `rocm/sgl-dev:v0.5.10rc0-rocm720-mi35x-20260414`（04-25，仅 FP8，配方需要 `SGLANG_HACK_FLASHMLA_BACKEND=torch` 才能编译）→ `rocm/sgl-dev:rocm720-mi35x-583b1b6-20260501-DSv4`（05-02，通过 `SGLANG_DSV4_FP4_EXPERTS=True` 启用 FP4）→ `a8410de6-20260502`（05-03，融合 compress-decode）→ `bfd32b6-20260507`（05-08，AITER MHC 前/后处理 + Triton SWA prepare）→ `0363e6c-20260509` → `b19052c-20260518`（05-19，稳定的 `lmsysorg/sglang:v0.5.12-rocm720-mi35x` 仓库，含 Triton 注意力后端、FlyDSL MoE、融合 hash topk）→ `8c3b5aa-20260521`（05-21 最终版）。镜像更新之间的配方调优收紧了 `--num-continuous-decode-steps`（4 → 8，+4.7%），将 `--max-running-requests` 和 `--cuda-graph-max-bs` 调整为矩阵并发值，并在 DP attention 配置上启用了 `--enable-prefill-delayer`。
 
@@ -147,7 +147,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
 | 40                  | _unreachable_ | _unreachable_ | _unreachable_ | 89            | 393           | _∞_           |
 | 50                  | _unreachable_ | _unreachable_ | _unreachable_ | _unreachable_ | 140           | _∞_           |
 
-核心结论是**从 2026-05-02 到 2026-05-21，在 10–20 tok/s/user 的服务区间内，等交互性下的每 GPU 吞吐量提升了 12–14 倍**。提升逐日期层层累加——每次镜像更新都将曲线再推高 1.6–4.4 倍。高交互性段（25+ tok/s/user）在 05-04 之后才完全打开，而 50 tok/s/user 仅在 05-21 配合最新的 FlyDSL MoE + 融合 hash topk 内核（`lmsysorg/sglang:v0.5.12-rocm720-mi35x`）后才可量测。
+核心结论是**从 2026-05-02 到 2026-05-21，在 10–20 tok/s/user 的服务区间内，等交互性下的每 GPU 吞吐量提升了 12–14 倍**。提升逐日期层层累加——每次镜像更新都将曲线再推高 1.6–4.4 倍。高交互性段（25+ tok/s/user）在 05-04 之后才完全打开，而 50 tok/s/user 仅在 05-21 配合最新的 FlyDSL MoE + 融合 hash topk kernel（`lmsysorg/sglang:v0.5.12-rocm720-mi35x`）后才可量测。
 
 <Figure
   srcLight="/images/mi355x-deepseek-v4-pro-sglang-110x-in-26-days/benchmark-light.png"
@@ -160,7 +160,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
 
 ## MI355X DeepSeek-V4-Pro 的后续计划
 
-**MI355X 与 NVIDIA 在 DSv4-Pro 上的差距不在硅片——在于软件。** 从纸面参数看，MI355X 的 HBM 更大（288 GB vs B200 的 180 GB——**1.60 倍容量**），HBM 带宽相同（均为 8 TB/s），密集计算在各精度下均略高（FP4 / FP8 / BF16 均为 B200 的 **1.12 倍**）。B200 唯一领先的硅片参数是节点内扩展带宽——NVLink 5 单向 900 GB/s vs 第五代 Infinity Fabric 的 576 GB/s，1.56 倍优势——但在单节点 TP=8 运行 1.6T 激活 49B 的 MoE 模型时，这一差距的影响小于 AMD 分支仍在弥合的内核栈成熟度差距。
+**MI355X 与 NVIDIA 在 DSv4-Pro 上的差距不在硅片——在于软件。** 从纸面参数看，MI355X 的 HBM 更大（288 GB vs B200 的 180 GB——**1.60 倍容量**），HBM 带宽相同（均为 8 TB/s），密集计算在各精度下均略高（FP4 / FP8 / BF16 均为 B200 的 **1.12 倍**）。B200 唯一领先的硅片参数是节点内扩展带宽——NVLink 5 单向 900 GB/s vs 第五代 Infinity Fabric 的 576 GB/s，1.56 倍优势——但在单节点 TP=8 运行 1.6T 激活 49B 的 MoE 模型时，这一差距的影响小于 AMD 分支仍在弥合的 kernel 栈成熟度差距。
 
 <Figure
   srcLight="/images/mi355x-deepseek-v4-pro-sglang-110x-in-26-days/specs-radar-light.png"
@@ -181,7 +181,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
 | 扩展域 HBM 容量         | 2.30 TB                    | 1.44 TB             | **1.60x**     |
 | 扩展域 HBM 带宽（聚合） | 64 TB/s                    | 64 TB/s             | 1.00x         |
 
-因此，当实测的 B200 SGLang DSv4-Pro 曲线在 15–30 tok/s/user 服务区间内比 MI355X SGLang 高出约 5 倍（完全相同的 FP4 / 8K / 1K 负载）时，这一差距不来自算力，不来自 HBM 容量，不来自 HBM 带宽，也几乎与扩展带宽无关。差距在于**上游内核覆盖度、融合完整性以及调度器调优**——正是 `amd/deepseek_v4` 分支持续 rebase 追赶的方向，也是 26 天内缩小了 110.5 倍的差距所在：
+因此，当实测的 B200 SGLang DSv4-Pro 曲线在 15–30 tok/s/user 服务区间内比 MI355X SGLang 高出约 5 倍（完全相同的 FP4 / 8K / 1K 负载）时，这一差距不来自算力，不来自 HBM 容量，不来自 HBM 带宽，也几乎与扩展带宽无关。差距在于**上游 kernel 覆盖度、融合完整性以及调度器调优**——正是 `amd/deepseek_v4` 分支持续 rebase 追赶的方向，也正是 26 天内缩小了 110.5 倍的那部分差距：
 
 <Figure
   srcLight="/images/mi355x-deepseek-v4-pro-sglang-110x-in-26-days/b200-vs-mi355x-light.png"
@@ -192,10 +192,10 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
 
 据 [SemiAnalysis 评估](https://x.com/SemiAnalysis_/status/2053520440589451720)，接下来需要弥合的差距：
 
-- **还需约 5 倍吞吐量才能追平单节点聚合 B200。** B200 上的 SGLang DSv4-Pro 技术栈在 70+ tok/s/user 时已达到数千 tok/s/GPU 区间，而 MI355X SGLang 仅在低交互性的左侧边缘触及此水平。按照 `amd/deepseek_v4` 分支当前的 PR 节奏，AMD 在未来几周内追平这一差距是现实可行的——硅片具备能力，内核只需继续追赶。
+- **还需约 5 倍吞吐量才能追平单节点聚合 B200。** B200 上的 SGLang DSv4-Pro 技术栈在 70+ tok/s/user 时已达到数千 tok/s/GPU 区间，而 MI355X SGLang 仅在低交互性的左侧边缘触及此水平。按照 `amd/deepseek_v4` 分支当前的 PR 节奏，AMD 在未来几周内追平这一差距是现实可行的——硅片具备能力，kernel 只需继续追赶。
 - **还需额外约 1.5 倍以追平 PD 分离式 B200。** InferenceX 尚未发布 MI355X DSv4-Pro 的分离式配方。`mori-sglang` AMD 分离式分支具备 prefill/decode 分离原语，但尚未接入 InferenceX 循环中的 DSv4-Pro 配方。
-- **AMD 分支上的持续内核节奏。** 31 个 PR 的开发节奏造就了 110.5 倍的提升；[开放的 compare 视图](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4)仍在每 2–3 天添加新的性能优化 PR，因此本文中的曲线到下周就会过时。新的压缩器路径（[#25353](https://github.com/sgl-project/sglang/pull/25353)）和 extend 的融合 nosplitk 注意力调度（[#25977](https://github.com/sgl-project/sglang/pull/25977)）在 2026-05-21 数据集之后才合入，尚未反映在图表中。
-- **分支 → SGLang main 上游迁移。** 第一批代码在 [PR #24933](https://github.com/sgl-project/sglang/pull/24933)（kk，2026-05-18 合入，跨 17 个文件 +3,678 / -70）中合入——足以通过 `is_hip` / `use_aiter` 门控、替换无法在 ROCm 上编译的 JIT 融合内核的 Triton 版本，以及新的 HIP 注意力后端在 SGLang main 上以 **eager 模式**运行 DSv4-Pro。PR 描述明确标注了后续工作："后续 PR 将从 `amd/deepseek_v4` 分支合入剩余的 DSv4 优化"——压缩流融合、多流启用、TileLang 注意力索引器、FlyDSL MoE 以及关键的 SGLANG*OPT*\* 开关截至 2026-05-22 仍为分支专有。在这些迁移完成之前，MI355X 在 SGLang `main` 上的 DSv4-Pro 服务性能将比本文测量结果低一个数量级——分支镜像（`lmsysorg/sglang:v0.5.12-rocm720-mi35x-*`）仍是复现上述曲线的唯一途径。
+- **AMD 分支上的持续 kernel 节奏。** 31 个 PR 的开发节奏造就了 110.5 倍的提升；[开放的 compare 视图](https://github.com/sgl-project/sglang/compare/main...amd/deepseek_v4)仍在每 2–3 天添加新的性能优化 PR，因此本文中的曲线到下周就会过时。新的压缩器路径（[#25353](https://github.com/sgl-project/sglang/pull/25353)）和 extend 的融合 nosplitk 注意力调度（[#25977](https://github.com/sgl-project/sglang/pull/25977)）在 2026-05-21 数据集之后才合入，尚未反映在图表中。
+- **分支 → SGLang main 上游迁移。** 第一批代码在 [PR #24933](https://github.com/sgl-project/sglang/pull/24933)（kk，2026-05-18 合入，跨 17 个文件 +3,678 / -70）中合入——足以通过 `is_hip` / `use_aiter` 门控、替换无法在 ROCm 上编译的 JIT 融合 kernel 的 Triton 版本，以及新的 HIP 注意力后端在 SGLang main 上以 **eager 模式**运行 DSv4-Pro。PR 描述明确标注了后续工作："后续 PR 将从 `amd/deepseek_v4` 分支合入剩余的 DSv4 优化"——压缩流融合、多流启用、TileLang 注意力索引器、FlyDSL MoE 以及关键的 `SGLANG_OPT_*` 开关截至 2026-05-22 仍为分支专有。在这些迁移完成之前，MI355X 在 SGLang `main` 上的 DSv4-Pro 服务性能将比本文测量结果低一个数量级——分支镜像（`lmsysorg/sglang:v0.5.12-rocm720-mi35x-*`）仍是复现上述曲线的唯一途径。
 
 对于当前的 MI355X DSv4-Pro 服务，基于 `lmsysorg/sglang:v0.5.12-rocm720-mi35x-20260517` 的 2026-05-21 配方是生产前沿——任何早于 05-10 的版本不应作为基准测试对比对象。
 
@@ -216,7 +216,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
       "name": "AMD MI355X SGLang DeepSeek-V4-Pro 自发布以来性能提升了多少？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "在 8K/1K 负载下，MI355X SGLang DeepSeek-V4-Pro 的每 GPU 吞吐量从 2026-04-25 的 20.4 tok/s/GPU、2.4 tok/s/user（FP8 首次点亮，并发 8）增长到 2026-05-21 的 2,256 tok/s/GPU、9.4 tok/s/user（FP4，并发 256，启用 DP attention）——26 天内每 GPU 吞吐量提升 110.5 倍，同时交互性也提升了 3.85 倍。在 10–20 tok/s/user 的服务区间内，从 2026-05-02 首次 FP4 测量到 2026-05-21 的等交互性累积提升为 12–14 倍（15 tok/s/user 时从 104 到 1,272 tok/s/GPU；20 tok/s/user 时从 61 到 876）。SemiAnalysis 此前指出 14 天内核心级别的提升约为 75 倍。测量于 InferenceX，GHA 运行 26306422380。"
+        "text": "在 8K/1K 负载下，MI355X SGLang DeepSeek-V4-Pro 的每 GPU 吞吐量从 2026-04-25 的 20.4 tok/s/GPU、2.4 tok/s/user（FP8 首次点亮，并发 8）增长到 2026-05-21 的 2,256 tok/s/GPU、9.4 tok/s/user（FP4，并发 256，启用 DP attention）——26 天内每 GPU 吞吐量提升 110.5 倍，同时交互性也提升了 3.85 倍。在 10–20 tok/s/user 的服务区间内，从 2026-05-02 首次 FP4 测量到 2026-05-21 的等交互性累积提升为 12–14 倍（15 tok/s/user 时从 104 到 1,272 tok/s/GPU；20 tok/s/user 时从 61 到 876）。SemiAnalysis 此前指出 14 天内 kernel 级别的提升约为 75 倍。测量于 InferenceX，GHA 运行 26306422380。"
       }
     },
     {
@@ -224,7 +224,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
       "name": "SGLang amd/deepseek_v4 分支上有哪些关键改动？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "截至 2026-05-22，sgl-project/sglang amd/deepseek_v4 分支上共有 31 个编号的性能优化 PR。关键内核变更包括：TileLang 注意力路径及注意力索引器（PR 24033 和 24050，Thomas Wang）；Triton 稀疏 MLA 内核及后续融合 gather+attention 调度（PR 24930、25878、25977，amd-danli103 和 jacky.cheng）；融合多头压缩（mHC）操作（PR 24355 kk、PR 24424 Thomas Wang、PR 25353 Xinyi Song、PR 26014 Xinyi Song）；融合 RoPE 和 Hadamard（PR 24727 Xinyi Song）；FlyDSL MoE 后端（PR 24971 Thomas Wang）；融合 hash topk 路由（PR 24728 Xinyi Song）；FP4 模型路径启用（PR 24031 kk）；AITER MHC 前/后处理引入；input_layernorm 与 FP8 per-128 group 量化融合（PR 25043 jacky.cheng）；wqb 输入的 rmsnorm-quant 融合（PR 25375 Thomas Wang）。InferenceX 配方通过大约每 2–3 天一次的容器镜像更新吸收每波上游改进，从 rocm/sgl-dev:v0.5.10rc0-rocm720-mi35x-20260414 发展到 lmsysorg/sglang:v0.5.12-rocm720-mi35x-20260517。"
+        "text": "截至 2026-05-22，sgl-project/sglang amd/deepseek_v4 分支上共有 31 个编号的性能优化 PR。关键 kernel 变更包括：TileLang 注意力路径及注意力索引器（PR 24033 和 24050，Thomas Wang）；Triton 稀疏 MLA kernel 及后续融合 gather+attention 调度（PR 24930、25878、25977，amd-danli103 和 jacky.cheng）；融合多头压缩（mHC）操作（PR 24355 kk、PR 24424 Thomas Wang、PR 25353 Xinyi Song、PR 26014 Xinyi Song）；融合 RoPE 和 Hadamard（PR 24727 Xinyi Song）；FlyDSL MoE 后端（PR 24971 Thomas Wang）；融合 hash topk 路由（PR 24728 Xinyi Song）；FP4 模型路径启用（PR 24031 kk）；AITER MHC 前/后处理引入；input_layernorm 与 FP8 per-128 group 量化融合（PR 25043 jacky.cheng）；wqb 输入的 rmsnorm-quant 融合（PR 25375 Thomas Wang）。InferenceX 配方通过大约每 2–3 天一次的容器镜像更新吸收每波上游改进，从 rocm/sgl-dev:v0.5.10rc0-rocm720-mi35x-20260414 发展到 lmsysorg/sglang:v0.5.12-rocm720-mi35x-20260517。"
       }
     },
     {
@@ -232,7 +232,7 @@ DeepSeek 在预览发布时公布了 V4-Pro-Max 与 Claude Opus 4.6、GPT-5.4-xH
       "name": "为什么 2026-04-25 的首次点亮测量如此之慢？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "DeepSeek-V4-Pro 于 2026-04-24 发布，采用新颖的注意力路径（逐 token 压缩加 DSA，即 DeepSeek Sparse Attention），上游 SGLang main 分支在发布时无法在 Blackwell 或 ROCm 上运行该模型。04-25 的 InferenceX 配方被迫使用 SGLANG_HACK_FLASHMLA_BACKEND=torch 作为回退，且仅 FP8 路径可以编译，因此实测的内核时间主要由 torch 回退路径主导，而非后续两周陆续合入的生产级注意力索引器或压缩器内核。结果是峰值仅 67 tok/s/GPU、0.93 tok/s/user，这并非可用的服务工作点。2026-05-02 使用正式 TileLang 注意力路径的首次 FP4 测量才是曲线首次进入可用交互性区间。"
+        "text": "DeepSeek-V4-Pro 于 2026-04-24 发布，采用新颖的注意力路径（逐 token 压缩加 DSA，即 DeepSeek Sparse Attention），上游 SGLang main 分支在发布时无法在 Blackwell 或 ROCm 上运行该模型。04-25 的 InferenceX 配方被迫使用 SGLANG_HACK_FLASHMLA_BACKEND=torch 作为回退，且仅 FP8 路径可以编译，因此实测的 kernel 时间主要由 torch 回退路径主导，而非后续两周陆续合入的生产级注意力索引器或压缩器 kernel。结果是峰值仅 67 tok/s/GPU、0.93 tok/s/user，这并非可用的服务工作点。2026-05-02 使用正式 TileLang 注意力路径的首次 FP4 测量才是曲线首次进入可用交互性区间。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/mi355x-glm5-fp8-sglang-40-cheaper-than-b200.mdx b/packages/app/content/blog/zh/mi355x-glm5-fp8-sglang-40-cheaper-than-b200.mdx
index a708678ef..a7ea42bb9 100644
--- a/packages/app/content/blog/zh/mi355x-glm5-fp8-sglang-40-cheaper-than-b200.mdx
+++ b/packages/app/content/blog/zh/mi355x-glm5-fp8-sglang-40-cheaper-than-b200.mdx
@@ -19,7 +19,7 @@ tags:
 
 GLM-5 发布 14 周后，AMD MI355X SGLang FP8 在 8k/1k 工作负载的大部分单节点 Pareto 前沿上，每百万 token 成本低于 NVIDIA B200 SGLang FP8（从约 10 到约 77 tok/s/user；B200 在约 90 tok/s/user 以上重新反超）。峰值差距为**使用 MTP 时在 18 tok/s/user 下达到 1.41 倍**（B200 $0.30/M vs MI355X $0.22/M — 降低 40%），**不使用 MTP 时在 10 tok/s/user 下达到 1.36 倍**（$0.31/M vs $0.23/M）。两项测试均使用 **SGLang v0.12**，MI355X 的 ROCm 软件栈在此版本上已与 B200 的 CUDA 软件栈功能对齐：均支持 MTP 和非 MTP 方案，均支持 FP8 KV 缓存，均基于 SGLang 最新的 TileLang MLA 路径。
 
-这正是关键的节奏。GLM-5 发布后，一个季度内 AMD 就完成了上游 SGLang 内核的合入（[sgl-project/sglang PR #21511](https://github.com/sgl-project/sglang/pull/21511)）及其他优化，并提交了配套的 InferenceX 方案（[InferenceX PR #1440](https://github.com/SemiAnalysisAI/InferenceX/pull/1440)），将该模型的 FP8 单节点成本曲线翻转为 AMD 占优。速度就是护城河。
+这正是关键的节奏。GLM-5 发布后，一个季度内 AMD 就完成了上游 SGLang kernel 的合入（[sgl-project/sglang PR #21511](https://github.com/sgl-project/sglang/pull/21511)）及其他优化，并提交了配套的 InferenceX 方案（[InferenceX PR #1440](https://github.com/SemiAnalysisAI/InferenceX/pull/1440)），将该模型的 FP8 单节点成本曲线翻转为 AMD 占优。速度就是护城河。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_model=GLM-5&i_prec=fp8&g_rundate=2026-05-20&g_runid=26187777287&i_active=b200_sglang%2Cb200_sglang_mtp%2Cmi355x_sglang%2Cmi355x_sglang_mtp&i_metric=y_costh&i_linelabel=1">
   点击查看完整 InferenceX 仪表板 →
@@ -31,11 +31,11 @@ GLM-5 是智谱（ZAI）的 MoE 旗舰模型，于 2026-02-11 发布 — 距本
 
 ## 推动这一结果的关键优化
 
-AMD 方面的标志性性能优化之一是 [sgl-project/sglang PR #21511](https://github.com/sgl-project/sglang/pull/21511)（由 [HaiShaw](https://github.com/HaiShaw) 提交，2026-04-03 合入）。该 PR 通过 SGLang 的 TileLang 后端为 MI300/MI355 启用了 FP8 KV 缓存和 FP8 注意力内核（在 DeepSeek-V3.2 和 GLM-5 上均已测试），并针对不同硬件代际采用了不同的融合策略：
+AMD 方面的标志性性能优化之一是 [sgl-project/sglang PR #21511](https://github.com/sgl-project/sglang/pull/21511)（由 [HaiShaw](https://github.com/HaiShaw) 提交，2026-04-03 合入）。该 PR 通过 SGLang 的 TileLang 后端为 MI300/MI355 启用了 FP8 KV 缓存和 FP8 注意力 kernel（在 DeepSeek-V3.2 和 GLM-5 上均已测试），并针对不同硬件代际采用了不同的融合策略：
 
-- **在 MI355 上**，该 PR **复用了现有的 `fused_qk_rope_cat_and_cache_mla` 内核来同时处理 Q 和 KV 的 FP8 量化**。QK rope 拼接、MLA 缓存写入以及 Q 和 KV 的 FP8 量化全部合并到每个解码步骤的单次内核调用中 — 无需额外的 HBM 往返，无需单独的量化内核启动。
+- **在 MI355 上**，该 PR **复用了现有的 `fused_qk_rope_cat_and_cache_mla` kernel 来同时处理 Q 和 KV 的 FP8 量化**。QK rope 拼接、MLA 缓存写入以及 Q 和 KV 的 FP8 量化全部合并到每个解码步骤的单次 kernel 调用中 — 无需额外的 HBM 往返，无需单独的量化 kernel 启动。
 
-TileLang 依赖版本已更新以在 AMD 上启用 FP8 GEMM，并新增了 `sparse_mla_fwd_decode_partial_fp8` 内核用于部分解码归约路径。该 PR 报告 MI355 吞吐量提升超过 5%（MI300 超过 10%），gsm8k 准确率无下降（DeepSeek-V3.2 0.945 → 0.946；GLM-5 0.946 → 0.950），通过 `--kv-cache-dtype fp8_e4m3` 配合 TileLang 预填充/解码后端激活。
+TileLang 依赖版本已更新以在 AMD 上启用 FP8 GEMM，并新增了 `sparse_mla_fwd_decode_partial_fp8` kernel 用于部分解码归约路径。该 PR 报告 MI355 吞吐量提升超过 5%（MI300 超过 10%），gsm8k 准确率无下降（DeepSeek-V3.2 0.945 → 0.946；GLM-5 0.946 → 0.950），通过 `--kv-cache-dtype fp8_e4m3` 配合 TileLang 预填充/解码后端激活。
 
 ## 基准测试数据
 
@@ -142,7 +142,7 @@ TileLang 依赖版本已更新以在 AMD 上启用 FP8 GEMM，并新增了 `spar
 
 ## 致谢
 
-该方案的快速落地得益于 [Anush Elangovan](https://x.com/AnushElangovan)、[HaiShaw](https://github.com/HaiShaw) 及更广泛的 AMD AI 团队在 GLM-5 发布后 14 周内完成了上游 SGLang TileLang 融合 MLA + FP8 KV 内核的提交。SGLang 维护者在提交后数天内即完成了审查与合入。从上游到基准测试的闭环速度就是护城河。
+该方案的快速落地得益于 [Anush Elangovan](https://x.com/AnushElangovan)、[HaiShaw](https://github.com/HaiShaw) 及更广泛的 AMD AI 团队在 GLM-5 发布后 14 周内完成了上游 SGLang TileLang 融合 MLA + FP8 KV kernel 的提交。SGLang 维护者在提交后数天内即完成了审查与合入。从上游到基准测试的闭环速度就是护城河。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference?g_model=GLM-5&i_prec=fp8&g_rundate=2026-05-20&g_runid=26187777287&i_active=b200_sglang%2Cb200_sglang_mtp%2Cmi355x_sglang%2Cmi355x_sglang_mtp&i_metric=y_costh&i_linelabel=1">
   点击查看完整 InferenceX 仪表板 →
@@ -165,7 +165,7 @@ TileLang 依赖版本已更新以在 AMD 上启用 FP8 GEMM，并新增了 `spar
       "name": "SGLang PR #21511 是什么？它如何帮助 MI355X 运行 GLM-5？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "sgl-project/sglang PR #21511（由 HaiShaw 提交，2026-04-03 合入）通过 SGLang 的 TileLang 后端为 AMD MI300 和 MI355 启用了 FP8 KV 缓存和 FP8 注意力内核，在 DeepSeek-V3.2 和 GLM-5 上均已测试。在 MI355 上，它复用了现有的 fused_qk_rope_cat_and_cache_mla 内核来同时处理 Q 和 KV 的 FP8 量化，将 QK rope 拼接、MLA 缓存写入以及 FP8 量化合并到每个解码步骤的单次内核调用中。在 MI300 上，使用独立的 Triton 内核 set_mla_kv_buffer_fp8_quant 处理 KV 缓存量化。该 PR 报告 MI355 吞吐量提升超过 5%（MI300 超过 10%），gsm8k 准确率无下降（GLM-5 0.946 → 0.950，DeepSeek-V3.2 0.945 → 0.946），通过 --kv-cache-dtype fp8_e4m3 配合 TileLang 预填充/解码后端激活。"
+        "text": "sgl-project/sglang PR #21511（由 HaiShaw 提交，2026-04-03 合入）通过 SGLang 的 TileLang 后端为 AMD MI300 和 MI355 启用了 FP8 KV 缓存和 FP8 注意力 kernel，在 DeepSeek-V3.2 和 GLM-5 上均已测试。在 MI355 上，它复用了现有的 fused_qk_rope_cat_and_cache_mla kernel 来同时处理 Q 和 KV 的 FP8 量化，将 QK rope 拼接、MLA 缓存写入以及 FP8 量化合并到每个解码步骤的单次 kernel 调用中。在 MI300 上，使用独立的 Triton kernel set_mla_kv_buffer_fp8_quant 处理 KV 缓存量化。该 PR 报告 MI355 吞吐量提升超过 5%（MI300 超过 10%），gsm8k 准确率无下降（GLM-5 0.946 → 0.950，DeepSeek-V3.2 0.945 → 0.946），通过 --kv-cache-dtype fp8_e4m3 配合 TileLang 预填充/解码后端激活。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx b/packages/app/content/blog/zh/mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx
index e76bf1bd5..7cbb5067e 100644
--- a/packages/app/content/blog/zh/mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx
+++ b/packages/app/content/blog/zh/mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx
@@ -28,9 +28,9 @@ tags:
 
 Kimi K2.5 是一个 1T 参数的 MoE 模型，使用多头潜在注意力（MLA，Multi-head Latent Attention），这是 DeepSeek 在 V2 中引入的注意力变体。MLA 通过将 key 和 value 投影到共享潜空间来减少 KV 缓存占用。由此产生的每 rank 注意力头数取决于 tensor-parallel rank 数：TP=4 时 Kimi K2.5 为 16 头/rank，TP=8 时为 8 头/rank。
 
-AITER（AMD 面向 ROCm 的手动调优 AI Tensor Engine）在 CDNA4 上有优化的 MLA 内核路径，但 vLLM 的集成代码在 TP=8 时未能正确分发到该路径。AITER 的 MLA 解码内核围绕 `gqa_ratio=16` 的 ASM 路径构建，原生接受 16 头/rank（TP=4）和 128 头/rank，并拒绝中间值。在 Kimi K2.5 TP=8 的 8 头/rank 下，分发因头数断言失败而回退到 vLLM 的参考 TritonMLA 路径，该路径在 MXFP4 下比 AITER 慢很多。
+AITER（AMD 面向 ROCm 的手动调优 AI Tensor Engine）在 CDNA4 上有优化的 MLA kernel 路径，但 vLLM 的集成代码在 TP=8 时未能正确分发到该路径。AITER 的 MLA 解码 kernel 围绕 `gqa_ratio=16` 的 ASM 路径构建，原生接受 16 头/rank（TP=4）和 128 头/rank，并拒绝中间值。在 Kimi K2.5 TP=8 的 8 头/rank 下，分发因头数断言失败而回退到 vLLM 的参考 TritonMLA 路径，该路径在 MXFP4 下比 AITER 慢很多。
 
-PR #35850 在单次提交中完成了三项修改：通过头重复技巧（将 8 头填充到 16 头以使用现有的 `gqa_ratio=16` ASM 内核）支持 `num_heads < 16` 的 AITER MLA——这为 Kimi K2.5 TP=8 和 Kimi-Linear TP=16 解锁了性能；放宽了头数断言以接受 4、8 或 [16, 128] 内任意 16 的倍数；以及当使用 FP8 KV 缓存时自动从 TritonMLA 回退到 AITER MLA（TritonMLA 对 FP8 KV 抛出 `NotImplementedError`）。三项修改均随 vLLM 0.18 发布。此外，AMD 对 MoE 专家形态的 MXFP4 GEMM 自动调优也与该 PR 一起贡献了观测到的吞吐量提升。
+PR #35850 在单次提交中完成了三项修改：通过头重复技巧（将 8 头填充到 16 头以使用现有的 `gqa_ratio=16` ASM kernel）支持 `num_heads < 16` 的 AITER MLA——这为 Kimi K2.5 TP=8 和 Kimi-Linear TP=16 解锁了性能；放宽了头数断言以接受 4、8 或 [16, 128] 内任意 16 的倍数；以及当使用 FP8 KV 缓存时自动从 TritonMLA 回退到 AITER MLA（TritonMLA 对 FP8 KV 抛出 `NotImplementedError`）。三项修改均随 vLLM 0.18 发布。此外，AMD 对 MoE 专家矩阵形状（shape）的 MXFP4 GEMM 自动调优也与该 PR 一起贡献了观测到的吞吐量提升。
 
 ## 解读曲线
 
@@ -49,7 +49,7 @@ InferenceX 的基准测试结果在变化一落地就捕获到了：
 | 3 月 26 日     | 32    | 8         | 1,255     | 27 ms     | 36.4       | 6.5x       |
 | 3 月 26 日     | 64    | 8         | 1,647     | 43 ms     | 23.3       | 4.7x       |
 
-两个日期均使用 TP=8 以进行等条件对比。延迟下限从 152–199 ms 崩塌至 13–43 ms，覆盖整个批次曲线。
+两个日期均使用 TP=8 以进行等条件对比。延迟下限从 152–199 ms 骤降至 13–43 ms，覆盖整个批次曲线。
 
 对于峰值吞吐量，修复后的最优配方切换到 TP=4，以少量低批次交互性为代价换取更高的每 GPU token 数：
 
@@ -67,7 +67,7 @@ InferenceX 的基准测试结果在变化一落地就捕获到了：
 | 337                  | 5.1（插值，约并发 62）    | **78.9**（实测，并发 4）  | **15.6x**  |
 | 380                  | 4.9（外推）               | 74.7（插值，约并发 5）    | 15.2x      |
 
-"最高 15 倍"的标题出现在 337 tok/s/GPU 处，v0.16 破损的延迟下限（152–199 ms TPOT，与批大小无关）与 v0.18 在并发 4 下 13 ms 的正常下限在此交汇。在该工作点上，vLLM v0.18 已能在 Kimi K2.5 推理上实现接近实时语音的延迟。
+"最高 15 倍"的标题出现在 337 tok/s/GPU 处，v0.16 异常的延迟下限（152–199 ms TPOT，与批大小无关）与 v0.18 在并发 4 下 13 ms 的正常下限在此交汇。在该工作点上，vLLM v0.18 已能在 Kimi K2.5 推理上实现接近实时语音的延迟。
 
 <Figure
   srcLight="/images/mi355x-kimi-k2-5-vllm-aiter-7x-speedup/benchmark-light.png"
@@ -84,7 +84,7 @@ InferenceX 的基准测试结果在变化一落地就捕获到了：
 
 AMD 已经展示了其能够在自有技术栈上交付生产级分离式推理的能力。MI355X DeepSeek R1 结果使用了 `mori-sglang` 配合分离式预填充/解码、MXFP4 和 MXFP8，含和不含 MTP 投机解码两种模式。我们期待尽快在 Kimi K2.5 上看到同样的方案。
 
-而这正是我们基准测试所展示的更新节奏为何如此重要。如果在 3 月 1 日做一次时间点 MI355X vs B200 对比，结论会是 MI355X 落后 10 倍且几乎不可用。然而，仅仅 25 天后的数据证明 MI355X 已进入 B200 单节点的射程之内。
+这也正是我们基准测试所体现的更新节奏如此重要的原因。如果在 3 月 1 日做一次时间点 MI355X vs B200 对比，结论会是 MI355X 落后 10 倍且几乎不可用。然而，仅仅 25 天后的数据证明 MI355X 已进入 B200 单节点的射程之内。
 
 <DashboardCTA href="https://inferencex.semianalysis.com/inference">
   点击查看完整 InferenceX 仪表板 →
@@ -99,7 +99,7 @@ AMD 已经展示了其能够在自有技术栈上交付生产级分离式推理
       "name": "vLLM PR #35850 为 MI355X 上的 Kimi K2.5 修复了什么？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "vLLM PR #35850（2026 年 3 月 6 日合入）通过头重复技巧为 MI355X CDNA4 添加了 num_heads < 16 的 AITER MLA 支持，将 8 个头填充到 16 个后调用优化的 gqa_ratio=16 ASM 内核。这为 Kimi K2.5 TP=8（8 头/rank）和 Kimi-Linear TP=16（4 头/rank）解锁了性能。该 PR 还放宽了头数断言以接受 4、8 或 [16, 128] 内任意 16 的倍数，并在使用 FP8 KV 缓存时添加了从 TritonMLA 到 AITER MLA 的自动回退。修复前，TP=8 的 Kimi K2.5 回退到参考 Triton MLA 路径，在 MXFP4 下比 AITER 慢很多。该修复随 vLLM 0.18 发布。"
+        "text": "vLLM PR #35850（2026 年 3 月 6 日合入）通过头重复技巧为 MI355X CDNA4 添加了 num_heads < 16 的 AITER MLA 支持，将 8 个头填充到 16 个后调用优化的 gqa_ratio=16 ASM kernel。这为 Kimi K2.5 TP=8（8 头/rank）和 Kimi-Linear TP=16（4 头/rank）解锁了性能。该 PR 还放宽了头数断言以接受 4、8 或 [16, 128] 内任意 16 的倍数，并在使用 FP8 KV 缓存时添加了从 TritonMLA 到 AITER MLA 的自动回退。修复前，TP=8 的 Kimi K2.5 回退到参考 Triton MLA 路径，在 MXFP4 下比 AITER 慢很多。该修复随 vLLM 0.18 发布。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/mi355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx b/packages/app/content/blog/zh/mi355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx
index 5e2e6738d..e73832a9a 100644
--- a/packages/app/content/blog/zh/mi355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx
+++ b/packages/app/content/blog/zh/mi355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx
@@ -1,7 +1,7 @@
 ---
 title: 'AMD MI355X Qwen3.5 397B-A17B 推理：SGLang FP8 三个月内每 GPU 吞吐量提升最高 19 倍'
-subtitle: '从 v0.5.8（2 月）→ v0.5.10rc0（4 月）→ v0.5.12（5 月），三次 AITER 内核合入 MI355X 加上从 TP=8 到 TP=2/TP=4 的重新调优，将 Qwen3.5 8k/1k 峰值从 1.3k 推高至 6.4k tok/s/GPU，并将曲线延伸至 75 tok/s/user'
-seoDescription: 'AMD MI355X 在 SGLang FP8 上 3 个月内将 Qwen3.5 397B-A17B 每 GPU 吞吐量最高提升 19 倍——经 AITER 内核从 1.3k 提升至 6.4k tok/s/GPU。'
+subtitle: '从 v0.5.8（2 月）→ v0.5.10rc0（4 月）→ v0.5.12（5 月），三次 AITER kernel 合入 MI355X 加上从 TP=8 到 TP=2/TP=4 的重新调优，将 Qwen3.5 8k/1k 峰值从 1.3k 推高至 6.4k tok/s/GPU，并将曲线延伸至 75 tok/s/user'
+seoDescription: 'AMD MI355X 在 SGLang FP8 上 3 个月内将 Qwen3.5 397B-A17B 每 GPU 吞吐量最高提升 19 倍——经 AITER kernel 从 1.3k 提升至 6.4k tok/s/GPU。'
 date: '2026-05-25'
 publishDate: '2026-05-25'
 tags:
@@ -15,7 +15,7 @@ tags:
   - rocm
 ---
 
-阿里巴巴于 [2026-02-16 发布 Qwen3.5-397B-A17B](https://www.alibabacloud.com/blog/602894) 后 13 周，AMD MI355X 上 SGLang FP8 在 8k/1k 工作负载下的每 GPU 吞吐量在 40 tok/s/user 的等交互性下**最高提升至 19.0 倍**（在仪表板的单调三次 Hermite Pareto 插值上，从 2026-02-20 v0.5.8.post1 基线的 192 tok/s/GPU 提升至 2026-05-19 v0.5.12 运行的 3,660 tok/s/GPU）。这一增长叠加了三个 SGLang 版本以及三次 AITER MoE 内核合入带来的大部分提升，5 月的 v0.5.10rc0 → v0.5.12 镜像升级又在此基础上额外贡献了约 **1.5 倍**。
+阿里巴巴于 [2026-02-16 发布 Qwen3.5-397B-A17B](https://www.alibabacloud.com/blog/602894) 后 13 周，AMD MI355X 上 SGLang FP8 在 8k/1k 工作负载下的每 GPU 吞吐量在 40 tok/s/user 的等交互性下**最高提升至 19.0 倍**（在仪表板的单调三次 Hermite Pareto 插值上，从 2026-02-20 v0.5.8.post1 基线的 192 tok/s/GPU 提升至 2026-05-19 v0.5.12 运行的 3,660 tok/s/GPU）。这一增长叠加了三个 SGLang 版本以及三次 AITER MoE kernel 合入带来的大部分提升，5 月的 v0.5.10rc0 → v0.5.12 镜像升级又在此基础上额外贡献了约 **1.5 倍**。
 
 这完全是软件优化——全程使用相同的 MI355X CDNA4 硅片，TCO 始终为 $1.48/GPU/hr。相关记录：[sgl-project/sglang#20736](https://github.com/sgl-project/sglang/pull/20736)、[sgl-project/sglang#21188](https://github.com/sgl-project/sglang/pull/21188) 和 [sgl-project/sglang#21421](https://github.com/sgl-project/sglang/pull/21421)，均在 3–4 月合入，且均通过 `SGLANG_USE_AITER=1` 开关控制。上游到基准测试的闭环速度本身就是护城河。
 
@@ -36,9 +36,9 @@ Qwen3.5-397B-A17B 是阿里巴巴的 MoE 旗舰模型，于 2026-02-16 发布，
 
 带来这些巨大性能提升的部分优化包括：
 
-- **[sgl-project/sglang PR #20736](https://github.com/sgl-project/sglang/pull/20736)**，由 [zhentaocc](https://github.com/zhentaocc) 提交（合著者 [yichiche](https://github.com/yichiche)），2026-04-15 合入——**在 Qwen2 MoE 和 Qwen3.5 MoE 中将共享专家与路由专家融合**。当 `shared_expert_intermediate_size == moe_intermediate_size` 时，共享专家被视为额外的一个专家（top-K + 1），在单次 AITER MoE 分发中一并处理。每个 MoE 层减少一次内核启动，共享专家权重的 HBM 往返次数也减少。据报告在 Qwen3.5 并发 16 时总吞吐量提升 +4.6%，TPOT 降低 -4%；FP8 精度最初需要 AITER split-K 修复后才能启用。
-- **[sgl-project/sglang PR #21188](https://github.com/sgl-project/sglang/pull/21188)**，由 [yichiche](https://github.com/yichiche) 提交，2026-03-23 合入——**为 `GemmaRMSNorm` 添加 `forward_hip` 路径，使 AMD GPU 使用融合 RMSNorm 内核（AITER `fused_add_rms_norm` / `rms_norm`）而非原生回退路径**。原生路径在 MI355X 上受标量运算限制；融合路径将 Gemma 风格的 `weight + 1.0` 偏移吸收进内核中。据报告在 8x MI355X、并发 1、8k/1k 下：**中位端到端延迟降低 -23.1%，总吞吐量提升 +30.0%，中位首 token 延迟（TTFT）降低 -17.0%**，同时 GSM8K 精度从 0.943 提升至 0.955。
-- **[sgl-project/sglang PR #21421](https://github.com/sgl-project/sglang/pull/21421)**，由 [zhentaocc](https://github.com/zhentaocc) 提交，2026-03-26 合入——**将 AITER 的 `fused_topk` 内核集成到 SGLang 的 `fused_topk` 中，用于 softmax 评分的 MoE top-K 选择**。启用 AITER 时自动分发到 `aiter.fused_moe.fused_topk`。内核微基准测试显示：在 Qwen3.5 形态（E=512, top-K=10）上比 sgl-kernel 基线快约 1.31x 到 **6.29x**，在高 token 数下增益最大。端到端 bs=64 1k/1k 下：总吞吐量提升 +1.9%，GSM8K 精度与基线偏差在 ±0.001 以内。
+- **[sgl-project/sglang PR #20736](https://github.com/sgl-project/sglang/pull/20736)**，由 [zhentaocc](https://github.com/zhentaocc) 提交（合著者 [yichiche](https://github.com/yichiche)），2026-04-15 合入——**在 Qwen2 MoE 和 Qwen3.5 MoE 中将共享专家与路由专家融合**。当 `shared_expert_intermediate_size == moe_intermediate_size` 时，共享专家被视为额外的一个专家（top-K + 1），在单次 AITER MoE 分发中一并处理。每个 MoE 层减少一次 kernel 启动，共享专家权重的 HBM 往返次数也减少。据报告在 Qwen3.5 并发 16 时总吞吐量提升 4.6%，TPOT 降低 4%；FP8 精度最初需要 AITER split-K 修复后才能启用。
+- **[sgl-project/sglang PR #21188](https://github.com/sgl-project/sglang/pull/21188)**，由 [yichiche](https://github.com/yichiche) 提交，2026-03-23 合入——**为 `GemmaRMSNorm` 添加 `forward_hip` 路径，使 AMD GPU 使用融合 RMSNorm kernel（AITER `fused_add_rms_norm` / `rms_norm`）而非原生回退路径**。原生路径在 MI355X 上受标量运算限制；融合路径将 Gemma 风格的 `weight + 1.0` 偏移吸收进 kernel 中。据报告在 8x MI355X、并发 1、8k/1k 下：**中位端到端延迟降低 23.1%，总吞吐量提升 30.0%，中位首 token 延迟（TTFT）降低 17.0%**，同时 GSM8K 精度从 0.943 提升至 0.955。
+- **[sgl-project/sglang PR #21421](https://github.com/sgl-project/sglang/pull/21421)**，由 [zhentaocc](https://github.com/zhentaocc) 提交，2026-03-26 合入——**将 AITER 的 `fused_topk` kernel 集成到 SGLang 的 `fused_topk` 中，用于 softmax 评分的 MoE top-K 选择**。启用 AITER 时自动分发到 `aiter.fused_moe.fused_topk`。kernel 微基准测试显示：在 Qwen3.5 形态（E=512, top-K=10）上比 sgl-kernel 基线快约 1.31x 到 **6.29x**，在高 token 数下增益最大。端到端 bs=64 1k/1k 下：总吞吐量提升 1.9%，GSM8K 精度与基线偏差在 ±0.001 以内。
 
 ## 测试数据
 
@@ -149,7 +149,7 @@ Qwen3.5-397B-A17B 是阿里巴巴的 MoE 旗舰模型，于 2026-02-16 发布，
       "name": "哪些 SGLang PR 推动了 MI355X Qwen3.5 的加速？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "三个由 AMD 编写、通过 SGLANG_USE_AITER=1 开关控制的上游 PR 被纳入 v0.5.10rc0 镜像。PR #20736（zhentaocc 提交，2026-04-15 合入）在 Qwen2/Qwen3.5 MoE 中将共享专家与路由专家融合为单次 AITER 分发中的 topk+1。PR #21188（yichiche 提交，2026-03-23 合入）为 GemmaRMSNorm 添加 forward_hip 路径，使 AMD GPU 使用融合 RMSNorm 内核（AITER fused_add_rms_norm / rms_norm）而非原生回退路径，据报告在 8k/1k 并发 1 下端到端延迟降低 -23.1%，吞吐量提升 +30.0%。PR #21421（zhentaocc 提交，2026-03-26 合入）将 AITER 的 fused_topk 内核集成到 SGLang 的 fused_topk 中用于 softmax MoE top-K 选择，内核微基准测试在 Qwen3.5 形态上比 sgl-kernel 基线快 1.31x 到 6.29x。"
+        "text": "三个由 AMD 编写、通过 SGLANG_USE_AITER=1 开关控制的上游 PR 被纳入 v0.5.10rc0 镜像。PR #20736（zhentaocc 提交，2026-04-15 合入）在 Qwen2/Qwen3.5 MoE 中将共享专家与路由专家融合为单次 AITER 分发中的 topk+1。PR #21188（yichiche 提交，2026-03-23 合入）为 GemmaRMSNorm 添加 forward_hip 路径，使 AMD GPU 使用融合 RMSNorm kernel（AITER fused_add_rms_norm / rms_norm）而非原生回退路径，据报告在 8k/1k 并发 1 下端到端延迟降低 23.1%，吞吐量提升 30.0%。PR #21421（zhentaocc 提交，2026-03-26 合入）将 AITER 的 fused_topk kernel 集成到 SGLang 的 fused_topk 中用于 softmax MoE top-K 选择，kernel 微基准测试在 Qwen3.5 形态上比 sgl-kernel 基线快 1.31x 到 6.29x。"
       }
     },
     {
@@ -157,7 +157,7 @@ Qwen3.5-397B-A17B 是阿里巴巴的 MoE 旗舰模型，于 2026-02-16 发布，
       "name": "从 TP=8 切换到 TP=2/TP=4 带来了多少增益？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "2026 年 4 月的 InferenceX 配方更新将 TP 重新调优、v0.5.10rc0 镜像升级和 AITER PR 打包为一次变更，因此从公开的 InferenceX 数据集无法将它们完全分离。可以确定的是：TP=8 在 Qwen3.5 的 512 专家 MoE 分发路径上浪费了 MI355X 大部分的 tensor-core 算力，而 TP=2 / TP=4 将解码批次分配到更少的 rank 上以保持 AITER 融合 MoE 分发的高效运行。TP 重新调优是 AITER 内核优化在端到端层面得以体现的必要条件。"
+        "text": "2026 年 4 月的 InferenceX 配方更新将 TP 重新调优、v0.5.10rc0 镜像升级和 AITER PR 打包为一次变更，因此从公开的 InferenceX 数据集无法将它们完全分离。可以确定的是：TP=8 在 Qwen3.5 的 512 专家 MoE 分发路径上浪费了 MI355X 大部分的 tensor-core 算力，而 TP=2 / TP=4 将解码批次分配到更少的 rank 上以保持 AITER 融合 MoE 分发的高效运行。TP 重新调优是 AITER kernel 优化在端到端层面得以体现的必要条件。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/minimax-m3-agentx-b200-b300-vs-rack-scale.mdx b/packages/app/content/blog/zh/minimax-m3-agentx-b200-b300-vs-rack-scale.mdx
index 37164b1da..c0faa19d4 100644
--- a/packages/app/content/blog/zh/minimax-m3-agentx-b200-b300-vs-rack-scale.mdx
+++ b/packages/app/content/blog/zh/minimax-m3-agentx-b200-b300-vs-rack-scale.mdx
@@ -30,7 +30,7 @@ tags:
 
 ## 没有人在使用上下文并行
 
-尽管 p90 输入序列长度达到 317k token，目前仍没有任何提交使用[上下文并行](/zh/glossary/context-parallelism)。这恰恰是该技术存在的意义所在，因此这种缺席需要解释。
+尽管 p90 输入序列长度达到 317k token，目前仍没有任何提交使用[上下文并行](/zh/glossary/context-parallelism)。这恰恰是该技术所针对的场景，因此这种缺席需要解释。
 
 M3 只有 4 个 KV head，即使在 TP8 下 DCP 也最多只能到 2；而且 MSA indexer 还需要单独的上下文并行处理，相关 vLLM PR 已经提交。因此这个上限是架构层面的，而不是调优疏忽，它也限定了长上下文并行策略在这个模型上能带来多少收益。
 
@@ -38,7 +38,7 @@ M3 只有 4 个 KV head，即使在 TP8 下 DCP 也最多只能到 2；而且 MS
 
 NVIDIA 所有 Pareto 最优点在并发 20 以上都启用了 [KV offload](/zh/glossary/kv-cache-offload)。而 AMD 的 Pareto 最优点没有一个使用 DRAM KV offload；在其他模型上，AMD 使用 offload 的比例也低于 NVIDIA。
 
-原因很机械：AMD vLLM 上 CPU KV cache offload 所需的 GPU 到 CPU 传输效率极低，因为 hipMemcpyBatchAsync API 直到 ROCm 7.14 才提供。没有它，vLLM 原生的 simple CPU offloading 只能做串行 memcpy，而无法把多次拷贝合并成更大的消息。
+原因在于实现机制：AMD vLLM 上 CPU KV cache offload 所需的 GPU 到 CPU 传输效率极低，因为 hipMemcpyBatchAsync API 直到 ROCm 7.14 才提供。没有它，vLLM 原生的 simple CPU offloading 只能做串行 memcpy，而无法把多次拷贝合并成更大的消息。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/2b40624a-223c-44db-a403-0be563b2af82_2048x1298.png"
diff --git a/packages/app/content/blog/zh/openai-jalapeno-better-than-nvidia.mdx b/packages/app/content/blog/zh/openai-jalapeno-better-than-nvidia.mdx
index 5daf684a3..2ae0aa4f7 100644
--- a/packages/app/content/blog/zh/openai-jalapeno-better-than-nvidia.mdx
+++ b/packages/app/content/blog/zh/openai-jalapeno-better-than-nvidia.mdx
@@ -191,7 +191,7 @@ Jalapeño 的架构设计重点在于消除 KVCache 与权重的内存搬运，
 
 在核心层面，OpenAI 描述的是带 L1 缓存的乱序（OoO）核心。这与我们在其他加速器上看到的模式差异很大：后者普遍采用软件管理的 scratchpad，并搭配某种异步 DMA 支持。同样，这里的论点是它能让 Jalapeño 避免诸如 barrier 延迟这类固定开销；而在 GPU 等其他加速器上，这些开销必须靠给每个核心分配更多工作来掩盖或摊薄，也因此更难逼近原始的峰值带宽与算力。
 
-代价是 Jalapeño 因而更依赖良好的预取来保证内存请求及时到达，而这一点可预测性更差、也更难推理。不过，只要 Codex 处在一个好的 harness 中并能拿到详细 trace，为给定形状找到预取最优的 kernel 很可能几乎不需要人工介入。我们认为 OpenAI 正是这样做的，才得以如此迅速地跑通 DeepSeek R1、Kimi K2.5 和 GPT-OSS。
+代价是 Jalapeño 因而更依赖良好的预取来保证内存请求及时到达，而这一点可预测性更差、也更难分析。不过，只要 Codex 处在一个好的 harness 中并能拿到详细 trace，为给定形状找到预取最优的 kernel 很可能几乎不需要人工介入。我们认为 OpenAI 正是这样做的，才得以如此迅速地跑通 DeepSeek R1、Kimi K2.5 和 GPT-OSS。
 
 这些核心还支持「小」矩阵维度。视其小到什么程度，这应当能让它在不同模型和 batch 维度上更通用，也更不易受矩阵维度对齐、padding 开销和 tiling 低效的影响。相比之下，TPU、Trainium 和 Etched 的芯片都采用很大的脉动阵列，往往需要较大 batch 或恰好可整除的模型维度，才能避免 tiling 带来的浪费。
 
diff --git a/packages/app/content/blog/zh/qwen3-5-397b-agentx-b300-fp4-vs-h100.mdx b/packages/app/content/blog/zh/qwen3-5-397b-agentx-b300-fp4-vs-h100.mdx
index 08107acff..35c161461 100644
--- a/packages/app/content/blog/zh/qwen3-5-397b-agentx-b300-fp4-vs-h100.mdx
+++ b/packages/app/content/blog/zh/qwen3-5-397b-agentx-b300-fp4-vs-h100.mdx
@@ -34,7 +34,7 @@ tags:
 
 ## 请按你自己的运行点来读
 
-12 倍的总体比值是一个标题，而不是部署方案。真正承载决策的是曲线：先确定你的产品需要的[交互性](/zh/glossary/interactivity)，在该点读取每套系统的表现，并在同一点核对首 token 延迟，然后再下结论。
+12 倍的总体比值只是一个吸睛的数字，而不是部署方案。真正承载决策的是曲线：先确定你的产品需要的[交互性](/zh/glossary/interactivity)，在该点读取每套系统的表现，并在同一点核对首 token 延迟，然后再下结论。
 
 这也是各模型的 AgentX 图表默认展示完整前沿、而不是单个数字的原因。较老的硬件可能在低并发下于每美元性能上仍有竞争力，却在高吞吐区间完全掉队；单一比值无法同时表达这条曲线的两端。
 
diff --git a/packages/app/content/blog/zh/sglang-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx b/packages/app/content/blog/zh/sglang-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx
index a631535a9..bf4c39521 100644
--- a/packages/app/content/blog/zh/sglang-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx
+++ b/packages/app/content/blog/zh/sglang-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx
@@ -1,6 +1,6 @@
 ---
 title: 'SGLang 0.5.6 在 B200 DeepSeek R1 FP4 上的表现：低并发下最高提升 1.8 倍'
-subtitle: '针对 DeepSeek V3 的分段 CUDA graph、统一事件循环和 JIT 内核将 8k/1k 吞吐量从 508 提升至 907 tok/s/GPU，使用相同的 16 GPU B200 资源池'
+subtitle: '针对 DeepSeek V3 的分段 CUDA graph、统一事件循环和 JIT kernel 将 8k/1k 吞吐量从 508 提升至 907 tok/s/GPU，使用相同的 16 GPU B200 资源池'
 date: '2026-05-02'
 publishDate: '2026-05-02'
 tags:
@@ -22,13 +22,13 @@ SGLang 0.5.6 于 2025-12-03 发布，InferenceX 基准测试在 28 天后的 202
   点击查看完整 InferenceX 仪表板 →
 </DashboardCTA>
 
-性能提升在低并发下最为显著。在并发数 4 和 8 时，解码循环的每步耗时中有相当比例花在 Python 调度器和内核分发代码上而非矩阵乘法中，因此 0.5.6 的调度器和计算图优化效果最为直接。在高并发下 tensor core 接近饱和，较小的吞吐量提升（并发数 64 为 1.03 倍，并发数 128 为 1.16 倍）来自重构后的注意力内核路径。
+性能提升在低并发下最为显著。在并发数 4 和 8 时，解码循环的每步耗时中有相当比例花在 Python 调度器和 kernel 分发代码上而非矩阵乘法中，因此 0.5.6 的调度器和计算图优化效果最为直接。在高并发下 tensor core 接近饱和，较小的吞吐量提升（并发数 64 为 1.03 倍，并发数 128 为 1.16 倍）来自重构后的注意力 kernel 路径。
 
 ## SGLang 0.5.6 中的关键更新
 
-[SGLang 0.5.6](https://github.com/sgl-project/sglang/releases/tag/v0.5.6) 于 2025-12-03 发布。三项更新与低并发吞吐量提升直接相关。分段 CUDA graph 支持扩展到了 DeepSeek V3 和 MLA 注意力路径，减少了构建和回放计算图的每步 Python 开销。事件循环在 PD 分离式、重叠式和 DP 注意力服务模式间统一，降低了内部循环开销。引入了 JIT 内核，减少了启动成本并允许内核编译针对运行时观察到的形状进行特化。
+[SGLang 0.5.6](https://github.com/sgl-project/sglang/releases/tag/v0.5.6) 于 2025-12-03 发布。三项更新与低并发吞吐量提升直接相关。分段 CUDA graph 支持扩展到了 DeepSeek V3 和 MLA 注意力路径，减少了构建和回放计算图的每步 Python 开销。事件循环在 PD 分离式、重叠式和 DP 注意力服务模式间统一，降低了内部循环开销。引入了 JIT kernel，减少了启动成本并允许 kernel 编译针对运行时观察到的形状进行特化。
 
-另外三项 0.5.6 更新影响注意力内核路径。MHA 和 MLA KV 缓存重构以支持 FP4。FlashInfer TRTLLM GEN MHA 路径重新启用。FlashInfer 更新至 0.5.2。这些在高并发下更为重要，此时 KV 缓存较大且注意力计算是主要开销。并发数 128 下的 1.16 倍提升即来自此路径。
+另外三项 0.5.6 更新影响注意力 kernel 路径。MHA 和 MLA KV 缓存重构以支持 FP4。FlashInfer TRTLLM GEN MHA 路径重新启用。FlashInfer 更新至 0.5.2。这些在高并发下更为重要，此时 KV 缓存较大且注意力计算是主要开销。并发数 128 下的 1.16 倍提升即来自此路径。
 
 ## 基准测试数据
 
@@ -64,7 +64,7 @@ B200 SGLang，DeepSeek R1 NVFP4，TP 4 / EP 4 解码，16 GPU 非分离式资源
 
 ## 各项优化在曲线上的作用位置
 
-TP 4 / EP 4 配置下 DeepSeek R1 NVFP4 的解码有固定的每步开销。内核启动、Python 调度器处理和计算图构建是主要贡献项，与注意力和 MoE GEMM 计算并列。在并发数 4 时，GEMM 规模较小，固定开销占步骤耗时的比例显著。减少固定开销直接加速了每步执行，这就是最大提升比（并发数 4 为 1.79 倍，并发数 8 为 1.59 倍）出现在低并发的原因。分段 CUDA graph 和 JIT 内核是相关的发布项。
+TP 4 / EP 4 配置下 DeepSeek R1 NVFP4 的解码有固定的每步开销。kernel 启动、Python 调度器处理和计算图构建是主要贡献项，与注意力和 MoE GEMM 计算并列。在并发数 4 时，GEMM 规模较小，固定开销占步骤耗时的比例显著。减少固定开销直接加速了每步执行，这就是最大提升比（并发数 4 为 1.79 倍，并发数 8 为 1.59 倍）出现在低并发的原因。分段 CUDA graph 和 JIT kernel 是相关的发布项。
 
 在并发数 128 时，KV 缓存较大，注意力计算是每步的主要开销。重构后的 MHA 和 MLA KV 缓存对 FP4 的支持以及重新启用的 FlashInfer TRTLLM GEN MHA 路径在并发数 128 下产生了 1.16 倍的提升，尽管调度器开销的减少在此并发量级已趋于平坦。在中等并发数（16、32、64）下，两种效果均不占主导，吞吐量提升较小且不太稳定（1.02 倍、1.33 倍、1.03 倍）。
 
@@ -89,7 +89,7 @@ TP 4 / EP 4 配置下 DeepSeek R1 NVFP4 的解码有固定的每步开销。内
       "name": "SGLang 0.5.6 中哪些变更带来了性能提升？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "三项更新在低并发下贡献最大。分段 CUDA graph 支持扩展到了 DeepSeek V3 和 MLA 注意力路径，减少了每步 Python 和内核启动开销。事件循环在 PD 分离式、重叠式和 DP 注意力服务模式间统一，收紧了内部解码循环。引入了 JIT 内核，降低了启动成本并允许内核编译针对运行时观察到的形状进行特化。MHA 和 MLA KV 缓存重构以支持 FP4，FlashInfer 更新至 0.5.2，这些提高了注意力内核的上限，但对低并发吞吐量提升贡献较小。"
+        "text": "三项更新在低并发下贡献最大。分段 CUDA graph 支持扩展到了 DeepSeek V3 和 MLA 注意力路径，减少了每步 Python 和 kernel 启动开销。事件循环在 PD 分离式、重叠式和 DP 注意力服务模式间统一，收紧了内部解码循环。引入了 JIT kernel，降低了启动成本并允许 kernel 编译针对运行时观察到的形状进行特化。MHA 和 MLA KV 缓存重构以支持 FP4，FlashInfer 更新至 0.5.2，这些提高了注意力 kernel 的上限，但对低并发吞吐量提升贡献较小。"
       }
     },
     {
@@ -97,7 +97,7 @@ TP 4 / EP 4 配置下 DeepSeek R1 NVFP4 的解码有固定的每步开销。内
       "name": "为什么 0.5.6 的性能提升在低并发下最大？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "调度器和内核启动开销在小批量时占每个解码步骤的比例更大。在 8k/1k 并发数 4 下，MoE GEMM 形状较小，每步固定开销占解码步骤的比例显著，因此分段 CUDA graph 和 JIT 内核的变更带来了明显的 1.79 倍提升。在中等并发（16 至 64）时，调度器优化的收益减弱而注意力内核尚未成为主导，提升比率较小且不太稳定。在并发数 128 时 KV 缓存较大，注意力计算主导了每步耗时，重构的 MHA 和 MLA KV 缓存加上重新启用的 FlashInfer TRTLLM GEN MHA 路径带来了 1.16 倍的提升。"
+        "text": "调度器和 kernel 启动开销在小批量时占每个解码步骤的比例更大。在 8k/1k 并发数 4 下，MoE GEMM 形状较小，每步固定开销占解码步骤的比例显著，因此分段 CUDA graph 和 JIT kernel 的变更带来了明显的 1.79 倍提升。在中等并发（16 至 64）时，调度器优化的收益减弱而注意力 kernel 尚未成为主导，提升比率较小且不太稳定。在并发数 128 时 KV 缓存较大，注意力计算主导了每步耗时，重构的 MHA 和 MLA KV 缓存加上重新启用的 FlashInfer TRTLLM GEN MHA 路径带来了 1.16 倍的提升。"
       }
     },
     {
diff --git a/packages/app/content/blog/zh/sparse-savings-persistent-demand-inside-glm53.mdx b/packages/app/content/blog/zh/sparse-savings-persistent-demand-inside-glm53.mdx
index fd785a6aa..dc21783a5 100644
--- a/packages/app/content/blog/zh/sparse-savings-persistent-demand-inside-glm53.mdx
+++ b/packages/app/content/blog/zh/sparse-savings-persistent-demand-inside-glm53.mdx
@@ -97,7 +97,7 @@ GLM 5.2 / 5.3 的注意力架构降低了内存需求，但长时间运行的智
 
 ### TileRT
 
-TileRT 对 GLM5.3 的支持首先落地于 AMD MI355X。TileRT 是一种低延迟 LLM 推理引擎，将 decode 编译成单个持久化内核，减少内核启动开销，并让计算、内存访问和通信重叠。
+TileRT 对 GLM5.3 的支持首先落地于 AMD MI355X。TileRT 是一种低延迟 LLM 推理引擎，将 decode 编译成单个持久化 kernel，减少 kernel 启动开销，并让计算、内存访问和通信重叠。
 
 它优先提高单用户 token 生成速度，而非追求最大批处理吞吐量；prefill 则由 vLLM 处理。
 
@@ -138,7 +138,7 @@ lightning indexer 在功能上类似**轻量级注意力机制**。query 和 key
 
 ### 稀疏 MLA
 
-[我们在 Kimi K3 文章中解释过](https://newsletter.semianalysis.com/i/209189055/multi-head-latent-attention)，MLA 有 Multi-Head Attention（MHA）和 Multi-Query Attention（MQA）两种运行模式。两者各有取舍：MHA 的 FLOPs 较少，但内存成本是 42 倍；MQA 的内存成本较低，但 FLOPs 最多达到 3.4 倍。DSA 使用 MQA 模式，因为稀疏注意力关注的 token 更少，可以缓解其较高的计算量。不过，实际存在一个序列长度阈值，低于该阈值时 MHA 反而更高效。直观上，较短序列下内存加载时间的主导性较弱，FLOPs 较少的 MHA 就可能占优。vLLM 实现了这一机制：数据并行时，序列长度从 2K 到约 5K 使用 MHA；张量并行时，则从 2K 到约 77K 使用 MHA。下限设为 2K，是因为 top K 为 2048，而低于 2K 时使用稠密注意力。
+[我们在 Kimi K3 文章中解释过](https://newsletter.semianalysis.com/i/209189055/multi-head-latent-attention)，MLA 有 Multi-Head Attention（MHA）和 Multi-Query Attention（MQA）两种运行模式。两者各有取舍：MHA 的 FLOPs 较少，但内存成本是 MQA 的 42 倍；MQA 的内存成本较低，但 FLOPs 最多为 MHA 的 3.4 倍。DSA 使用 MQA 模式，因为稀疏注意力关注的 token 更少，可以缓解其较高的计算量。不过，实际存在一个序列长度阈值，低于该阈值时 MHA 反而更高效。直观上，较短序列下内存加载时间的主导性较弱，FLOPs 较少的 MHA 就可能占优。vLLM 实现了这一机制：数据并行时，序列长度从 2K 到约 5K 使用 MHA；张量并行时，则从 2K 到约 77K 使用 MHA。下限设为 2K，是因为 top K 为 2048，而低于 2K 时使用稠密注意力。
 
 <Figure
   src="/images/sparse-savings-persistent-demand-inside-glm53/sparse-mla-mha-vs-mqa.png"
diff --git a/packages/app/content/blog/zh/tpu-inferencex-full-steam.mdx b/packages/app/content/blog/zh/tpu-inferencex-full-steam.mdx
index 3a34eff0b..5d275c04b 100644
--- a/packages/app/content/blog/zh/tpu-inferencex-full-steam.mdx
+++ b/packages/app/content/blog/zh/tpu-inferencex-full-steam.mdx
@@ -55,7 +55,7 @@ Google 用十多年时间展示了自己能用 TPU 做出什么。现在，轮
 
 在 100 tokens/s/user 的交互速度下，Ironwood 每百万 total token 的成本约为 $0.181，B200 为 $0.222，B300 为 $0.276。也就是说，在提供相同单用户生成速度的前提下，成本比 B200 低约 19%，比 B300 低约 34%。
 
-这一对比使用的是外部 TPU TCO，即一家超大规模实验室（hyperscaler lab）购买 TPU 时的成本，对照 B200/B300 的 TCO。[去年，SemiAnalysis Accelerator Model 率先披露 Google 正在直接销售 TPU，而不再只是通过 Google Cloud 出租](https://semianalysis.com/accelerator-hbm-model/)。在大部分交互速度区间内，TPU 更低的小时成本足以抵消其较低的吞吐量。[SemiAnalysis TCO Model 提供了 TPU BoM 估算与 TCO 估算的完整拆解。](https://semianalysis.com/ai-cloud-tco-model/)
+这一对比使用的是外部 TPU TCO，即一家超大规模实验室（hyperscaler lab）购买 TPU 时的成本，并以 B200/B300 的 TCO 作为对照。[去年，SemiAnalysis Accelerator Model 率先披露 Google 正在直接销售 TPU，而不再只是通过 Google Cloud 出租](https://semianalysis.com/accelerator-hbm-model/)。在大部分交互速度区间内，TPU 更低的小时成本足以抵消其较低的吞吐量。[SemiAnalysis TCO Model 提供了 TPU BoM 估算与 TCO 估算的完整拆解。](https://semianalysis.com/ai-cloud-tco-model/)
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/8047a697-0d6f-41fe-8c16-71998778ecb4_2048x1228.png"
@@ -69,7 +69,7 @@ Google 用十多年时间展示了自己能用 TPU 做出什么。现在，轮
   caption="来源：InferenceX Preview"
 />
 
-在原始性能曲线的大部分区间里，TPU 并没有超过 NVIDIA GPU。但这种对比没有考虑 TPU 更低的 TCO。**TPU 的买家真正关心的是能赚多少收入，也就是每美元性能和每瓦性能。**
+在原始性能曲线的大部分区间里，TPU 并没有超过 NVIDIA GPU。但这种对比没有考虑 TPU 更低的 TCO。**TPU 的买家主要关心的是能赚多少收入，也就是每美元性能和每瓦性能。**
 
 即便如此，在 20 tok/s/user 的交互速度下，Ironwood 在原始吞吐量上同样领先：达到 9,364 total tokens/s/chip，B200 为 8,903，B300 为 8,925。在这些运行中，这比两款 GPU 都高出约 5%。再叠加更低的建模小时成本，Ironwood 的每美元 token 数比 B200 多 50.4%，比 B300 多 96.0%。
 
@@ -127,7 +127,7 @@ Google 在内部生产环境中运行分离式推理已有多年，那条路径
   点击查看完整 InferenceX 仪表板 →
 </DashboardCTA>
 
-## 全新原生、一等公民的 TorchTPU 后端对比此前的 TorchAX 软件栈
+## 推理服务：全新原生、一等公民的 TorchTPU 后端对比此前的 TorchAX 软件栈
 
 ### 此前的 TorchAX vLLM 后端
 
@@ -139,7 +139,7 @@ vLLM 对 TPU 的支持经历了三个阶段：
 - 当前公开的后端 [tpu-inference](https://vllm.ai/blog/2025-10-16-vllm-tpu) 在有针对 TPU 优化的 JAX 实现时优先使用它；否则由 TorchAX 把原始 PyTorch 模型翻译成 JAX 可以执行的算子。目标是复用成熟的 TPU 原语和并行支持，而不必重写每一个 PyTorch 模型。
 - 即将推出的第三种设计 TorchTPU，让 vLLM 把 TPU 当作原生 PyTorch 设备。它将成为今后 SGLang 和 vLLM 在 TPU 上的首选后端。
 
-下图聚焦第二阶段，展示了 vLLM 的 tpu-inference 后端如何把直接的 JAX 模型与通过 TorchAX 运行的 PyTorch 模型结合起来。
+下图聚焦第二阶段，展示了 vLLM 的 tpu-inference 后端如何把直接以 JAX 实现的模型与通过 TorchAX 运行的 PyTorch 模型结合起来。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/678ca15d-f0c0-4c36-a63f-b1108939cbb1_2048x1620.png"
@@ -205,7 +205,7 @@ vLLM 和 SGLang 是两大主流开源生产级推理服务栈。Inferact、Radix
 
 ## TPU 推理优化深度解析
 
-为原生 TorchTPU 服务栈的首个 bring-up 模型优化 TPU 推理，是一场投入了数百工程小时和大量 PR 的冲刺。正如后文所述，TPU 架构与 GPU 架构不同，因此需要一套专属优化才能高效运行模型。下面介绍在 Ironwood 上提升（某些情况下是首次实现）Qwen3.5-397B 及其他模型性能的各项优化。大部分 Pallas kernel 优化都可以迁移到全新的原生 TorchTPU 软件栈。
+为原生 TorchTPU 服务栈的首个 bring-up 模型优化 TPU 推理，是一场投入了数百工程小时和大量 PR 的冲刺。正如后文所述，TPU 架构与 GPU 架构不同，因此需要一套专属优化才能高效运行模型。下面介绍在 Ironwood 上改善 Qwen3.5-397B 及其他模型性能的各项优化；其中一些改动使这些模型得以运行。大部分 Pallas kernel 优化都可以迁移到全新的原生 TorchTPU 软件栈。
 
 ### DP Attention 优化
 
@@ -249,7 +249,7 @@ Google 还[在 SparseCore 上实现了 ReduceScatter 集合通信](https://githu
 
 ### 优化 MoE 路由与专家 Kernel
 
-混合专家层会为每个专家产生大小不规则的 token 分组，这些参差不齐的分组必须被重排成 TPU 矩阵单元能够高效消费的形式。下面的一些改动是对路由和 grouped-matmul 后端的通用改进，任何 MoE 模型都能受益；另一些则是直接在 Qwen3.5 上测得的。
+混合专家层会为每个专家产生大小不规则的 token 分组，这些参差不齐的分组必须被重排成 TPU 矩阵单元能够高效处理的形式。下面的一些改动是对路由和 grouped-matmul 后端的通用改进，任何 MoE 模型都能受益；另一些则是直接在 Qwen3.5 上测得的。
 
 [第二版 grouped matmul](https://github.com/vllm-project/tpu-inference/pull/1688) 重新设计了向 MXU 馈送专家输入的方式。它去掉了冗余的 tile 计算，按有效行数而非 padding 后的最大值确定传输大小，对专家权重做三重缓冲以便在计算当前分组时下一分组的权重已在传输途中，并把分组元数据的生成融合进 kernel。
 
@@ -357,7 +357,7 @@ Qwen3.5 是一个混合模型，有两类状态：GQA 层积累随每个 token 
 
 ### Paged Attention 中的 Lane 布局与流水线深度
 
-有两个硬件事实决定了 KV cache 在 TPU 上的布局方式；下一节会更详细地讨论 TPU 硬件。第一，向量单元处理的 tile 最后一维宽度为 128 个 lane，因此任何末尾维度小于 128 的数组都会被 padding 到 128。第二，Pallas kernel 通过双缓冲来隐藏 HBM 延迟：在计算当前 block 的同时预取下一个 block。两个 block 都必须放进 VMEM，因此计算 block 的大小决定了预取能走多远。这两个约束此前都在消耗容量和吞吐量。
+有两个硬件事实决定了 KV cache 在 TPU 上的布局方式；下一节会更详细地讨论 TPU 硬件。第一，向量单元所处理的 tile，其最后一维宽度为 128 个 lane，因此任何末尾维度小于 128 的数组都会被 padding 到 128。第二，Pallas kernel 通过双缓冲来隐藏 HBM 延迟：在计算当前 block 的同时预取下一个 block。两个 block 都必须放进 VMEM，因此计算 block 的大小决定了预取能走多远。这两个约束此前都在消耗容量和吞吐量。
 
 在批量注意力 kernel 中，KV cache 沿 head 维度打包 key 和 value，FP8 下的打包因子为 4。而每个设备只有一个 KV head 的模型只有两样东西可以打包，于是每个 tile 有一半浪费在 padding 上。[sequence-on-lane 布局](https://github.com/vllm-project/tpu-inference/pull/3170)改为把 page 内的 token 放在 128 lane 的轴上，把 head 维度放在 sublane 轴上，从而解决了这一问题。可用 KV page 数翻倍（在报告的配置中从 5,141 增至 10,283），head 维度也只需是 32 的倍数而非 128 的倍数，使 head dim 为 64 的模型同样能使用该 kernel。这一布局在低并发下使每 token 延迟增加约 3%，但在 8k1k、并发 128 下，多出来的容量把吞吐量提升了 16.5%，并把 TTFT 中位数降低了 95%，因为请求不再需要等待 KV 空间。
 
@@ -367,7 +367,7 @@ Qwen3.5 是一个混合模型，有两类状态：GQA 层积累随每个 token 
   caption="来源：SemiAnalysis"
 />
 
-RPA v3 的 block 大小启发式规则也有类似的盲点。在 v7x 的 decode 阶段，它把 KV 计算 block 设为与 KV 读取 block 相同，约 16k 个 token，几乎没有给预取缓冲区留下任何 VMEM。[把两者拆开](https://github.com/vllm-project/tpu-inference/pull/3102)后，KV 读取 block 保持 16k 个 token，计算 block 缩小到 4k。这给了流水线在 MXU 之前跑起来的空间，使 decode 吞吐量从 64.9k 提升到 96.3k tokens/s，提升 49%，并在 Qwen3-0.6B 上通过四次运行复现。在 block 大小的扫描中，吞吐量呈现出干净的倒 U 形曲线。由于调优参数表为每种形状只存一个 block 大小，无法表达这一改进，因此该改动最初以环境变量覆盖的形式落地。后续改动扩展了该表，以分别保存读取和计算两个大小。
+RPA v3 的 block 大小启发式规则也有类似的盲点。在 v7x 的 decode 阶段，它把 KV 计算 block 设为与 KV 读取 block 相同，约 16k 个 token，几乎没有给预取缓冲区留下任何 VMEM。[把两者拆开](https://github.com/vllm-project/tpu-inference/pull/3102)后，KV 读取 block 保持 16k 个 token，计算 block 缩小到 4k。这给了流水线在 MXU 之前跑起来的空间，使 decode 吞吐量从 64.9k 提升到 96.3k tokens/s，提升 49%，并在 Qwen3-0.6B 上通过四次运行复现。在 block 大小的扫描中，吞吐量呈现出清晰的倒 U 形曲线。由于调优参数表为每种形状只存一个 block 大小，无法表达这一改进，因此该改动最初以环境变量覆盖的形式落地。后续改动扩展了该表，以分别保存读取和计算两个大小。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/72c0863c-a506-404a-8522-70bcadb3a89a_2048x756.png"
@@ -413,7 +413,7 @@ TPUv7 Ironwood 打破了 TPU v4 和 TPU v5p 所采用的「MegaCore」惯例：
 
 #### TPU 很挑剔
 
-GPU 的矩阵核心消费的是小 tile，因此各种 head 维度、专家宽度和切分后的 KV head 数量都能接近峰值。在 H100 或 B200 上，把维度从 128 改成 64 几乎没有代价，还能换来更便宜的注意力层。GPU 架构让研究人员可以优先追求评估表现，而不损失推理性能。但在 TPU 上，这个超参数变成了一种取舍。
+GPU 的矩阵核心处理的是小 tile，因此各种 head 维度、专家宽度和切分后的 KV head 数量都能接近峰值。在 H100 或 B200 上，把维度从 128 改成 64 几乎没有代价，还能换来更便宜的注意力层。GPU 架构让研究人员可以优先追求评估表现，而不损失推理性能。但在 TPU 上，这个超参数变成了一种取舍。
 
 如前所述，这些选择在 256 宽的 systolic array 上并不免费。按照把 Llama 3 8B 注意力矩阵乘法上限压到 50% 的同一套算术，head 维度 64 在写下第一行 kernel 代码之前就把上限压到了 25%。gpt-oss 的 head 维度就是 64。DeepSeek 的 MLA 把 query/key 维度拆成 128 加 64、共 192，对任何 2 的幂次阵列都不友好，对更宽的阵列更是如此。
 
@@ -426,7 +426,7 @@ GPU 的矩阵核心消费的是小 tile，因此各种 head 维度、专家宽
 
 ### Torus 拓扑
 
-大规模推理和训练运行在数千颗需要持续相互通信的芯片上。TPU 通过一种名为 ICI（芯片间互连）的定制网络点对点连接。ICI 完全绕过主机 CPU，让芯片可以直接交换激活值和梯度，而不必经过 PCIe 和通用网卡。ICI 背后的拓扑随代际演进：TPU v2 和 v3 使用 2D torus，每颗芯片连接 4 个邻居；从 TPU v4 和 v5p 开始，Google 转向 3D torus，每颗芯片沿 +/-X、+/-Y、+/-Z 三个轴连接 6 个邻居。Ironwood（TPUv7）沿用了这一 3D torus。基本构建单元是一个由 64 颗芯片组成的 4x4x4 立方体，其规模恰好能整齐地映射到一个物理服务器机架上。
+大规模推理和训练运行在数千颗需要持续相互通信的芯片上。TPU 之间通过一种名为 ICI（芯片间互连）的定制网络点对点互连。ICI 完全绕过主机 CPU，让芯片可以直接交换激活值和梯度，而不必经过 PCIe 和通用网卡。ICI 背后的拓扑随代际演进：TPU v2 和 v3 使用 2D torus，每颗芯片连接 4 个邻居；从 TPU v4 和 v5p 开始，Google 转向 3D torus，每颗芯片沿 +/-X、+/-Y、+/-Z 三个轴连接 6 个邻居。Ironwood（TPUv7）沿用了这一 3D torus。基本构建单元是一个由 64 颗芯片组成的 4x4x4 立方体，其规模恰好能整齐地映射到一个物理服务器机架上。
 
 <Figure
   src="https://substack-post-media.s3.amazonaws.com/public/images/f07dc2e7-090b-472a-a2bf-82c6fbb1cb67_1456x1956.png"
diff --git a/packages/app/content/blog/zh/ultra-high-interactivity-on-nvidia.mdx b/packages/app/content/blog/zh/ultra-high-interactivity-on-nvidia.mdx
index 45cdc7a95..f4702baf5 100644
--- a/packages/app/content/blog/zh/ultra-high-interactivity-on-nvidia.mdx
+++ b/packages/app/content/blog/zh/ultra-high-interactivity-on-nvidia.mdx
@@ -62,7 +62,7 @@ InferenceX 是我们开源、厂商中立、持续更新的 AI 推理基准测
 
 任何推理系统都必须在两个相互竞争的目标之间取得平衡。
 
-- **交互性（tok/s/user）** 衡量单个用户接收 token 的速度，是 TPOT 的倒数。它决定了响应体验是流畅还是迟滞。
+- **交互性（tok/s/user）** 衡量单个用户接收 token 的速度，是 TPOT 的倒数。它决定了响应体验是流畅还是卡顿。
 - **吞吐量（tok/s/GPU）** 衡量系统在所有用户上合计产出的 token 数量，很大程度上决定了每 token 成本。
 
 批处理通过同时处理更多请求来提升总吞吐量，但每个用户等待每个 token 的时间通常更长。小批量则相反：提升单用户速度，同时降低每张 GPU 完成的有效工作量。
@@ -125,7 +125,7 @@ B200 上的 TileRT 自成一档。在 8k/1k 输入／输出 token 场景下，Ti
 
 ## TileRT 究竟是什么？
 
-前面简要介绍了 TileRT 的作用并展示了部分基准结果，现在让我们停下来更深入地解释 TileRT 是什么、如何工作。传统服务引擎以成千上万个独立 GPU kernel 依次启动的方式运行。这些启动与收尾意味着 GPU 花费了惊人的时间在等待上；这类开销对中低交互性推理或许无关紧要，但对超高交互性推理（即低延迟推理）影响显著。更糟的是，每个 kernel 都会把未完成的中间结果写回 HBM。在小批量下问题更严重，因为 kernel 规模不足以摊薄启动延迟、同步与调度开销。
+前面简要介绍了 TileRT 的作用并展示了部分基准结果，现在让我们停下来更深入地解释 TileRT 是什么、如何工作。传统服务引擎以成千上万个独立 GPU kernel 依次启动的方式运行。这些启动与收尾意味着 GPU 有惊人比例的时间花在等待上；这类开销对中低交互性推理或许无关紧要，但对超高交互性推理（即低延迟推理）影响显著。更糟的是，每个 kernel 都会把未完成的中间结果写回 HBM。在小批量下问题更严重，因为 kernel 规模不足以摊薄启动延迟、同步与调度开销。
 
 如前所述，在批大小为 1、仅使用单台 HGX H200 服务器（合计 38.4 TB/s HBM 内存带宽）时，MXFP8 精度下每 token 的激活参数访存量为 42 GB。理论上，若只受内存带宽约束，那么即便不使用投机解码，推理也应能达到最高 1,000 tok/s/user 的交互性。现实显然并非如此。症结在于 GPU 的编程与架构模型传统上并非为低延迟而设计。尽管每 GPU 内存带宽每代提升 2–3 倍，内存延迟却完全没有改善——而 HBM 价格还在持续上涨。
 
@@ -297,7 +297,7 @@ InferenceX 的长上下文多轮编码场景 AgentX 现已在具备对应数据
       "name": "TileRT 会取代 vLLM 吗？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "不会。vLLM 仍是高吞吐量预填充引擎及其外围服务层，包括调度器、分块预填充、前缀缓存、OpenAI 兼容 API 与运维工具。只有对延迟敏感的解码流量转移到 TileRT，通过 vLLM 的 MultiConnector API 将 TileRTConnector 与原生 connector 组合实现。一个共享的 vLLM 预填充池可同时供给 TileRT 超高交互性解码池与常规 vLLM 解码池。TileRT 使用 Mooncake Transfer Engine 与 NIXL Transfer Engine 在预填充与解码之间搬运 KV cache。"
+        "text": "不会。vLLM 仍是高吞吐量预填充引擎及其外围服务层，包括调度器、分块预填充、前缀缓存、OpenAI 兼容 API 与运维工具。只有对延迟敏感的解码流量转移到 TileRT，这一路由通过 vLLM 的 MultiConnector API 组合 TileRTConnector 与原生 connector 实现。一个共享的 vLLM 预填充池可同时供给 TileRT 超高交互性解码池与常规 vLLM 解码池。TileRT 使用 Mooncake Transfer Engine 与 NIXL Transfer Engine 在预填充与解码之间搬运 KV cache。"
       }
     },
     {
@@ -313,7 +313,7 @@ InferenceX 的长上下文多轮编码场景 AgentX 现已在具备对应数据
       "name": "为什么 TileRT 的开发进展缓慢？",
       "acceptedAnswer": {
         "@type": "Answer",
-        "text": "静态提前编译意味着模型目录很小（目前为 GLM-5/5.1 与 DeepSeek-V3.2）、依赖被硬性锁定，且每新增一种架构都需要实打实的工程投入。持久化 engine kernel 要求预先决定 tile 形状、流水线深度、缓冲区在寄存器共享内存与 L2 中的驻留策略、warp group 在加载计算与通信之间的划分、集合通信在何处融合进 tile 流程，以及哪些 GPU 承担专用角色。更换注意力机制或路由方案会使这套调度的大部分失效。TileOPs 旨在减轻该负担，它以机器可读的 manifest 声明每个算子，驱动代码生成、测试，并以硬件上界为基准进行性能评测。"
+        "text": "静态提前编译意味着模型目录很小（目前为 GLM-5/5.1 与 DeepSeek-V3.2）、依赖被硬性锁定，且每新增一种架构都需要实打实的工程投入。持久化 engine kernel 要求预先决定 tile 形状、流水线深度、缓冲区在寄存器、共享内存与 L2 中的驻留策略、warp group 在加载、计算与通信之间的划分、集合通信在何处融合进 tile 流程，以及哪些 GPU 承担专用角色。更换注意力机制或路由方案会使这套调度的大部分失效。TileOPs 旨在减轻该负担，它以机器可读的 manifest 声明每个算子，驱动代码生成、测试，并以硬件上界为基准进行性能评测。"
       }
     }
   ]
diff --git a/packages/app/content/blog/zh/vera-rubin-nvl72-vs-gb200-nvl72-inference.mdx b/packages/app/content/blog/zh/vera-rubin-nvl72-vs-gb200-nvl72-inference.mdx
index 6385c0653..46cc94e31 100644
--- a/packages/app/content/blog/zh/vera-rubin-nvl72-vs-gb200-nvl72-inference.mdx
+++ b/packages/app/content/blog/zh/vera-rubin-nvl72-vs-gb200-nvl72-inference.mdx
@@ -28,7 +28,7 @@ _相关阅读：[Vera Rubin – 极致协同设计：从 Grace Blackwell Oberon
 
 目前 VR NVL72 的早期指标均来自 CoreWeave，我们尚未独立验证。Nvidia 已承诺在 2026 自然年第三季度前向 InferenceX 提交可验证的数据。Google 预计将在未来几个月内提交 TPUv7 结果，AMD 也已承诺提交 MI455X UALoE72。等这些数据落地后，整个生态系统将获得一份跨系统的客观对比。
 
-在本文中，我们将对照多条基线来拆解 Nvidia 的 Rubin 性能宣称，展示 Rubin 明显领先 Blackwell 的地方，以及领先幅度较薄弱的地方。我们还将基于已有的 Rubin 总拥有成本（TCO）估算来分析其每 TCO 性能。Rubin 及众多其他系统的 TCO 数据来自我们的 [AI TCO 模型，该模型追踪各类 AI 芯片的总拥有成本，涵盖资本开支（capex）、运营开支（opex）及其他各项费用。](https://semianalysis.com/ai-cloud-tco-model/)我们还使用[数据中心模型中的全口径公用电力配置估算（All-in Utility Provisioned Power Estimates）](https://semianalysis.com/datacenter-industry-model/)来考察每瓦性能。
+在本文中，我们将对照多条基线来拆解 Nvidia 的 Rubin 性能宣称，展示 Rubin 明显领先 Blackwell 的地方，以及领先幅度较薄弱的地方。我们还将基于已有的 Rubin 总拥有成本（TCO）估算来分析其每美元 TCO 性能。Rubin 及众多其他系统的 TCO 数据来自我们的 [AI TCO 模型，该模型追踪各类 AI 芯片的总拥有成本，涵盖资本开支（capex）、运营开支（opex）及其他各项费用。](https://semianalysis.com/ai-cloud-tco-model/)我们还使用[数据中心模型中的全口径公用电力配置估算（All-in Utility Provisioned Power Estimates）](https://semianalysis.com/datacenter-industry-model/)来考察每瓦性能。
 
 最后，我们将呈现 [VR NVL72 逐组件构建的物料清单（BoM）。这部分内容收录于即将发布的 SemiAnalysis 物料清单（BoM）模型。](https://semianalysis.com/vr-nvl72-model/)
 
@@ -199,7 +199,7 @@ CoreWeave-Nvidia 图表上第一个值得注意的宣称是：在约 150 tok/s/u
 
 - NVFP4 精度
 - 投机解码（使用 MTP）
-- 分离式服务（使用 Dynamo）
+- 分离式推理（使用 Dynamo）
 - 宽专家并行（Wide Expert Parallelism）
 - 基于 TensorRT-LLM
 
diff --git a/packages/app/content/hardware/zh/tpu-v7-ironwood-vs-gb300-nvl72-agentx-results.mdx b/packages/app/content/hardware/zh/tpu-v7-ironwood-vs-gb300-nvl72-agentx-results.mdx
index 4cc4ff969..88d52b6bf 100644
--- a/packages/app/content/hardware/zh/tpu-v7-ironwood-vs-gb300-nvl72-agentx-results.mdx
+++ b/packages/app/content/hardware/zh/tpu-v7-ironwood-vs-gb300-nvl72-agentx-results.mdx
@@ -39,7 +39,7 @@ TPU v7 目前在两个模型上有 AgentX 结果，即 Qwen3.5-397B 和 Kimi K3
 
 每美元 token 数是仪表板的默认指标，统计每 1 美元 TCO 所服务的总 token 数（输入和输出）。成本采用 [SemiAnalysis AI Cloud TCO Model](https://semianalysis.com/ai-cloud-tco-model/) 中按超大规模云大批量采购计算的自持成本：GB300 NVL72 为每 GPU 每小时 $2.31，TPU v7 则有两个数值。外部数值为每芯片每小时 $1.21，是 Google 以外买家的自持成本。若以 3 年期承诺向 Google Cloud 租用，则为每芯片每小时 $2.00。仪表板默认采用每芯片每小时 $1.03，即 Google 自己持有并运营这颗芯片的成本。表格以“外部（$1.21）/ 内部（$1.03）”的形式同时列出两者。两种口径中只有 TPU v7 的成本不同，因此 GB300 NVL72 和其他 GPU 在两种口径下的每美元 token 数相同。图表采用仪表板默认值，因此按外部成本计算，TPU v7 的每个数据点都比图中低 15%。
 
-每 MW 指标采用 [SemiAnalysis Datacenter Industry Model](https://semianalysis.com/datacenter-industry-model/) 中的单芯片全口径规划功率，TPU v7 为 1.207 kW，GB300 NVL72 为 2.12 kW，均为已部署系统的规划数值。一颗 TPU v7 芯片的规划功率是 GB300 GPU 的 57%，每小时成本按外部成本计算是其 52%，按内部成本计算是其 45%，因此每美元比值比每 MW 比值按外部成本计算高 9%，按内部成本计算高 28%。
+每 MW 指标采用 [SemiAnalysis Datacenter Industry Model](https://semianalysis.com/datacenter-industry-model/) 中的单芯片全口径规划功率，TPU v7 为 1.207 kW，GB300 NVL72 为 2.12 kW，均为已部署系统的规划数值。一颗 TPU v7 芯片的规划功率是 GB300 GPU 的 57%，每小时成本按外部成本计算是其 52%，按内部成本计算是其 45%，因此按外部成本计算，每美元比值比每 MW 比值高 9%；按内部成本计算则高 28%。
 
 我们的 [Vera Rubin NVL72 结果](/zh/hardware/vera-rubin-nvl72-vs-gb300-nvl72-agentx-results)介绍了 AgentX 工作负载。
 
diff --git a/packages/app/content/hardware/zh/vera-rubin-nvl72-vs-gb300-nvl72-agentx-results.mdx b/packages/app/content/hardware/zh/vera-rubin-nvl72-vs-gb300-nvl72-agentx-results.mdx
index d5540734a..4f36b8924 100644
--- a/packages/app/content/hardware/zh/vera-rubin-nvl72-vs-gb300-nvl72-agentx-results.mdx
+++ b/packages/app/content/hardware/zh/vera-rubin-nvl72-vs-gb300-nvl72-agentx-results.mdx
@@ -113,7 +113,7 @@ MiniMax-M3 总参数约 428B、激活参数约 23B，采用 MiniMax Sparse Atten
   precisions="fp4"
 />
 
-从图中可以看到，GB300 NVL72 唯一的 MiniMax-M3 AgentX 曲线来自较早的运行，前沿从 99 tok/s/user 才开始，因此没有可与 Vera Rubin 每美元 136.6M token 的峰值对比的 GB300 NVL72 高吞吐点。在另一端，Vera Rubin 的 10-GPU 分离式配置可达 483 tok/s/user。
+从图中可以看到，GB300 NVL72 唯一的 MiniMax-M3 AgentX 曲线来自较早的运行，前沿从 99 tok/s/user 才开始，因此 GB300 NVL72 没有可与 Vera Rubin 每美元 136.6M token 峰值对比的高吞吐点。在另一端，Vera Rubin 的 10-GPU 分离式配置可达 483 tok/s/user。
 
 数值为每 1 美元 TCO 的 M token 数，GB300 各行均运行 Dynamo vLLM，比值为 Vera Rubin / GB300。
 
diff --git a/packages/app/content/models/zh/deepseek-v41-flash.mdx b/packages/app/content/models/zh/deepseek-v41-flash.mdx
index bfc9558d1..733c05ce9 100644
--- a/packages/app/content/models/zh/deepseek-v41-flash.mdx
+++ b/packages/app/content/models/zh/deepseek-v41-flash.mdx
@@ -21,6 +21,6 @@ DeepSeek-V4.1-Flash 是原生支持图像与文本输入的 MoE 模型，采用
 
 上述维度以及 3 层 next-token prediction 配置均可在[公开配置](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/raw/main/config.json)中核对。[模型卡](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash)解释了 prefill 与 decode 激活参数量不同的原因，不能用单一数值代替。
 
-## 推理数据范围
+## 推理服务范围
 
 模型以 MIT 许可证发布。厂商报告的 FP4 KV cache 占用和有界 SWA replay 属于架构特性；InferenceX 的实测性能取决于实际 checkpoint、推理引擎及运行配置，不能只根据参数量推导速度提升（[模型卡](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash)）。
diff --git a/packages/app/content/models/zh/muse-spark-open.mdx b/packages/app/content/models/zh/muse-spark-open.mdx
index 0e588c521..412770f53 100644
--- a/packages/app/content/models/zh/muse-spark-open.mdx
+++ b/packages/app/content/models/zh/muse-spark-open.mdx
@@ -20,6 +20,6 @@ Muse Spark Open 是 Meta 面向代码与智能体任务发布的开放权重模
 
 上述层数与张量维度来自 [AMD 发布的 checkpoint 配置](https://huggingface.co/amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4/raw/main/config.json)与 [Transformers 实现文档](https://huggingface.co/docs/transformers/v5.20.0/en/model_doc/muse_spark)。Meta 的原始 checkpoint 配置需要申请访问权限，因此这里列出上述公开来源以说明数据出处，而不暗示该文件可以自由获取。
 
-## Checkpoint 与数据范围
+## Checkpoint 与适用范围
 
 Meta 以 Muse Model License 发布 BF16 和 NVFP4 checkpoint，AMD 另行发布 MXFP4 checkpoint。816B 是厂商公布的标称参数量，与仓库中的张量统计值不同，引用时应保留其原本的统计口径。架构说明属于静态元数据；下方 InferenceX 图表展示实测的推理性能（[Meta 文档](https://dev.meta.ai/docs/muse-spark-open)）。
diff --git a/packages/app/src/lib/blog/blog-content.test.ts b/packages/app/src/lib/blog/blog-content.test.ts
index 00b72ea75..149083926 100644
--- a/packages/app/src/lib/blog/blog-content.test.ts
+++ b/packages/app/src/lib/blog/blog-content.test.ts
@@ -1,5 +1,7 @@
 import fs from 'node:fs';
 import path from 'node:path';
+import { compileMDX } from 'next-mdx-remote/rsc';
+import { renderToStaticMarkup } from 'react-dom/server';
 import { describe, expect, it } from 'vitest';
 
 import { compareBlogPair } from '../i18n/zh-objective-guard';
@@ -86,3 +88,25 @@ describe.each(enFiles)('%s', (file) => {
     }
   });
 });
+
+describe('Chinese technical Markdown rendering', () => {
+  it('renders every multiplication factor in the workflow job calculation', async () => {
+    const source = read(path.join(ZH_DIR, 'inferencemax-open-source-inference-benchmarking.mdx'));
+    const paragraph = source.split('\n\n').find((block) => block.startsWith('具体来说：'));
+    expect(paragraph).toBeDefined();
+    const { content } = await compileMDX({ source: paragraph! });
+    const html = renderToStaticMarkup(content);
+    expect(html).toContain('3 * 7 * 3 * 2 * 4 * 4 = 2016');
+    expect(html).not.toContain('<em>');
+  });
+
+  it('preserves underscores and the wildcard in the SGLang optimization flag', async () => {
+    const source = read(path.join(ZH_DIR, 'mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx'));
+    const paragraph = source
+      .split('\n')
+      .find((block) => block.startsWith('- **分支 → SGLang main 上游迁移。**'));
+    expect(paragraph).toBeDefined();
+    const { content } = await compileMDX({ source: paragraph! });
+    expect(renderToStaticMarkup(content)).toContain('<code>SGLANG_OPT_*</code>');
+  });
+});