一句话看懂：一个名为 picchio 的开源诊断工具，通过跑三个回合的推理并解析引擎日志，能够精准识别本地大模型是否真的在使用 GPU 推理，还是无声无息地退回到了 CPU 运行。它在 Apple M5 实测中发现，GPU 加速对解码阶段（写出答案的速度）仅有约 2 倍提升，但对预填充阶段（读提示的速度）提升高达 22 倍，而大多数用户发布的 tok/s 数字只反映了前者。
事件核心：发生了什么
开发者 logxio 在 GitHub 上发布了 picchio（意大利语“啄木鸟”），这是一个仅依赖 Python 标准库、无需 pip 安装的 980 行单文件工具。它通过调用 llama.cpp 或 ollama，用固定提示词对本地模型执行三次推理（第一次冷启动，后两次热启动），然后从引擎原始日志中提取 GPU 层分配、预填充速度、解码速度、冷载耗时等数据，最终输出一个包含“HEALTHY”或“NOT ENGAGED”等判决的 15 行诊断块。项目关键发现包括：一台 Apple M5、32GB 内存设备上，Qwen3.5-9B 模型在 GPU 加速下的解码中位数为 20.0 tok/s，CPU 回退时降至 11.0 tok/s；预填充速度则从 559 tok/s 跌至 26 tok/s。另一个案例显示，后台下载活动可将解码速度砍掉近一半。
为什么重要
这一工具直接揭露了本地 LLM 推理领域长期被忽视的测量盲区。目前大部分用户和评测者习惯只展示一个 tok/s 数字，但 picchio 明确区分了“预填充”“解码”和“墙钟”三个不可合并的度量：预填充决定第一字的响应延迟（读入长提示所需时间），解码决定打字般生成的速度，墙钟则包含加载和预热等全部开销。帖文指出，一张声称达到 500 tok/s 的 Mac 截图，几乎肯定只是预填充速度，而非用户体感对应的解码速度。更隐蔽的风险是“静默 CPU 回退”——引擎可能在未报错的情况下将部分或全部层交给 CPU，此时解码数字看起来还算正常，但预填充耗时已大幅增加，导致长提示场景下的应用“首字延迟”严重恶化。
对用户/开发者/创作者的影响
对于运行本地大模型的用户和开发者，picchio 提供了一种低成本、可复现的基准验证方式。建议在以下场景中运行一次诊断：升级 llama.cpp 或 ollama、更新操作系统、更换模型量化格式、调整 GPU 层数（-ngl）或上下文窗口大小，以及在公开发布 tok/s 数字之前。诊断输出包含详细的冷启动耗时拆解（加载权重、预填充、解码、引擎杂项分别用时和占比），这有助于定位是权重加载瓶颈（IO 瓶颈）还是推理计算瓶颈（GPU/CPU 瓶颈）。对于内容创作者，跑一次诊断能确认自己的硬件配置是否真正发挥了应有性能，避免因后台进程或配置错误导致体验降级而误判硬件性能。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，picchio 的 parser 通过回放原始日志文件的回归测试来保证判决准确性，这种测试设计能否被其他硬件配置（如 Windows + CUDA、Linux + ROCm）上的社区验证通过，将决定其适用范围。第二，工具当前聚焦于 llama.cpp 和 ollama 生态，是否支持其他推理引擎（如 llama-cpp-python、text-generation-webui）未见提及，社区可能很快会 fork 扩展开源生态。第三，该项目的核心价值在于暴露“一个 tok/s 数字不够”这一事实，可能推动主流硬件测试工具（如 llama-bench）在未来输出更多细分指标和 GPU 状态判断。
来源：github.com
