Eval bug: Llama-server on Mac starting at b5478 only producing 2-3 streaming tokens on Qwen3 and Deepseek R1 0528

快速结论：该“Eval bug: Llama-server on Mac starting at b5478 only producing 2-3 streaming tokens on Qwen3 and Deepseek R1 0528”现象并非 llama.cpp 本身的推理错误，而是从 b5478 版本起流式 API 的 delta.content 字段在首个 token 之前返回 None（而非空字符串），导致前端未兼容而断开连接，表现为只输出 2–3 个 token 后停止。优先排查前端对 None 的处理逻辑。

适用环境：macOS（Metal 后端）、M3 Ultra / 512GB、llama-server b5478 及更高版本、模型 Qwen3 235B-A22B-GGUF（Q8_K_XL）和 DeepSeek R1 0528（Q4_K_M / Q5_K_M）

最快修复方案：修改前端流式解析代码，将 choice["delta"]["content"] 为 None 的情况视为无内容（如改为空字符串），而不是直接中断。若不需改动前端，可回退到 b5477 及更早版本的 llama-server。

注意事项：当前方案仅基于 Issue 作者的自查结论，未在其他环境复现；用户本人已确认是误报。若仍遇到问题，可尝试同时更新 llama-server 和前端至最新版本。

问题场景

用户在 macOS 上使用 llama-server 运行大语言模型（Qwen3 235B / DeepSeek R1 0528）时，通过流式 API 发送相同 prompt，从 b5478 版本起，模型仅输出 2–3 个 token 就停止响应，而 b5361 和 b5477 版本正常。用户最初以为是 llama.cpp 的 eval bug，随后自行排查发现是前端未能处理流式返回中 delta.content 为 None 的情况，导致前端断开 WebSocket 连接。

报错原文

Eval bug: Llama-server on Mac starting at b5478 only producing 2-3 streaming tokens on Qwen3 and Deepseek R1 0528

（实际日志中并未出现明确报错代码，主要表现为流式响应提前终止，前端无错误输出）

原因分析

在 llama.cpp b5478 提交中，OpenAI 兼容的流式 API 行为发生了微小变更：首个 chunk 中 choice["delta"]["content"] 从原来的空字符串 "" 变为 None。如果前端代码仅判断 content 是否为 "" 而跳过，或者未对 None 进行异常处理，会导致前端解析失败并断开连接，从而让用户误以为推理引擎停止输出。

环境排查

确认 llama-server 版本：若版本 ≥ b5478，且出现该现象，请检查前端流式解析代码。
确认模型：Qwen3 235B-A22B-GGUF 和 DeepSeek R1 0528 等大参数模型更易触发（因流式 chunk 较多）。
确认前端使用的 SDK / 框架版本（如 Open WebUI、自定义客户端等），是否跟随了 llama.cpp API 的语义更新。
排查网络代理或防火墙是否因收到异常 JSON 而中断连接。

解决步骤

定位前端代码：找到处理流式 SSE 响应的位置（例如 for chunk in response 或 on message 回调）。
修复 None 处理：将类似 if i == 0: assert choice["delta"]["content"] == "" 修改为 assert choice["delta"]["content"] is None，并将后续追加内容的逻辑改为 content += choice["delta"]["content"] or ''。
验证修改：使用同样命令重新启动 llama-server（如 ./llama-server -ngl 200 --model <model> --ctx-size 32768 --host 0.0.0.0 --port 5001 -lv 1 --jinja --mlock）并发送测试请求。
临时回退：若无法立即修改前端，可降级至 b5477 或更早版本的 llama-server。

验证方法

两次请求分别使用 b5477 和 b5478+ 版 llama-server，使用同一个前端发送相同 prompt，若能完整输出全文且不再提前截断，则表明修复有效。也可直接检查流式响应中首个 text/event-stream 消息的 JSON 结构，确认 delta.content 字段是否为 null。