Intel Arc Alchemist架构（A770A750）运行Qwen 3.5并支持多模态之二
- 内容介绍
- 文章标签
- 相关推荐
继续上周的开源推广项目的记录，本篇不涉及推广内容，基本算是技术路线描述、性能统计和一点碎碎念，因此需要获取原项目的直接移步下面帖子里的Github链接即可
项目起始：
https://linux.do/t/topic/1829505
开源地址
Intel Arc Alchemist架构（A770 / A750）运行Qwen 3.5并支持多模态 开发调优本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 继续昨天的…
周末主要做的工作就是写基于Pytorch 的 XPU 自定义算子。
只支持 XPU，限定了 query/key/value/z 同 dtype，支持 float16、bfloat16、float32。但内部把 beta、g、norm_weight 和递推状态统一提升到 float32 来算，状态张量 working_state 也统一 float32，这是为了数值稳定做出的妥协，降级的话总是遇到乱码问题。
对每个 head 的输出做 RMSNorm，再乘 norm_weight，最后乘 silu(z) 门控。
Qwen3GatedDeltaNet.forward 先做投影和 depthwise conv，得到 query/key/value/z/beta/g，再把它们一次性交给 fused op。beta = sigmoid(b)，g = -exp(A_log) * softplus(a + dt_bias)，所以 exp(g) 实际上是衰减因子；解码时如果是单 token，会把上一步缓存的 recurrent state 作为 initial_state 传进去，并把新的 final_state 存回 cache。
你可以在下面这个截图里面看到cache生效的标志。
image1040×755 43.9 KB
这个自定义算子实现的是：
Qwen3 线性注意力里 Gated DeltaNet 的 XPU 融合核，把“递推状态更新 + 当前输出计算 + RMSNorm + z-gate”压成了一个 SYCL kernel，主要价值是减少中间张量和调度开销，针对 Intel Arc 上的推理和单步解码进行的特定优化。
对于各种量化格式
现在只测试了BF16、FP8、AWQ-4bit，其它量化格式还没测试
性能表现
Qwen3___5-9B-Claude-4___6-Opus-Reasoning-Distilled-v2（BF16）
平均输出速度稳定在 12 tokens/s
首字TTFT下降到了2000ms（相比上周的16000ms快了数倍）
VRAM usage: 9.7 GB
System RAM usage: 17 GB
网友解答：--【壹】--：
看又看不懂。只能给你点个赞了。
--【贰】--：
也是物尽其用了
--【叁】--：
这卡跟你这辈子值了
--【肆】--：
佬的技术太强了，好奇这种手写算子和llamacpp vulkan后端相比起来有什么优势吗，感觉后者会不会比较通用。
--【伍】--：
你看得懂，只是你比较谦虚
--【陆】--：
直接用llamacpp + vulkan的话性能上我还没有试过呢，主要是我之前不想在Win端装llamacpp
不过这个项目主要还是明显更偏“针对 Intel Arc Alchemist架构在Qwen 3.5 的垂直优化”，针对Qwen的线性注意力和Xe核心调用，特别是XPU int4，主要面向当前 XPU 路径；
llama.cpp 官方量化档位更全，从 1.5-bit 到 8-bit，也支持 CPU+GPU hybrid inference，技术支持这块确实比不了
做这个项目一方面是想多了解下架构信息，解决旧版Xe一代运行前沿模型的适配缺失问题；
另一方面也是闲着没事干（
手写的算子可以调整的地方很多，你可以根据CPU性能、RAM频率来调整cpu offload的具体参数，由于上周是先测试的Qwen3.5-35B-A3B的MoE，所以项目里对应的文件被命名为gate control了，但实际是通用的
举个例子就是
我开发环境是12400 + A770 + 32GB DDR4 3200 RAM，占用情况在主帖里已经显示
但再低一档配置的话使用12100 + A750 + 16GB DDR4 2666 RAM，也可以微调算子参数重新编译后实现贴近我开发环境的性能，实现自定义的cpu offload占用定义，尤其是在MoE模型运行时，只处理你需要的那几层丢进GPU，而不是永远只处理0层，或者全部丢进去
（当然了，A750 + 16GB要运行35B非常吃力）
继续上周的开源推广项目的记录，本篇不涉及推广内容，基本算是技术路线描述、性能统计和一点碎碎念，因此需要获取原项目的直接移步下面帖子里的Github链接即可
项目起始：
https://linux.do/t/topic/1829505
开源地址
Intel Arc Alchemist架构（A770 / A750）运行Qwen 3.5并支持多模态 开发调优本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 继续昨天的…
周末主要做的工作就是写基于Pytorch 的 XPU 自定义算子。
只支持 XPU，限定了 query/key/value/z 同 dtype，支持 float16、bfloat16、float32。但内部把 beta、g、norm_weight 和递推状态统一提升到 float32 来算，状态张量 working_state 也统一 float32，这是为了数值稳定做出的妥协，降级的话总是遇到乱码问题。
对每个 head 的输出做 RMSNorm，再乘 norm_weight，最后乘 silu(z) 门控。
Qwen3GatedDeltaNet.forward 先做投影和 depthwise conv，得到 query/key/value/z/beta/g，再把它们一次性交给 fused op。beta = sigmoid(b)，g = -exp(A_log) * softplus(a + dt_bias)，所以 exp(g) 实际上是衰减因子；解码时如果是单 token，会把上一步缓存的 recurrent state 作为 initial_state 传进去，并把新的 final_state 存回 cache。
你可以在下面这个截图里面看到cache生效的标志。
image1040×755 43.9 KB
这个自定义算子实现的是：
Qwen3 线性注意力里 Gated DeltaNet 的 XPU 融合核，把“递推状态更新 + 当前输出计算 + RMSNorm + z-gate”压成了一个 SYCL kernel，主要价值是减少中间张量和调度开销，针对 Intel Arc 上的推理和单步解码进行的特定优化。
对于各种量化格式
现在只测试了BF16、FP8、AWQ-4bit，其它量化格式还没测试
性能表现
Qwen3___5-9B-Claude-4___6-Opus-Reasoning-Distilled-v2（BF16）
平均输出速度稳定在 12 tokens/s
首字TTFT下降到了2000ms（相比上周的16000ms快了数倍）
VRAM usage: 9.7 GB
System RAM usage: 17 GB
网友解答：--【壹】--：
看又看不懂。只能给你点个赞了。
--【贰】--：
也是物尽其用了
--【叁】--：
这卡跟你这辈子值了
--【肆】--：
佬的技术太强了，好奇这种手写算子和llamacpp vulkan后端相比起来有什么优势吗，感觉后者会不会比较通用。
--【伍】--：
你看得懂，只是你比较谦虚
--【陆】--：
直接用llamacpp + vulkan的话性能上我还没有试过呢，主要是我之前不想在Win端装llamacpp
不过这个项目主要还是明显更偏“针对 Intel Arc Alchemist架构在Qwen 3.5 的垂直优化”，针对Qwen的线性注意力和Xe核心调用，特别是XPU int4，主要面向当前 XPU 路径；
llama.cpp 官方量化档位更全，从 1.5-bit 到 8-bit，也支持 CPU+GPU hybrid inference，技术支持这块确实比不了
做这个项目一方面是想多了解下架构信息，解决旧版Xe一代运行前沿模型的适配缺失问题；
另一方面也是闲着没事干（
手写的算子可以调整的地方很多，你可以根据CPU性能、RAM频率来调整cpu offload的具体参数，由于上周是先测试的Qwen3.5-35B-A3B的MoE，所以项目里对应的文件被命名为gate control了，但实际是通用的
举个例子就是
我开发环境是12400 + A770 + 32GB DDR4 3200 RAM，占用情况在主帖里已经显示
但再低一档配置的话使用12100 + A750 + 16GB DDR4 2666 RAM，也可以微调算子参数重新编译后实现贴近我开发环境的性能，实现自定义的cpu offload占用定义，尤其是在MoE模型运行时，只处理你需要的那几层丢进GPU，而不是永远只处理0层，或者全部丢进去
（当然了，A750 + 16GB要运行35B非常吃力）