ik_llama.cpp 在 ARM CPU 上输出乱码的排查实录：从 `-DGGML_SVE=ON` 到 `GGML_ARCH

ik_llama.cpp 在 ARM CPU 上输出乱码的排查实录：从`-DGGML_SVE=ON`到`GGML_ARCH_FLAGS`的 CPU 特性配置指南

【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp

本文基于 ik_llama.cpp 仓库中收录的真实 issue 记录（github-data/issues/539 - Bug_ garbage output.md）整理而成，并结合仓库源码与构建文档进行原理级展开。文章面向在 aarch64/ARM 服务器（如 Azure Cobalt、Graviton、Neoverse 系列）上部署 ik_llama.cpp 的用户，完整复现了"模型加载正常但生成输出为乱码"这一典型故障的诊断过程、根因分析和最终解决方案，读完后你将掌握 ARM 平台下 ik_llama.cpp 的编译特性检测机制、GGML_SVE/GGML_ARCH_FLAGS等构建选项的实际作用，以及-rtr（运行期重打包）在混合负载下的使用边界。

问题现象：多个模型在 ARM 服务器上生成乱码

2025 年 6 月，用户jagusztinl在一台 aarch64 Linux 服务器（Azure Cobalt ARM CPU，64 物理核、512GB 内存）上从源码编译了 ik_llama.cpp（build 3751, commit 8b3002bb，GCC 14.2.0），随后尝试运行多个模型，结果无一例外输出无意义内容。

最典型的复现命令与输出如下（原文照录）：

../ik_llama.cpp/build/bin/llama-cli -m gemma-3-27b-it-Q4_0.gguf --prompt "What is the meaning of life?"

模型加载阶段一切正常：llama_model_loader成功解析了 GGUF 元数据（gemma3 架构、62 层、262208 词表、上下文 131072），llm_load_tensors正常加载了 808 个张量。但生成阶段输出的却是：

What is the meaning of life?[multimodal][multimodal][multimodal][multimodal][multimodal]

换成 Qwen3-32B-Q4_0 后情况类似，只是乱码形态不同：

What is the meaning of life?*:F+=@*GB&-4%G0'B$4HF;@E(H(C6;()@:%'8"4<-HC.&$G>)$2)536.).C5346=D=6;C41AD@BD&6D';-.:G1+;=;C!+7;A>!+:8DG466)+9#:<99)3

用户补充了关键排查信息：

CLI 与 server 行为一致，带不带-rtr（运行时张量重打包）都一样；
换成 gemma IQ4_XS 模型时输出正常，但一加上-rtr就又变成乱码，且出现典型的重复 token 循环（"please please please..."）；
该机器上所有模型的 prompt processing 阶段看起来都正常，问题集中在解码/采样结果上。

第一轮排查：量化类型、`-rtr`与编译警告

量化类型不是唯一变量

用户最初怀疑是 Q4_0 量化本身的问题："I tried with IQ4_XS models (gemma) it works perfectly, maybe Q4_0 is bad." 但随后的实验推翻了这一假设——IQ4_XS 在不带-rtr时正常，带上-rtr后同样产生乱码与重复循环。这说明问题与具体的量化类型无关，而更可能出在运行环境（CPU 特性检测）或运行时路径上。

这里有必要解释-rtr是什么。在 common/common.cpp 中它的定义是：

-rtr, --run-time-repack repack tensors if interleaved variant is available

对应参数默认值为false（见 common/common.h）。启用后，模型加载阶段会把所有支持 row-interleaved（_R4/_R8）变体的张量在内存中重打包，从而在部分 CPU 上获得更好的矩阵乘法性能。需要注意：

对纯 CPU 推理，-rtr通常是安全的，因为所有张量留在内存中；
但如果是 CPU/GPU 混合推理 MoE 模型，README.md 明确警告不要使用-rtr：重打包后的 k-quants（Q2_K, Q3_K, Q4_K, Q5_K, Q6_K等）没有对应的 CUDA row-interleaved 实现，会导致这些张量的矩阵乘法永远在 CPU 上执行，反而拖慢 prompt processing；
它与llama-bench的默认行为不同：bench 工具默认开启 repack（examples/llama-bench/llama-bench.cpp），因此直接对比 bench 数字时要注意该差异。

编译期的大量警告

用户贴出了完整编译日志，其中包含大量来自ggml/src/iqk/目录的警告，例如：

ggml/src/iqk/fa/iqk_fa_templates.h:534:30: warning: dereferencing type-punned pointer will break strict-aliasing rules ggml/src/iqk/iqk_common.h:851:31: warning: 'always_inline' function might not be inlinable unless also declared 'inline' ggml/src/iqk/iqk_gemm_floats.cpp:1039:34: warning: this statement may fall through [-Wimplicit-fallthrough=]

这些警告主要源于iqk（IQK 量化内核库）在 ARM NEON 路径下的类型双关（type-punning）和 inline 提示，属于该项目的已知编译噪音，与本次乱码问题没有直接因果关系。可以推断，它们不会导致生成内容损坏，用户也并未把这些警告当作根因。真正值得注意的是ggml/src/iqk/iqk_gemm_1bit.cpp中ggml_vdotq_s32相关的-Waggressive-loop-optimizations警告——它提示编译器在自动向量化时对循环上界的推断可能触发未定义行为，这类警告在特定架构/优化等级组合下才可能出现，但本案例中最终定位到的问题并不在此。

根因定位：ARM CPU 特性未正确启用

在维护者ikawrakow建议"尝试最新构建"后，用户用 build 3762 (1843ed22) 重新编译验证，乱码依旧。随后用户提供了一条决定性的线索——对比两次构建的system_info输出：

未启用任何 ARM 特定选项编译时：

system_info: n_threads = 64 / 64 | ... | NEON = 1 | SVE = 0 | ARM_FMA = 1 | FP16_VA = 0 | ... | MATMUL_INT8 = 0 | LLAMAFILE = 1 |

改用-DGGML_SVE=ON编译后：

system_info: n_threads = 64 / 64 | ... | NEON = 1 | SVE = 1 | ARM_FMA = 1 | FP16_VA = 1 | ... | MATMUL_INT8 = 1 | LLAMAFILE = 0 |

用户据此判断："this is the root cause of the garbage output on this server"——默认编译时 ARM 特性宏（FP16 向量运算、INT8 矩阵乘等）没有被正确启用，某些内核走了不匹配的数据路径，最终表现为解码结果整体损坏。

从源码看 ARM 构建逻辑

这个结论可以从 ggml/src/CMakeLists.txt 的 ARM 分支得到印证。在非 MSVC 的 aarch64 分支（约 L1080-L1146）中，构建系统做三件事：

特性探测：用check_cxx_source_compiles探测__ARM_FEATURE_DOTPROD（int8 dotprod）、__ARM_FEATURE_MATMUL_INT8、__ARM_FEATURE_FP16_VECTOR_ARITHMETIC等，只有探测通过才add_compile_definitions对应宏；
GGML_SVE开关：if (GGML_SVE) list(APPEND ARCH_FLAGS -march=armv8.6-a+sve)（L1136-L1138）。注意这不仅仅是"启用 SVE"，而是把整体架构目标抬高到armv8.6-a，连带解锁了 armv8.6 基线所具备/编译器允许的 FP16 与 INT8 指令路径；
GNU 兼容性：对 GCC 追加-flax-vector-conversions，并说明 "else we fail on Gravitons and such"（否则会在 Graviton 等平台上失败），默认GGML_NATIVE只在 GCC 下追加-march=native（L1139-L1145）。

因此，用户观察到的现象（加-DGGML_SVE=ON后FP16_VA、MATMUL_INT8由 0 变 1）本质上是-march=armv8.6-a+sve改变了整体架构目标，编译器随之启用了更多 ARM 特性代码路径，使内核与 CPU 实际能力对齐。

需要客观呈现的一点是：维护者对这一"解法"本身表示过疑惑——"no usage is made of SVE anywhere in ik_llama.cpp. The only ARM implementation that exists is NEON"（整个项目没有任何 SVE 用法，唯一 ARM 实现是 NEON）。结合源码看，GGML_SVE的实际作用确实是抬高-march基线而非直接开启 SVE 内核，因此"它为什么恰好修复乱码"在 issue 中没有定论；可以推断，起作用的更可能是该选项连锁触发的特性宏（FP16 向量、INT8 矩阵乘、LLAMAFILE 禁用等）让编译产物与 CPU 特性表保持一致。对用户而言，更有普适性的做法是下面介绍的GGML_ARCH_FLAGS。

最终方案：用`GGML_ARCH_FLAGS`显式指定 CPU 微架构

在另一位社区成员saood06的提示下（指向GGML_ARCH_FLAGS的用法，见 docs/build.md），用户最终采用了显式指定微架构的编译方式：

cmake -B ./build \ -DGGML_LTO=ON \ -DCMAKE_CXX_FLAGS=" -flto -Ofast -DINTEGER64 -I${ARMPL_DIR}/include -larmpl_ilp64_mp -lamath -lastring -lm " \ -DCMAKE_C_FLAGS=" -flto -Ofast -DINTEGER64 -I${ARMPL_DIR}/include -larmpl_ilp64_mp -lamath -lastring -lm " \ -DGGML_ARCH_FLAGS="-mcpu=neoverse-n2+crc+sve2-aes+sve2-sha3+sve2-sm4+norng+nossbs+dotprod+i8mm+sve+nosme"

其中：

-DGGML_LTO=ON启用链接时优化，配合-flto -Ofast获得全局优化；
-DGGML_ARCH_FLAGS会被构建系统原样透传给 C/C++ 编译命令行（源码证据：ggml/src/CMakeLists.txt 中的set(ARCH_FLAGS ${GGML_ARCH_FLAGS})）；
-mcpu=neoverse-n2+...是针对 Azure Cobalt（Arm Neoverse N2 衍生核）的微架构目标，其中+dotprod +i8mm显式开启 INT8 点积与矩阵乘指令，+sve系特性按 CPU 实际能力声明；
用户同时链接了 ARM Performance Libraries（armpl_ilp64_mp、amath、astring）。

这也是维护者在 issue 中反复强调的要点："Unlike llama.cpp, nothing is automatically set for you on ARM. It is likely you need to set arch options manually."——与 x86 平台相比，ARM 平台没有默认的自动架构检测兜底，必须手动声明目标微架构。项目在 ARM 上的特性探测逻辑同样印证了这一点：MSVC 分支固定用/arch:armv8.2做探测基线（ggml/src/CMakeLists.txt），GCC/Clang 分支则依赖GGML_NATIVE或显式 flags，探测不到就静默降级。

修复后的性能验证与负载场景讨论

采用上述配置后，用户在 64 核 Cobalt VM 上跑出了可用的结果（DeepSeek 671B 量化模型，CPU 后端，KV 使用 q8_0 量化，开启 flash attention、MLA、-rtr、fused MoE）：

引擎/配置	测试	吞吐
llama.cpp（Cobalt 优化 + ARM 性能库）	pp512	43.27 ± 0.16 t/s
llama.cpp（同上）	tg128	10.97 ± 0.07 t/s
ik_llama.cpp（GGML_ARCH_FLAGS 配置）	pp512	68.19 ± 0.16 t/s
ik_llama.cpp（同上）	tg128	11.54 ± 0.07 t/s

需要说明：以上数字来自 issue 当事人自报的运行结果，属于特定机型、特定量化（Q4_0/Q4_K_R4）下的个案测量，不代表通用性能结论。但 issue 中的讨论对如何正确解读这些数字提出了几点有价值的提醒，值得读者参考：

PP-512 / TG-128 是误导性指标：维护者指出，真实场景中 KV cache 很少是空的，"Try running with something more significant in the KV cache (8k-18k tokens)"，即在 8k~18k token 上下文下再测才贴近实际；
用sweep-bench测上下文衰减：该工具专门用于衡量性能随上下文长度的衰减，并自带绘图工具（examples/sweep-bench）；
高 ubatch 可提升 PP：在内存带宽允许的前提下调大-ub（micro batch）能进一步提升 prompt processing 吞吐；
批量服务用batched-bench：如果要让多个用户共享一个实例，可用 examples/batched-bench 验证批处理吞吐；
MLA 版本选择：同一次会话中用户曾用 MLA 3（-mla 3）与 MLA 2（-mla 2）跑出不同结果，切换时要注意模型头文件是否匹配。

这些基准工具与-rtr等参数的完整说明可以在 docs/parameters.md 与 examples/llama-bench/llama-bench.cpp 中找到。

给 ARM 部署者的实践建议

综合本次 issue 的完整过程，在 aarch64 服务器上部署 ik_llama.cpp 时建议按以下顺序排查与配置：

确认 CPU 特性被正确启用：启动日志中检查system_info行的NEON、FP16_VA、MATMUL_INT8等标志位；若你的 CPU 支持这些特性而日志显示为 0，务必手动指定架构；
优先使用GGML_ARCH_FLAGS显式声明微架构：例如-DGGML_ARCH_FLAGS="-mcpu=neoverse-n2+dotprod+i8mm+sve"，比依赖GGML_SVE这类间接开关更可控、更可预期；
遇到乱码先做最小化对比实验：固定模型与量化，交替开关-rtr、-fa（flash attention）、-ctk/-ctv（KV 量化类型），逐项缩小变量范围；
警惕-rtr的适用边界：纯 CPU 场景可放心使用；混合 CPU/GPU 的 MoE 模型请遵守 README.md 的警告避免启用；
用llama-bench/sweep-bench替代单一 t/s 数字：尤其要覆盖非空 KV cache 的长上下文场景，才能得到接近真实负载的结论。

回到 issue 本身：该问题最终以用户确认-DGGML_SVE=ON修复、并在GGML_ARCH_FLAGS下获得满意性能而关闭（2025-06-26）。对于 ARM 平台，项目维护者明确表示这是"功能可维护但非重点"的方向，主要开发/测试平台是 AVX2、Zen4 与 Apple Silicon（NEON）——这提醒 ARM 服务器用户：与 x86 相比，你需要为编译期架构声明承担更多主动配置的责任，而本次 issue 恰恰给出了一个完整可复用的排查范本。

【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

ik_llama.cpp 在 ARM CPU 上输出乱码的排查实录：从 `-DGGML_SVE=ON` 到 `GGML_ARCH_FLAGS` 的 CPU 特性配置指南