[BUG]: Inference with Qwen3:4b and Qwen3:8b is slower than with gemma4:e4b

快速结论：在 Windows 11 ARM 的 Snapdragon X Elite 设备上，通过 AnythingLLM 的 NPU（GenieX）通道运行 Qwen3:4b / Qwen3:8b 时推理异常缓慢、NPU 利用率上不去，通常不是模型文件损坏，而是推理引擎对特定模型算子与 NPU/CPU 调度支持不足导致。优先排查：是否走 NPU 通道、机型是否为 X Elite、以及换用已在同机型跑满 NPU 的 gemma 模型做对比。

适用环境：AnythingLLM 本地开发版 1.16.1；Windows 11 ARM；Qualcomm Snapdragon X Elite X1E80100（12 核）；NPU + Chat 模式（无 agent、无 query）；涉及模型 Qwen3:4b、Qwen3:8b、Qwen2.5:7b、gemma4:e4b。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者确认这属于底层 engine（GenieX）范围，需在该引擎侧优化 X Elite 的算子与 NPU/CPU 分配；用户侧可优先尝试更换已在同机型跑满 NPU 的模型（如 gemma4:e4b）作为临时规避。

注意事项：该问题未被验证为 AnythingLLM 应用层 bug，修复依赖引擎厂商；模型中显示的 token/s 与 NPU 占用受机型、引擎版本、模型算子支持共同影响，不代表模型本身质量差异。评论区提到的 guff 模式报错属另一现象，不能与 NPU 慢速问题混为一谈。

问题场景

用户在 Windows 11 ARM 设备上用 AnythingLLM 1.16.1 的本地开发版，通过 Qualcomm NPU（GenieX provider）以纯 Chat 模式（不启用 agent、不启用 query）调用 Qwen3 系列模型。运行 Qwen3:4b 与 Qwen3:8b 时，NPU 利用率始终低于 10%，推理速度不到 1 token/s；而同一环境下换成 gemma4:e4b，NPU 利用率可达 100%，速度约 12 token/s，形成明显反差。补充测试中 Qwen2.5:7b 同样 NPU 利用率偏低，但 token/s 略好于 Qwen3。

报错原文

[BUG]: Inference with Qwen3:4b and Qwen3:8b is slower than with gemma4:e4b

Running `Qwen3` models, the NPU doesn't reach the 10% of usage, with a performance of less than 1 token per second.

Could not respond to message.
Connection error.

Could not respond to message.
500 "SDKError(Model loading failed)"

原因分析

根据 Issue 讨论，维护者明确指出这属于底层 engine 相关问题（AnythingLLM 在 Snapdragon 设备上与引擎方协作，引擎即 GenieX），并非 AnythingLLM 应用逻辑本身。可能原因包括：

GenieX 对 Qwen3 系列所用算子缺少针对性优化，导致大量计算回落到 CPU 执行，NPU 参与度低。
在 X Elite 平台上，GenieX 的 NPU/CPU 共享计算分配偏保守，实际更多跑在 CPU 上，且该分配策略与具体模型强相关。
不同模型在该引擎下的算子支持程度不同，gemma4:e4b 恰好命中了已优化的路径，因此能跑满 NPU。

维护者同时提到，X2 Elite 上表现明显更好，说明引擎对 X Elite 的优化投入不足是当前瓶颈之一。以上均为引擎侧推测性归因，不以本地配置错误为主要怀疑方向。

环境排查

确认运行方式：AnythingLLM 是否为 Local development / 1.16.1。
确认操作系统：Windows 11 ARM。
确认硬件：Snapdragon X Elite X1E80100（12 核），或同类 ARM NPU 平台。
确认 LLM Provider：是否使用 AnythingLLM NPU（GenieX）通道，而非 CPU/guff 路径。
确认模型：Qwen3:4b、Qwen3:8b、Qwen2.5:7b、gemma4:e4b 分别的 NPU 占用与 token/s。
确认模式：是否处于 Chat（无 agent、无 query），排除 RAG/agent 负载干扰。
确认引擎来源：是否已关注 GenieX 侧对应 Issue（维护者提示 AnythingLLM 相关问题提交到引擎仓库会被优先处理）。

解决步骤

在同一 NPU（GenieX）通道下分别跑 Qwen3:4b、Qwen3:8b、Qwen2.5:7b 与 gemma4:e4b，记录 NPU 利用率与 token/s，确认慢速只出现在 Qwen 系列而非全通道故障。
检查任务管理器中 NPU 占用是否确实偏低（低于 10%），同时观察 CPU 占用，判断计算是否回落 CPU。
临时规避：在等待引擎修复期间，优先选用在同机型已验证能跑满 NPU 的模型（如 gemma4:e4b）承担对话任务。
将机型、引擎版本、模型名与复现数据整理后，提交到引擎（GenieX）对应仓库，并注明用于 AnythingLLM，按维护者说明此类 Issue 在该仓库会被优先处理。
若曾卸载 NPU 版本模型并切到 guff 模式后出现 “Connection error.” 或 500 “SDKError(Model loading failed)”，请单独作为模型加载/SDK 报错排查，不要与本次 NPU 慢速问题混在一起处理。

验证方法

用同一提示词、同一模式（Chat，无 agent/query）对比 Qwen3 与 gemma4:e4b：如果 Qwen3 的 NPU 占用仍低于 10%、token/s 低于 1，而 gemma4:e4b 能接近 100% NPU 且 token/s 达两位数，即可确认问题归属于引擎对 Qwen 模型的算子/调度支持，而非本地配置。引擎侧更新后，若 Qwen3 的 NPU 利用率与 token/s 明显上升，则说明修复生效。