llama.cpp 贡献记录

llama.cpp 是一个跨平台 C/C++ 推理项目，涵盖模型加载、本地与 server 推理、CPU/GPU 后端以及多模态输入。问题位于 libmtmd——媒体进入模型前的准备层，不在 backend kernel 或文本生成循环中。

音频路径中，llama-server 接收 OpenAI-compatible 的 input_audio 文件；mtmd_helper 通过 miniaudio 将 WAV/MP3/FLAC 解码成单声道 F32 PCM；libmtmd 创建 audio bitmap，随后 mtmd_tokenize 选择 model-specific preprocessor，将媒体转换成 multimodal chunks 与 audio tokens。

音频输入仍属 experimental，且共享 tokenizer 会选择多种 preprocessor。这意味着共享边界检查不能因为某一模型也许会为超短信号补零，就悄悄扩大所有音频模型的可接受输入域。

Issue 报告描述了 Voxtral 路径上的一个 16 kHz 单声道 WAV，解码后恰好只有一个 sample。一个 mono F32 sample 会形成合法的四字节 buffer：nx == 1、buf.size() == sizeof(float)，且 buffer 仍然正确对齐。

当前 tokenizer 已把 nx == 0 作为可恢复的空输入错误，但后面又要求 buf.size() > sizeof(float)。对一个 sample 而言，4 > 4 为假，因此 GGML_ASSERT 会走到 ggml_abort，而不是返回一次请求错误。

上游报告中 CLI 会退出、server 在一次请求后失去 /health；这些运行结果属于作者报告，尚非我的本地复现。我当前参与确认的是静态路径与剩余验收门禁，而不是宣称已在 Windows 复现或已经修复。

底层 bitmap 并没有损坏。它的字节数是 nx * sizeof(float)，所以单采样对象满足表示与对齐不变量。真正的问题是：一个用户可控的最小长度问题，被写成了会终止整个进程的内部内存断言。

把 > 简单改成 >= 虽能避开这条特定断言，却会把单采样信号送入所有 model-specific preprocessor。Whisper-style 路径可能补零；Conformer、Parakeet、Granite Speech、Qwen3 TTS 等路径则有不同的 frame、normalisation 或最小长度语义。静态证据不足以支持全局放行。

错误边界还必须覆盖 /input_tokens 使用的 placeholder bitmap。若只根据 real buffer 修复，同一个 sample count 可能在 token-count 与正常 completion 路径产生不一致行为。

目前没有源码修改。暂定方向是在共享 audio-tokenization 边界以现有的 LOG_ERR + return-error 契约拒绝 nx < 2，并放在 real-buffer 与 placeholder 分流之前。这样异常输入会变成可恢复的请求失败，而不会继续到 abort。

已有的对齐断言仍保留为内部不变量。正常 nx >= 2 的音频仍进入完全相同的 preprocessor 路径；该方案也避免为所有音频模型定义单采样的数值行为。

这是设计候选，而不是实现完成声明。任何代码之前都需要基线复现、对 zero-sample 错误文案作出明确选择、验证 real-buffer 与 placeholder，并补上一条修复前失败、修复后通过的回归测试。