便宜的昇腾卡跑通Qwen3.8，从语无伦次到30 tok/s

两块96GB昇腾卡跑通Qwen3.8 Flash-Next：硬件笔记、vLLM工作、基准测试与下一步

这段时间，我一直在搭建一台有点非典型的本地推理机，核心是两张华为 Atlas 300I Duo 卡。它们相对便宜，是被动散热、双加速器的 PCIe 卡，每张卡有 96 GB 设备内存。但绝不能把它们当作 CUDA 的直接替代品。

过去两周刚把 Qwen3.8 Flash-Next 跑起来时，输出经常语无伦次，速度大约每秒 1 个 token，有时甚至更低。现在，同样的两台卡机，单请求大约能稳定输出 30 tok/s，四个并发请求在我的短解码基准测试中合计约 61 tok/s。它还完整跑完了 GPQA Diamond 的 198 道题。

这篇帖子是这些卡的上手指南的开端：卡的实际物理结构、我如何散热、“96 GB”到底意味着什么、我在 vLLM 和 vLLM Ascend 中改了什么、哪些优化真正起作用，以及还有哪些问题未解决。

简而言之：硬件是能打的。我的工作主要花在软件栈上——Ubuntu 26.04 驱动支持、模型架构支持、内存布局、自定义算子，以及把每一个异步状态转换都弄得完全正确。

硬件：一张卡实际上是两个设备

我当前的机器有两张 Atlas 300I Duo 卡，枚举出来是四个 Ascend 310P3 设备。

每张卡有两个加速器 SoC，总共 96 GB LPDDR4X，也就是每个芯片本地 48 GB。这不是一个统一的 96 GB 分配。 一个放不进单个 48 GB 设备的模型，仍然需要 tensor、expert、pipeline 或其他形式的模型并行。这张卡是 PCIe Gen4 x16，全高全长，而且是惊人的薄型单槽设计。华为标称聚合内存带宽 408 GB/s，最大板级功率 150 W。官方规格见这里（[https://support.huawei.com/enterprise/en/doc/EDOC1100285916?section=j00e0）。

另外，尽管很多加速器软件用泛泛的“HBM”术语，这些卡上的内存是 LPDDR4X。

这种每卡双芯片的布局很重要。模型内部的通信仍然走分布式运行时，内存在每个 rank 本地。我用 HCCL 集合通信，并显式地把 tensor 和 expert 所有权映射到全部四个芯片上。把这台机器看成四个 48 GB rank，比看成两个 96 GB GPU 有用得多。

https://reddit.com/link/1wvt1m4/video/7rju7qbrw1th1/player

被动散热不是问题

这些卡有大面积散热片，没有板载风扇。它们是为服务器风道设计的，所以放进普通工作站、指望机箱后置风扇解决一切，是个糟糕的方案。这里有一篇有用的拆解（[https://videocardz.com/newz/huawei-atlas-300i-dual-ai-gpu-with-96gb-memory-worth-1400-has-been-taken-apart1），如果你想看看散热片和热管布局。

我给它们提供直接、大流量的气流，并用空调/热泵给房间制冷。在真实的多小时模型负载下，这些卡能持续满载运行而不出幺蛾子。在我记录的 Qwen 运行中，峰值设备温度一般在 72–78 °C。我的看门狗上限是 96 °C，它们从未接近过。

所以，再加一张被动散热卡我眼睛都不会眨一下。实际操作清单很平常：

- 保持散热片鳍片气流畅通无阻。
- 确保机箱风扇有足够的静压。
- 每张卡额外预留 150 W 板级功率，加上宿主机其余部分。
- 把热量排出房间，而不是在机架内循环。
- 在长时间 prefill、decode 和并发测试期间记录温度，而不是相信空闲读数。

被动不代表低功耗或能自行散热。它意味着机箱和房间就是散热系统。一旦处理好这一点，对我来说这些卡就和普通的 150 W 服务器卡一样省心。

注意： 没有什么比在内存中加载/搬移东西更让这些卡发热的——NPU 满载运行反而比大块内存分配凉快。我们在优化模型服务代码路径时牢记了这一点。

ECC、铭牌内存，以及实际可用多少

我的卡默认开启了 ECC。我把它关闭以回收设备内存。这是一台推理和开发机器，在这里我明确选择容量优先于 ECC 保护。这是一个可靠性权衡，不是普适建议。

即使关闭 ECC，固件、运行时、通信缓冲区、图捕获、workspace、分配器预留仍然占用内存。实际上，软件看到的每个 48 GB 芯片大约是 43 GiB。因此四个芯片总共大约 172 GiB 的可用聚合容量，但它仍然是四个独立的本地池。具体可用数字还会随 CANN 构建和启动配置变化。

这个区别影响了几乎每一个模型决策。问题不只是“checkpoint 总量能否放进 192 GB？”，而是“每个 rank 的权重分片、循环状态、KV/缓存分配、图捕获、集合通信 workspace，以及最坏情况下的临时分配，能否各自放进自己的 43 GiB？”

为什么我同时 fork 了 vLLM 和 vLLM Ascend

公开工作放在 OpenSensor vLLM Ascend fork（[https://github.com/opensensor/vllm-ascend2）和配套的 vLLM fork（[https://github.com/opensensor/vllm3）。我两边都需要，因为这不仅仅是缺少一个设备 kernel。

目前我是这两个 fork 的唯一开发者。软件 bus factor 现在是 1。我取得了不少进展，但一个快速推进的单人 fork，不应被误认为 mainline vLLM 在 NVIDIA 上的成熟度、测试覆盖或支持深度。

我还遇到了一个奇怪的工具体问题：在我的会话里，Claude 一再拒绝处理关于这个架构的提示，因为这些卡是来自中国的华为硬件。这些只是关于服务、切分、散热和性能的普通工程讨论——不是要求构建受限应用。我是在描述自己的直接经验，而不是声称每个 Claude 版本或账号都会表现一样，但这确实让 Claude 作为这个项目的开发助手变得不可靠。无论任何人对政治怎么看，在选择围绕这个硬件的工具时，这是一个真实存在的实际约束。

Qwen3.8 Flash-Next 结合了 MoE（混合专家）路由、Gated DeltaNet 循环层、稀疏二次注意力层、打包的低比特专家、长上下文，以及 MTP（多 token 预测）草稿模型。要干净地支持它，涉及模型集成、v1 runner、缓存记账、调度、图捕获、分布式状态、模型加载，以及 Ascend 专用算子。

当前的开发冲刺大约持续了两周半，几乎不间断地做 bring-up 和优化，提交了数百次 fork commit，反复完整加载 checkpoint，做 profiler 捕获、算子微基准测试、数小时的质量运行。这不是一个神奇的 kernel 补丁。

是什么让 Qwen 从不连贯的 ~1 tok/s 变成现在这样

以下是推动进展的架构性改变。

1. 先让混合模型正确，再让它变快

早期模型能生成 token，但生成不是正确性测试。我发现了只在生产几何形状下才会暴露的失败：Gated DeltaNet 门控向量处理错误、循环状态精度和生命周期问题、稀疏注意力分数宽度不完整，以及宿主算子 API 与已安装 kernel 包之间的不匹配。

其中一个特别糟糕的 GDN 问题在小头测试中看起来没问题，但在真正的 36 个循环层中累积了状态误差，导致生成语无伦次。把循环状态保持为 FP32，并修复生产形状的数据搬移，是基础。把自定义 OPP 包和 Python 宿主代码当作一个 ABI 版本化的整体来处理，同样重要。一个过期的 kernel 可能长时间伪装成模型问题。

2. 在加载时切分模型，而不是每处都加载全部内容

Qwen checkpoint 约 169 GiB，包含 1,610 个 safetensor 文件。在我某个 bring-up 配置中，它比我宿主机可用内存还大，更不用说单个 NPU 的内存了。

我构建了一个感知 expert 的加载器，只读取每个 rank 拥有的 expert，按需保留 dense/共享张量，避免先把整个 expert bank 物化再丢掉大部分。宿主侧的 expert 数据惰性映射和搬移。这把模型加载从一次意外的内存压力测试，变成了确定性的 TP4/EP4 布局。

3. 保持低比特权重打包，在 NPU 上完成工作

我的第一个可用的 W4 参考实现，在 eager 路径中反量化打包权重，然后调用常规 matmul。对正确性有用，但一次记录的 smoke 测试只跑出了 0.229 tok/s。

生产路径保持权重打包，在设备上把 token 路由到 expert，并用自定义 AscendC Cube 算子做分组 expert 投影。我加了 FRACTAL_NZ 布局、融合 gate/up 处理、分块归约、路由和 tile 复用，以及专门的 W4A8 执行，而不是把 W4 权重反复展开成更大的临时表示。

这既是速度提升，也是容量提升。避免瞬态展开的 expert bank，为状态、缓存、图和并发留出内存。

4. 为实际拥有的模型构建缓存

Flash-Next 不是传统的全注意力 transformer。我的配置有 36 个循环 GDN 层和 12 个稀疏 QSA 层。把所有这些当作普通 dense KV 缓存处理，会浪费内存并丢失状态语义。

我实现了独立的循环状态管理、紧凑的物理缓存布局、前缀状态分层、稀疏页选择、直接 NZ gather，以及 310P 专用的 QSA 路径。服务配置为 262,144 token 的上下文限制，缓存规划器保留了大约 4.08 个这样的窗口容量。这是一个内存规划结果，不是声明所有可能的四乘 262K 负载都完成了端到端浸透测试。

5. 从 token 循环中移除同步和启动开销

在这些设备上，一次离群的设备到宿主标量读取就可能让整个流水线串行化。我去掉了热路径中的 .item() 调用，复用每步张量，把集合通信推迟到有用工作之后，收紧 CPU 亲和性，并把路由和稀疏选择移出 Python。

eager 路径正确后，我加入了 decode-only ACL 图和 MTP2 推测解码。我捕获实际服务的并发形状，而不是假装一个图是万能的。当一个 decode 步骤由许多小 kernel 启动组成时，融合算子和图回放至关重要。

6. 优化服务，而不只是孤立 kernel

有几个 kernel 在微基准中胜出，却在端到端中落败。我保留了那些真正减少请求时间的，拒绝或隔离了其他的。多请求 QSA、分组 MTP expert、expert 路由缓存、缓存记账、冷 prefill 分块、集合通信重叠，都在 API 边界做了测量。

最后一点，正是为什么四个并发请求能到约 61 tok/s 的聚合，而单请求约 30 tok/s。额外的工作可以占用单个 token 流会留空的机器部分。

Qwen 当前性能

以下里程碑来自不同阶段和工作负载，不是一组受控的单变量基准：

30/61 tok/s 的数字是短、固定输出 decode 测试。长推理请求讲述的是不那么好看但更有用的故事。

https://reddit.com/link/1wvt1m4/video/rpc5c2c1s1th1/player

关于质量： 我在四芯片 Ascend W4 服务上跑了全部 198 道 GPQA Diamond 题，并作为参考，用 RTX 6000 Pro 在 llama.cpp 里跑了一个不同的 IQ4_XS GGUF。两者都得了 140/198（70.71%），使用同一个 AISBench 风格的答案提取器。这表明 Ascend 路径是连贯的；这不是一次纯粹的硬件或量化对比，因为运行时、量化、聊天模板和并发都不同。

在最后一段无中断的 106 例 Ascend 阶段，四个 worker 在 2 小时 52 分 46 秒内生成了 507,256 个 token：聚合 48.93 tok/s。这些长推理生成中，每个请求的客户端中位数速率是 12.50 tok/s。服务器完成了该阶段的每一个请求，没有 eager 回退，也没有零接受区间。RTX 参考在单请求上快得多，所以我不是说这能杀 NVIDIA。我是说，这是一个大型模型在最初只会输出缓慢胡言乱语的硬件上，现在正确、有用。

GLM 是我下一个更难啃的模型

我也在 bring-up 大约 304B 参数的 GLM-5.3-Flash 架构。它结合了 34 个 KDA 线性注意力层、11 个 DSA 稀疏注意力层、288 个 expert、latent MLA 历史、mHC 混合，以及混合 W2/W4 expert checkpoint。这个 checkpoint 约 151.6 GiB，在一个四 rank profile 中，每个 rank 约加载 35.6 GB 权重。

它现在能在同一台机器上加载和生成。到目前为止的速度进展：

一个 8,232 token 的 GLM prompt 以约 39.1 prompt tok/s 做 prefill，之后以约 2.16 tok/s 做 decode。这些数字离我的目标还远，而且 32 token 的测试补全太短，无法确定答案质量。GLM 目前是一个 bring-up 和优化结果，不是服务推荐。

我已经在那里发现了一个重要的量化教训。一个早期的 W2 checkpoint 显示残差增长，最后一层的 RMS 高达 525。把受影响的 expert 改成无截断 W4 处理，保持了网络有界。另外，我自定义的 blocked-dequant Cube kernel 在孤立测试中比 eager 参考快约 17 倍。正如 Qwen 教我的，数字行为和端到端集成都必须通过，才能说“完成”。

第三张卡：不只是多 50% 内存和核心

我计划给系统加第三张 Atlas 300I Duo。这让机器从四个 310P 设备变成六个，从 192 GB 变成 288 GB 铭牌设备内存。同样的 ECC 和运行时预留，我预计大约再增加 86 GiB 运行时可见容量，六个 rank 加起来约 258 GiB。

n 卡架构设计就是要利用它的。Expert 所有权分布在所有 rank 上，所以新增的两个芯片增加了本地 expert 容量和加速核心，不只是被动存储。Token 路由到拥有其 expert 的 rank，新 rank 参与模型计算和集合通信。我预期 EP6 会带来有用的规模提升，不过确切加速比会在测量后公布，不会提前吹。

额外容量给了我几个选择：

- 保留更大的 expert 集或更高精度的层常驻内存。
- 塞进刚好超过四芯片限制的模型，无需 host offload。
- 在长上下文状态和缓存上花更多内存。
- 在质量权衡不值得的地方减少激进量化。
- 运行大型分布式模型，同时保留另一个较小服务或评估负载的空间。

代价是多一张卡、150 W 最大板级功率、两个设备 rank，以及另一个需要真实气流的被动散热片。在制冷的房间里，这些都不是架构问题。真正的成本是通信：六个 rank 会改变路由平衡、集合通信规模、PCIe/HCCL 流量。我会调优和基准这个拓扑，但软件已经围绕 n 卡 expert 分布组织，而不是硬编码四路所有权。

已知问题和进行中的工作

这些还在我的工作台上：

- 我刚修了一个真正的跨流竞争：一个 prefix-Mamba 状态槽可能在其挂起的 NPU 写入完成前被换出或复用，导致恢复出较旧 checkpoint。修复带有一个 NPU 回归测试。之后一个 106 例运行经历了 12 次状态换出而没有质量下降，这令人鼓舞，但不是根因证明。我会继续做长混合负载和逐出/复用浸透。
- Qwen 冷 prefill。40K 冷 prompt 仍然需要约两分钟，即使后续 decode 很快。剖析主要指向 12 个 QSA 层，尤其是稀疏选择和分块注意力。这现在比再做一次微小的 decode 微优化更重要。
- Qwen 长上下文认证。规划器有容量，但我在区分“配置的上下文”“分配的容量”和“完成的端到端长上下文测试”。我要的是检索和并发填充证据，而不是启动参数的截图。
- GLM 连贯性和性能。在 KDA、MLA、QSA 和 runner 集成改动后，我正在重新认证全模型，然后让分组的混合 W2/W4 expert 路径、缓存布局、图回放，以及最终的 MTP，都经过与 Qwen 相同的正确性优先门。
- GLM 加载和内存。过滤加载器可以在张量物化前跳过大量 peer-owned 或已被取代的 checkpoint 有效负载。我观察到一个大约 20% 的加载时间改进，但需要受控重跑和字节记账，才能称之为结果。
- 六设备 expert 并行。第三张卡到位后，我会在精确的六 rank 拓扑上测量 rank 平衡、每卡温度、集合通信时间、模型容量，以及 c1/cN 吞吐。
- 其他模型适配器。同样的加载器、打包 expert、缓存和算子基础设施正在支持 DeepSeek 和其他混合/MoE 工作的持续进行。我尽量避免在底层契约可以泛化时，让代码里满是模型名条件判断。

你应该买一张吗？

我计划下周在 OpenSensor 商店（[https://www.opensensor.io/4）上架我的第一张追加卡，价格 $2,900。上架还没有生效。我认为对于这个硬件已经能做到的事，以及软件应该解锁的能力，这是个好价格。但它还不是那种像受支持的 NVIDIA 卡跑 mainline vLLM 一样的开箱即用采购。

我认为合适的买家是开发者、实验室或具备系统思维的用户，并且能同时接受以下两点：

1. 你要自己解决气流。这些是被动散热服务器卡。根据机箱和主板，可能意味着高静压机箱风扇、风道，或 3D 打印导流罩。我用 Fusion 360，并且很乐意帮助设计更多导流罩。主板布局、卡间间距、风扇尺寸和机箱几何结构太多了，假装一个设计能适配所有情况是不切实际的。
2. 你接纳的是一个活跃开发中的 fork。目前我是 vLLM 相关工作的唯一开发者，而上游更专注于他们尚未在美国上市的服务器级加速模块。进展是真实的，这篇帖子的基准来自实际硬件，但未来会发现更多 bug 和更好的方法。买家应该……