Eval bug: qwen4exp / deepseek-v4 abort at first decode on Vulkan (RADV, gfx1151)

快速结论：这个报错通常发生在 llama.cpp 以全量 GPU offload 加载 qwen4exp / deepseek-v4 后、首次 decode 阶段；最先排查的是容器或启动环境里是否误设了 embeddings-only 相关变量（如 LLAMA_ARG_EMBEDDINGS=true），而不是先怀疑 Vulkan 后端本身。

适用环境：llama.cpp 0.4.0（revs 18443257、96ffdc4）；Linux（NixOS 26.11.20260829.d2f6794）；Vulkan (RADV) 与 ROCm (HIP) 后端；AMD Ryzen AI Max+ 395 / Radeon 8060S（gfx1151），128 GB 统一内存；模型 qwen4exp（Qwen3.8-Flash-Next GGUF）、deepseek-v4（DeepSeek-V4-Flash GGUF）。

最快修复方案：移除或显式取消启动环境中的 LLAMA_ARG_EMBEDDINGS（例如在容器启动命令前加 env -u LLAMA_ARG_EMBEDDINGS），确认该服务以生成模式而非 embeddings-only 模式加载模型。这是 Issue 中已定位并验证的做法。

注意事项：该结论来自报告者在 gfx1151 + HIP 路径下的对照验证；显卡仍为 gfx1151。若取消该变量后仍复现，则需回到后端/分配层面继续排查。Issue 另提到，在 embeddings-only 限制下加载生成模型时，报 offset assert 不如直接给出明确错误提示，但这一改进尚未由 llama.cpp 侧确认。

问题场景

用户用 llama.cpp 0.4.0 在 AMD Strix Halo（Radeon 8060S iGPU，gfx1151，RADV）上运行 llama-server，加载 qwen4exp（Qwen3.8-Flash-Next）或 deepseek-v4（DeepSeek-V4-Flash）GGUF。使用 --n-gpu-layers 999 全量 offload 时，权重加载到 100%，随后第一次 llama_context::decode 触发断言中止；deepseek-v4 以 --n-gpu-layers 48 部分 offload 时，首次图计算丢失设备，worker 进程 SIGSEGV 退出（exit 139）。RPC 与 node-local 均复现，加不加 --no-warmup、--fit off 都一样。较老的 qwen3.8-27b 在同一 RADV 设备上可长时间运行无异常。

报错原文

/build/source/ggml/src/ggml-backend.cpp:283: GGML_ASSERT(offset + size <= ggml_nbytes(tensor) && "tensor read out of bounds") failed

terminate called after throwing an instance of 'vk::DeviceLostError'
  what():  vk::Queue::submit: ErrorDeviceLost

原因分析

根因已由报告者定位：失败的 pod 容器环境里设置了 LLAMA_ARG_EMBEDDINGS=true，使服务被限制为 embeddings-only 用途。生成式模型仍能加载，但第一次 decode 在读取输出张量时越界，从而触发 ggml/src/ggml-backend.cpp:283 的同一条断言。报告者的对照矩阵显示：无该环境变量时正常完成；单独设置该变量时首次 decode 即断言；容器内继承该变量时断言，用 env -u 去掉后恢复。此前关于 RPC 与模型产物完整性的怀疑均已排除，flash-attn 与量化 KV cache 也被证明无关。也就是说，llama.cpp 后端本身在此场景下并无已确认缺陷；断言路径中 ggml_backend_tensor_get_async 读输出张量越界，可视为在 embeddings-only 模式下加载生成模型时的一种具体表现。

环境排查

确认启动命令或容器环境是否设置了 LLAMA_ARG_EMBEDDINGS（尤其是否被 Kubernetes manifest / Helm values 意外继承）。
确认 llama.cpp 版本与 rev（Issue 涉及 0.4.0、18443257、96ffdc4）。
确认后端为 Vulkan (RADV) 还是 ROCm (HIP)，以及是否经 RPC 执行。
确认模型与量化版本：qwen4exp 使用 unsloth/Qwen3.8-Flash-Next-GGUF UD-Q4_K_XL，deepseek-v4 使用 lmstudio-community/DeepSeek-V4-Flash-0731-GGUF MXFP4。
确认显卡为 gfx1151（Radeon 8060S）及统一内存容量（128 GB UMA）。
确认 offload 参数（--n-gpu-layers）、上下文长度（如 -c 2048）以及是否启用 mmproj。

解决步骤

在服务启动环境里定位 LLAMA_ARG_EMBEDDINGS 是否被设置，常见于容器 env、Kubernetes Deployment/StatefulSet、Helm values 或镜像默认变量。
移除该变量，或在启动命令前显式取消：env -u LLAMA_ARG_EMBEDDINGS <原启动命令>，然后以原本的生成式用法重新加载模型。
如果确认是路由配置误把该服务配成 embedding 模式，修正配置源本身，避免容器重新拉起后又继承该变量。
先用与 Issue 相同的单次 8-token completion 复测，再逐步加回 --n-gpu-layers 999、mmap、flash-attn 等参数。
若去掉变量后仍然断言或 DeviceLost，再按后端维度排查（Vulkan vs HIP、是否经 RPC、是否部分 offload），并提供 llama.cpp rev、后端、模型量化与完整启动命令。

验证方法

在相同命令、相同模型、相同 gfx1151 环境下，去掉 LLAMA_ARG_EMBEDDINGS 后发送一次 completion，能正常完成解码且不再出现 tensor read out of bounds 断言或 vk::DeviceLostError，即说明问题已解决。可进一步用 env -u LLAMA_ARG_EMBEDDINGS 与带该变量两种方式做对照，若前者通过、后者复现，即可确认根因。