llmfit：一条命令找出你的硬件能跑哪些大模型

本地跑大模型的第一个问题永远是同一个：我这台机器到底带得动哪些模型？ 每次翻着模型卡片的参数量，对照自己 16GB 还是 64GB 内存反复心算，还要担心某个量化版会不会 OOM（内存耗尽）——llmfit 把这件反复试错的事收敛成了一条命令。

本文的目标分三个：讲清 llmfit 如何从硬件规格算出“能不能跑、能跑多快”；它的估算为什么可信、又如何被实测替代；以及怎样用一条命令完成选型并接入自己的脚本或 Agent（智能体）流程。

目录

• 一分钟总览
• 硬件检测：先摸清机器有什么
• 它怎么判断"能不能跑"
• 速度预估为什么可信
• 实测闭环：bench 把估算变成实测
• 安装与上手
• 适用边界
• 和其他工具的关系
• 常见问题 FAQ
• 练习与自测
• 进阶方向
• 参考文献

一分钟总览

llmfit 是一个 Rust 编写的终端工具，默认 TUI 交互界面，也提供经典 CLI（命令行工具）模式。项目采用 MIT 协议，仓库约 3.3 万 stars（截至 2026-08-19）。它检测你的硬件（RAM、CPU、GPU/VRAM、加速后端），然后为目录里几百个模型逐一给出内存适配度、预估速度、质量、上下文长度四个维度的评分，并排出一个"在你机器上真的能跑"的榜单。

llmfit                # 交互式 TUI：你的硬件 + 每个模型的 fit 排名
llmfit fit            # 表格列出所有模型按适配度排名
llmfit recommend --json   # 输出推荐列表（给脚本/Agent 用）
llmfit info "<model>"     # 单个模型的适配分析 + 验证命令
llmfit bench          # 对正在运行的 provider 实测真实 tok/s 与 TTFT
llmfit doctor         # 硬件检测报告（提 bug 用）

它不是"替你下载模型"的工具，而是决策工具：告诉你在动手下载之前，某个模型在这台机器上到底行不行、能到什么速度，并给你可验证的命令。推理交给本地运行时，llmfit 只负责"选"。

硬件检测：先摸清机器有什么

判断模型能不能跑之前，llmfit 先探测硬件。它的检测面覆盖了本地推理的主流形态：

同时它识别加速后端——CUDA、Metal、ROCm、SYCL、CPU（ARM/x86）、昇腾——这个结果直接决定后续速度预估的口径。GPU 显存上报失败时，还会退一步按 GPU 型号名估算 VRAM。

它怎么判断"能不能跑"

核心判断分三步。

第一步：模型需要多少内存。 模型数据库来自 HuggingFace API（应用程序接口），Llama、Mistral、Qwen、Gemma、Phi、DeepSeek 等几百个模型在编译期烘焙进二进制。llmfit 按参数量计算内存需求，并从 Q8_0（质量最高）到 Q2_K（压缩最狠）遍历量化档位，挑能塞进你内存的最高质量量化，而不是假设一个固定版本；全上下文塞不下，再按半上下文重试。

第二步：以什么模式跑。 每个模型会被归入一种运行模式：

• GPU：模型整体进 VRAM，速度最快
• MoE（混合专家模型）：专家卸载，激活专家在 VRAM、非激活在内存
• CPU+GPU：VRAM 不够，部分溢出到系统内存
• CPU：无 GPU，全部进系统内存

适配度分四档：Perfect、Good、Marginal、Too Tight。纯 CPU 运行的上限就是 Marginal；Too Tight 的模型永远排在榜单末尾。内存利用的"甜点区间"被定义为可用内存的 50%–80%。

第三步：四个维度打分。 适配、速度、质量、上下文各打 0–100 分，再按使用场景加权合成总分——Chat 场景把速度权重调高（0.35），Reasoning 场景把质量权重调高（0.55）。质量分不只看参数量，还参考一份从公开排行榜聚合的按家族策划基准表，所以 --use-case coding 模式下，一个强编码模型能压过参数更多的通用模型。

MoE 模型只按激活参数算

这是 llmfit 适配判断里最值钱的一处。MoE 架构每个 token（词元）只激活一部分专家，按总参数量估算内存会把大多数本地机器吓退。llmfit 通过模型配置里的 num_local_experts、num_experts_per_tok 和已知架构映射自动识别 MoE。官方文档给了具体例子：Mixtral 8x7B 总参数 46.7B，每 token 只激活约 12.9B，配合专家卸载后 VRAM 需求从 23.9 GB 降到约 6.6 GB。

速度预估为什么可信

LLM（大语言模型）推理时，生成每个 token 都要把整套模型权重从显存读一遍，吞吐量因此受内存带宽约束。llmfit 认出 GPU 时，直接用它的实际带宽计算：

预估速度 = 带宽（GB/s）÷ 模型体积（GB）× 效率因子（0.55）

效率因子覆盖内核开销、KV cache（键值缓存）读取与内存控制器效应，可以在 TUI 的高级配置面板（按 A）里调整。这套方法对照过 llama.cpp 社区的公开基准（Apple Silicon 与 NVIDIA T4 两组数据），带宽查询表覆盖约 80 款 GPU，横跨 NVIDIA（消费级 + 数据中心）、AMD（RDNA + CDNA）与 Apple Silicon。

遇到不认识的 GPU，llmfit 退回按后端的速度常数：CUDA 220、Metal 160、ROCm 180、SYCL 100、CPU ARM 90、CPU x86 70、昇腾 390——这些是经验常数，不是实测。估算终究是估算，真正的确定性来自下一节的实测闭环。

另一个值得记住的设计：每个预估都带着输入条件。llmfit info 会展示一个数字"假设了什么、怎么在你的机器上验证"。llmfit 1.0 正是把"数字可核实"当作主题的版本，此后数字不再是无源之水，而是可核实、可替代的。

实测闭环：bench 把估算变成实测

llmfit bench 会把"估算"升级成"实测"。下载模型、跑起来、测量真实 tok/s 和 TTFT（time to first token，首 token 延迟），然后把结果作为 PR 回馈给项目——直接从 TUI 发起，不需要 gh CLI，不需要第三方账号。每次运行先存本地，你自己的测量会替换表格里的估算值，合并的提交随下一次发布分发。之后任何一台相同硬件的人，在你跑基准之前就能直接看到打勾的实测数字。

这个设计把"社区排行榜"从一个营销概念变成了自举的数据闭环：每个人贡献自己的硬件测量，榜单质量随使用人数增长。

安装与上手

llmfit 支持 Homebrew、Scoop、MacPorts、uv/pip、Docker/Podman 与源码构建：

brew install AlexsJones/llmfit/llmfit   # macOS/Linux 预编译
# 或
curl -fsSL https://llmfit.axjns.dev/install.sh | sh
# 或
uv tool install -U llmfit

Windows 用 scoop install llmfit；Docker/Podman 可以直接跑 ghcr.io/alexsjones/llmfit（默认输出 recommend 的 JSON）。安装脚本默认装到 /usr/local/bin，没有 sudo 时装进 ~/.local/bin（加 --local 参数）。Windows 发布二进制经过 SignPath 数字签名。遇到硬件检测错误时，先跑 llmfit doctor 生成报告再提 issue，排查起来会快很多。

第一次跑 llmfit 会看到这样的 TUI：顶部是你的机器规格，下方是每个模型的四维评分和适配度排名。脚本或 Agent 场景下，llmfit recommend --json 的输出可以直接解析：

llmfit recommend --use-case coding --json | jq '.models[].name'

本地运行 provider

llmfit 不自己托管模型，而是把推理交给本地运行时：Ollama、llama.cpp、MLX（Apple Silicon）、Docker Model Runner、LM Studio。配合 --use-case coding 这类场景筛选，它会在这些后端之上给出针对性的模型推荐。

适用边界

• 适合：想跑本地模型但不确定该下哪个的人；想比较"换更大模型值不值"的人；做模型选型时想拿实测数据说话的人。
• 不适合：只依赖云 API、没有本地推理需求的人——llmfit 的整个价值建立在"你有一台要跑模型的机器"之上。
• 注意：速度是估算，尤其是尚未被社区实测覆盖的硬件组合；真正的确定性来自 llmfit bench 实测闭环。

和其他工具的关系

README 里明确对比了 llm-checker：那是 Node.js 写的、通过 Ollama 直接拉模型实测的工具，走的是"真跑一遍"路线，适合已装 Ollama、想看真实性能的人；但它不区分 MoE，Mixtral、DeepSeek-V3 这类模型会被按总参数量估算内存。llmfit 走的是"先估算、后可实测验证"路线，两者的取舍正好互补。

常见问题 FAQ

估算到底准不准？ 已识别的 GPU 走真实带宽公式，并对照过 llama.cpp 社区基准；不认识的硬件退回经验常数。想要确切数字，用 llmfit bench 在自己机器上测一次。

为什么纯 CPU 机器最高只有 Marginal？ 这是档位设计：CPU 推理受内存带宽限制，适配上限就是 Marginal，不代表模型跑不动，只代表跑不快。

模型库怎么更新？ 模型数据库编译期烘焙，终端用户升级 llmfit 本身（brew upgrade llmfit、scoop update llmfit 或新版发布）即可获得新模型；贡献者用 make update-models 从 HuggingFace 刷新。

想要的模型不在目录里怎么办？ 参考 docs/custom-models.md，可以本地添加（无需重新编译），也可以提 PR 进内置目录。

练习与自测

1. 跑一次 llmfit doctor，确认检测出的 RAM、GPU 与加速后端和你的预期一致。
2. 用 llmfit fit 找一个你感兴趣的模型，再用 llmfit info 看它选了哪档量化、假设了多少可用内存，并照着给出的验证命令实测。
3. 对已经跑起来的模型执行 llmfit bench，对比实测 tok/s 与预估值的差距，想想差距来自哪里。

进阶方向

• 读仓库 docs/how-it-works.md，拿到完整估算公式与模型数据库维护方法
• 在多卡或 MoE 场景下观察 fit 档位与运行模式的变化，理解专家卸载的边界
• 给 use_case_benchmarks.json（按模型家族的任务基准表）纠错或补充，直接影响推荐排序

小结论

llmfit 解决的不是"哪个模型最好"，而是"哪个模型在我这台机器上最可能跑得动、跑得快"——这个问题的答案，过去要么靠猜，要么靠下载后撞 OOM 才能知道。它把模型选型的决策成本压到一条命令，用带假设的估算保证可核实，再用实测闭环让数字越来越准。如果你正在给本地推理选型，值得跑一次 llmfit 看看你的硬件到底有多少潜力。

参考文献

1. llmfit 仓库与 README：https://github.com/AlexsJones/llmfit
2. 估算模型与模型数据库说明：仓库内 docs/how-it-works.md
3. 基准测试指南：仓库内 docs/benchmarking.md
4. llmfit 1.0 发布讨论（数字可核实的版本）：https://github.com/AlexsJones/llmfit/discussions/708
5. 对照基准：llama.cpp 社区讨论 https://github.com/ggml-org/llama.cpp/discussions/4167 与 https://github.com/ggml-org/llama.cpp/discussions/4225
6. 对比工具 llm-checker：https://github.com/Pavelevich/llm-checker