From dc6c25fe3d6081bed15f0b2fb41b094cef17662c Mon Sep 17 00:00:00 2001 From: functionstackx <47992694+functionstackx@users.noreply.github.com> Date: Sat, 4 Jul 2026 02:48:00 -0400 Subject: [PATCH 1/3] feat(i18n): add Simplified Chinese (/zh) pages across the whole site MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Every indexable page now has a hand-authored Chinese sibling under /zh so the site is crawled and indexed in Chinese as well as English: - /zh landing + 8 dashboard tabs (Chinese metadata + server-rendered SEO intro above the charts), about (incl. Chinese FAQ + FAQPage JSON-LD), quotes (all 45 supporter quotes translated), land-acknowledgement, and the compare / compare-per-dollar index pages - Chinese blog: content/blog/zh/.mdx pairs by filename; all 14 posts translated per the AGENTS.md quality bar; /zh/blog list + /zh/blog/[slug] pages; visibility gating derives from the English post - Bidirectional hreflang (en / zh-CN / x-default) on both trees via new helpers in src/lib/i18n.ts; sitemap emits EN+zh pairs; OG locale zh_CN - Locale-aware chrome: header nav + EN<->中文 toggle, dashboard TabNav labels/links, footer 中文版 link, zh 404 page, document lang fixup - Blog lib: CJK-aware reading time (400 chars/min) and Han-preserving slugify so Chinese headings get real anchor ids - AGENTS.md: new mandatory rule — every new page/tab/post ships its /zh version in the same PR; docs/i18n.md records the design rationale - Tests: i18n + tab-meta-zh unit tests, zh blog lib tests, zh-pages Cypress spec (10 tests) Not mirrored (documented): per-slug compare pages, /datasets, gated tabs, feed.xml/llms.txt; zh posts reuse the English OG image (Satori default font has no CJK glyphs). 中文：为全站新增简体中文 /zh 页面——首页、8 个仪表板标签页（中文元数据 与图表上方的服务器端中文简介）、关于页（含中文 FAQ 与 FAQPage 结构化 数据）、支持者页（45 条支持者评价全部翻译）、土地致谢页、GPU 对比索引 页，以及全部 14 篇博客文章翻译（content/blog/zh/，与英文原文按文件名 配对）。通过新的 i18n 辅助函数实现双向 hreflang，站点地图成对输出中英 URL；页眉新增 EN↔中文 切换，仪表板标签栏与页脚支持中文；博客库支持 CJK 阅读时长与中文标题锚点。AGENTS.md 新增强制规则：所有新页面、标签 页与博客文章必须在同一 PR 中提供中文版本；设计说明见 docs/i18n.md。 Co-Authored-By: Claude Fable 5 --- AGENTS.md | 18 +- docs/i18n.md | 29 + docs/index.md | 1 + ...nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx | 215 ++++ ...vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx | 248 +++++ ...h200-int4-kimi-k2-vllm-perf-per-dollar.mdx | 201 ++++ ...seekv4-16t-day-0-to-day-43-performance.mdx | 588 +++++++++++ ...vl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx | 136 +++ ...b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx | 192 ++++ ...nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx | 181 ++++ ...max-open-source-inference-benchmarking.mdx | 671 +++++++++++++ ...x-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx | 943 ++++++++++++++++++ ...deepseek-v4-pro-sglang-110x-in-26-days.mdx | 254 +++++ ...x-glm5-fp8-sglang-40-cheaper-than-b200.mdx | 195 ++++ ...mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx | 130 +++ ...i355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx | 179 ++++ ...-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx | 112 +++ packages/app/cypress/e2e/zh-pages.cy.ts | 87 ++ packages/app/src/app/(landing)/page.tsx | 3 +- packages/app/src/app/about/page.tsx | 3 +- packages/app/src/app/blog/[slug]/page.tsx | 15 +- packages/app/src/app/blog/page.tsx | 3 +- .../app/src/app/compare-per-dollar/page.tsx | 4 +- packages/app/src/app/compare/page.tsx | 4 +- .../app/src/app/land-acknowledgement/page.tsx | 3 +- packages/app/src/app/quotes/page.tsx | 3 +- packages/app/src/app/sitemap.ts | 91 +- .../app/zh/(dashboard)/calculator/page.tsx | 23 + .../app/zh/(dashboard)/evaluation/page.tsx | 21 + .../app/zh/(dashboard)/gpu-metrics/page.tsx | 16 + .../src/app/zh/(dashboard)/gpu-specs/page.tsx | 16 + .../app/zh/(dashboard)/historical/page.tsx | 19 + .../src/app/zh/(dashboard)/inference/page.tsx | 19 + .../app/src/app/zh/(dashboard)/layout.tsx | 5 + .../app/zh/(dashboard)/reliability/page.tsx | 19 + .../app/zh/(dashboard)/submissions/page.tsx | 16 + packages/app/src/app/zh/about/page.tsx | 215 ++++ .../app/zh/blog/[slug]/opengraph-image.tsx | 43 + packages/app/src/app/zh/blog/[slug]/page.tsx | 214 ++++ packages/app/src/app/zh/blog/layout.tsx | 9 + packages/app/src/app/zh/blog/page.tsx | 127 +++ .../src/app/zh/compare-per-dollar/layout.tsx | 13 + .../src/app/zh/compare-per-dollar/page.tsx | 149 +++ packages/app/src/app/zh/compare/layout.tsx | 13 + packages/app/src/app/zh/compare/page.tsx | 161 +++ .../src/app/zh/land-acknowledgement/page.tsx | 99 ++ packages/app/src/app/zh/layout.tsx | 18 + packages/app/src/app/zh/not-found.tsx | 16 + packages/app/src/app/zh/page.tsx | 26 + packages/app/src/app/zh/quotes/page.tsx | 23 + .../app/src/components/about/faq-data-zh.ts | 127 +++ .../src/components/blog/blog-back-link.tsx | 12 +- .../src/components/blog/blog-post-card.tsx | 6 +- .../app/src/components/blog/blog-post-nav.tsx | 18 +- .../app/src/components/blog/blog-tag-link.tsx | 6 +- packages/app/src/components/blog/blog-toc.tsx | 9 +- packages/app/src/components/footer/footer.tsx | 8 + packages/app/src/components/header/header.tsx | 56 +- packages/app/src/components/intro-section.tsx | 22 +- .../src/components/landing/landing-page.tsx | 135 ++- .../app/src/components/quote-carousel.tsx | 5 +- .../src/components/quotes/quotes-content.tsx | 36 +- .../app/src/components/quotes/quotes-data.ts | 151 ++- .../app/src/components/set-document-lang.tsx | 22 + packages/app/src/components/tab-nav.tsx | 25 +- .../app/src/components/zh/zh-tab-intro.tsx | 19 + packages/app/src/lib/blog.test.ts | 139 +++ packages/app/src/lib/blog.ts | 82 +- packages/app/src/lib/i18n.test.ts | 103 ++ packages/app/src/lib/i18n.ts | 110 ++ packages/app/src/lib/tab-meta-zh.test.ts | 62 ++ packages/app/src/lib/tab-meta-zh.ts | 144 +++ packages/app/src/lib/tab-meta.ts | 8 +- packages/constants/src/seo.ts | 10 + 74 files changed, 6892 insertions(+), 212 deletions(-) create mode 100644 docs/i18n.md create mode 100644 packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx create mode 100644 packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx create mode 100644 packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx create mode 100644 packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx create mode 100644 packages/app/content/blog/zh/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200.mdx create mode 100644 packages/app/content/blog/zh/gb200-nvl72-vs-b200-disagg-deepseek-r1-fp4-dynamo-trt.mdx create mode 100644 packages/app/content/blog/zh/gb300-nvl72-vs-gb200-nvl72-dsv4-pro-vllm-fp4.mdx create mode 100644 packages/app/content/blog/zh/inferencemax-open-source-inference-benchmarking.mdx create mode 100644 packages/app/content/blog/zh/inferencex-v2-nvidia-blackwell-vs-amd-vs-hopper.mdx create mode 100644 packages/app/content/blog/zh/mi355x-deepseek-v4-pro-sglang-110x-in-26-days.mdx create mode 100644 packages/app/content/blog/zh/mi355x-glm5-fp8-sglang-40-cheaper-than-b200.mdx create mode 100644 packages/app/content/blog/zh/mi355x-kimi-k2-5-vllm-aiter-7x-speedup.mdx create mode 100644 packages/app/content/blog/zh/mi355x-qwen3-5-sglang-v0-5-12-up-to-17x.mdx create mode 100644 packages/app/content/blog/zh/sglang-0-5-6-b200-deepseek-r1-fp4-up-to-1-8x.mdx create mode 100644 packages/app/cypress/e2e/zh-pages.cy.ts create mode 100644 packages/app/src/app/zh/(dashboard)/calculator/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/evaluation/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/gpu-metrics/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/gpu-specs/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/historical/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/inference/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/layout.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/reliability/page.tsx create mode 100644 packages/app/src/app/zh/(dashboard)/submissions/page.tsx create mode 100644 packages/app/src/app/zh/about/page.tsx create mode 100644 packages/app/src/app/zh/blog/[slug]/opengraph-image.tsx create mode 100644 packages/app/src/app/zh/blog/[slug]/page.tsx create mode 100644 packages/app/src/app/zh/blog/layout.tsx create mode 100644 packages/app/src/app/zh/blog/page.tsx create mode 100644 packages/app/src/app/zh/compare-per-dollar/layout.tsx create mode 100644 packages/app/src/app/zh/compare-per-dollar/page.tsx create mode 100644 packages/app/src/app/zh/compare/layout.tsx create mode 100644 packages/app/src/app/zh/compare/page.tsx create mode 100644 packages/app/src/app/zh/land-acknowledgement/page.tsx create mode 100644 packages/app/src/app/zh/layout.tsx create mode 100644 packages/app/src/app/zh/not-found.tsx create mode 100644 packages/app/src/app/zh/page.tsx create mode 100644 packages/app/src/app/zh/quotes/page.tsx create mode 100644 packages/app/src/components/about/faq-data-zh.ts create mode 100644 packages/app/src/components/set-document-lang.tsx create mode 100644 packages/app/src/components/zh/zh-tab-intro.tsx create mode 100644 packages/app/src/lib/i18n.test.ts create mode 100644 packages/app/src/lib/i18n.ts create mode 100644 packages/app/src/lib/tab-meta-zh.test.ts create mode 100644 packages/app/src/lib/tab-meta-zh.ts diff --git a/AGENTS.md b/AGENTS.md index c2b8f25b..282a322b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -6,6 +6,8 @@ For detailed subsystem docs, see [docs/index.md](./docs/index.md). > **Translation quality bar:** write natural technical Chinese, not word-for-word machine translation (style reference: [`vllm-project/vllm-ascend` `README.zh.md`](https://github.com/vllm-project/vllm-ascend/blob/main/README.zh.md)). Preserve product names, hardware SKUs, framework/library names (Next.js, React Query, D3.js, Tailwind ...), flags, and code identifiers in English. Use parenthetical English clarification for acronyms on first use. Preferred terms: benchmark 基准测试, dashboard 仪表板, chart 图表, config 配置, throughput 吞吐量, latency 延迟, single-node/multi-node 单节点/多节点, evaluation 评估, artifact 产物. +> **The website itself is bilingual too — every indexable page must ship a Simplified Chinese sibling under `/zh`.** See [Chinese Website Pages](#chinese-website-pages-zh--mandatory-for-all-indexable-surfaces) below; a new page, tab, or blog post without its `/zh` version is 🔴 BLOCKING on PR review. + ## Project Overview InferenceX App — Next.js 16 dashboard for ML inference benchmark data. DB-backed with Neon PostgreSQL, React Query for data fetching, D3.js for charts. @@ -121,6 +123,18 @@ When adding a chart feature (toggle, label, overlay, filter, export, share-link If the feature genuinely cannot apply to overlays (e.g., it depends on data only ingested for official runs), say so explicitly in code comments and the PR description. Default to "must support overlays." +## Chinese Website Pages (/zh) — Mandatory for All Indexable Surfaces + +The site ships a hand-authored Simplified Chinese sibling for every indexable page under the `/zh` route prefix (`/` ↔ `/zh`, `/about` ↔ `/zh/about`, `/blog/` ↔ `/zh/blog/`, …) so the site is crawled and indexed in Chinese as well as English. There is no i18n framework — each `/zh` page is a real page that reuses the shared helpers in `packages/app/src/lib/i18n.ts` (`zhAlternates`, `enAlternates`, `ZH_OG_LOCALE`, `ZH_MIRRORED_ROUTES`) and `src/lib/tab-meta-zh.ts`. The translation quality bar above applies to all site content. + +**Every new indexable page, dashboard tab, or blog post MUST ship its Chinese version in the same PR:** + +1. **New page** → create `packages/app/src/app/zh//page.tsx` with fully translated content and metadata. Metadata: `alternates: zhAlternates('')` plus `openGraph.locale: ZH_OG_LOCALE`. Switch the English page's `alternates` to `enAlternates('')` so both sides carry bidirectional hreflang. Register the route in `ZH_MIRRORED_ROUTES` (`src/lib/i18n.ts`) so the header nav and EN↔中文 toggle link to it, and add it to the sitemap via `localizedPair()` in `src/app/sitemap.ts`. +2. **New dashboard tab** → add the tab to `ZH_TAB_KEYS`, `TAB_META_ZH`, `TAB_INTRO_ZH`, and `TAB_LABELS_ZH` in `src/lib/tab-meta-zh.ts`, then create `src/app/zh/(dashboard)//page.tsx` mirroring the English page with `tabMetadataZh('')` and a `` block above the chart (the interactive chart UI itself stays English). `tab-meta-zh.test.ts` enforces dictionary completeness. +3. **New blog post** → the translation `packages/app/content/blog/zh/.mdx` is REQUIRED in the same PR. Translate frontmatter `title`/`subtitle` and the body; keep `date`, `publishDate`, `modifiedDate`, `tags`, and the filename/slug identical (English and Chinese posts pair by filename; visibility gating always follows the English post's `publishDate`). Rewrite internal `/blog/` links to `/zh/blog/`; never alter numbers, code blocks, or `
`/`` structure. The `/zh/blog` listing, hreflang, and sitemap pick the file up automatically. +4. **Editing an existing English page or post** → update its Chinese sibling in the same PR. Content drift between languages is a 🔴 BLOCKING review issue. +5. **Intentionally not mirrored** (skip these, or add them to `ZH_MIRRORED_ROUTES` when you do mirror them): per-slug compare pages (`/compare/[slug]`, `/compare-per-dollar/[slug]` — the `/zh/compare*` index pages link to the English slug pages), `/datasets`, feature-gated tabs (`ai-chart`, `current-inferencex-image`, `feedback`), `feed.xml`/`llms.txt`, and per-post OG images (Chinese posts reuse the English post's OG image — the OG renderer's font has no CJK glyphs). + ## Chart Interpolation — TS and Python Helpers MUST Stay in Sync The blog-writing workflow (`.claude/skills/write-inferencex-blog/`) ships a Python port of the chart's interpolation algorithm at `.claude/skills/write-inferencex-blog/iso_interactivity.py`. It exists so iso-interactivity tables in blog posts produce **exactly the same numbers** readers see when they hover the rendered chart. Linear-interpolation shell scripts will produce visibly different values — Cursor Bugbot has flagged this on prior posts. @@ -197,7 +211,8 @@ Authoritative total / active parameter counts for every model in the dashboard. 1. Create `packages/app/content/blog/.mdx` with frontmatter: `title`, `subtitle`, `date` (required), `tags`, `modifiedDate` (optional) 2. Write content using Markdown + custom MDX components (`Figure`, `Blur`) -3. No code changes needed — the post automatically appears in the blog list, sitemap, RSS feed, llms.txt, and gets a generated OG image +3. Create the Simplified Chinese translation at `packages/app/content/blog/zh/.mdx` (**required** — see [Chinese Website Pages](#chinese-website-pages-zh--mandatory-for-all-indexable-surfaces)) +4. No code changes needed — the post automatically appears in the blog list, sitemap, RSS feed, llms.txt, and gets a generated OG image; the zh file appears on `/zh/blog` with hreflang pairing See [Blog](./docs/blog.md) for content format, available MDX components, and design details. @@ -222,6 +237,7 @@ See [Blog](./docs/blog.md) for content format, available MDX components, and des 2. Create a per-section context provider (see `InferenceContext.tsx`, `EvaluationContext.tsx` for patterns) 3. Use `ChartLegend` with `variant="sidebar"`, sorted by `HW_REGISTRY` sort order, default expanded 4. Analytics: all interactive elements use `track()` with `{tabname}_` prefix +5. Create the Chinese sibling: extend `src/lib/tab-meta-zh.ts` dictionaries and add `src/app/zh/(dashboard)//page.tsx` (see [Chinese Website Pages](#chinese-website-pages-zh--mandatory-for-all-indexable-surfaces)) ### Bumping dependencies diff --git a/docs/i18n.md b/docs/i18n.md new file mode 100644 index 00000000..50bdaca1 --- /dev/null +++ b/docs/i18n.md @@ -0,0 +1,29 @@ +# Chinese Pages (/zh) + +Why the Simplified Chinese site is a hand-authored `/zh` page tree instead of an i18n framework, and how the pieces fit together. The authoring rules (what you MUST do when adding a page/tab/post) live in [AGENTS.md — Chinese Website Pages](../AGENTS.md#chinese-website-pages-zh--mandatory-for-all-indexable-surfaces); this doc covers the design rationale. + +## Why hand-authored pages, not next-intl / `[locale]` routing + +- **SEO is the goal, not full UI translation.** The objective is Chinese pages that crawlers can index: Chinese titles, meta descriptions, server-rendered Chinese content, and bidirectional hreflang. The interactive dashboard (charts, filters, tooltips) stays English — model/GPU/framework names are English-first terms in Chinese ML writing anyway, and translating deep chart UI would touch hundreds of client components for little search value. +- **A `[locale]` root segment would move every route** and force middleware rewrites to keep existing URLs stable — high blast radius for a two-locale site. A parallel `/zh` tree adds pages without touching English URLs. +- **No message-catalog indirection.** With exactly two locales and mostly page-level content, colocated `STRINGS = { en, zh }` dictionaries (landing page, quotes content) and dedicated zh files (`tab-meta-zh.ts`, `faq-data-zh.ts`) are easier to review than a parallel key-file hierarchy, and dead strings die with their page. + +## Architecture + +| Piece | Where | Notes | +| ---------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| URL mapping + hreflang | `src/lib/i18n.ts` | `zhPath`, `enAlternates`/`zhAlternates` (both sides emit the same `languages` map, `x-default` = English), `ZH_MIRRORED_ROUTES` (single source of truth for "which routes have a zh sibling"), `switchLocalePath` for the header toggle | +| Tab dictionaries | `src/lib/tab-meta-zh.ts` | `TAB_META_ZH` (metadata), `TAB_INTRO_ZH` (server-rendered intro), `TAB_LABELS_ZH` (TabNav), `NAV_LABELS_ZH` (header). Completeness enforced by `tab-meta-zh.test.ts` | +| zh page tree | `src/app/zh/**` | Mirrors the English tree; dashboard pages render `` above the same chart components | +| Blog translations | `content/blog/zh/.mdx` | Same filename pairs the languages. Visibility gating (publishDate) always derives from the **English** post so a translation can never publish early; title/subtitle/reading time come from the zh file | +| Locale-aware chrome | `header.tsx`, `tab-nav.tsx`, `footer.tsx` | Client components detect `/zh` from `usePathname()` — no prop drilling, no context | + +## Non-obvious decisions + +- **``**: the root layout hardcodes `lang="en"` and Next.js cannot override it per segment without multiple root layouts. The zh layout wraps content in `
` (valid, scopes language for crawlers/AT) and `SetDocumentLang` fixes `document.documentElement.lang` after hydration. Google detects language from content, not the attribute, so this is not an SEO problem. +- **Slugs stay English.** zh posts keep the English filename/slug — `slugify()` would previously have destroyed CJK slugs, and shared slugs are what pair the two languages for hreflang. `slugify()` now _preserves_ Han characters, but only so Chinese _headings_ get meaningful anchor ids (`extractHeadings` and the MDX heading renderer share it). +- **Reading time is CJK-aware**: `getReadingTime` counts Han characters at 400 chars/min alongside Latin words at 265 wpm; pure word-splitting counts an entire Chinese paragraph as ~1 "word". +- **zh OG images reuse the English post meta** — the `next/og` default Satori font has no CJK glyphs, so a Chinese title would render as tofu. Loading a subset CJK font is a known follow-up. +- **`/zh/inference` canonicalizes to `/zh`**, mirroring the English quirk where `/inference` canonicalizes to `/`. +- **Compare slug pages are not mirrored**: `compareTableNarrative` (`compare-ssr.ts`) generates hundreds of lines of English prose per programmatic page; translating the templates is a separate project. The `/zh/compare*` index pages exist and link to the English slug pages. +- **Sitemap pairs**: `localizedPair()` in `sitemap.ts` emits the EN and zh URL together, both carrying the same `alternates.languages` map. Blog posts without a translation fall back to an English-only entry, so a missing translation degrades gracefully instead of 404-ing crawlers. diff --git a/docs/index.md b/docs/index.md index a95646a2..ea6154ed 100644 --- a/docs/index.md +++ b/docs/index.md @@ -15,3 +15,4 @@ Design rationale and non-obvious conventions. See [CLAUDE.md](../CLAUDE.md) for - [Data Transforms](./data-transforms.md) — Full pipeline from BenchmarkRow to RenderableGraph: type hierarchy, hardware key construction, derived metrics, memoization strategy - [State Ownership](./state-ownership.md) — Which context owns which state, availability filtering cascade, comparison date mechanics, URL param sync - [Blog](./blog.md) — MDX content system, SEO features (OG images, RSS, llms.txt, JSON-LD), TOC sidebar, reading progress, heading links, analytics events +- [Chinese Pages (/zh)](./i18n.md) — Why hand-authored /zh pages instead of an i18n framework, hreflang pairing, blog translation pairing, html lang workaround, CJK reading time/slugs 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 new file mode 100644 index 00000000..36d30314 --- /dev/null +++ b/packages/app/content/blog/zh/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar.mdx @@ -0,0 +1,215 @@ +--- +title: 'B200 NVFP4 对比 H200 FP8 运行 GLM-5：SGLang MTP 下性价比提升高达 3.65 倍' +subtitle: '两款 GPU 均运行 SGLang EAGLE MTP；Blackwell 世代在峰值处带来约 1.2 倍的性价比提升，NVIDIA GLM-5-NVFP4 检查点搭配 FlashInfer TRT-LLM 稀疏 MLA 在 8K/1K 场景下再叠加约 2.4–3.0 倍优势' +date: '2026-05-26' +publishDate: '2026-05-26' +tags: + - benchmark + - gpu + - inference + - glm5 + - nvidia + - b200 + - h200 + - sglang + - fp4 +--- + +在 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）——但组合提升始终保持稳定。 + + + 点击查看完整 InferenceX 仪表板 → + + +
+ +GLM-5 是智谱（ZAI/Zhipu）的 MoE 旗舰模型，发布于 2026-02-11——距本次测试约 14 周。它是一个 **744B 参数的稀疏 MoE，每个 token 激活约 40B 参数**：256 个专家 + top-8 路由（约 5.9% 稀疏度）加共享专家，解码阶段使用 **DeepSeek Sparse Attention（DSA）** 并搭配 Multi-head Latent Attention（MLA）进行 KV 缓存压缩，上下文窗口为 200K。发布的架构名称为 `glm_moe_dsa`——与 DeepSeek 在 V3.2 中引入的稀疏注意力模式相同，也是 SGLang 在 Blackwell 上的 TRT-LLM 稀疏 MLA 后端所针对优化的架构。 + +NVIDIA 还发布了量化权重版本 [`nvidia/GLM-5-NVFP4`](https://huggingface.co/nvidia/GLM-5-NVFP4)——与 `zai-org/GLM-5-FP8` 采用相同的模型架构，但所有 MoE GEMM 权重从 FP8 重新转换为 NVFP4（16 元素分块、FP8 逐块缩放因子、FP32 逐张量缩放因子）。KV 缓存保持 FP8。这就是图表（chart）中 B200 曲线所加载的检查点；H200 曲线加载 `zai-org/GLM-5-FP8`，因为 Hopper 没有 FP4 张量核心。 + +## 纸面规格 + +在介绍具体方案之前，先看硬件。H200 SXM（Hopper）和 B200 SXM（Blackwell）相隔一代。下方雷达图（chart）将每个轴归一化到 [`/gpu-specs`](/gpu-specs) 中所有 NVIDIA + AMD SKU 的最大值——因此 H200 和 B200 的多边形在 GB200/GB300 NVL72 设定上限的轴上显得较小（特别是 Scale-up Domain Memory 和 Scale-up Domain Memory Bandwidth，它们随 72-GPU NVLink 域的机架级规模而扩展）。 + +
+ +本次基准测试中两款 SKU 的绝对值： + +| 规格 | H200 SXM | B200 SXM | B200 / H200 | +| --------------------------------- | ------------------- | ------------------- | ----------- | +| HBM 容量 | 141 GB (HBM3e) | 180 GB (HBM3e) | 1.28x | +| HBM 带宽 | 4.8 TB/s | 8.0 TB/s | 1.67x | +| Dense FP4 (TFLOP/s) | — | 9,000 | — | +| Dense FP8 (TFLOP/s) | 1,979 | 4,500 | 2.27x | +| Dense BF16 (TFLOP/s) | 989 | 2,250 | 2.28x | +| Scale-up 每 GPU 带宽（单向） | 450 GB/s (NVLink 4) | 900 GB/s (NVLink 5) | 2.00x | +| Scale-up 节点规模 | 8 | 8 | 1.00x | +| Scale-up Domain HBM 容量 | 1,128 GB | 1,440 GB | 1.28x | +| Scale-up Domain HBM 带宽（聚合） | 38.4 TB/s | 64.0 TB/s | 1.67x | +| TCO（SemiAnalysis AI Cloud 模型） | $1.41/GPU/hr | $1.95/GPU/hr | 1.38x | + +对 FP8 对 FP8 对比的启示：在相同精度和相同方案下，B200 相对 H200 的性价比上限在完全计算瓶颈的工作负载上约为 `2.27 / 1.38 ≈ 1.64x`，在完全显存带宽瓶颈的工作负载上约为 `1.67 / 1.38 ≈ 1.21x`（以 HBM 为带宽轴；若以 NVLink 带宽计，则上限为 `2.00 / 1.38 ≈ 1.45x`）。实测在 80 tok/s/user 时为 1.22x，落在显存带宽瓶颈区间内——GLM-5 在此并发度下的解码阶段主要受 MoE 权重和 KV 缓存的 HBM 读取限制，而非 FP8 GEMM 吞吐量，因此 Blackwell 的 dense 计算余量大部分未被利用。NVFP4 才是打破 GEMM 天花板的关键杠杆：H200 没有 FP4 张量核心，而 B200 拥有 9 PFLOP/s，由此带来的精度提升在世代提升之上再叠加 2.41x–3.07x。 + +## 促成此结果的上游变更 + +**上游软件栈。** 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 默认配置并增加了第一轮性能优化。关键内核变更： + +- [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 吞吐量提升。 +- [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 在下面方案中唯一的不同是模型检查点和注意力后端的选择。 + +## 详细数据 + +所有行均为 GLM-5 在 **ISL 8192 / OSL 1024** 下的单节点非分离式推理结果，数据来自 2026-05-25 的 InferenceX 基准测试，使用 **SGLang v0.5.12** 并在每个方案中启用基于 EAGLE 的 MTP。每百万 total tokens 成本计算公式为 `TCO_$/GPU/hr / (3600 × tput_per_gpu / 1e6)`，H200 为 $1.41/GPU/hr，B200 为 $1.95/GPU/hr，来源于 [SemiAnalysis AI Cloud TCO 模型](https://newsletter.semianalysis.com/p/ai-cloud-economics)。 + +容器镜像：两款 SKU 均使用 `lmsysorg/sglang:v0.5.12-cu130`。 + +**H200 SGLang FP8 + MTP，TP=8，8 GPU**（模型 `zai-org/GLM-5-FP8`）： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 347.9 | 84.49 | 11.84 | $1.13 | +| 8 | 489.7 | 59.82 | 16.72 | $0.80 | +| 16 | 675.9 | 39.64 | 25.22 | $0.58 | +| 32 | 851.9 | 24.90 | 40.16 | $0.46 | +| 64 | 847.2 | 20.80 | 48.08 | $0.46 | + +并发 64 时 tok/s/GPU 略有回落，因为首 token 延迟（TTFT）开始主导请求时间预算——并发 32 在此方案下设定了 H200 的吞吐量上限和成本下限。Pareto 前沿剔除了并发 64，因为并发 32 在两个轴上都优于它。 + +**B200 SGLang FP8 + MTP，TP=8，8 GPU**（模型 `zai-org/GLM-5-FP8`）： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 417.0 | 100.85 | 9.92 | $1.30 | +| 8 | 650.1 | 77.82 | 12.85 | $0.83 | +| 16 | 952.7 | 56.93 | 17.57 | $0.57 | +| 32 | 1,296.8 | 38.16 | 26.21 | $0.42 | +| 64 | 1,619.3 | 23.56 | 42.45 | $0.33 | +| 128 | 1,929.5 | 13.78 | 72.59 | $0.28 | +| 256 | 1,947.3 | 11.88 | 84.15 | $0.28 | + +**B200 SGLang NVFP4 + MTP，TP=4，4 GPU**（模型 `nvidia/GLM-5-NVFP4`）——成本前沿的锚点： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 1,038.7 | 121.22 | 8.25 | $0.52 | +| 8 | 1,523.5 | 94.53 | 10.58 | $0.36 | +| 16 | 2,228.1 | 66.27 | 15.09 | $0.24 | +| 32 | 3,037.3 | 43.99 | 22.73 | $0.18 | +| 64 | 3,739.7 | 26.78 | 37.33 | $0.14 | +| 128 | 4,115.5 | 17.63 | 56.73 | $0.13 | +| 256 | 4,090.7 | 17.37 | 57.57 | $0.13 | + +**B200 SGLang NVFP4 + MTP，TP=8，8 GPU**——单个高交互性数据点，向右延伸 FP4 前沿： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 579.2 | 140.08 | 7.14 | $0.94 | + +TP=8 / 8 GPU 配置以牺牲一半的每 GPU 吞吐量为代价，在相同并发下获得了比 TP=4 高 16% 的交互性——额外的 GPU 将 TPOT 从 8.25 ms 降至 7.14 ms。FP4 的综合 Pareto 前沿从 $0.13/M（TP=4，并发 128）的 18 tok/s/user 延伸至 $0.94/M（TP=8，并发 4）的 140 tok/s/user。 + +## 等交互性下的性价比对比 + +在匹配的交互性水平下，沿每款 SKU 的 Pareto 前沿插值得出的每 GPU 吞吐量和每百万 tokens 成本。最后一列的性价比提升倍数为 $/M 比值的倒数——B200 NVFP4 相对于 H200 的性价比。超出前沿测量范围的单元格标记为 _unreachable_。 + +| 交互性 (tok/s/user) | H200 FP8 MTP $/M | B200 FP8 MTP $/M | B200 NVFP4 MTP $/M | B200 NVFP4 性价比 vs H200 | +| ------------------- | ---------------- | ---------------- | ------------------ | ------------------------- | +| 25 | $0.46 | $0.34 | $0.14 | 3.24x | +| 30 | $0.50 | $0.37 | $0.15 | 3.32x | +| 40 | $0.58 | $0.43 | $0.17 | 3.44x | +| 50 | $0.69 | $0.51 | $0.19 | 3.54x | +| 60 | $0.80 | $0.60 | $0.22 | 3.60x | +| 70 | $0.93 | $0.72 | $0.26 | 3.63x | +| **80** | **$1.06** | **$0.87** | **$0.29** | **3.65x** | +| 84 | $1.12 | $0.94 | $0.31 | 3.64x | +| 100 | _unreachable_ | $1.28 | $0.38 | _∞_ | +| 120 | _unreachable_ | _unreachable_ | $0.51 | _∞_ | +| 140 | _unreachable_ | _unreachable_ | $0.93 | _∞_ | + +B200 NVFP4 相对 H200 的性价比提升在 **80 tok/s/user 时达到峰值 3.65 倍**，且在整个 H200 运行区间内保持在 3.24x–3.65x 范围——不存在 H200 FP8 + MTP 能在 3 倍以内接近 B200 NVFP4 + MTP 的交互性点。仅精度切换带来的提升（B200 FP8 → B200 NVFP4）随交互性单调递增，从 **25 tok/s/user 时的 2.41 倍到 84 tok/s/user 时的 3.07 倍**，因为 B200 FP8 的性价比随批量减小而下降得更快。在 84 tok/s/user 以上，对比便不复存在：H200 没有任何方案能再提供一个 tok/s/user 的交互性，而 B200 NVFP4 的运行区间还可以延伸 60 tok/s/user，直达 TP=8 下的 140 tok/s/user。 + +
+ +[在线图表](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)，已预筛选为 2026-05-25 测试中 H200 + B200 上的 GLM-5 SGLang MTP。[在线成本视图](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_metric=y_costh&i_linelabel=1)展示相同对比的成本维度。 + +## GLM-5 在 Blackwell 上的后续进展 + +三个方向仍有望进一步提升当前数字，均已在上游跟踪中： + +- **NVL72 上的分离式推理。** 上述数字均为单节点聚合方式。[跟踪 issue](https://github.com/sgl-project/sglang/issues/19380) 正在积极推进 FP8 B200 分离式 8K/1K 及 GB300 分离式 MTP 的工作。宽 EP（Expert Parallelism）在 NVL72 上已在 Kimi K2.5 上展示了[每 GPU 吞吐量约 3 倍的优势](/zh/blog/gb200-nvl72-kimi-k2-5-vllm-wide-ep-3x-vs-b200)——同样的杠杆应该能在 FP4 前沿趋于平台的低交互性/高吞吐量端进一步提升 GLM-5 的性价比。 + +对于在 25–84 tok/s/user 区间的聊天场景 GLM-5 推理，B200 NVFP4 + MTP 在使用 SGLang 的每个可测量运行点上均实现了 H200 FP8 + MTP 3.2x–3.65 倍的性价比优势。 + +## 致谢 + +本轮方案优化进展迅速，得益于 [SGLang 与 NVIDIA 的协作](https://github.com/sgl-project/sglang/issues/19380)在大约一个季度内完成了 Blackwell 上 no-MTP/MTP 和 Agg/Disagg 的所有 Functional 和 Baseline Perf 行——FlashInfer 中的 NVFP4 IMA 修复、sm100/sm103 上的稀疏 MLA 默认配置、IndexCache、GLM-5 的基于 EAGLE 的 MTP——而 InferenceX 方案循环在上游稳定后一周内即完成了 H200 MTP 兄弟方案的接入。感谢 SGLang 维护者、FlashInfer 团队、NVIDIA SGLang 协作线程以及在[跟踪 issue](https://github.com/sgl-project/sglang/issues/19380) 上提交 PR 的所有人。上游到基准测试的闭环速度就是护城河。 + + + 点击查看完整 InferenceX 仪表板 → + + +{`{ + "@context": "https://schema.org", + "@type": "FAQPage", + "mainEntity": [ + { + "@type": "Question", + "name": "NVIDIA B200 NVFP4 在 GLM-5 SGLang MTP 推理中的性价比比 H200 FP8 高多少？", + "acceptedAnswer": { + "@type": "Answer", + "text": "在 GLM-5 8K/1K 序列长度下使用 SGLang v0.5.12 并在两款 SKU 上均启用基于 EAGLE 的 MTP，B200 NVFP4（模型 nvidia/GLM-5-NVFP4）在等交互性下性价比最高达 H200 FP8（模型 zai-org/GLM-5-FP8）的 3.65 倍。峰值提升出现在 80 tok/s/user：H200 每百万 tokens 成本为 $1.06，B200 NVFP4 仅为 $0.29。该优势在 H200 的 25 至 84 tok/s/user 全运行区间内保持在 3.24 倍至 3.65 倍。TCO 输入为 H200 $1.41/GPU/hr、B200 $1.95/GPU/hr，来源于 SemiAnalysis AI Cloud TCO 模型。数据来自 2026-05-25 的 InferenceX 基准测试（GHA run 26381101926）。" + } + }, + { + "@type": "Question", + "name": "3.65 倍的 B200 NVFP4 vs H200 FP8 性价比提升中，世代因素和精度因素各贡献多少？", + "acceptedAnswer": { + "@type": "Answer", + "text": "该提升在峰值处可清晰分解。保持精度和 MTP 不变，B200 SGLang FP8 + MTP 在 80 tok/s/user 时的性价比约为 H200 SGLang FP8 + MTP 的 1.22 倍——这是在两款 SKU 上使用相同 EAGLE 方案和相同 zai-org/GLM-5-FP8 检查点时，仅靠 Blackwell 世代加软件带来的提升。将 B200 的权重从 zai-org/GLM-5-FP8 切换为 nvidia/GLM-5-NVFP4 再叠加 2.98 倍——纯粹的精度提升。1.22 乘以 2.98 约等于 3.65。在 H200 运行区间内，世代因素在 1.19 倍（84 tok/s/user）到 1.36 倍（50 tok/s/user）之间，精度因素在 2.41 倍（25 tok/s/user）到 3.07 倍（84 tok/s/user）之间；两者贡献比例互换但组合提升保持在 3.24 倍至 3.65 倍。" + } + }, + { + "@type": "Question", + "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 调度器。" + } + }, + { + "@type": "Question", + "name": "为什么 B200 上 FP4 vs FP8 的精度差距从 25 tok/s/user 的 2.41 倍扩大到 84 tok/s/user 的 3.07 倍？", + "acceptedAnswer": { + "@type": "Answer", + "text": "在低交互性（高并发）时，B200 FP8 + MTP 和 B200 NVFP4 + MTP 均达到权重加载带宽饱和，因此成本比接近 FP4 vs FP8 GEMM 吞吐量的原始 2 倍差异——18 tok/s/user 时为 2.26 倍，25 tok/s/user 时为 2.41 倍。随着交互性提升、并发降低，每个 decode 步骤在更少的 token 间分摊权重加载开销。每个 token 的 GEMM 时间增长，FP4 张量核心的计算优势与 TP=4 NVFP4 方案中更小的每 rank 权重占用（4 GPU vs FP8 曲线的 8 GPU）叠加。在 84 tok/s/user 时，B200 FP8 插值为每百万 tokens $0.94，而 B200 NVFP4 为 $0.31——差距为 3.07 倍，精度差异已成为该方案的成本下限。" + } + }, + { + "@type": "Question", + "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 曲线。" + } + } + ] +}`} 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 new file mode 100644 index 00000000..73da4323 --- /dev/null +++ b/packages/app/content/blog/zh/b200-minimax-m2-5-vllm-nvfp4-vs-h100-fp8-perf-per-dollar.mdx @@ -0,0 +1,248 @@ +--- +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 倍' +date: '2026-05-26' +publishDate: '2026-05-26' +tags: + - benchmark + - gpu + - inference + - minimax + - nvidia + - b200 + - h100 + - vllm + - fp4 +--- + +在 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 天花板成为瓶颈时更为突出。 + + + 点击查看完整的 InferenceX 仪表板 → + + +
+ +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.5 值得投入优化 + +MiniMax-M2.5 是 M2 系列中面向编码和智能体的开源权重模型。其 256 小专家路由层针对软件工程工作负载进行了调优（SWE-Bench 系列、Terminal Bench、智能体工具使用评估），在主要编码质量评估中**与 Claude Opus 4.5/4.6 在每项基准测试上的差距仅 1–4 分**，并在 Multi-SWE-Bench（51.3 vs 42.7）和 VIBE-Pro（54.2 vs 36.9）上**领先 Gemini 3 Pro**。特别是 Multi-SWE-Bench——Opus 4.5 得分 50.0、Opus 4.6 得分 50.3——M2.5 以 51.3 领先。 + +
+ +质量水准是服务成本故事的前提。一个**激活参数仅 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 域扩展）被压缩。 + +
+ +本次基准测试涉及的两个 SKU 的绝对值： + +| 规格 | H100 SXM | B200 SXM | B200 / H100 | +| --------------------------------- | ------------------- | ------------------- | ----------- | +| HBM 容量 | 80 GB (HBM3) | 180 GB (HBM3e) | 2.25x | +| HBM 带宽 | 3.35 TB/s | 8.0 TB/s | 2.39x | +| 密集 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 | +| 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 为零。 + +## TensorRT-LLM MoE 内核集成至 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 前沿使用的配方形状相同。 + +内核的选择至关重要。以下是 MiniMax-M2.5 上的逐内核对比（1K/1K——_不是_ 8K/1K，但内核排序一致），展示了 vLLM 中各 MoE 后端的表现： + +
+ +## 数据详情 + +所有数据行均为 MiniMax-M2.5 在 **ISL 8192 / OSL 1024** 下，使用单节点非分离式配置，于 2026-05-22 在 InferenceX 上使用 vLLM 测量。每百万总 token 的成本计算公式为 `TCO_$/GPU/hr / (3600 × tput_per_gpu / 1e6)`，其中 H100 为 $1.30/GPU/hr，B200 为 $1.95/GPU/hr，参照 [SemiAnalysis AI Cloud TCO 模型](https://newsletter.semianalysis.com/p/ai-cloud-economics)。 + +**H100 vLLM FP8，TP=8，8 GPU**（模型 `MiniMaxAI/MiniMax-M2.5`）： + +| 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 476.5 | 110.93 | 9.01 | $0.76 | +| 8 | 771.4 | 89.71 | 11.15 | $0.47 | +| 16 | 1,193.7 | 69.09 | 14.47 | $0.30 | +| 32 | 1,707.6 | 49.70 | 20.12 | $0.21 | +| 64 | 2,317.0 | 33.00 | 30.31 | $0.16 | +| 128 | 2,985.6 | 21.19 | 47.19 | $0.12 | + +**B200 vLLM FP8，TP=2，2 GPU**（大部分曲线的吞吐量锚点）： + +| 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 1,926.8 | 112.30 | 8.90 | $0.28 | +| 8 | 3,143.5 | 92.25 | 10.84 | $0.17 | +| 16 | 4,684.8 | 68.04 | 14.70 | $0.12 | +| 32 | 6,514.0 | 47.40 | 21.10 | $0.08 | +| 64 | 9,079.0 | 32.35 | 30.91 | $0.06 | +| 128 | 10,053.9 | 23.91 | 41.82 | $0.05 | +| 256 | 10,134.1 | 23.92 | 41.81 | $0.05 | +| 512 | 10,112.2 | 23.85 | 41.93 | $0.05 | + +**B200 vLLM FP8，TP=4，4 GPU**（延伸低交互性段）： + +| 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 256 | 11,035.8 | 19.67 | 50.85 | $0.05 | +| 512 | 11,827.1 | 12.71 | 78.68 | $0.05 | + +**B200 vLLM NVFP4，TP=2，2 GPU**（左侧成本前沿锚点，模型 `nvidia/MiniMax-M2.5-NVFP4`）： + +| 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 128 | 16,256.5 | 28.82 | 34.70 | $0.03 | +| 256 | 17,407.3 | 20.61 | 48.51 | $0.03 | +| 512 | 17,577.0 | 20.63 | 48.47 | $0.03 | + +**B200 vLLM NVFP4，TP=1，1 GPU**（中高交互性段）： + +| 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 4,488.8 | 131.18 | 7.62 | $0.12 | +| 8 | 6,683.0 | 97.87 | 10.22 | $0.08 | +| 16 | 9,546.6 | 68.76 | 14.54 | $0.06 | +| 32 | 11,698.0 | 44.16 | 22.65 | $0.05 | +| 256 | 11,962.0 | 44.29 | 22.58 | $0.05 | + +**B200 vLLM NVFP4，TP=4 和 TP=8，4 和 8 GPU**（在 conc=4 处延伸高交互性段）： + +| 配方 | 并发 | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ------------- | ---- | --------- | ---------- | --------- | ---------- | +| TP=4 / 4 GPUs | 4 | 1,423.3 | 165.92 | 6.03 | $0.38 | +| TP=4 / 4 GPUs | 8 | 2,468.9 | 144.91 | 6.90 | $0.22 | +| TP=8 / 8 GPUs | 4 | 768.6 | 180.26 | 5.55 | $0.70 | + +NVFP4 组合帕累托前沿从 21 tok/s/user 时的 $0.031/M（TP=2，conc=512）延伸到 180 tok/s/user 时的 $0.70/M（TP=8，conc=4）。 + +## 等交互性每美元性能 + +在匹配交互性水平下的每 GPU 吞吐量和每百万 token 成本，沿各 SKU 的帕累托前沿插值。最后一列的每美元性能提升为 $/M 比率的倒数——B200 NVFP4 相对于 H100 的性能/成本。超出前沿测量范围的单元格显示为 _unreachable_。 + +| 交互性 (tok/s/user) | H100 FP8 $/M | B200 FP8 $/M | B200 NVFP4 $/M | B200 NVFP4 性能/$ vs H100 | +| ------------------- | ------------- | ------------- | -------------- | ------------------------- | +| 22 | $0.12 | $0.05 | $0.031 | 3.96x | +| 30 | $0.15 | $0.06 | $0.034 | 4.32x | +| 40 | $0.18 | $0.07 | $0.042 | 4.23x | +| 50 | $0.21 | $0.08 | $0.048 | 4.39x | +| 60 | $0.25 | $0.10 | $0.052 | 4.85x | +| 70 | $0.31 | $0.12 | $0.058 | 5.36x | +| 80 | $0.38 | $0.14 | $0.065 | 5.84x | +| 90 | $0.47 | $0.16 | $0.073 | 6.41x | +| 100 | $0.60 | $0.20 | $0.083 | 7.19x | +| **110** | **$0.74** | **$0.25** | **$0.091** | **8.16x** | +| 130 | _unreachable_ | $0.44 | $0.118 | _∞_ | +| 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。 + +
+ +[实时图表](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)，已预过滤为 MiniMax-M2.5 vLLM 在 H100 + B200 上 2026-05-22 运行的数据。[实时成本视图](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_metric=y_costh&i_linelabel=1&i_advlabel=1)展示相同对比。 + +## Blackwell 在 MiniMax-M2.5 上的后续方向 + +仍有三个方向可以进一步扩大或强化标题数据： + +- **NVL72 分离式（无需宽专家并行）。** **更宽的专家并行对此模型不是正确的杠杆**——在 10B 激活参数、256 个小专家的情况下，TP=2 / 8-GPU 配置中每个 rank 已经只持有少量专家，因此在 72-GPU NVLink 域中扩展 EP 不会显著缩小每 rank 权重占用（不同于 DeepSeek R1 或 Kimi K2.5，后者可通过 EP 集合上的计算-通信重叠实现复合增益）。**分离式 prefill + decode 仍然可行**：当前的单节点聚合配方将两个阶段放在同一个 TP=2 岛上，在 conc 256+ 饱和拐点处争抢 HBM 带宽；GB200/GB300 NVL72 上的分离式配方将 KV 通过 NVLink 5 在专用 prefill 和 decode 池之间传输，使 decode 池在饱和前能吸收更多并发。InferenceX 尚未发布 MiniMax 在 NVL72 上的分离式配方。 + +对于当前的 MiniMax-M2.5 服务，B200 NVFP4 在 H100 可达的每个交互性点上都是更经济的选择，优势为 4 倍至 8.2 倍。 + +## 致谢 + +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 团队发布的开源权重。 + + + 点击查看完整的 InferenceX 仪表板 → + + +{`{ + "@context": "https://schema.org", + "@type": "FAQPage", + "mainEntity": [ + { + "@type": "Question", + "name": "NVIDIA B200 NVFP4 相比 H100 FP8 在 MiniMax-M2.5 vLLM 上每美元性能提升了多少？", + "acceptedAnswer": { + "@type": "Answer", + "text": "在 MiniMax-M2.5 8K/1K 序列长度下使用 vLLM，B200 NVFP4（模型 nvidia/MiniMax-M2.5-NVFP4）在等交互性下相比 H100 FP8（模型 MiniMaxAI/MiniMax-M2.5）最高实现 8.2 倍的每美元性能提升。峰值出现在 110 tok/s/user：H100 为每百万 token $0.74，B200 NVFP4 为每百万 token $0.091。提升从 22 tok/s/user 时的 3.96 倍单调递增至 110 时的 8.16 倍。TCO 参数为 H100 $1.30/GPU/小时、B200 $1.95/GPU/小时，来自 SemiAnalysis AI Cloud TCO 模型。测量于 2026-05-22 的 InferenceX（GHA 运行 26306422380）。" + } + }, + { + "@type": "Question", + "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 在此路由方法下无竞争力。" + } + }, + { + "@type": "Question", + "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 倍而非保持恒定的原因。" + } + }, + { + "@type": "Question", + "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 内核，代际步骤将向其纸面天花板收窄。" + } + }, + { + "@type": "Question", + "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 曲线。" + } + } + ] +}`} 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 new file mode 100644 index 00000000..38e84357 --- /dev/null +++ b/packages/app/content/blog/zh/b200-nvfp4-vs-h200-int4-kimi-k2-vllm-perf-per-dollar.mdx @@ -0,0 +1,201 @@ +--- +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 张量核心——可清晰分解该优势' +date: '2026-05-26' +publishDate: '2026-05-26' +tags: + - benchmark + - gpu + - inference + - kimi + - nvidia + - b200 + - h200 + - vllm + - nvfp4 +--- + +Kimi K2.5 和 K2.6 是 xAI Cursor Composer 2 和 Composer 2.5 背后的开源权重模型——Cursor IDE 日活用户超百万，且 K2.6 以 58.6% 的成绩领跑 SWE-Bench Pro。在 8K/1K 工作负载下，vLLM 在 NVIDIA B200 上以 NVFP4 运行 K2.5/K2.6，在整个单节点 Pareto 前沿上均比 H200 INT4 更便宜。**在 30–90 tok/s/user 推理区间内，B200 NVFP4 每百万 tokens 成本比 H200 INT4 低 2.71x–2.95x**，峰值为 **32 tok/s/user 时的 2.95 倍**（B200 NVFP4 为 $0.140/M vs H200 INT4 为 $0.413/M——成本降低 66%）。在相同 B200 硬件上，从 INT4 切换到 NVFP4 在等交互性下还可额外带来 **2.45x–2.74x 的优势**（40 tok/s/user 时 $0.397/M → $0.154/M）。数据来自 SemiAnalysis InferenceX，2026-05-19，[GHA run 26118912054](https://github.com/SemiAnalysisAI/InferenceX/actions/runs/26118912054)。 + +两款 SKU 均运行相同的 `vllm/vllm-openai:v0.21.0` 容器。差距来自硬件和精度。B200 的 FP8 dense 吞吐量是 H200 的 2.27 倍（4,500 vs 1,979 TFLOP/s）、HBM 带宽 1.67 倍（8 vs 4.8 TB/s）、NVLink Scale-up 带宽 2.00 倍（900 vs 450 GB/s 单向）。在 FP4 轴上 H200 完全空白——Hopper SM90 没有 FP4 张量核心，[官方数据表](https://resources.nvidia.com/en-us-data-center-overview/gtc24-h200-datasheet)止步于 FP8。B200 的 NVFP4 核心提供 9,000 TFLOP/s。实测的约 3 倍 token 成本差距，就是这些硅片比值在折算 B200 1.38 倍 TCO 溢价（$1.95 vs $1.41/GPU/hr，来源于 [SemiAnalysis AI Cloud TCO 模型](https://newsletter.semianalysis.com/p/ai-cloud-economics)）之后的呈现。 + + + 点击查看完整 InferenceX 仪表板 → + + +
+ +## 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)——两者是在同一预训练架构上的后训练优化，因此**本文中的每一个推理结果都同样适用于这两个版本**。 + +
+ +**K2.5 和 K2.6 是 xAI Cursor Composer 2 和 Composer 2.5 背后的开源权重模型**，服务于 Cursor IDE 超过百万的日活用户。**K2.6 还在公开 agentic 编程基准测试中领先前沿模型**：SWE-Bench Pro 得分 58.6%——领先 GPT-5.4（57.7%）、Claude Opus 4.6（53.4%）和 Gemini 3.1 Pro（54.2%）——SWE-Bench Verified 得分 80.2%（[Moonshot K2.6 模型卡](https://huggingface.co/moonshotai/Kimi-K2.6)）。Cline 的[生产部署数据](https://cline.bot/blog/moonshots-kimi-k2-for-coding-our-first-impressions-in-cline)显示其在复杂 diff 编辑任务上的失败率为 3.3%，与 Claude 4 Sonnet 持平。K2.6 的 Agent Swarm 原语可扇出至 **300 个并行子 agent，跨 4,000 个协调步骤**，从 K2.5 的 100 / 1,500 提升。如果你今天在托管开源 agentic 编程栈，K2.5 或 K2.6 就是你在服务的模型。 + +关于量化的说明：Moonshot 发布 K2.5/K2.6 时，**原生 INT4 权重**是默认的开源权重检查点——本文中 H200 INT4 和 B200 INT4 曲线直接使用该检查点。**B200 NVFP4 曲线使用的是相同权重的 NVFP4 再量化版本**，以便 B200 的 FP4 张量核心能以全速率执行 MoE GEMM。H200 无法运行此路径——Hopper SM90 没有 FP4 张量核心。 + +## 纸面规格 + +NVIDIA B200 SXM（Blackwell，2025）vs NVIDIA H200 SXM（Hopper，2024）——两者均为 NVIDIA，均运行 vLLM，均部署在 8-GPU NVLink 域中。下方雷达图（chart）将每个轴归一化到 [`/gpu-specs`](/gpu-specs) 中的跨厂商最大值，因此可见多边形在 GB200 NVL72 / GB300 NVL72 设定上限的轴上被压缩（Scale Up Domain Memory + 带宽在 72-GPU 节点规模下），FP4 轴由 GB300 NVL72 的 15,000 TFLOP/s 主导——B200 的 9,000 TFLOP/s 在该轴上约为 60%。 + +
+ +| 规格 | H200 SXM | B200 SXM | B200 / H200 | +| --------------------------------- | ------------------- | ------------------- | ----------- | +| HBM 容量 | 141 GB | 180 GB | 1.28x | +| HBM 带宽 | 4.8 TB/s | 8 TB/s | **1.67x** | +| Dense FP4 (TFLOP/s) | —（无 FP4 核心） | 9,000 | **∞** | +| Dense FP8 (TFLOP/s) | 1,979 | 4,500 | **2.27x** | +| Dense BF16 (TFLOP/s) | 989 | 2,250 | 2.27x | +| Scale-up 每 GPU 带宽（单向） | 450 GB/s (NVLink 4) | 900 GB/s (NVLink 5) | **2.00x** | +| Scale-up 节点规模 | 8 | 8 | 1.00x | +| Scale-up Domain HBM 容量 | 1.13 TB | 1.44 TB | 1.28x | +| Scale-up Domain HBM 带宽（聚合） | 38.4 TB/s | 64 TB/s | 1.67x | +| TCO（SemiAnalysis AI Cloud 模型） | $1.41/GPU/hr | $1.95/GPU/hr | 1.38x | + +**从硅片规格到实测性能的映射。** 当两款 SKU 在同一模型上都运行 vLLM INT4 时，工作负载在 **decode 路径上受 HBM 带宽瓶颈限制**——每一步通过 HBM 流式读取活跃专家权重，在并发用户间分批执行。B200 1.67 倍的 HBM 带宽优势直接体现在吞吐量上：在 iv = 26 tok/s/user 时，**B200 INT4 达到 1,791 tok/s/GPU vs H200 INT4 的插值 1,055——比值为 1.70x，正好位于硅片极限**。扣除 1.38 倍 TCO 溢价后，B200 INT4 相对 H200 INT4 获得 1.22 倍的 token 成本优势。 + +**HBM 容量带来了雷达图上看不到的第二个硅片优势：更低的 TP，每个 token 更少的集合通信开销。** Kimi K2.5/K2.6 INT4 的模型活跃状态约占 **500 GB**（1T 总参数 × 约 4 bit + 激活值 + KV 缓存 + paged attention 暂存空间）。在 B200 的 **180 GB/GPU** 上，可以放入 **4 GPU（720 GB 聚合，约 30% 空间留给 KV 缓存和激活值）→ TP=4 可行**。在 H200 的 **141 GB/GPU** 上，同样的模型需要 **至少 8 GPU（1,128 GB 聚合）才能留出足够的 KV 缓存空间 → 必须使用 TP=8**。本文中每一个 Pareto 最优的 B200 NVFP4 数据点都是 **TP=4**；每一个 H200 INT4 数据点都是 **TP=8**。 + +张量并行度减半意味着每个 decode 步骤的集合通信流量减半——注意力输出投影、MoE gather 和 post-MLP reduce 上各少一个 log₂N AllReduce 跳。Amdahl 定律在串行集合通信瓶颈上拉低了每步延迟下限。B200 NVFP4 曲线不仅因精度比值而位于 B200 INT4 之上；它还因每个 decode 步骤完成更快而在交互性轴上向左偏移。 + +**精度解锁叠加在以上两个因素之上。** 将 B200 的路径从 INT4 切换为 NVFP4，使其 dense 张量核心吞吐量翻倍——这条路径承担了 K2 中 MoE GEMM 的大部分计算——且无需额外的 HBM 开销。B200 NVFP4 在 32 tok/s/user 时达到 **3,879 tok/s/GPU，是 B200 INT4 峰值（26 tok/s/user）的 2.17 倍**。将三个因素相乘——**1.67x HBM 带宽（decode 瓶颈下的吞吐量下限）× 约 2x NVFP4（精度解锁）× TP=4 vs TP=8 的集合通信优势**——再除以 1.38x TCO 溢价。最终得到实测的 **2.95 倍每百万 tokens 成本优势**。 + +## 详细数据 + +所有行均为 Kimi K2.5 / K2.6 在 **ISL 8192 / OSL 1024** 下的单 8-GPU 节点结果，数据来自 2026-05-19 的 InferenceX 基准测试，[GHA run 26118912054](https://github.com/SemiAnalysisAI/InferenceX/actions/runs/26118912054)。吞吐量为每 GPU 数值。每百万 tokens 成本使用 SemiAnalysis AI Cloud TCO 模型：H200 $1.41/GPU/hr，B200 $1.95/GPU/hr。公式：`$/M tok = TCO\_$/GPU/hr × 1e6 / (3600 × tput_per_gpu)`。 + +**H200 vLLM INT4 (TP=8)**——参考基准： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 384.4 | 91.18 | 10.97 | $1.019 | +| 8 | 590.2 | 70.28 | 14.23 | $0.664 | +| 16 | 797.9 | 46.64 | 21.44 | $0.491 | +| 32 | 990.9 | 28.86 | 34.65 | $0.395 | +| 64 | 1,174.5 | 16.67 | 59.98 | $0.334 | + +**B200 vLLM INT4 (TP=8)**——相同精度下的 Blackwell 硬件，隔离纯硬件差异： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | +| ---- | --------- | ---------- | --------- | ---------- | +| 4 | 446.7 | 104.36 | 9.58 | $1.213 | +| 8 | 692.8 | 81.12 | 12.33 | $0.782 | +| 16 | 969.4 | 59.21 | 16.89 | $0.559 | +| 32 | 1,351.4 | 40.48 | 24.70 | $0.401 | +| 64 | 1,790.7 | 26.01 | 38.45 | $0.303 | + +**B200 vLLM NVFP4 (TP=4 + TP=8)**——标题中的最优方案；dense Pareto 最优段在所有并发度下均为 TP=4，外加一个 TP=8 conc=4 数据点延伸高交互性端： + +| Conc | tok/s/GPU | tok/s/user | TPOT (ms) | $/M tokens | TP | +| ---- | --------- | ---------- | --------- | ---------- | ---- | +| 4 | 532.0 | 125.51 | 7.97 | $1.018 | TP=8 | +| 4 | 947.4 | 111.08 | 9.00 | $0.572 | TP=4 | +| 8 | 1,537.2 | 90.66 | 11.03 | $0.352 | TP=4 | +| 16 | 2,318.7 | 67.40 | 14.84 | $0.234 | TP=4 | +| 32 | 3,202.7 | 46.83 | 21.35 | $0.169 | TP=4 | +| 64 | 3,879.3 | 32.19 | 31.07 | **$0.140** | TP=4 | + +加粗行即为标题数字：**B200 NVFP4 在 32 tok/s/user 时每百万 tokens 仅需 $0.140**，为图表中的最低推理成本。 + +## 等交互性成本对比 + +在匹配的交互性水平下，沿每款 SKU 的 Pareto 前沿插值得出的每百万 tokens 成本。超出前沿测量范围的单元格标记为 `_unreachable_`（比值列标记为 `_∞_`）。三条曲线的重叠区间为 **30–90 tok/s/user**——这是有意义的三方对比所在的区间。 + +| 交互性 (tok/s/user) | H200 INT4 $/M | B200 INT4 $/M | B200 NVFP4 $/M | H200 / B200 NVFP4 | H200 / B200 INT4 | B200 INT4 / B200 NVFP4 | +| ------------------- | ------------- | ------------- | -------------- | ----------------- | ---------------- | ---------------------- | +| **32** | **$0.413** | **$0.343** | **$0.140** | **2.95x** | **1.20x** | **2.45x** | +| 35 | $0.427 | $0.362 | $0.145 | 2.95x | 1.18x | 2.50x | +| 40 | $0.453 | $0.397 | $0.154 | 2.94x | 1.14x | 2.58x | +| 50 | $0.511 | $0.477 | $0.177 | 2.88x | 1.07x | 2.69x | +| 60 | $0.569 | $0.566 | $0.206 | 2.75x | 1.00x | **2.74x** | +| 70 | $0.660 | $0.655 | $0.244 | 2.71x | 1.01x | 2.69x | +| 80 | $0.811 | $0.766 | $0.286 | 2.84x | 1.06x | 2.68x | +| 90 | $0.996 | $0.927 | $0.347 | 2.87x | 1.07x | 2.67x | +| 100 | _unreachable_ | $1.123 | $0.421 | _∞_ | _unreachable_ | 2.67x | +| 110 | _unreachable_ | _unreachable_ | $0.550 | _∞_ | _∞_ | _∞_ | +| 125 | _unreachable_ | _unreachable_ | $1.000 | _∞_ | _∞_ | _∞_ | + +**B200 NVFP4 vs H200 INT4 的差距在重叠区间内几乎恒定：30 到 90 tok/s/user 范围内为 2.71x–2.95x。** 曲线的两端获得相同的优势。在低交互性/高批量端，工作负载受 decode 瓶颈限制，B200 的 HBM 带宽 + NVFP4 张量核心均保持饱和。在高交互性/低批量端，NVFP4 随批量缩小持续降低每 token 计算开销。同精度行（H200 INT4 vs B200 INT4）则呈现不同的趋势：在 **60–80 tok/s/user 时收窄至 1.00x–1.07x**，B200 的硅片优势仅仅能覆盖其 TCO 溢价。精度解锁才是支撑标题数字的核心。 + +在 100 tok/s/user 以上，只有 B200 NVFP4 还有可用方案。H200 INT4 的前沿在 91 tok/s/user 终止（并发 4 时单步计算饱和）；B200 INT4 在 104 tok/s/user 终止。**B200 NVFP4 仍可在 125 tok/s/user 时以 $1.00/M 提供服务**——这是任何 Hopper 方案都无法到达的区间。 + +
+ +[在线图表](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)，已预筛选为 2026-05-19 测试中 B200 + H200 上的 vLLM Kimi K2.5/K2.6 FP4 和 INT4 对比。 + +## 致谢 + +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 上执行。速度就是护城河。 + + + 点击查看完整 InferenceX 仪表板 → + + +{`{ + "@context": "https://schema.org", + "@type": "FAQPage", + "mainEntity": [ + { + "@type": "Question", + "name": "NVIDIA B200 NVFP4 在 Kimi K2.5 和 K2.6 推理中比 H200 INT4 便宜多少？", + "acceptedAnswer": { + "@type": "Answer", + "text": "在 8K/1K 工作负载下使用 vLLM，B200 NVFP4 在 30 到 90 tok/s/user 推理区间内每百万 tokens 成本比 H200 INT4 低 2.71 倍到 2.95 倍。峰值差距为 32 tok/s/user 时的 2.95 倍，B200 NVFP4 每百万 tokens 为 $0.140，H200 INT4 为 $0.413——成本降低 65%。在 100 tok/s/user 以上，H200 INT4 没有可用方案，而 B200 NVFP4 仍可在 125 tok/s/user 时以 $1.00/M 提供服务。TCO 使用 SemiAnalysis AI Cloud TCO 模型：H200 $1.41/GPU/hr，B200 $1.95/GPU/hr。数据来自 InferenceX，GHA run 26118912054，2026-05-19。" + } + }, + { + "@type": "Question", + "name": "差距中有多少来自硅片，多少来自精度解锁？", + "acceptedAnswer": { + "@type": "Answer", + "text": "三个因素叠加。（1）HBM 带宽：B200 的 HBM 带宽是 H200 的 1.67 倍（8 vs 4.8 TB/s），且工作负载受 decode 瓶颈限制，因此在 iv = 26 tok/s/user 时 B200 INT4 达到 1,791 tok/s/GPU，而 H200 INT4 插值为 1,055——1.70 倍，正好位于硅片比值。（2）HBM 容量解锁更低的张量并行度：Kimi K2.5/K2.6 INT4 的模型活跃状态约 500 GB，可放入 4 块 B200 GPU（每块 180 GB，聚合 720 GB），但需要 8 块 H200 GPU（每块 141 GB，聚合 1,128 GB）才能留出足够的 KV 缓存空间。本文中每个 Pareto 最优的 B200 NVFP4 方案为 TP=4；每个 H200 INT4 数据点为 TP=8。张量并行度减半意味着每个 decode 步骤的集合通信流量减半（少一个 log-base-2-N AllReduce 跳），Amdahl 定律在串行集合通信瓶颈上拉低每步延迟下限。（3）精度解锁：将 B200 从 INT4 切换为 NVFP4 使 dense 张量核心吞吐量翻倍，B200 NVFP4 峰值达到 3,879 tok/s/GPU（B200 INT4 峰值的 2.17 倍）。三者相乘再除以 1.38 倍 TCO 溢价（B200 $1.95 vs H200 $1.41/GPU/hr），得到实测的 2.71x-2.95x 每百万 tokens 成本优势。NVFP4 是精度杠杆；HBM 带宽是吞吐量下限；HBM 容量是降低 TP 的杠杆；H200 三者皆无（Hopper 不支持 FP4 张量核心、更低的 HBM 带宽、更低的 HBM 容量迫使 TP=8）。" + } + }, + { + "@type": "Question", + "name": "在相同 B200 硬件上从 INT4 切换到 NVFP4 值得吗？", + "acceptedAnswer": { + "@type": "Answer", + "text": "值得。在相同 B200 硬件上，将 vLLM 精度从原生 INT4 切换为 NVFP4，在 30 到 90 tok/s/user 推理区间内可获得 2.45 倍到 2.74 倍的等交互性成本优势，峰值在 60 tok/s/user 时达到 2.74 倍（INT4 每百万 tokens $0.566 vs NVFP4 $0.206）。机制：NVFP4 启用了 B200 的 9,000 TFLOP/s FP4 张量核心，而 INT4 路径不使用这些核心。NVFP4 还扩展了可达的交互性范围——B200 INT4 上限为 104 tok/s/user，B200 NVFP4 可服务至 125 tok/s/user。无需更换硬件，无 TCO 变化，仅靠精度切换。" + } + }, + { + "@type": "Question", + "name": "为什么 Kimi K2.5 / K2.6 是这里重要的模型？", + "acceptedAnswer": { + "@type": "Answer", + "text": "Kimi K2.5 和 K2.6 是 xAI Cursor Composer 2 和 Composer 2.5 后端的开源权重模型，服务于 Cursor IDE 超过百万的日活用户。K2.6 还在公开 agentic 编程基准测试中领先前沿模型：SWE-Bench Pro 得分 58.6%，领先 GPT-5.4（57.7）、Claude Opus 4.6（53.4）和 Gemini 3.1 Pro（54.2），SWE-Bench Verified 得分 80.2%。Cline 的生产部署数据显示其在复杂 diff 编辑任务上的失败率为 3.3%，与 Claude 4 Sonnet 持平。架构为 1T 总参数、每 token 32B 激活、384 个专家（选 8 个加 1 个共享）、61 个 Transformer 层、Multi-head Latent Attention 和 256K 上下文窗口。K2.5（发布于 2026-01-27）和 K2.6（发布于 2026-04-20）共享相同的预训练骨干网络，因此本文中的每一个推理结果都同样适用于两者——它们是后训练优化，不是新架构。如果你今天在托管开源 agentic 编程栈，K2.5 或 K2.6 就是你在服务的模型。" + } + }, + { + "@type": "Question", + "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 上下文窗口模型产生影响后重新排列曲线。" + } + } + ] +}`} 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 new file mode 100644 index 00000000..7bb0d216 --- /dev/null +++ b/packages/app/content/blog/zh/deepseekv4-16t-day-0-to-day-43-performance.mdx @@ -0,0 +1,588 @@ +--- +title: 'DeepSeekV4 1.6T 第0天至第43天性能演进 — Huawei、GB300 NVL72、MI355X、B200' +subtitle: '第0天推理性能、InferenceX、26天内性能提升100倍、每百万 token 成本、Huawei 950DT 推理 Trace 分析' +date: '2026-06-09' +publishDate: '2026-06-09' +tags: + - benchmark + - gpu + - inference + - deepseek + - nvidia + - amd + - huawei + - gb300 + - b300 + - b200 + - mi355x + - h200 + - sglang + - vllm + - trtllm +--- + +_本文最初于 2026 年 6 月 9 日发布在 [SemiAnalysis 通讯](https://newsletter.semianalysis.com/p/deepseekv4-16t-day-0-to-day-43-performance)。_ + +DeepSeek v4 的发布标志着开源模型社区又迈出了重要一步——毫不意外，它再次出自中国实验室之手。其推理性能的演进对整个 AI 生态系统至关重要。[开源 InferenceX 工程团队连续多个通宵，在第 0 天、第 1 天、第 2 天及之后持续测量该模型的性能表现，并将结果公之于众。](https://inferencex.semianalysis.com/)在本文中，我们将重点介绍 DeepSeek v4 的第 0 天性能，并解释模型发布后数周内所取得的重大改进。我们还将阐述 DeepSeek v4 模型架构的核心组件，并探讨其部分设计如何针对 Huawei Ascend 推理进行了协同优化。 + +在博客文章的第二节中，我们对 DeepSeekv4 在 Huawei Ascend 950DT 上的第 0 天推理进行了全面分析。本文是 Ascend 950DT 上 DeepSeekv4 推理的首篇分析报告，我们详细拆解了 Huawei 为优化性能所做的计算↔通信重叠以及不同的计算流设计。 + +InferenceX 的一个核心目标，尤其是在模型第 0 天发布窗口期间，是使用开源镜像和配方，尽可能多地在各种框架上记录每种 SKU 的性能表现，无论这些镜像和配方的实际性能如何。这使我们能够追踪性能的持续改进，我们认为这最能反映每种芯片真实可部署的性能。下方视频展示了 vLLM/SGLang 从第 0 天起非 MTP 配置的迭代改进过程。[访问 inference.com 查看从第 0 天起的 MTP 配置](https://inferencemax.ai/)。 + +
diff --git a/packages/app/src/components/header/header.tsx b/packages/app/src/components/header/header.tsx index eebef27d..576a3bdb 100644 --- a/packages/app/src/components/header/header.tsx +++ b/packages/app/src/components/header/header.tsx @@ -9,6 +9,8 @@ import { track } from '@/lib/analytics'; import { ModeToggle } from '@/components/ui/mode-toggle'; import { MinecraftToggles } from '@/components/minecraft/minecraft-toggles'; import { navigateInApp } from '@/lib/client-navigation'; +import { hasZhSibling, isZhPathname, switchLocalePath, ZH_PREFIX, zhPath } from '@/lib/i18n'; +import { NAV_LABELS_ZH } from '@/lib/tab-meta-zh'; import { cn } from '@/lib/utils'; import { GitHubStars } from './GithubStars'; @@ -57,12 +59,36 @@ const NAV_LINKS = [ ] as const; function isActive(pathname: string, href: string): boolean { - if (href === '/') return pathname === '/'; - if (href === '/inference') return DASHBOARD_TABS.some((tab) => pathname.startsWith(tab)); + // Chinese pages mirror the English tree under /zh; active state is computed + // against the English path so both trees highlight the same nav entry. + const enPathname = isZhPathname(pathname) + ? pathname === ZH_PREFIX + ? '/' + : pathname.slice(ZH_PREFIX.length) + : pathname; + if (href === '/') return enPathname === '/'; + if (href === '/inference') return DASHBOARD_TABS.some((tab) => enPathname.startsWith(tab)); // Exact match or a child path under `/...`. The bare `startsWith` would // light up `/compare` when the user is on `/compare-per-dollar/...` since the // latter starts with the literal string `/compare`. - return pathname === href || pathname.startsWith(`${href}/`); + return enPathname === href || enPathname.startsWith(`${href}/`); +} + +/** EN ↔ 中文 switcher; maps the current page to its sibling in the other language. */ +function LanguageToggle({ pathname }: { pathname: string }) { + const isZh = isZhPathname(pathname); + const target = switchLocalePath(pathname); + return ( + track('header_language_toggled', { to: isZh ? 'en' : 'zh' })} + > + {isZh ? 'EN' : '中文'} + + ); } export const Header = ({ starCount }: { starCount?: number | null }) => { @@ -71,7 +97,16 @@ export const Header = ({ starCount }: { starCount?: number | null }) => { const [mobileMenuOpen, setMobileMenuOpen] = useState(false); const menuRef = useRef(null); - const navLinks = NAV_LINKS; + const isZh = isZhPathname(pathname); + // On /zh pages, nav entries with a Chinese sibling navigate within the + // Chinese tree and show Chinese labels; the rest keep their English target. + const navLinks = isZh + ? NAV_LINKS.map((link) => ({ + ...link, + label: NAV_LABELS_ZH[link.href] ?? link.label, + displayHref: hasZhSibling(link.href) ? zhPath(link.href) : link.href, + })) + : NAV_LINKS.map((link) => ({ ...link, displayHref: link.href })); // Close menu on route change useEffect(() => { @@ -126,11 +161,11 @@ export const Header = ({ starCount }: { starCount?: number | null }) => { {/* Desktop nav */}