Eval bug: Repeats the same token or generates garbage on any models.

快速结论：该问题通常出现在 Windows 上通过 Vulkan 后端（尤其是 AMD RDNA4 显卡）运行 llama.cpp 新构建版本时，模型会重复输出同一 token 或生成乱码。优先排查 AMD 显卡驱动版本，以及 Vulkan 后端对 RDNA4 架构的识别是否正确。

适用环境：Windows；Vulkan 后端；GPU 为 Radeon AI PRO R9700、Radeon RX 6700 XT（Vulkan0）、Radeon RX 9070 XT（Vulkan1）；构建版本 0.5.0-dev（涉及 b11160 / commit 70c4e1582、b11175 / commit 4de092659、b11193 等）；使用 Clang 20.1.8 编译的 Windows x86_64 版本。原 Issue 未提供 Python、CUDA、PyTorch 版本信息。

最快修复方案：更新 AMD 显卡驱动到 26.10.44，原 Issue 报告者确认由此解决。

注意事项：报告中提到旧 AMD Windows 驱动未在 RDNA4 上暴露 shader_float8，导致设备架构被误判为 AMD_RDNA3，进而向 70c4e1582 引入的 int8 量化 coopmat matmul 路径传入错误常量。手动修改 ggml-vulkan.cpp 的方案仅由报告者在 9070 XT 上验证过，用于 R9700 时其命名匹配是否准确尚未确认；如无编译或维护自定义构建的需要，应优先尝试更新官方驱动。

问题场景

用户在 Windows 上使用 llama.cpp 的 Vulkan 后端运行 llama-cli 或 llama-server，加载 GGUF 模型并设置 -ngl all 与 -dev Vulkan0 后触发问题。示例模型包括 Cyber-Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf、Ling-3.0-tiny-Q4_1.gguf、nex-agi_Nex-N2.5-mini-Q4_K_L.gguf、Sharp-Spark-X2.5-4B-Q6_K_XL.gguf，以及 unsloth/Qwen3.8-27B-GGUF:UD-Q6_K、unsloth/gemma-4-26B-A4B-it-qat-GGUF:Q4_K_XL。用户报告在任意模型上都会出现重复同一 token 或输出乱码，而 0.5.0 release 版本正常。

报错原文

Eval bug: Repeats the same token or generates garbage on any models.

build      : b11160-70c4e1582
model      : Cyber-Tiel-Coder-35B-A3B-UD-Q4_K_XL.gguf
ftype      : Q4_K - Medium

> write a sample code in python

[Start thinking]

<think>
[End thinking]

# 00000000000000000000000000000000

# 00000000000000000000000000000000

## 00000000000000000000000000000000

# 00000000000000000000000000000000

```
00000000000000000000000000000000
```

原因分析

根据 Issue 中的讨论，可能原因集中在 Vulkan 后端对 AMD GPU 架构的识别上。旧版 AMD Windows 驱动在 RDNA4 显卡上未暴露 shader_float8，导致 get_device_architecture 将设备降级判定为 AMD_RDNA3。这个误判会把错误常量送入 commit 70c4e1582 引入的 int8 量化 coopmat matmul 路径，从而产生损坏的输出。该结论来自评论中的分析，并非上游确认的官方根因；同时报告者指出更新驱动即可解决，说明驱动暴露能力与该路径之间存在关联。

环境排查

确认当前 llama.cpp 构建版本，重点检查是否处于 b11160（70c4e1582）之后、问题仍存在的版本区间，如 b11175（4de092659）乃至 b11193。
确认 Windows 版本，Issue 报告为 Windows 11。
确认 AMD 显卡型号与驱动版本；报告涉及 Radeon AI PRO R9700、Radeon RX 6700 XT、Radeon RX 9070 XT，且旧驱动存在 shader_float8 未暴露的情况。
确认后端为 Vulkan，并记录 -dev Vulkan0 或 --device Vulkan1 等设备选择参数。
确认所用模型及量化格式，便于区分是否为特定量化路径触发。
原 Issue 未提供 Python、CUDA、PyTorch 版本，无需据此排查。

解决步骤

先对比已知正常版本与异常版本。评论中 b11149（d2e54583c）输出正常，b11175（4de092659）及之后版本输出异常，可借此确认问题是否由该提交区间引入。
优先更新 AMD 显卡驱动到 26.10.44。报告者确认该操作解决了问题，这是 Issue 中已验证的首选处理方式。
更新驱动后重新运行原本失败的 llama-cli 或 llama-server 命令，观察输出是否恢复连贯。
如果仍无法更新驱动或问题依旧，可优先尝试评论中给出的手动补丁思路：在 ggml/src/ggml-vulkan/ggml-vulkan.cpp 的架构判断逻辑中，除了检查 shader_float8，还根据设备名称匹配 RDNA4。
应用手动补丁后需重新编译 llama.cpp，再运行同样的模型与参数进行验证。
该手动补丁仅在 9070 XT 上测试过，R9700 的设备名称匹配是否准确需要自行确认；若不打算维护自定义构建，不应将手动补丁作为常规修复手段。

验证方法

使用与报错时相同的模型、后端和设备参数重新生成内容，确认不再出现重复的 00000000000000000000000000000000 一类无意义输出，模型能够按提示正常生成连贯文本。也可在更新驱动后检查日志中设备架构识别结果是否与显卡实际架构一致；若仍被识别为较低架构，说明驱动暴露能力或匹配逻辑仍未生效。