Qwen3.8-27B 在幻x2025(AI Max+ 395/8060S/128G内存) 上的推理优化（4->10）到上限了吗？

设备：华硕幻x2025 / ROG Flow Z13 2025（型号 GZ302EA）
芯片：AMD Ryzen AI Max+ 395（Strix Halo）+ Radeon 8060S 核显 + 128G 统一内存
软件：LM Studio（llama.cpp 后端）+ Qwen3.8-27B-Q4_K_M.gguf
时间：2026-08-15

一、结论先行

从 4 tok/s 卡到 7 tok/s，是本次优化真实可落地的成果；再往上追是硬件/架构的物理天花板，已非配置问题。

⚠️ 注意：中途一度冲到 10 tok/s（新会话、短上下文时），但随对话变长回落到 7。所以 7 tok/s 是稳态天花板，10 tok/s 是理想峰值，两者都是"已上 GPU"的真实成绩，远好于最初的 4 tok/s。

二、优化时间线与速度变化

4 tok/s ──► 7.75 tok/s ──► 9.4~10.4 tok/s ──► 7 tok/s（稳态）
  ROCm     Vulkan偏好生效   注册Vulkan ICD    长上下文+降回真实天花板
 回退CPU   但设备未注册      模型真上8060S     (理想峰值10,非稳态)
  (17:44)    (18:28切换)      (19:05验证)      (19:49体检)

三、根因演化（三个阶段，逐步逼近真相）

阶段①：以为是"没开 GPU 卸载"

• 现象：4 tok/s，prefill 快、decode 慢，prefill 80–115 tok/s（快）、decode 4–8 tok/s（慢）。
• 初判：模型没走 GPU / 显存不够。
• 实情：旧状态用 ROCm 后端，跑不了 Qwen3.8-27B 的 Gated DeltaNet 混合循环层 → 回退 CPU 逐 token。
• 排除：per-model 配置已 offloadRatio=1、flashAttention=true、KV 量化已开——不是"没开 GPU"的问题。

阶段②：以为是"LM Studio 配置错了"

• 现象：切到 Vulkan 偏好后重载，仍只有 7.75 tok/s。
• 深挖：backend-preferences-v1.json 已经是 Vulkan，llm.load.llama.* 命名空间无任何后端选择键 → 后端由全局偏好决定，配置层没毛病。
• 实情：系统层面 8060S 没注册成 Vulkan 设备。

阶段③：找到真正根因——系统缺 Vulkan ICD 注册

• 铁证：

  • vulkan-1.dll（加载器）在 System32，但 amdvlk64.dll（AMD Vulkan 驱动）只在 DriverStore\FileRepository\amdvlk.inf_amd64_* 里，未注册到系统。
  • HKLM\SOFTWARE\Khronos\Vulkan\Drivers 注册表键不存在 → Vulkan 加载器找不到 8060S。
  • llama-server 占 17GB RAM，但 8060S 共享显存仅 455MB → 模型在 CPU，没上 GPU。
• 本质：LM Studio 配置写的是"用 Vulkan 后端"，但系统没有可用的 Vulkan 设备，等于选了 GPU 后端却没装 GPU 驱动 → 退回自带的 vk_swiftshader（纯 CPU）。

四、前后全面对比

五、本次实际落地的修改（可复现）

六、关键经验教训（踩坑与心得）

1. "backend=Vulkan 配置正确" ≠ "系统真有 Vulkan 设备"
   LM Studio 里选了 GPU 后端，但 AMD 核显若没注册 Vulkan ICD，会静默退回 SwiftShader（CPU）。诊断 AMD 推理慢，必须查 Vulkan ICD 注册，不能只看 UI 配置。
2. DriverStore 里有 amdvlk64.dll ≠ 系统已激活 Vulkan
   驱动文件躺在盘上，但没写注册表那一条"指路"记录，加载器就找不到设备。补回注册表项比下载 600MB 安装器更快、等价、零风险。
3. OEM 驱动安装器会清掉手写的 Vulkan ICD 值
   华硕 OEM 安装器按自身清单重整 Vulkan\Drivers 键，把外来值直接删掉（且不提供"清洁安装"勾选项，这是 OEM 包常态）。任何驱动更新后都要重跑一次 reg import 并 vulkaninfo 复验。
4. iGPU 架构下，任务管理器"GPU 利用率 1%"是假象
   对 Vulkan Compute 负载不敏感，更可靠指标是专用显存占用。8060S 吃了 ~20GB 显存就说明模型真在 GPU 上。
5. NPU 高占用与 LM Studio 无关
   截图里 NPU 67% 来自第三方进程（华硕 AIXHost、字节 Doubao、Windows Studio Effects 等），llama-server 不加载任何 NPU 模块。
6. MTP 投机解码对混合架构有收益上限
   draftMaxTokens 从 4 提到 8 对 Qwen3.8-27B 几乎无效（接受率反而略降）。不要盲目调高。

7. 诊断环境限制（重要）

   • 当前 PowerShell 工具非管理员，写 HKLM 会静默失败/虚拟化 —— 注册表修复必须经用户管理员手动导入。
   • Start-Process / Start-Job 被安全策略禁止 —— 无法后台采样 GPU 利用率，只能 Get-Counter 同步快照或读日志 print_timing。

七、为什么卡在 7 tok/s（物理天花板，非配置遗漏）

decode 7 tok/s = Gated DeltaNet 循环层 + 统一内存带宽 的硬限制：

• Gated DeltaNet 是循环层（recurrent）：必须逐 token 串行计算，无法像纯 attention 那样并行 prefill。这是 prefill 能到 24 tok/s、decode 卡 7 的根本架构原因。
• 8060S 统一内存 LPDDR5x-8000 ~256 GB/s：27B Q4 权重 ~17GB，每生成 1 token 要把全部权重从内存读一遍 → 理论上限 ≈ 15 tok/s，实测 7 已是当前 Vulkan kernel 水平（约 50–65%）。
• AMD 官方同芯片 24.5 tok/s 可能基于更新版 llama.cpp 对混合层的更优 Vulkan kernel / 更激进 MTP。

定性：从 4→7 是"修复回退 CPU"的必要成果；7 是这条芯片+这个模型的真实水平。继续追更高速度需从量化 / 模型架构 / 软件更新入手，而非再调后端或 MTP。

八、后续可优化方向（按可行性排序）

为什么卡在 7\~10 tok/s（物理天花板？- 需要 高手 评论区 给指导 ）