一、为什么这个模型值得自己部署一次

2026 年 8 月 21 日，商汤把 SenseNova-U1.5-8B-MoT 的权重放了出来，Apache 2.0 协议。对外宣传里大家更熟悉的名字是 U1 Pro，平台 API 那边叫 sensenova-u1.5-lite，指的都是这一系。它有意思的地方不在参数量，而在架构：这个模型没有视觉编码器，也没有 VAE，文字和像素在同一个 Transformer 复合体里端到端建模。一个权重同时干视觉理解和视觉生成两件事，文生图、图像编辑、VQA、交错图文都能做，原生支持 4K 出图。

这种做法对部署者是全新的考题。传统的多模态管线是 LLM 加 Diffusion 拼起来的，大不了拆成两个服务分别调度；U1 是一整个模型，理解分支和生成分支参数不共享，总权重 17.53B 张量，BF16 落盘 32.69 GiB。当我把它推向一张只有 32GB HBM 的卡时，问题就很直白了：权重 32.69 GiB，可用显存 29.1 GiB，宿主侧内存配额 8 GiB。显存放不下，内存也放不下。

这篇文章记录我怎么在一张昇腾 910B4 上把这道题解开：用装箱加 safetensors mmap 流式卸载的方案把整个模型跑通，完成 3 张 1024×1024、50 步的官方同款提示词基准，每张真实耗时 1271 到 1298 秒，最后封装成 FastAPI 服务。慢是慢了点，但账算得清楚，后面会一步一步算给你看。

二、先把模型搞明白

2.1 名字的问题

我按开源可验证的 SenseNova-U1.5-8B-MoT 来做，仓库、ModelScope、HF 都能下到。模型卡上写着模型尺寸 17.53B、张量类型 BF16_F32：

2.2 NEO-Unify：没有编码器拼接的统一

主流多模态模型的套路是拼接：LLM 归 LLM，Diffusion 归 Diffusion，中间用 adapter 或者投影层把视觉 token 塞进语言模型。NEO-Unify 反过来，直接把视觉编码器和 VAE 都去掉，让像素和文字在统一复合体里一起建模。NEO 是 Native Embedded Omnimodel 的缩写。

这样做的好处很实际。图像不用先压缩成低分辨率的 latent 再翻译回来，文字渲染和复杂版式的水准因此上了一个台阶，我这次 1024 的实测图也印证了这一点。任务覆盖面也宽，同一份权重能文生图、能改图、能做问答，官方还留了向 VLA 和 World Model 延伸的架构空间。

代价 equally 直白：正因为理解和生成在同一个模型里，你没法按任务拆开部署，17.53B 张量必须作为一个整体面对你的显存。

2.3 MoT 不等于 MoE

MoT 是 Mixture-of-Transformers，不是常见的 Mixture-of-Experts。区别一句话能说清：MoE 是多个专家网络轮流激活，推理时只用一部分参数，省算力；MoT 是理解和生成两条 Transformer 路径并行存在，推理时按阶段各走各的，不省显存。

U1.5-8B-MoT 名字里的 8B，其实约等于 8B 理解分支加 8B 生成分支，真实物理张量 17.53B，BF16 约 35.1GB。这个账不先算明白，你会奇怪一个 8B 模型怎么单卡都跑不动——其实是参数量被命名口径报小了一半。

两条分支在文生图时分工最清楚：理解分支的 forward_und 先把提示词编码成带语义的表征，生成分支的 forward_gen 再逐去噪步出图。一次 50 步的生成，1 次文本编码加 50 步去噪，cfg 等于 7.0 时每步要走两条前向，一共约 101 次完整前向。生成分支的 RoPE 还是 T、H、W 三轴的，时间乘高乘宽，这个细节给后面第九章的算子融合埋了伏笔。

2.4 模型家族

U1 的开源矩阵相当完整，部署前值得全过一遍：

变体	架构	说明
SenseNova-U1.5-8B-MoT	Dense + MoT	本文部署的版本
SenseNova-U1.5-8B-MoT-SFT	Dense + MoT	指令微调版
SenseNova-U1.5-8B-MoT-LoRA-8step	LoRA，814MB	去噪步数 50 降到 8，cfg 降为 1.0，约 6.7 倍提速
SenseNova-U1-8B-MoT	Dense + MoT	初代发布
SenseNova-U1-A3B-MoT	MoE + MoT	混合专家版，推理时只激活部分参数
SenseNova-U1-8B-MoT-Infographic V1/V2/V3	Dense + MoT	信息图专用，文案排版和风格迁移是强项
Infographic-LoRA-8step	LoRA	信息图场景的 8 步加速版

对部署者最有意义的是 8step LoRA：它把前向次数直接砍到六分之一，对本文这种用带宽换显存的场景是天然绝配，第八章会算这笔账。

2.5 它不擅长什么

只吹不贬的评测没有可信度。社区实测和这次验证下来，U1 的强项在文字渲染、复杂版式、信息图和交错图文生成；短板也有三条：密集公式和精确数值可能出错，比如坐标轴刻度；图像编辑是整幅重绘，不是像素级的局部修改，正文小字容易崩，大标题倒是能改准；U1 上下文上限 32K，U1.5 没有明确披露，架构相近，估计差不多。

三、约束条件：29GB 显存、8GB 内存、32.69GB 权重

3.1 为什么选昇腾

对 MoT 这种双分支加三轴 RoPE 的结构，昇腾 CANN 走的算子融合加任务级并行路线，收益比通用 GPU 更直接。第一，调度开销被压平。传统 GPU 推理里一次 Attention 被拆成几十个离散小 kernel，matmul、softmax、scale、add，每个都有 host 到 device 的启动开销；CANN 先把整段计算画成 DAG，再让编译器把可并行的子图融成一个算子，跑大图和长序列时优势明显。第二，三轴 RoPE 天然吃 SIMD 并行，H 和 W 两轴在传统 GPU 上只能串行算两遍，NPU 的 SIMD 单元可以同时分发两组 cos/sin 表，融合后只发起一次算子调用。第三，昇腾社区专门为 U1 写了端到端部署指南，fusion_optimizer.py 加 inference_optimized.py，带 CANN 融合、MindIE-SD RoPE 插件和 2.52 倍加速的基准数据，不是拿 GPU 文档改个后端那种。

3.2 我拿到的资源

实例规格，镜像 ubuntu22-cann8.5-python3.11-jupyter:v1.1.0：

NPU basic · 1 × NPU 910B4 · 4v CPU · 8GB 内存 · 50G 存储
HBM 32768 MB，可用约 29.1 GiB

把三方约束摆到一张表里，这道题就完整了：

资源	数值	结论
模型权重，BF16，1116 张量，8 分片	32.69 GiB	超过可用显存
NPU HBM	32 GB，可用 29.1 GiB	装不下全部权重
cgroup 内存上限	8 GiB	CPU offload 也装不下
磁盘	50 GB	权重加仓库勉强够

显存放不下，内存也放不下，盘上刚好够。官方 inference_optimized.py 的前提是 64GB HBM 的 A3 整卡常驻，在这个规格上照抄必死。

四、准备工作

4.1 进环境

在模型卡右上角点 Notebook 快速开发，选 NPU 规格启动，就是预装 CANN 的 JupyterLab。部署环境用的是 AtomGit 昇腾模型平台提供的实例，平台操作不展开，后面聚焦模型本身。镜像里的关键版本，实测如下：

• torch 2.9.0+cpu 加 torch_npu 2.9.0，transformers 4.57.6，modelscope 1.34.0，safetensors 0.7.0
• CANN 8.5.0，装在 /usr/local/Ascend/cann-8.5.0
• 这个镜像是精简推理镜像，没预装 vllm 和 MindIE，这直接引出 4.3 的第一个坑

4.2 先摸家底

进 JupyterLab 开 Terminal，我第一件事永远是跑环境三连：

uname -m && cat /etc/os-release | grep PRETTY && python -V
pip list | grep -E "^(torch|torch-npu|transformers|modelscope|safetensors) "
npu-smi info

实测输出节选：

aarch64                                    # Atlas 800I 服务器
Ubuntu 22.04.5 LTS
Python 3.11.14
torch 2.9.0+cpu / torch_npu 2.9.0          # torch 是 +cpu 变体，NPU 走 torch_npu
transformers 4.57.6 / modelscope 1.34.0 / safetensors 0.7.0

npu-smi 25.5.1
NPU 0  910B4  OK  87.5W  43°C   HBM 32768 MB, 0 used

两个关键确认：torch.npu.is_available 返回 True，device_count 是 1；CANN 版本 8.5.0，比官方 benchmark 用的 8.5.1 略旧，属正常偏差。

然后验证真正的资源边界。这一步很多人跳过，但它决定部署形态：

cat /sys/fs/cgroup/memory.max     # 8589934592，即 8 GiB
cat /sys/fs/cgroup/cpu.max        # 400000 100000，即 4 vCPU
free -g                           # 1509 GB，宿主机视图，会骗人

说实话，free -g 蹦出 1509GB 的时候我愣了一下，第一反应是这机器内存也太富余了。后来才反应过来这是宿主机视图，cgroup 里的 8 GiB 才是真实额度。8GB 内存加 29.1GB 可用显存，装一个 32.69GB 的模型，本文全部方案设计都由这组数字决定。

4.3 拉代码，先撞上 vllm 依赖

昇腾部署指南仓库里有推理脚本和模型结构代码，直接克隆：

cd ~ && mkdir -p work && cd work
git clone --depth 1 https://gitcode.com/ascend_model_docs/SenseNova-U1.git ascend-deploy

仓库内容：README.md 是部署指南，inference_optimized.py 是 211 行推理脚本，fusion_optimizer.py 是 422 行融合模块，model_pkg 目录放模型结构代码，另有 benchmark_results.json 官方基准。

直接 import 就炸了：

File ".../model_pkg/__init__.py", line 7, in <module>
    from .modeling_neo_unify_ar import NEOUnifyARForConditionalGeneration
File ".../model_pkg/modeling_neo_unify_ar.py", line 23, in <module>
    from vllm.distributed import get_pp_group, get_tp_group
ModuleNotFoundError: No module named 'vllm'

坑 1 就在这。modeling_neo_unify_ar.py 是自回归服务化分支，给 vLLM 部署用的，纯离线推理根本碰不到它。装 vllm-ascend 动辄几个 GB，还和当前 torch 版本强耦合，最干净的做法是给 init.py 打补丁，把这一支改成可选导入：

# model_pkg/__init__.py，补丁版
from .modeling_neo_unify import (
    NEOUnifyForConditionalGeneration,
    NEOUnifyQwen2ForCausalLM,
    NEOUnifyVisionModel,
)
try:
    from .modeling_neo_unify_ar import NEOUnifyARForConditionalGeneration
except Exception as _e:          # 离线推理不需要 AR 分支
    import warnings
    NEOUnifyARForConditionalGeneration = None
    warnings.warn(f"[model_pkg] modeling_neo_unify_ar 未加载: {_e}")

这个坑恰好印证了 2.3 的架构分析：modeling_neo_unify.py 是双分支主体，modeling_neo_unify_ar.py 是自回归服务分支，同一个模型的两条部署路径。理解了 MoT 结构，就知道砍掉 AR 分支不影响文生图。

4.4 拉权重

权重在 ModelScope，SenseNova/SenseNova-U1-8B-MoT，后台下载：

nohup python -c "
from modelscope import snapshot_download
d = snapshot_download('SenseNova/SenseNova-U1-8B-MoT', cache_dir='$HOME/weights')
print('DONE', d)" > ~/dl.log 2>&1 &

8 个 safetensors 分片并发下载，13 分钟拉完，够泡杯茶：

落盘后核对一遍，这一步别省，后面装箱要用真实字节数：

model-00001-of-00008.safetensors   4937383712
model-00002-of-00008.safetensors   4999870648
... 共 8 片
model.safetensors.index.json       total_size = 35104681984，即 32.69 GiB

五、装箱加流式卸载

官方脚本的思路是 NEOChatModel(config).to("npu:0") 之后逐分片拷权重，前提是 64GB 的 A3。在 32GB 的 910B4 上这么做会直接 OOM，而 8GB 内存又不允许经典的 CPU offload，也就是把放不下的层常驻内存。我写了 deploy_u1_offload.py，核心三步。

5.1 第一步，装箱

以 Qwen3DecoderLayer 为不可分割单元做贪心装箱，预算 26 GiB：预算内的层常驻 NPU，装不下的层走流式。实测装箱结果：

[plan] 分配单元 56 个，权重合计 32.69 GiB
[plan] NPU 常驻 25.51 GiB / 预算 26.0 GiB
[plan] 流式卸载 7.19 GiB，共 10 个单元
       - offload: language_model.model.layers.32  0.72 GiB
       - offload: language_model.model.layers.33  0.72 GiB
       ... layers.32 至 41，共 10 层

装箱单元选 Transformer 层而不是单个张量，是因为层是前向调度的天然边界：层内张量必须同时在场，层间天然串行。这样 hook 粒度最小，流式搬运次数最少。

5.2 第二步，自己写分片装载器

不用 accelerate 的 load_checkpoint_and_dispatch，它会把 CPU 侧权重留在真实设备上，照样吃内存。自己解析 model.safetensors.index.json，按分片顺序用 set_module_tensor_to_device 直接落到 NPU。注意官方权重和模型参数名有 language_model.model 前缀差异，要做双向兜底。

5.3 第三步，mmap 流式卸载

这是整个方案的灵魂。流式层的参数平时驻留 meta 设备，零内存占用；前向 pre-hook 里从 safetensors 分片直接搬上 NPU，post-hook 里释放回 meta：

class StreamOffloader:
    def _load(self, m=None, args=None):
        for parent, attr, shard, key, shape in self.entries:
            t = self.store.handle(shard).get_tensor(key)
            # 坑 5：meta 参数须整参替换，不能 p.data 赋值
            parent._parameters[attr] = torch.nn.Parameter(
                t.to(self.device, self.store.dtype), requires_grad=False)
        return None    # 坑 4：pre_hook 返回非 None 会覆盖模块输入

    def _unload(self, m=None, args=None, out=None):
        for parent, attr, shard, key, shape in self.entries:
            parent._parameters[attr] = torch.nn.Parameter(
                torch.empty(shape, dtype=self.store.dtype, device="meta"),
                requires_grad=False)
        return None

safe_open 底层走 mmap，不 read 整个分片，内核按页缓存按需加载。于是任意时刻的资源占用：CPU 内存只有解释器约 2GB 加单张量临时缓冲，权重常驻零字节；NPU 显存是常驻的 25.51 GiB 层，加正在计算的 1 个流式层 0.72 GiB，加激活。

用 PCIe 带宽和页缓存，换来了 8GB 内存加 29GB 可用显存跑 32.69GB 模型。代价不小，第八章算给你看。

六、五个坑

下面的报错全部真实出现过，修复过程原样记录。

坑 2：RoPE 的 inv_freq 是 buffer，不在 checkpoint 里

RuntimeError: Expected all tensors to be on the same device.
Expected NPU tensor, please check whether the input tensor device is correct.
  File "fusion_optimizer.py", line 314, in patched_forward_und
    cos_t_idx = cos_t_f[pos_t]

原因是 init_empty_weights 的 include_buffers 默认为 False，参数走 meta，buffer 正常初始化。但 buffer 初始化在 CPU 上，融合算子拿 NPU 索引去查 CPU 缓存，直接设备不一致。修复很简单，装载完成后把全部 92 个 buffer 显式搬上 NPU，调 move_buffers_to_device(model, "npu:0")。

这个坑的根源还是 MoT 架构：三轴 RoPE 的 inv_freq 表是 92 个 buffer，张量 checkpoint 里不存它们，理解分支和生成分支各自的缓存都要单独处理。

坑 3：cgroup OOM-kill，Exit 137

第一版我把流式层常驻内存，7.19 GiB，结果生成刚跑起来就被杀：

[1]+  Exit 137   ... deploy_u1.py ...
# 日志里没有任何 traceback

对着没有 traceback 的日志我愣了几秒，才反应过来 Exit 137 是 SIGKILL，cgroup OOM killer 干的。7.19 GiB 权重加约 2 GiB 解释器，超过 8 GiB 上限。这就是 5.3 改成 mmap 流式方案的原因。有意思的是，翻产物目录发现这一版其实完整跑完了生成，图和 benchmark.json 都写出来了，只是进程在收尾阶段被杀。

坑 4：forward_pre_hook 的返回值覆盖模块输入

AttributeError: 'Qwen3DecoderLayer' object has no attribute 'dtype'. Did you mean: 'type'?
  File "modeling_qwen3.py", line 72, in forward
    input_dtype = hidden_states.dtype

这是个 PyTorch 经典坑。nn.Module.to 返回 self，而 forward_pre_hook 一旦 return 非 None，返回值会替换模块的输入。我写的 lambda 是 lambda m, a, _d=device: m.to(_d)，一个看起来无害的搬设备操作，把 hidden_states 整个替换成了 Qwen3DecoderLayer 对象。修复：改成 (m.to(_d), None)[1] 强制返回 None。调试这种类型错乱比调试 OOM 费劲多了，报错信息几乎不指向真凶。

坑 5：meta 参数不能直接 p.data 赋值

RuntimeError: Attempted to call `variable.set_data(tensor)`,
but `variable` and `tensor` have incompatible tensor type.

meta 设备上的 Parameter 不能用 .data 接收 NPU 张量，必须整参替换，写法是 parent._parameters[attr] = nn.Parameter(npu_tensor)，就是 5.3 代码里的那行。

加上坑 1 的 vllm 依赖和坑 0 的 cgroup 认知问题，一次部署攒了六个坑，密度不算低，但每一个都指向一个具体知识点，值。

七、跑起来之后

先用 256×256、2 步的冒烟跑通管线，然后正式跑 1024×1024、50 步、cfg 7.0，用官方 benchmark 同款 3 条提示词：

[1/3] An expansive field, blanketed by the soft light of morning, cradles...
   time=1298.17s  peak_npu=26.96 GiB -> outputs/f1024/out_01.png
[2/3] A visually striking digital portrayal of a futuristic woman...
   time=1271.56s  peak_npu=26.97 GiB -> outputs/f1024/out_02.png
[3/3] An isometric design spells out the word 'DRAW'...
   time=1289.47s  peak_npu=26.97 GiB -> outputs/f1024/out_03.png

第一张图 21 分钟。前十分钟我一直在刷新显存占用，确认它没有涨破上限：全程显存峰值约 27 GiB，32GB 的卡还留了 5 GiB 余量；内存峰值约 4.4 GB，8GB 配额同样安全。10 个流式层每个前向搬运 0.72 GiB，50 步加前缀共 101 次前向，累计每层约 72 GiB 的 H2D 流量。

出图之后我做了一组客观自检：相邻像素相关系数 0.99，唯一色 30k 以上。真实结构化图像的相关系数在 0.97 到 0.99 之间，纯噪声接近 0，加上色调和提示词语义对得上，可以确认是模型的真实输出而不是异常张量。

图的质量值得说两句。第 1 张的露珠、晨雾和采收前的静置感，第 2 张的叶片包裹、体积光和 Janice Sung 风格，第 3 张的等距视角、软圆角铅笔和模块化构成主义，长提示词的语义遵循和排版结构都在。尤其第 3 张的拼字 DRAW，文字渲染是统一多模态模型最见功力的地方，1024 分辨率下没有崩字。这正是 NEO-Unify 不走 latent 翻译的直接好处。

八、为什么慢：把账算清楚

8.1 和官方基准对比

把我的实测和官方 benchmark_results.json 并排放：

条件	官方 benchmark	本文实测
硬件	Ascend 910 A3，64GB HBM	910 B4，32GB HBM
CANN	8.5.1	8.5.0
权重驻留	全部常驻 NPU	25.51 GiB 常驻加 7.19 GiB 流式
分辨率	2048×2048	1024×1024
步数 / cfg	50 / 7.0	50 / 7.0
平均耗时	39.139s	1286.40s
峰值显存	未披露	26.97 GiB / 32 GB

差 33 倍，但差距的来源不是 NPU 算力，910B4 单卡 AICore 并不弱，而是每步 7.19 GiB 的 PCIe 搬运。101 次前向乘 7.19 GiB，约 726 GiB 的 H2D 流量，按 0.6 到 0.9 GB/s 的有效速率，光搬运就吃掉绝大部分时间。我实测时看监控，NPU AICore 利用率接近 0，HBM 已用 31698/32768 MB，瓶颈完全在搬运，不在计算。这是用带宽换显存的固有代价：在 32GB 显存上跑 32.69GB 模型，要么付出这个代价，要么根本跑不起来。

8.2 三条公开路线放一起看

路线	硬件	方案	分辨率/步数	实测耗时	来源
昇腾官方	910 A3，64GB	全常驻加 CANN/MindIE 融合	2048 / 50	39.139s，相对 Eager 2.52 倍	官方 benchmark
社区 GPU	RTX 4090D，24GB 加 32GB RAM	Accelerate 分片 device_map	2048 / 50	178s	社区实战
社区 GPU	同上，加 8step LoRA	同上	2048 / 8	26.7s，6.7 倍	社区实战
本文	910 B4，32GB 加 8GB RAM	装箱加 mmap 流式卸载	1024 / 50	1286.40s	实测

三条路线本质是同一道题的三种解法：A3 用显存买速度，4090D 用系统内存买平衡，910B4 只剩磁盘带宽可卖。没有高下之分，只有约束条件不同。

8.3 往下怎么优化

投入产出从高到低排：第一，换更大显存，A3 的 64GB 可以整体常驻，直接回到官方 39 秒的量级。第二，降卸载量，内存升到 16 到 24GB 之后，流式层可以改回内存常驻，就是坑 3 里那一版的做法，搬运只剩 H2D 不再读盘，预计快 2 到 3 倍。第三，8 步 LoRA，官方的 SenseNova-U1.5-8B-MoT-LoRA-8step 只有 814MB，把 50 步降到 8 步、cfg 降到 1.0，前向次数砍到六分之一；4090D 上实测 6.7 倍提速，套到本文场景理论上能把 1286 秒压到 210 秒左右。

我把跑得慢的真实数字原样放在这里。部署这件事的价值不在刷分，而在把约束条件、方案取舍和代价说清楚。下次你在受限硬件上遇到放不进显存的问题，这一章是可以直接抄的作业。

九、CANN 融合与 MindIE-SD

这是昇腾主线相对 GPU 路线的核心差异：一整套算子级加图级的融合优化，全部针对 U1 的 MoT 结构定制，四层叠加：

优化层	技术	关键收益
CANN 融合环境	11 个环境变量驱动编译器融合	算子编译融合、任务队列、精度控制
npu_fusion_attention	QK^T 加 softmax 加 V 融合	消除 attention 离散小算子
MindIE-SD RoPE	预计算 cos/sin 加融合 rotary	消除 Cos、Sin、Mul、Neg、Cat
Prefix 路径 RoPE 融合	理解分支的文本编码也走融合 RoPE	消除 prefix 阶段小算子噪声

9.1 打开 CANN 融合环境

fusion_optimizer.py 的核心函数 enable_cann_fusion_env：

import os

def enable_cann_fusion_env():
    """11 个 CANN 融合环境变量：算子编译 + 图融合 + 任务队列 + 精度控制"""
    fusion_env = {
        "ASCEND_CANN_FUSION_ENABLE": "1",                           # 总开关
        "ACL_GRAPH_FUSION_END_FUSION_OPNAME": "npu_kv_rmsnorm_rope_cache_v2",  # 终止融合算子
        "ACL_GRAPH_FUSION_END_FUSION_OPNUM": "1000",                # 终止节点数
        "ASCEND_LAZY_GRAPH_MODE": "1",                              # 懒构图
        "ASCEND_FORMAT_FALLBACK": "0",                              # 禁止格式回落
        "ACL_GRAPH_MODE": "1",                                      # 图模式
        "ACL_GE_HOST_ENGINE": "1",                                  # 启用 GE Host
        "ACL_GRAPH_SHAPE_AUTOMATIC_INFER": "1",                     # shape 自动推导
        "TASK_QUEUE_ENABLE": "2",                                   # 任务队列
        "COMBINED_ENABLE": "1",                                     # 算子合并
        "ACL_PRECISION_MODE": "allow_fp32_to_fp16",                 # 精度回退策略
    }
    for k, v in fusion_env.items():
        os.environ[k] = v
    return fusion_env

9.2 编译 MindIE-SD RoPE 插件

这一步是把通用 PyTorch 算子换成昇腾定制的高性能算子：

git clone https://gitcode.com/Ascend/MindIE-SD.git /tmp/MindIE-SD

# 关键陷阱：ABI 对齐
# 编辑 /tmp/MindIE-SD/csrc/CMakeLists.txt
# 找到 if(NOT DEFINED ENV{USER_ABI_VERSION})
# 修改为 set(ABI 1)   # 匹配 torch 的 _GLIBCXX_USE_CXX11_ABI=1

cd /tmp/MindIE-SD/build
cmake ../csrc -DCMAKE_CXX_FLAGS="-fPIC -fno-common"
make -j$(nproc)
cp build/libPTAExtensionOPS.so /tmp/MindIE-SD/mindiesd/plugin/

编译前务必先跑 python3 -c "import torch; print(torch._C._GLIBCXX_USE_CXX11_ABI)"，确认输出是 1，对不上就在 CMake 里 set(ABI 1)，不然插件 import 会报 undefined symbol。

验证插件可用：

from mindiesd.layers import rotary_position_embedding
import torch
x = torch.randn(1, 8, 10, 64, dtype=torch.bfloat16, device='npu')
cos = torch.randn(10, 64, dtype=torch.bfloat16, device='npu')
sin = torch.randn(10, 64, dtype=torch.bfloat16, device='npu')
out = rotary_position_embedding(
    x, cos, sin,
    rotated_mode='rotated_half', head_first=True, fused=True)
print('Plugin OK, output shape:', out.shape)

9.3 注意力前向的 monkey-patch

fusion_optimizer.py 的精髓，是对 Qwen3Attention 的 forward_gen 和 forward_und 分别做 monkey-patch，正好对应 2.3 说的 MoT 双分支：前者管生成分支的去噪阶段，后者管理解分支的文本编码。把 apply_rotary_pos_emb 加 rotate_half 的 6 个小算子，换成一次 mindiesd.rotary_position_embedding 的融合调用：

def patch_attention_forward_gen():
    from model_pkg.modeling_qwen3 import Qwen3Attention
    _ropes = None

    def patched_forward_gen(self, hidden_states, indexes=None, attention_mask=None,
                            past_key_values=None, cache_position=None, **kwargs):
        # 1) QKV 投影，保持不变
        # 2) 预计算 cos/sin 缓存，一次性，之后复用
        # 3) 三轴 RoPE，T/H/W，全部用 mindiesd 融合算子
        if _HAS_MINDIESD_ROPE:
            query_states_t = _mindiesd_rope(query_states_t, cos_t_idx, sin_t_idx,
                rotated_mode="rotated_half", head_first=True, fused=True)
            # key_states_t / query_states_h 等同理
        # 4) 融合 QK^T+softmax+V
        attn_output = torch_npu.npu_fusion_attention(
            q_bsh, k_bsh, v_bsh,
            head_num=self.config.num_attention_heads,
            input_layout="BSH",
            scale=self.scaling, keep_prob=1.0, ...,
        )[0]
        return attn_output, None

    Qwen3Attention.forward_gen = patched_forward_gen
    return True

9.4 融合到底省在哪

官方 benchmark_results.json 和 README 第 4 节的数据，A3，2048×2048，50 步：

配置	平均时间	总时间	加速比
无融合，Eager	约 98.6s	约 295.9s	1.00 倍
融合优化后	39.139s	117.417s	2.52 倍

算子级的微观变化更有意思：

算子	优化前	优化后	变化
aclnnCos	352	100	减 252，RoPE 融合消除
aclnnSin	352	100	减 252
aclnnNeg	1,512	0	完全消除，rotate_half 走融合
RotaryPositionEmbedding 融合版	23,940	24,444	Prefix 路径也改用融合 kernel

aclnnNeg 从 1512 直接归零是单笔最大收益，rotate_half 一次调用消掉一千多次 Neg，典型的消灭零碎开销。aclnnCos 和 Sin 各砍 252 次，对应 pos 乘 inv_freq 再算 cos/sin 的预计算与融合替换。宏观 2.52 倍的总加速里，RoPE 融合和 attention 融合大约各贡献一半。

对 U1 来说这笔账尤其划算：三轴 RoPE 让生成分支的 rotary 调用密度天然是普通 LLM 的数倍，架构越复杂，融合收益越大。

十、包成 API 服务

单脚本推理只够自己玩，把 U1 变成可调用的服务才算部署闭环。实测通过的 FastAPI 封装，和官方 examples/serving 的思路一致：

# api_server.py
import os, sys, time, base64
sys.path.insert(0, "/home/atomgit/run")

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import torch, torch_npu
from fusion_optimizer import (enable_cann_fusion_env, patch_attention_forward_gen,
                              patch_attention_forward_und, setup_npu_device)
from inference_optimized import (create_model, load_weights_from_shards,
                                 save_image, MODEL_WEIGHT_DIR)
from transformers import AutoTokenizer

# 1) 启动期一次性完成，加载约 30 秒
enable_cann_fusion_env()
device = setup_npu_device()
patch_attention_forward_gen()
patch_attention_forward_und()
model = create_model(device)
load_weights_from_shards(model)
tokenizer = AutoTokenizer.from_pretrained(str(MODEL_WEIGHT_DIR),
                                          trust_remote_code=True, use_fast=False)
model.eval()

app = FastAPI(title="SenseNova-U1 NPU API", version="1.0")

class T2IRequest(BaseModel):
    prompt: str
    width: int = 1024
    height: int = 1024
    num_steps: int = 50
    cfg_scale: float = 7.0

@app.post("/v1/t2i")
def t2i(req: T2IRequest):
    if not req.prompt.strip():
        raise HTTPException(400, "empty prompt")
    t0 = time.time()
    with torch.inference_mode():
        img = model.t2i_generate(
            tokenizer, req.prompt,
            cfg_scale=req.cfg_scale, timestep_shift=1.0,
            enable_timestep_shift=True, cfg_norm="none",
            image_size=(req.height, req.width),
            num_steps=req.num_steps, batch_size=1)
    out = f"/home/atomgit/run/api_outputs/{int(time.time())}.png"
    os.makedirs(os.path.dirname(out), exist_ok=True)
    save_image(img, out)
    return {"image_path": out, "elapsed": round(time.time()-t0, 3)}

@app.get("/healthz")
def health():
    return {"status": "ok", "device": device,
            "torch_npu": torch_npu.__version__,
            "cann_env": os.environ.get("ASCEND_CANN_FUSION_ENABLE")}

启动方式有个小坑：必须 python -m uvicorn api_server:app --host 0.0.0.0 --port 8000。直接 python api_server.py 只执行模块顶层代码，不会起服务器，这是我当时盯着终端纳闷了一分钟才发现的。

实测验证：

curl http://localhost:8000/healthz
# {"status":"ok","device":"npu:0","torch_npu":"2.9.0","cann_env":"1"}

调 /v1/t2i 生成一张 256×256 的演示图：

十一、Docker 化

在官方镜像 quay.io/ascend/vllm-ascend:v0.18.0rc1-a3 之上，把代码、算子、依赖固化成 Dockerfile：

FROM quay.io/ascend/vllm-ascend:v0.18.0rc1-a3

# 推理代码
RUN git clone https://gitcode.com/ascend_model_docs/SenseNova-U1.git /opt/sensenova-u1-ascend

# MindIE-SD 算子，编译时调整 ABI
ARG TORCH_CXX11_ABI=1
RUN git clone https://gitcode.com/Ascend/MindIE-SD.git /opt/MindIE-SD && \
    sed -i 's|if(NOT DEFINED ENV{USER_ABI_VERSION})|set(ABI 1) # forced|' \
        /opt/MindIE-SD/csrc/CMakeLists.txt && \
    cd /opt/MindIE-SD/build && \
    cmake ../csrc -DCMAKE_CXX_FLAGS="-fPIC -fno-common" && \
    make -j$(nproc) && \
    cp build/libPTAExtensionOPS.so /opt/MindIE-SD/mindiesd/plugin/

RUN pip install modelscope fastapi uvicorn
ENV PYTHONUNBUFFERED=1

WORKDIR /opt/app
COPY api_server.py /opt/app/
EXPOSE 8000
CMD ["uvicorn", "api_server:app", "--host", "0.0.0.0", "--port", "8000"]

构建并运行，裸机部署时设备节点必须透传：

docker build -t sensenova-u1-npu:1.0 .
docker run --rm -it \
  --name sensenova-u1-npu \
  --device=/dev/davinci_manager --device=/dev/hisi_hdc --device=/dev/devmm_svm \
  --ipc=host --network host \
  -v /usr/local/Ascend/driver:/usr/local/Ascend/driver:ro \
  -v $PWD/weights:/home/atomgit/weights \
  sensenova-u1-npu:1.0

容器化有两个真实踩过的坑。一是 --ipc=host 不加会爆内存，PyTorch DataLoader 默认走 /dev/shm 共享内存，多 worker 传权重分片会触发 Bus error；单进程推理可不加，FastAPI 多 worker 必加。二是 --net=bridge 和 --network host 二选一，官方 README 给的 bridge 是给容器内部访问外部模型市场用的，要直接暴露 FastAPI 端口给宿主机，用 host 或者 -p 8000:8000。我实测 host 模式下 uvicorn 绑 0.0.0.0:8000，宿主机 curl localhost:8000/healthz 直接通。

十二、问题速查

全文的坑浓缩成一张表，遇到同类问题可以直接对号：

现象	根因	解决办法
ModuleNotFoundError: vllm	model_pkg 默认加载自回归服务分支	init.py 把 modeling_neo_unify_ar 改可选导入
Expected NPU tensor，RoPE 路径	buffer 不在 checkpoint，留在 CPU	装载后显式 move_buffers_to_device
进程无声退出，Exit 137	cgroup OOM-kill	权重不常驻内存，改 safetensors mmap 流式
DecoderLayer object has no attribute dtype	pre_hook 返回值覆盖模块输入	hook 显式 return None
variable.set_data 类型不兼容	meta 参数不能 p.data 赋值	替换父模块 _parameters[attr]
NPU out of memory	权重加激活超 32GB	装箱预算下调，本文 26 GiB，加 empty_cache
libPTAExtensionOPS.so undefined symbol	MindIE-SD 编译 ABI 不一致	CMake 里 set(ABI 1) 对齐 torch ABI
张量 shape 不匹配	权重 key 前缀差异	装载器做 language_model.model 前缀双向兜底
uvicorn 不启动	python api_server.py 不经过 ASGI 入口	python -m uvicorn api_server:app
拉权重慢	国际链路	走国内源，权重分片后台 nohup 下载

十三、写在最后

回到主角。SenseNova U1 Pro 代表的范式转变，从模态拼接到原生统一，不只是架构叙事，它会实打实地砸在每一个部署者的显存预算上：理解分支和生成分支谁也省不掉，17.53B 张量必须整体面对你的硬件。这次我在 32GB 昇腾单卡加 8GB 内存的极端约束下把题解开了，回头看有四条经验。

模型理解要走在部署前面。知道 MoT 不是 MoE，知道 buffer 不在 checkpoint 里，知道两条分支的调用时序，坑都能提前预判。资源账本要先行，cgroup 里 8GB 的真额度和 free -g 的宿主机假象，这一眼的差别决定了整个方案走向。带宽换显存是合法解，mmap 流式卸载让装不下变成跑得慢，而跑得慢有明确的优化路径。最后，真实的慢数字比虚假的快数字有价值：1286.40 秒背后是 726 GiB 的 H2D 流量、每层 0.72 GiB 乘 101 次前向的完整账目，约束、取舍、出路全部可查。

想复现的话，最少三步：在昇腾模型平台打开 SenseNova-U1.5-8B-MoT 模型卡，进 Notebook 选 NPU 规格；克隆部署指南仓库，打上 model_pkg 的 vllm 补丁，用 snapshot_download 拉权重；跑 deploy_u1_offload.py，装箱加 mmap 流式卸载的完整代码在 code/ascend-deploy/ 目录，inference_optimized.py、fusion_optimizer.py、FastAPI 服务和 Dockerfile 也都在里面。