学习中经常取得成功可能会导致更大的学习兴趣，并改善学生作为学习的自我概念。—— 布鲁姆

llmfit：让本地大模型选择不再靠猜

项目地址：https://github.com/AlexsJones/llmfit

本地运行大语言模型这件事，常常从一个看似简单的问题开始：

我的电脑，到底能跑什么模型？

但真正面对这个问题时，答案很少是一句型号名称就能说清的。内存容量、CPU、GPU、显存、后端、模型架构、量化方式、上下文长度、推理速度，这些因素会在同一台机器上彼此交织。一个模型也许能装进内存，却未必有令人满意的速度。一个模型也许运行很快，却未必适合当前的任务。一个模型看起来参数规模合适，却可能因为上下文或硬件条件而失去实际意义。

llmfit 正是为这类选择而生的终端工具。

它面向数百个模型与提供方，通过一条命令帮助用户寻找能够在当前硬件上运行的模型。llmfit 会检测系统的 RAM、CPU、GPU 与显存条件，再从内存适配度、预估速度、质量和上下文四个维度为模型评分，最终给出适合当前机器的模型选择。

它不是让用户先记住一长串模型名称，再逐个下载、运行、观察结果。它更像一个站在终端里的硬件观察者：先看看机器拥有怎样的资源，再把模型目录铺开，让适合的候选项浮现出来。

从硬件出发，而不是从模型热度出发

选择本地模型时，人们很容易先问哪个模型更强、哪个模型更流行、哪个模型参数更多。

llmfit 提出的入口则不同。它首先关注的是硬件。

工具会检测本机的 RAM、CPU、GPU、VRAM 与后端信息。随后，它会针对目录中的每个模型进行评估，并从四个方向给出评分：

内存适配度
预估速度
质量
上下文

内存适配度回答的是模型是否能与当前系统资源相匹配。

预估速度回答的是模型在当前硬件上可能具备怎样的生成速度。

质量维度用于衡量模型在目录中的质量表现。

上下文维度则关注模型能够承载的上下文能力。

这四个方向并不会被拆开孤立呈现。llmfit 将它们放在同一个排序与推荐过程里，让模型选择不只停留在能不能运行，还能够进一步进入好不好用、快不快、适不适合的层面。

交互式 TUI：把机器与模型放到同一张视野里

直接运行 llmfit，会进入交互式终端界面。

llmfit

这是 llmfit 默认提供的 TUI 模式。

在这个界面中，用户能够在顶部看到已经检测到的硬件规格，同时查看全部模型围绕适配度、速度、质量和上下文所得出的评分。机器的资源条件与模型的排序结果被放在同一片终端视野中，原本需要来回比对的内容被集中起来。

TUI 并不只是一个静态列表。README 中列出的相关能力包括导航、规划、模拟、下载、社区基准测试以及提供方相关操作。模型、硬件与运行条件不再只是分散在不同工具中的零碎信息，而是成为一个可以浏览和比较的交互界面。

当本地模型的选择空间不断扩大时，终端界面里的排序和评分能够帮助用户先缩小范围。用户不必从完整目录中盲目翻找，而可以先看到更适配当前硬件的候选项。

经典 CLI：为脚本、自动化与智能体准备

除了默认的交互式 TUI，llmfit 也提供传统的命令行模式。

对于脚本、自动化流程和智能体而言，终端输出与 JSON 往往比交互界面更合适。llmfit 为这些场景准备了多个命令。

查看全部模型并按适配度排序：

1	llmfit fit

获取推荐模型的 JSON 输出：

1	llmfit recommend --json

查看某一个模型的适配分析、估算依据与验证命令：

1	llmfit info "<model>"

测试正在运行的提供方，测量真实的 tok/s 与 TTFT：

1	llmfit bench

生成硬件检测报告，用于问题报告：

1	llmfit doctor

这些命令让 llmfit 的工作方式具有两种表情。

在交互式场景中，它是一块能够浏览、筛选和比较模型的终端面板。

在自动化场景中，它是一组可以输出排序表、JSON、单模型分析、基准数据与硬件报告的命令。

同一个工具既可以帮助人做判断，也可以将结果交给脚本和智能体继续处理。

多 GPU、MoE 与动态量化选择

硬件环境并不总是单一的。

llmfit 支持多 GPU 配置，也支持 MoE 架构，并提供动态量化选择与速度估算能力。它并不把模型选择限定在简单的单 GPU 或固定量化条件下，而是将这些因素纳入适配与推荐过程。

多 GPU 环境意味着可用计算资源可能分布在多个 GPU 上。

MoE 架构意味着模型本身拥有不同于普通密集模型的结构特征。

动态量化选择意味着模型的量化条件可以参与模型与硬件之间的匹配。

速度估算则让用户在真正运行模型之前，就能够获得与当前硬件相关的性能判断。

这些能力共同指向同一件事：本地模型选择不是只看一个参数规模，而是要让模型、量化、硬件和运行方式彼此对齐。

连接本地运行时提供方

llmfit 支持本地运行时提供方，包括 Ollama、llama.cpp、MLX、vLLM、LM Studio、Jan 等。

本地模型环境往往不是单一运行方式。用户可能已经在某个提供方中运行模型，也可能希望在不同后端之间比较与验证。llmfit 将这些本地运行时提供方纳入支持范围，使模型推荐、速度估算与真实基准测试能够与本地运行环境形成连接。

当某个提供方正在运行模型时，bench 命令能够用于测量真实的 tok/s 和 TTFT。

1	llmfit bench

tok/s 反映每秒生成 token 的速度。

TTFT 则是首次 token 的时间。

估算能够帮助用户在下载和运行前做选择，而真实基准测试则让模型在实际硬件与实际提供方中交出运行数据。两者之间不是彼此替代，而是前后衔接：先根据硬件得到推荐与估算，再针对正在运行的模型测量真实结果。

从预估走向真实数字

llmfit 的一个重点，是让模型速度不只停留在推测中。

工具可以下载模型、启动服务，并测量当前机器上的真实 tok/s。用户能够将这些结果贡献到社区基准测试数据中，让来自不同机器的实测数字参与后续估算。

社区基准测试通过下面的命令发起：

1	llmfit bench --all --share

这个过程会运行基准测试，展示将要提交的 JSON 数据，并在获得确认后创建一个添加结果文件的拉取请求。过程不要求使用 gh 命令行工具。

如果用户运行基准测试时没有选择共享，结果会保留在本地存储中。之后再次执行共享命令时，本地积累的结果可以一并提交。拒绝共享不会导致本地基准数据被丢弃。

如果只想预览将要提交的内容，而不联系 GitHub，可以使用：

1	llmfit bench --all --share --dry-run

这套机制让基准数据的流动拥有明确的节奏。

先在本机测量。

再查看准备提交的数据。

确认之后再发起提交。

如果暂时不共享，数据仍然留在本地。

真实数字不会因为用户暂时不提交而消失，它们可以继续等待后续的共享操作。

社区基准如何进入下一次发布

社区基准测试结果会按照硬件进行命名空间划分，并使用带内容哈希的文件名保存。

目录结构如下：

1
2
3

community/
  <hardware-slug>/
    <unix-timestamp>-<hash>.json

这种组织方式让不同硬件的结果各自归位，也让并发提交不会因为文件名冲突而彼此碰撞。

每个文件名会映射贡献者本地存储中的条目。若贡献者已经有一个开放的基准测试拉取请求，新的结果会被追加到同一个拉取请求中，而不是再开启一个新的拉取请求。若某次提交在部分完成后重试，已经成功提交的文件会被跳过，避免重复。

在结果合并之后，社区提交的数据会由 llmfit-core/build.rs 聚合，并嵌入二进制文件。后续发布版本会包含这些已经合并的社区结果。

对于拥有相同 CPU 和 GPU 的用户，社区实测数据能够在基准页面中显示为 llmfit community，并为已测试的模型提供实测 tok/s。对于其他模型，llmfit 也能够以这些实测结果为锚点给出校准后的估算。

这让一个用户机器上的真实测量，不只停留在那一次终端执行中。它能够进入下一次发布，让拥有相同硬件组合的其他用户在尚未亲自进行基准测试前，就获得来自相同硬件的参考数字。

社区数据也需要经过校验

社区基准结果并不是任意格式的数据都可以进入仓库。

每个涉及社区基准目录的拉取请求，都会运行 Community Benchmarks 工作流。该工作流会检查 schema 一致性、路径与命名约定，以及跨字段的合理性检查。

检查内容包括：

是否符合 schema.json
文件路径是否符合约定
文件名是否符合约定
tok/s 的排序是否合理
硬件范围是否合理
提交时间戳是否合理

手工提交的结果也可以被接受，但需要通过与自动生成结果相同的校验。

基准数据示例中包含了工具版本、硬件类别、硬件名称、显存容量、GPU 数量、统一内存状态、CPU、CPU 核心数、系统内存、操作系统，以及模型、提供方、运行次数、平均 tok/s、最小 tok/s、最大 tok/s、平均 TTFT、平均总耗时与平均输出 token 数等信息。

模型速度并不只是一个单独数字。它总是与硬件、提供方、运行次数和测试结果一起存在。llmfit 的社区基准格式把这些背景信息一并保留下来，让测量结果拥有更完整的上下文。

多种安装方式，进入同一个终端工具

llmfit 提供多种安装方式，覆盖 Windows、macOS、Linux、Python 工具环境、容器环境与从源码构建的路径。

Windows 可以通过 Scoop 安装：

1	scoop install llmfit

macOS 与 Linux 可以通过 Homebrew 安装预构建二进制：

1	brew install AlexsJones/llmfit/llmfit

也可以使用 homebrew-core formula：

1	brew install llmfit

MacPorts 安装方式如下：

1	port install llmfit

如果使用 uv，可以安装或更新 llmfit：

1	uv tool install -U llmfit

也可以不安装直接运行：

1	uvx llmfit

容器环境中，llmfit 可以通过 Docker 或 Podman 运行。Docker 默认会输出 llmfit recommend 命令的 JSON 结果：

1	docker run ghcr.io/alexsjones/llmfit

也可以将推荐结果交给 jq 继续查询：

1	podman run ghcr.io/alexsjones/llmfit recommend --use-case coding \| jq '.models[].name'

如果希望在容器中启动交互式 TUI，可以传入全局 --tui 参数：

1	docker run --rm -it ghcr.io/alexsjones/llmfit --tui

对于希望从源码构建的人，README 提供了基于 Cargo 的构建流程：

1
2
3

git clone https://github.com/AlexsJones/llmfit.git
cd llmfit
cargo build --release

构建完成后，二进制文件位于：

1	target/release/llmfit

不同安装路径最终通向的是同一个目标：在终端中启动 llmfit，让它读取当前机器的硬件条件，并开始筛选与排序模型。

本地 Web 仪表盘

llmfit 仓库中还包含 llmfit-web，这是 llmfit 本地 Web 仪表盘的 React 与 Vite 前端。

开发环境可以通过以下命令启动：

1 2	npm ci npm run dev

Vite 会运行在本地地址 http://127.0.0.1:5173，并将 /api/ 请求代理到 http://127.0.0.1:8787。

构建前端则使用：

1	npm run build

构建结果会输出到 llmfit-web/dist，并在编译时被嵌入 llmfit serve。

这让 llmfit 不只拥有终端中的 TUI 与经典 CLI，也具备本地 Web 仪表盘所需的前端部分。模型推荐、硬件识别与本地服务之间，于是又多出一种界面形态。

从模型目录到真实运行的一条路径

llmfit 的流程可以被理解为一条连续的路径。

先检测硬件。

再查看模型目录。

随后根据内存、速度、质量与上下文进行评分。

从评分中选出候选模型。

进一步查看单模型的适配分析与估算依据。

在本地运行时提供方中启动模型。

测量真实 tok/s 与 TTFT。

最后，如果愿意，将真实数据贡献给社区基准。

这条路径将模型选择从模糊的经验判断，推进到与机器条件、估算结果和实测数据相连接的过程。

对于刚开始接触本地模型的人，llmfit 可以先回答当前硬件适合什么。

对于正在比较模型的人，llmfit 可以展示多个维度的排序。

对于需要脚本与智能体消费结果的人，llmfit 可以输出 JSON。

对于已经启动本地提供方的人，llmfit 可以测量真实运行速度。

对于愿意共享基准数据的人，llmfit 还能把一次机器上的测试，变成后续发布版本中可被相同硬件用户使用的社区数据。

让本地模型选择回到机器本身

本地大模型的世界并不缺少模型名称，也不缺少参数规模、量化格式和后端选项。真正困难的部分，是如何把这些内容带回一台具体机器上。

这台机器有自己的内存，有自己的 CPU，有自己的 GPU 与显存，也有自己已经运行的提供方和实际速度。

llmfit 从这台机器出发。

它不要求用户先成为模型目录专家，再去猜测哪些模型可能适合。它先读取硬件，再将数百个模型与提供方放入评分、排序、估算与测量的流程中。

当本地模型的选择从一句模糊的推荐，变成内存适配度、预估速度、质量、上下文、真实 tok/s 与 TTFT 共同构成的判断时，模型终于不再只是远处的名字。

它们开始与眼前这台机器，真正发生关系。