Eval 错误: qwen4exp / DeepSeek-v4 在 Vulkan (RADV, gfx1151) 上在首次解码时中止
□ 名称和版本
LLaMA.cpp 0.4.0,第18443257分机和96ffdc4分机。 我的建筑指针/配置:pkgs/LLaMA-cpp/default.nix,shikanime-labs/机器#1357是这个问题的后端动力。
□ 操作系统
Linux (NixOS 26.11.20260829.d2f6794) (中文(简体) ).
□ GGML 后端
Vulkan(RADV)——失败如下. ROCm(HIP/rocblas),相同的rev,相同的GPU——qwen4exp通行证(型号载重和解码:8-token完成,~19 tok/s,没有声称,没有设备损失). ROCM上的DeepSeek-v4:未测试.
□ 硬件
AMD Ryzen AI Max + 395 / Radeon 8060S (gfx1151),128 GB 统一 LPDDR5X (UMA)(Minisforum MS-S1 MAX)
□ 型号
- qwen4exp:
unsloth/Qwen3.8-Flash-Next-GGUF',修订版:UD-Q4-K XL' - DeepSeek-v4:
lmstudio-community/DeepSeek-V4-Flash-0731-GGUF',修订版MXFP4'
□ 问题描述和复制步骤
在AMD Strix Halo上(Radeon 8060S iGPU,gfx1151,RADV),任意解码出qwen4exp(Qune3.8-Flash-Next)或DeepSeek-v4(DeepSeek-V4-Flash)都失败. Qwen4exp的同一种构造和GGUF在ROCm后端(DeepSeek-v4尚未在ROCm上重试)的同一种GPU上运行干净.
Vulkan/ RADV 失败模式 :
- 完全卸载( "-n-gpu-layers 999 " ,两个拱门):重量负载为100%,然后是第一个 " lama-context::decode " 中止:
/build/source/ggml/src/ggml-后端.cpp:283: GGML ASSERT(offset + 大小 + + ggml nbytes( tensor) * +"读出界限")失败.
- 部分卸载(DeepSeek-v4,`-n-gpu-layers 48'):该主张被绕过,权重负载,第一个图形计算器丢失:
扔出 “ vk: deviceLostError” 实例后终止调用
什么( ): vk: 队列: 提交: 错误Device Lost
工人过程与SIGSEGV(139出局)一起死亡. 回溯跟踪:"vk queue handle 未同步:submit"-"ggml backend graph compute"-"rpc server::graph compute".
反向追踪所主张的路径(router child, palital frame):"ggml abort"-"ggml-backend tensor get async"(ggml-backend.cpp:283)-"allama-context:::decode"-"llama-decode"-"common init from params"-"'server context imp:load model".
复制内容相同:超过RPC(由工人持有的Vulkan设备)和节点-局部;有和没有-不温暖';有和没有-fit off';在两个回转(以上)上,更新的回转在测试时等于主人。
老-arch模型(qwen3.8-27b)连续运行在同一RADV设备上,没有出事,因此缺陷是这些新-arch图所特有的.
Kubernetes标注:shikanime-labs/manifests/apps/LLaMA-cpp和shikanime-labs/manifests/apps/apps/ZZLLaMA-cpp
复制步骤:
LLaMA-server -hf unsloth/Quen3.8-Flash-Next-GGUF:UD-Q4 K XL-n-gpu-layers 999-c 2048
# 发送任何单个完成; ggml-后端. cpp: 283
. . . . . . .
内容来源: ggml-org/llama.cpp