实测总结：Qwen3.6-27B 在 Atlas 300I Duo 96G 上能跑，但基本谈不上实用

最近用一张 华为 Atlas 300I Duo 96G 对 Qwen3.6-27B 做了一轮比较完整的部署和优化测试。先说结论Qwen3.6-27B W8A8 可以在这张卡上启动并完成推理但以单卡本地部署的标准看基本可以认为不具备实用价值。这里的“不能用”不是指模型完全跑不起来而是指经过官方推理框架、图模式、W8A8、双芯片张量并行和一系列针对性优化后速度仍然只有大约 11 tokens/s。如果考虑首字延迟、长上下文、并发请求和实际对话体验距离一套有吸引力的 27B 本地推理方案还有明显差距。一、测试环境测试硬件华为 Atlas 300I Duo 96G内部芯片2 × Ascend 310P3总显存96G实际为两块相互独立的设备内存单芯片可用显存约43G双芯片总显存带宽约408 GB/s软件路线vLLM-AscendCANNQwen3.6-27B W8A8Tensor Parallel 2官方图模式官方融合算子权重常驻显存KV Cache常驻显存最终稳定结果生成速度约11.01 tokens/s语义测试5/5双芯片运行正常服务接口稳定显存占用每颗芯片约3536G这个结果已经不是“模型没配好”或者“只跑了一个未经优化的 Python 示例”。官方 W8A8、图捕获、融合算子、常驻权重和双芯片调度都已经启用。二、第一个天花板96G并不是一块完整显存Atlas 300I Duo 96G 最容易让人产生误解的地方就是这个“96G”。它实际上不是一颗芯片连接一块统一的96G显存而是310P3芯片0 独立显存310P3芯片1 独立显存Qwen3.6-27B W8A8 虽然总权重可以放进去但单颗芯片放不下完整模型因此必须使用 TP2把模型切到两颗芯片上运行。这意味着每一层都不只是“各算各的”还要处理张量切分局部矩阵乘AllReduce或其他集合通信数据同步跨芯片结果合并后续算子的依赖等待因此这张卡的96G解决了“模型装不进去”的问题却没有解决“模型高效运行”的问题。从大模型推理角度看它更像两张显存较小的卡被装在了同一块板卡上而不是一张具有96G统一显存的大卡。三、第二个天花板显存带宽不足27B模型在逐token生成阶段很多时候并不是算力优先而是带宽优先。每生成一个token都需要读取大量模型权重。即使采用W8A827B模型的权重数据仍然非常大。Atlas 300I Duo双芯片合计显存带宽约408 GB/s而且这个数字不能简单理解为所有权重读取都能持续获得408 GB/s权重分散在两颗芯片上每颗芯片只能访问自己的显存不同算子无法始终达到理论带宽TP2通信也会消耗时间小批量decode很难把所有计算单元喂满非线性算子和调度间隙会降低整体利用率所以即使INT8理论算力看起来不差逐token生成仍然很容易被权重读取速度限制。换句话说INT8算力可以很高但权重没有足够快地送到计算单元理论TOPS就很难转化成实际tokens/s。四、第三个天花板310P3的INT8优势主要集中在矩阵乘310P3确实是一颗面向INT8推理的芯片。它的Cube单元原生擅长INT8 activation × INT8 weight → INT32 accumulator官方W8A8路径已经利用了这部分能力。但是大模型推理不只有矩阵乘还包括RMSNormSoftmaxSiLU门控位置编码残差连接量化和反量化KV Cache读写GDN或其他递归状态更新张量并行通信kernel启动和图调度这些环节不一定都能直接运行在高吞吐的INT8 Cube单元上。很多操作仍然需要Vector单元、FP16、INT32、查表或者不同类型之间的转换。因此不能根据INT8 TOPS简单推算大模型的token生成速度。五、第四个天花板官方W8A8已经吃掉了大部分容易获得的红利测试前的一个设想是既然310P3原生支持INT8那么通过更加彻底的整数化和DCA离散计算或许可以明显超过官方路径。实际做下来发现官方W8A8已经完成了最重要的一步主要线性层使用INT8 Cube矩阵乘继续优化的空间主要集中在减少反量化和重新量化融合非线性算子减少kernel启动减少显存中间结果缩小双芯片通信量将部分FP16非线性计算替换成定点和LUT直接连接INT32累加器与后续整数算子这些方向在理论上成立但它们属于较细的算子级优化不太可能突破显存带宽和双芯片通信构成的整体天花板。六、第五个天花板离开官方图模式性能会断崖式下降测试中一个非常明显的现象是只要破坏官方图捕获和融合路径性能就会大幅下降甚至接近一个数量级。官方性能依赖的不只是某一个kernel还包括一整套运行时条件图捕获算子融合权重常驻固定内存布局已优化的Cube tiling减少Python调度减少Host与Device同步设备端任务编排已适配的TP2通信路径如果为了整数化重新写一套算子但没有同时保留这些运行时能力那么即使单个整数操作更简单整体推理反而会更慢。这也是本次测试中最重要的工程结论之一在昇腾平台上做算术优化必须从官方图和融合算子内部修改不能在图外重新拼装一套推理流程。七、第六个天花板自定义算子的开发成本很高这次还尝试实现了一个DCA化的GDN算子包括Q16定点表示Softplus查表Sigmoid查表Exp查表INT32索引整数线性插值ties-to-even舍入INT32拆分乘法行级批处理UB常驻LUT310P3 Ascend C编译ACLNN注册和调用图模式兼容性实验自定义kernel最终已经能够完成编译安装ACLNN注册tiling选择设备端发射输出显存写入但完整的Gather和向量LUT链在310P3上仍然出现数值异常不能接入生产模型。我们最终没有用错误的计算结果换取表面上的性能数字。生产服务恢复到了官方W8A8和FP16路径语义测试仍然保持5/5。这说明310P3不是不能开发自定义算子但要达到生产级正确性和性能调试成本远高于普通CUDA平台。八、为什么11 tokens/s仍然被认为“不实用”单看11 tokens/s好像还不至于完全不能使用。但实际部署不能只看理想条件下的短文本decode首字延迟并不低长提示词需要prefill上下文越长KV Cache访问越重只有单请求时才能接近理想结果并发后两颗芯片的带宽和通信压力会增加27B模型的优势往往体现在复杂和长上下文任务上300I Duo的软件环境和部署复杂度明显高于普通消费级GPU如果只是为了得到约11 tokens/s所付出的安装、驱动、CANN、容器、算子兼容和双芯片调试成本太高。所以更准确的结论是它可以作为技术验证、已有设备再利用或昇腾开发实验平台但不适合作为Qwen3.6-27B的高性价比本地部署方案。九、能不能通过进一步优化达到20 tokens/s理论上仍然存在一些优化空间更彻底的图内融合GDN定点化减少quant/dequant预计算固定系数优化双芯片通信边界缩减中间张量调整batch与调度参数编写更成熟的310P3自定义kernel但根据本轮实测我不认为这些工作可以轻松把性能翻倍。原因是现阶段已经不是某一个明显的低效Python循环也不是漏开了图模式而是同时接近了几个物理和架构天花板显存带宽天花板双芯片通信天花板decode低并行度天花板310P3算子能力天花板CANN运行时和算子生态天花板可以继续提高几个百分点甚至在特定输入上得到更好的数字但要稳定达到20 tokens/s并保持语言质量和长上下文能力难度很大。十、最终结论经过这次测试关于 Atlas 300I Duo 96G 运行 Qwen3.6-27B可以给出一个相对明确的结论容量上能装下。通过W8A8和TP2能够稳定运行。官方图模式下实测约11.01 tokens/s。语言输出可以保持正常。96G是双芯片分离显存不是统一显存。双芯片通信和显存带宽构成主要天花板。INT8高TOPS不能直接转化为大模型decode速度。官方W8A8已经利用了主要的INT8 Cube能力。破坏官方图和融合路径会导致严重性能回退。继续做深度定制的成本明显高于可能获得的收益。因此本次测试到此结束。如果手里本来就有一张闲置的300I Duo可以拿来运行小模型、做批量推理、视觉任务或者学习CANN和Ascend C。硬要运行27B模型也不是完全不行。但如果准备专门购买或租用这张卡部署Qwen3.6-27B我的建议是不要只看96G显存和INT8 TOPS。它确实能跑但整体体验、开发成本和性能上限都不理想。对于27B模型应该优先选择统一大显存、带宽更高、软件生态更成熟的硬件。这不是说300I Duo完全没有价值而是它的设计年代、硬件结构和目标工作负载与今天以逐token生成和长上下文为核心的大语言模型并不完全匹配。