最近用一张 华为 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-Ascend
CANN
Qwen3.6-27B W8A8
Tensor Parallel = 2
官方图模式
官方融合算子
权重常驻显存
KV Cache常驻显存
最终稳定结果：
生成速度：约11.01 tokens/s
语义测试：5/5
双芯片运行：正常
服务接口：稳定
显存占用：每颗芯片约35～36G
这个结果已经不是“模型没配好”或者“只跑了一个未经优化的 Python 示例”。官方 W8A8、图捕获、融合算子、常驻权重和双芯片调度都已经启用。
二、第一个天花板：96G并不是一块完整显存
Atlas 300I Duo 96G 最容易让人产生误解的地方，就是这个“96G”。
它实际上不是一颗芯片连接一块统一的96G显存，而是：
310P3芯片0 + 独立显存
310P3芯片1 + 独立显存
Qwen3.6-27B W8A8 虽然总权重可以放进去，但单颗芯片放不下完整模型，因此必须使用 TP2，把模型切到两颗芯片上运行。
这意味着每一层都不只是“各算各的”，还要处理：
张量切分
局部矩阵乘
AllReduce或其他集合通信
数据同步
跨芯片结果合并
后续算子的依赖等待
因此，这张卡的96G解决了“模型装不进去”的问题，却没有解决“模型高效运行”的问题。
从大模型推理角度看，它更像两张显存较小的卡被装在了同一块板卡上，而不是一张具有96G统一显存的大卡。
三、第二个天花板：显存带宽不足
27B模型在逐token生成阶段，很多时候并不是算力优先，而是带宽优先。
每生成一个token，都需要读取大量模型权重。即使采用W8A8，27B模型的权重数据仍然非常大。
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路径已经利用了这部分能力。
但是大模型推理不只有矩阵乘，还包括：
RMSNorm
Softmax
SiLU
门控
位置编码
残差连接
量化和反量化
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常驻LUT
310P3 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生成和长上下文为核心的大语言模型并不完全匹配。