llmfit

llmfit 快速入门

一行命令回答「我这台机器到底能跑哪些开源 LLM」——llmfit 自动检测你的 CPU、内存、GPU/VRAM 与量化格式兼容性，对数百个模型逐个估算显存/内存占用并给出适配度排名，避免反复试错。2026-09-19 核验：GitHub 36.8k★ / 2.3k fork，MIT，Rust 实现。

这是什么？适合谁？

llmfit（作者 AlexsJones，Rust 单二进制）解决的是本地部署 LLM 前最常见的实际问题：用户想知道「我的硬件能不能跑 Qwen3.5 235B、用哪种量化、大概什么速度」，而不是下载几十 GB 权重后才发现 OOM。它聚合数百家模型/服务商数据，检测本机 CPU 核数、系统内存、独显/核显 VRAM（支持 NVIDIA CUDA、Apple Silicon、AMD ROCm、Intel OneAPI），再按参数量、上下文长度和量化格式（GGUF、AWQ、GPTQ、EXL2）推算内存占用与 tokens/s 预估，输出按适配度（fit）、速度、质量、上下文四维打分的模型排名表。

适合人群：

• 本地推理玩家：买卡/加内存前先确认目标模型能否跑动
• 企业基础设施团队：批量评估办公机能否跑内网部署的模型
• 笔记本用户：想知道统一内存 Apple Silicon 上各量化的真实可行区间
• AI 工程师：通过 REST API 把硬件-模型匹配集成进部署流水线

不适合谁：只想用云端 API、完全不碰本地模型的用户。

准备工作

• 运行环境：macOS（Apple Silicon 与 Intel）、Linux（x86_64 / ARM64）、Windows（x86_64）均提供二进制
• 账号要求：无需任何账号，纯本地运行
• 付费要求：完全免费，MIT 开源
• 权限：读取硬件信息（CPU/RAM/GPU），无需管理员权限即可完成检测
• 时间预算：安装 1-2 分钟，首次扫描几十秒内出结果

3 步快速上手

第一步：安装

# macOS / Linux（Homebrew）
brew install AlexsJones/llmfit/llmfit

# Windows（Scoop）
scoop install llmfit

# 通用一键脚本（下载 GitHub Release 二进制到 /usr/local/bin 或 ~/.local/bin）
curl -fsSL https://llmfit.axjns.dev/install.sh | sh

# 也可通过 Python 包管理器安装（uv）
uv tool install -U llmfit

第二步：启动 TUI 查看排名

llmfit          # 交互式 TUI：本机硬件检测 + 全部模型按适配度排名

TUI 顶部显示检测到的硬件规格，下方是每个模型在 fit / speed / quality / context 四个维度的打分。常用键位：/ 按名称/家族/量化筛选，b 打开社区实测榜，I 查看实时推理基准，h 查看帮助。

首个任务：在 TUI 里按 / 输入你关心的模型名（如 qwen），观察其各量化档位在你的机器上的 fit 等级与内存预估——这一步就能回答「能不能跑、跑哪个量化」。

第三步：脚本化输出（CLI / JSON / API）

llmfit recommend              # 硬件遥测 + 推荐模型，纯文本输出
llmfit recommend --json       # 机器可读 JSON，适合管道与 CI
llmfit info "qwen3.5-235b"    # 单模型：适配分析、估算依据、验证命令
llmfit storage --keep 3 --selection largest --json   # 估算同时保留 3 个模型所需 SSD 空间
llmfit serve --host 0.0.0.0 --port 8787             # 启动 REST API（/api/v1/system、/api/v1/models）

预期结果：recommend 一条命令输出本机全部硬件参数与排序后的推荐清单；--json 可直接喂给部署脚本。

常见踩坑

1. 现象：估算说能跑，实际还是 OOM。 原因：llmfit 的内存占用是按参数量与量化的数学推算，不含运行时开销（KV cache 随上下文增长、系统占用）。 解决：用 llmfit info "<model>" 查看估算依据，给上下文长度留出余量；实测为准，llmfit 官方也提供了 benchmark 流程（下载-服务-实测 tok/s-回传 PR），同硬件的实测值会替换估算值。

2. 现象：MoE 模型（如 Mixtral、DeepSeek-V3 类）的内存预估偏高。 原因：MoE 架构总参数远大于激活参数，部分估算路径按总参数计。 解决：以 info 输出的估算基准说明为准；另可参考社区基准页（b 键）里同型号硬件的实测。

3. 现象：Windows 上 Scoop 安装失败。 原因：未先安装 Scoop 包管理器。 解决：按 scoop.sh 指南装好 Scoop 后重试；或改用 Python 方式 uv tool install -U llmfit，或直接从 GitHub Releases 下载 exe。

4. 现象：TUI 在远程 SSH 终端显示乱码。 原因：TUI 依赖终端渲染能力。 解决：改用 llmfit recommend 的纯文本/JSON 模式；或起 llmfit serve 后用浏览器访问 Web Dashboard。

5. 现象：想集成到部署流水线但不想装二进制。 原因：需要常驻服务形态。 解决：官方提供 Docker 镜像 ghcr.io/alexsjones/llmfit，docker run -d -p 8787:8787 ghcr.io/alexsjones/llmfit serve 即可暴露标准 HTTP JSON 端点（含 healthcheck 配置示例）。

权限、安全与限制

• 数据面：硬件检测在本机完成；模型元数据来自聚合数据源。不上传你的文件或凭据。
• 平台：TUI 与 REST API 均为本地服务；serve 绑定 0.0.0.0 时注意不要暴露到公网。
• 成本：软件免费；它帮助你避免的是「下载错模型浪费带宽与磁盘」的隐性成本。
• 估算 ≠ 实测：官方文档明确区分估算与实测，核心价值在于先筛后测。

小技巧

1. 用 llmfit storage --keep N 在下载前规划 SSD 空间，避免下到一半盘满。
2. 在 TUI 里按 b 查社区基准：同硬件配置的实测 tok/s 比估算更有参考价值。
3. llmfit recommend --json 直接作为 Ansible/脚本里的硬件画像输入，比手写 lshw 解析省事。
4. Docker 部署时保留官方 healthcheck 配置，便于编排系统探活。
5. 升级后重新跑一次 recommend：模型库与量化支持随版本更新（如新增 EXL2 支持）。

进阶学习方向

• 基准贡献闭环：按官方 benchmarking 指南（docs/benchmarking.md）下载模型 → 起服务 → 实测 tok/s → 在 TUI 内直接提交 PR 回传数据，无需 gh CLI 与第三方账号；合并后同硬件用户会看到带 ✓ 的实测值。
• REST API 集成：/api/v1/system 与 /api/v1/models 两个端点可以把「硬件画像 → 模型选择」做成自动化决策链。
• 与同类工具组合：README 提到 llm-checker（Node.js CLI，走 Ollama 实测路线、不支持 MoE）——llmfit 估算 + Ollama 实测是互补组合。

参考链接

• 官方仓库
• TUI 使用指南
• 基准测试指南
• CLI 文档
• crates.io 发布页

最后更新：2026-09-19 · 作者：MagicNetWorld · 基于公开资料整理，关键数据经 GitHub API 独立实测核验，AI 辅助生成