华为 Atlas 300I Duo 是一张被用于本地大模型推理的昇腾加速卡。知识库中有一份较为完整的实测记录：作者用两张这样的卡搭了一台非典型推理机，跑通了 Qwen3.8 Flash-Next，并记录了从输出语无伦次、每秒约 1 个 token 到单请求稳定约 30 tok/s 的全过程[1]。这份记录既讲了硬件特性，也讲了软件栈上踩过的坑。
先看硬件结构，这是理解这张卡的关键。一张 Atlas 300I Duo 实际上是两个设备：卡上有两个加速器 SoC，合计 96 GB LPDDR4X 内存，每个芯片本地 48 GB，并不是一个统一的 96 GB 池[1]。因此两块卡在系统里枚举为四个 Ascend 310P3 设备，把机器看成四个 48 GB rank 比看成两块 96 GB GPU 更有用[1]。一个放不进单个 48 GB 设备的模型仍然需要张量、专家或流水线并行。卡本身是 PCIe Gen4 x16、全高全长、单槽薄型设计，华为标称聚合内存带宽 408 GB/s，最大板级功率 150 W[1]。记录中特别提醒，这些卡上的内存是 LPDDR4X，尽管很多加速器软件习惯用泛泛的 HBM 术语[1]。
散热是这类卡最容易被低估的部分。Atlas 300I Duo 有大面积散热片但没有板载风扇，是为服务器风道设计的被动散热卡，放进普通工作站指望机箱后置风扇解决一切是个糟糕方案[1]。作者的做法是提供直接、大流量的气流，并用空调给房间制冷；在多小时满载模型负载下，峰值设备温度一般在 72 到 78 摄氏度，看门狗上限设为 96 摄氏度，从未接近过[1]。他的经验是保持散热片鳍片气流畅通、机箱风扇有足够静压、每张卡额外预留 150 W 板级功率并把热量排出房间，同时在长时间 prefill、decode 和并发测试期间记录温度，而不是相信空闲读数[1]。
内存容量方面有一个容易被忽略的折损。作者默认开启了 ECC，后来关闭以回收设备内存，这是一个明确的容量优先于 ECC 保护的可靠性权衡，并非普适建议[1]。即使关闭 ECC，固件、运行时、通信缓冲区、图捕获、workspace 和分配器预留仍会占用内存，软件实际看到的每个 48 GB 芯片大约只有 43 GiB，四个芯片合计约 172 GiB，而且仍然是四个独立的本地池[1]。这直接影响了模型决策：问题不只是 checkpoint 总量能否放进 192 GB，而是每个 rank 的权重分片、循环状态、KV 缓存、图捕获、集合通信 workspace 和最坏情况临时分配能否各自放进自己的 43 GiB[1]。
软件栈是这项工作真正的重心。作者同时 fork 了 vLLM 和 vLLM Ascend，公开工作在 OpenSensor 的两个仓库上，因为缺的不只是一个设备 kernel，还涉及 Ubuntu 驱动支持、模型架构支持、内存布局、自定义算子以及异步状态转换的正确性[1]。目前他是这两个 fork 的唯一开发者，软件 bus factor 为 1，他也明确提醒，一个快速推进的单人 fork 不应被误认为 mainline vLLM 在 NVIDIA 上的成熟度、测试覆盖或支持深度[1]。值得一提的是，他提到在自己的会话里 Claude 一再拒绝处理关于这个架构的提示，因为这些卡是来自中国的华为硬件，这让他把 Claude 作为该项目开发助手变得不可靠[1]。
性能数字分几个阶段。最早不受控的服务只有约 0.2 到 1.9 tok/s 且经常不连贯；正确的 eager W4 反量化参考实现为 0.229 tok/s；稳定的 W8 服务基线约 18 到 19 tok/s；原生 W4A8 加 MTP2 加图捕获后，单请求中位数 29.74 tok/s、峰值 34.34 tok/s，四个请求聚合中位数 60.88 tok/s[1]。两个并发的 40K 热前缀请求聚合 30.76 tok/s，而 40K 冷 prompt 的首令牌延迟约 120 秒，之后解码为 30 到 32 tok/s[1]。作者强调 30/61 tok/s 是短、固定输出的 decode 测试，长推理请求讲述的是不那么好看但更有用的故事[1]。
质量方面有可对照的验证。作者在四芯片 Ascend W4 服务上跑完全部 198 道 GPQA Diamond 题，同时用 RTX 6000 Pro 在 llama.cpp 里跑一个不同的 IQ4_XS GGUF 作为参考，两者都得了 140/198，即 70.71%，使用同一个 AISBench 风格的答案提取器[1]。他说明这表明 Ascend 路径是连贯的，但不是纯粹的硬件或量化对比，因为运行时、量化、聊天模板和并发都不同[1]。在最后一段无中断的 106 例 Ascend 阶段，四个 worker 在 2 小时 52 分 46 秒内生成了 507,256 个 token，聚合 48.93 tok/s，每个请求的客户端中位数速率是 12.50 tok/s，服务器完成了该阶段每一个请求，没有 eager 回退，也没有零接受区间[1]。
推动性能提升的不是某个神奇的 kernel 补丁，而是一系列架构性改动。先是让混合模型正确再让它变快，其中一个 Gated DeltaNet 问题在小头测试中看起来正常，却在真正的 36 个循环层中累积状态误差导致生成语无伦次，把循环状态保持为 FP32 并修复生产形状的数据搬移是基础[1]。然后是构建感知 expert 的加载器，只读取每个 rank 拥有的 expert，把约 169 GiB、1610 个 safetensor 文件的 checkpoint 加载从一次意外的内存压力测试变成确定性的 TP4/EP4 布局[1]。在计算路径上，保持低比特权重打包，用自定义 AscendC Cube 算子做分组 expert 投影，并加入 FRACTAL_NZ 布局、融合 gate/up 处理、分块归约和专门的 W4A8 执行，而不是把 W4 权重反复展开成更大的临时表示[1]。此外还有针对 36 个循环 GDN 层和 12 个稀疏 QSA 层的独立状态管理与紧凑缓存布局，以及去掉热路径中的 .item() 调用、加入 decode-only ACL 图和 MTP2 推测解码[1]。
这张卡也在被用于更难啃的模型。作者在 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 配置下每个 rank 约加载 35.6 GB 权重[1]。它现在已经能在同一台机器上加载和生成，但速度从初始完整服务 profile 的 0.764 tok/s 单请求、1.474 tok/s 四请求聚合，到最新测量的集成 runner 的 2.236 tok/s 单请求、4.476 tok/s 聚合，离目标还远，作者明确说 GLM 目前是 bring-up 和优化结果，不是服务推荐[1]。
扩展性方面，作者计划加入第三张 Atlas 300I Duo，把机器从四个 310P 设备变成六个，铭牌内存从 192 GB 变成 288 GB，预计运行时可见容量约 258 GiB[1]。因为 expert 所有权分布在所有 rank 上，新增的两个芯片增加的是本地 expert 容量和加速核心，而不只是被动存储，token 会路由到拥有其 expert 的 rank 并参与模型计算和集合通信[1]。代价是多一张卡、150 W 板级功率、两个设备 rank 和另一个需要真实气流的被动散热片，真正的成本是通信，因为六个 rank 会改变路由平衡、集合通信规模和 PCIe/HCCL 流量[1]。
关于是否值得买，作者给出了明确的定位。他计划以 2900 美元在 OpenSensor 商店上架第一张追加卡，认为对于这个硬件已经能做到的事和软件应该解锁的能力来说这是个好价格，但它还不是那种像受支持的 NVIDIA 卡跑 mainline vLLM 一样的开箱即用采购[1]。合适的买家是开发者、实验室或具备系统思维的用户，并且要同时接受两点：一是自己解决气流问题，二是接纳一个活跃开发中的 fork[1]。