- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
上次发帖忘记加模板被始皇狠狠指点了，虽然是系列之三但这次还是加上模板。
月经贴又来力 
已测试的模型：
google\gemma-4-E4B-it
Intel\Qwen3.5-2B-int4-AutoRound
Intel\Qwen3.5-35B-A3B-int4-AutoRound
Jackrong\Qwen3.5-9B-Claude-4.6-Opus-Reasoning-Distilled-v2
Qwen\Qwen3-TTS-12Hz-1.7B-Base
这个月着重于解决MoE模型的运行乱码问题、Turboquant适配。
1、 具备生产能力的 Qwen-3.5-35B-A3B 模型太大，不能全丢进显存里面。必须做 CPU-XPU 混合推理，也就是专家层放在内存里，需要时再调到 XPU，这个机制其实很多推理引擎已经有对应的"cpu-offload"实现了。
2、 MoE 的性能卡点主要出现在 decode 阶段。对 MoE 实施混合推理推理设计，decode 每走一步都可能要重新选专家，所以特别容易被CPU-XPU之间的数据搬运环节拖慢，由于开发环境在平时打游戏的PC上，内存频率受限3200Mhz，所以现在运行 35B-A3B 的输出速度只有 1 tokens/s。
3、 所有的模型权重都转换成项目内部兼容 XPU 的 int4 布局，节省资源。
项目内自定义算子的设计（如何自己写算子）：
1、 gated_delta_fused_op.sycl 里通过 TORCH_LIBRARY 注册算子名字和参数形式，让项目能在Pytorch上运行。
2、 同时提供 Meta 和 XPU 两套。Meta 实现不真正计算，只负责告诉 PyTorch“输出长什么样”；XPU 实现才是真正在 Intel XPU 上跑的 kernel。
3、 Python 侧只负责“接线”，因为性能表现太垃圾。
- fused_ops.py 负责加载 .pyd 动态库、暴露 run_xxx_fused() 这类包装函数。ops.py 再把这些 fused op 接到模型真实的 forward 调用链上。
4、 构建链路依赖 oneAPI + PyTorch XPU（最终还是脱离不了Intel官方提供的技术栈，因为这一部分实现比较完整，自己弄CPP太耗时间了，一个人做不了）
- build_gated_delta_fused_op.py 会调用 dpcpp 编译出 .pyd，再动态加载到 torch.ops.anna 命名空间。
5、 所有算子都要非常严格地检查输入的维度信息、dtype、device、是否 contiguous 以及 shape 是否匹配。自定义算子一旦吃到错误输入，往往不是普通报错中断，而是直接结果错乱，包括输出乱码、思维链循环、甚至直接不输出任何内容。
6、 项目里很多输入虽然是 bf16/fp16，但中间经常要用 float32。避免模型出现乱码、异常重复、输出不稳定的清空。
7、 对 MoE 来说，路由、dispatch、scatter、专家缓存、专家搬运，常常比矩阵乘本身更影响速度。所以项目里不仅做了 GEMM 算子，还做了 router、dispatch、scatter 这些算子。
8、 测试选用的 AutoRound 量化模型导出的 int4 权重格式，不等于项目内部适合 XPU 直接算的 int4 格式。因此还有一层转换来做兼容化。
结构是：
- gated_delta_fused_op.sycl - 真正写 XPU 核心计算逻辑的地方。
- fused_ops.py - Python 到自定义算子的桥接层。
- ops.py - 模型真正调用这些算子的地方。
- build_gated_delta_fused_op.py - 负责编译和注册自定义算子。
用 NotebookLM 内的 Nanobanana 2 帮忙画的简图
1 个帖子 - 1 位参与者