本地模型跑得慢，到底是模型、显卡还是配置的问题？用 AI & ML GPU Bench 把猜测变成可复现实验
在本地部署 LLM 时，“回答慢”常常被直接归因于显卡不够强。但一次体感卡顿可能来自模型大小、Ollama 后端、CPU/GPU 路径、显存压力，甚至是测试方式不一致。若每次只换一个模型、看一眼终端耗时，很难把不同机器、不同模型和不同配置放在同一把尺子上比较。
AI & ML GPU Bench Suite for Python 是 Alberto Danese 维护的 MIT 许可 Python 项目。它把两类本地工作负载放进同一套可配置的流程：一类是通过 Ollama 测量模型的 token 延迟与吞吐，另一类是用 HIGGS 数据集运行 XGBoost 的训练与推理。它不是替你挑选“最快模型”的黑盒评分器，而是一个把硬件、模型清单、重复次数和结果产物明确写下来的基准脚手架。
先把要回答的问题拆开
性能测试最容易失败的地方不是命令执行报错，而是问题定义含混。例如“这台电脑适不适合跑本地 AI”同时混合了至少三件事：LLM 生成速度、传统机器学习训练速度，以及 CPU 与 GPU 之间的差异。该项目将 Ollama 与 XGBoost 分为独立 suite，避免让某一个结论替代所有负载的结论。
配置文件中的 gpu_used: [true, false] 表示同一组任务会分别尝试 GPU 与 CPU 路径；repeats: 3 则让每个组合重复执行。XGBoost 的 rows 默认列出 100000、1000000 和完整数据集三种规模；Ollama 一侧则区分 models_fast 与额外模型列表。这样得到的不是某次偶然运行的单点数字，而是一组可以复查的组合。
需要注意，这也不是严格意义上的跨平台实验室基准：驱动、CUDA、Ollama 版本、后台负载和模型文件状态都会改变结果。因此同一台机器的前后对比特别有价值；跨机器比较时，则应保留配置和环境说明，而不是只转发一个“每秒多少 token”的数字。
从最小可运行集开始
项目要求 Python 3.13 及 uv。若要运行 Ollama 部分，还需要已启动的 Ollama 服务；README 指定的默认地址是 http://localhost:11434。先只运行较快的 Ollama 模型集，并明确关闭结果上传，适合用来确认环境、模型下载和输出路径是否都正常：
git clone https://github.com/albedan/ai-ml-gpu-bench cd ai-ml-gpu-bench uv run run_suite.py --suite ollama --fast --no-upload-results
--fast 只选择 YAML 中的 models_fast；它不是降低单个模型的精度参数。项目还提供 --autopull，用于拉取配置里缺失的 Ollama 模型；这个选项不会安装或升级 Ollama 本身。若你不希望自动下载模型，可以先不传它，查看程序报告的缺失项，再手工决定下载哪些模型。
只想检查传统 ML 任务时，可切换到 XGBoost suite：
uv run run_suite.py --suite xgboost --no-upload-results
README 说明：没有 GPU 的机器仍可运行，GPU 基准会被跳过。NVIDIA 环境若发现 XGBoost 没有走 GPU，应该先用 nvidia-smi 和 nvcc -V 核实 GPU 与 CUDA Toolkit，而不是马上把问题归咎于 Python 脚本。
配置比“跑一次”更重要
ai_bench_suite.yaml 是这套流程的实验记录中心。最实用的做法是复制并提交自己的配置版本：填写机器、CPU 与 GPU 标识；保留要比较的模型；把不需要的模型项注释掉；再固定重复次数。默认的 Ollama 配置包含较快模型和额外模型两组，执行器会将二者去重后运行；--fast 才只取前者。
例如，如果目标是比较一块新显卡是否改善本地问答体验，不必一次测试全部模型。保留两三个与真实工作负载接近的模型，维持相同 prompt、重复次数和 gpu_used 设置，分别在变更前后运行即可。若目标是了解 CPU 回退的代价，则不要删除 false；CPU 与 GPU 的结果正是判断“显卡没有真正参与”或“收益不明显”的依据。
项目会写出 results/xgb.csv 与 results/ollama.csv，并执行 notebook 导出 HTML 报告。CSV 适合纳入自己的分析或版本库附件；HTML 则方便浏览当前运行与参考结果。报告里的粗边框对应本次运行、细边框对应项目提供的参考结果——阅读时应先分清这两种来源，避免把别人的硬件数据当成自己的实测。
建立一条能解释异常的测试链
一次完整运行的意义，不只是生成两份 CSV，而是留下排查线索。建议在每次记录旁保存四类信息：提交时使用的 ai_bench_suite.yaml、Ollama 与驱动版本、是否选择 GPU 路径，以及运行时是否有其他重负载。项目执行器会在启动 Ollama suite 时尝试读取本地 Ollama 版本，并与 GitHub 上的最新稳定 release 比较；即使无法检测或发现版本较旧，它也只给出提示并继续执行。因此，版本警告不是失败结论，却是解释结果变化的重要上下文。
当结果看起来反常时，按“配置—服务—硬件”顺序缩小范围通常比反复换模型有效。第一步检查 YAML 中实际启用的模型，以及是否无意间用了 --fast；第二步确认 Ollama 服务可用、模型已在本机就绪；第三步比较同一模型的 CPU 与 GPU 两行结果。如果两者接近，不应急着得出“GPU 没价值”的结论，还要检查运行时的 GPU 利用率、显存容量和驱动环境。反过来，GPU 结果明显更快也只说明这一组 prompt、这个模型与这台机器上的路径受益，不能自动外推到更大的模型或 Agent 工作流。
XGBoost 部分也应独立阅读。它以样本行数、CPU/GPU 选择和重复次数构造任务，适合观察数据规模增长时训练与推理的变化；但它不能代表向量数据库、ETL 或深度学习训练的性能。将 LLM 生成和 XGBoost 结果放在同一篇硬件采购结论中之前，先确认业务真正更在意的是交互延迟、批量训练时间，还是两者兼有。
为了让前后测试更接近可比实验，还可以采用一个简单的基线策略：先连续运行一次较小模型集，确认首次下载、环境初始化等冷启动成本已经过去；随后不改 YAML 再运行一次，将第二次结果作为日常对比基线。升级 Ollama、驱动或更换显卡后重复这套过程。这样即使不做复杂统计，也能避免把下载模型或首次创建环境的开销误读为推理性能。
如果团队需要长期追踪，建议把每次 CSV 的副本与配置文件一起按日期归档，而不是覆盖掉旧结果。比较时优先看同一模型、同一 suite 和同一重复次数下的差异；当配置、模型版本或数据规模改变时，把它标记为新的实验组。这样报告既能服务日常排障，也不会把不可直接比较的数据拼成看似精确的结论。
上传、隐私与可复现性的取舍
默认配置启用了结果分享：README 表示 CSV 会先以 RSA-4096 加密，再上传到 Filebin；声明上传的是技术基准数据，不含 prompt、模型输出、数据集、notebook 或原始系统文件。即便如此，企业电脑、受管设备或不确定网络策略下，都应先使用 --no-upload-results。
这也是一个值得保留的工程习惯：性能结果可以分享，但是否离开本机应当是显式选择，而非测试副作用。先完成本地验证，再根据团队的数据治理要求决定是否共享，通常比为了“贡献参考库”而跳过审查更稳妥。
哪些场景值得用它，哪些不该过度解读
它适合三个场景：更换 GPU、驱动或 CUDA 后做前后回归；为本地 Ollama 模型建立可重复的选型记录；以及同时关心 LLM 推理与 XGBoost 工作负载的个人工作站评估。它不适合直接推出云端服务性能、复杂 Agent 端到端延迟，或把单一 prompt 的结果推广为所有模型能力。
把基准当作决策材料，而不是排行榜，价值才会显现。先固定环境和配置，再分开看 Ollama 与 XGBoost；发现异常时回到 CPU/GPU 两组、模型是否实际就绪、以及运行期间的系统状态。这样，“本地 AI 很慢”的模糊抱怨才能收敛成下一步可验证的工程问题。