llmfit

硬件感知的 local LLM model-fit analyzer：把“这台机器能跑什么、走 GPU/CPU/MoE 哪条路径、需要多少内存”变成 CLI/TUI/API 可查询的结果。

状态: active · 总分: 3.7/5 · 推荐度: 4/5

验证边界：本轮验证了 Rust 测试、REST API smoke test、Web production build 与 Python wrapper tests；没有实际下载/运行模型，没有 GPU/provider benchmark、distributed deployment 或 Tauri desktop build。网页 Vitest 在当前 jsdom 环境有 7 个 App 测试失败，不能把“代码可编译”误写成全栈测试通过 [Local:verification][Local:web]。

一句话总结

面向需要在本地工作站、节点或 agent runtime 中回答“哪些 LLM 适合这台硬件”的开发者，llmfit 是一个能力面很宽的 Rust model-fit / model-selection infrastructure；它提供估算和规划，不等于实际推理引擎或性能真值源 [GH:readme][Docs:how-it-works]。

总体评价

llmfit 的中心不是 agent orchestration，而是 hardware-aware model selection layer：检测 RAM、CPU、GPU/VRAM 与 backend，加载模型 catalog，计算 fit level、量化、运行路径、context 与速度估算，再通过 TUI、CLI/JSON、REST/Web、MCP、桌面端和 Python wrapper 暴露出去 [GH:architecture][Docs:cli]。

它把“模型能否运行”从凭经验猜测推进到可解释的估算：info 会展示 estimate basis，plan 反向回答目标模型需要何种硬件，bench 又允许用真实 tok/s/TTFT 校准公式，并将社区结果以 PR 形式回流 [Docs:how-it-works][Docs:benchmark]。这使它对 local LLM、coding agents、边缘节点和模型采购前的 capacity planning 都有价值。

但应保持边界意识：实际吞吐受模型格式、runtime、GPU driver、context、batch、KV cache 与 provider 状态支配；仓库当前仍年轻且变化快，issues 中已有估算偏高、provider detection、JSON contract 和文档命令错误等反馈 [GH:issues]。因此它适合做 第一轮筛选与规划器，不应单独充当 benchmark、scheduler 或生产 serving authority。

推荐度：4/5

定位：面向 local LLM 用户、agent/tooling 开发者、硬件评估者，以及需要对模型与节点做粗粒度 capacity planning 的工程师。

推荐度 4/5。它的价值集中且实际：跨平台硬件探测、动态 quant 选择、MoE/offload 分析、多 provider 发现、CLI/JSON 自动化、REST/MCP 集成和真实 benchmark 回流形成了完整的“选择→运行→测量→校准”闭环 [Docs:how-it-works][Docs:cli][Docs:providers][Docs:benchmark]。对于不知道“24 GB VRAM 到底能跑哪些模型”的用户，这比单纯浏览模型排行榜更有用。

不给 5 的原因也很明确：核心速度仍有公式/校准假设，模型 catalog 与 provider mapping 会持续变化；它不负责真正的高吞吐 serving、严格调度、权限治理或模型质量保证。当前 Web 测试失败、clippy warnings、无 SECURITY.md，以及 npm audit 的 critical/high 依赖告警，都要求在生产接入前做额外验证 [GH:local-scan][Local:verification][Local:web-audit]。

优势

1. 问题定义清楚：把硬件、模型参数、量化、context、fit 和 throughput 放进同一分析对象，直接回答本地模型选择问题 [Docs:how-it-works]。
2. 跨界面复用核心逻辑：Rust core 同时服务 CLI/TUI、REST API、MCP 与桌面端，减少各入口各算一套结果的风险 [GH:architecture]。
3. 运行路径覆盖广：支持 CPU-only、GPU、CPU offload、MoE offload、tensor parallel 等 fit path，并处理 unified memory、多 GPU 与多种 backend [GH:architecture][Docs:how-it-works]。
4. 自动化接口完整：recommend --json、plan、REST /api/v1/* 和 MCP tools 适合 agent、脚本和节点级集成 [Docs:cli]。
5. 估算可以被实测校准：bench 结果先本地保存，再可通过 device flow 贡献 PR；这比只发布不可复核的静态 tok/s 数字更诚实 [GH:readme][Docs:benchmark]。
6. 交付面丰富：有 Homebrew/Scoop/MacPorts/uv/pip、GHCR Docker、多平台 release、Web dashboard 和 Tauri desktop 路径 [GH:readme][GH:docker]。

劣势

1. 估算不是真实性能：没有实际 provider benchmark 时，带宽 roofline、backend constant 和经验系数只能作为先验；TTFT/prefill、并发与实际 kernel 行为不能由 fit 分数完整推出 [Docs:how-it-works][Local:verification]。
2. 项目仍在快速扩张：2026-02 创建，最新 release 已到 v1.1.10，但 commit/issue/PR 仍高频变化；接口和 catalog 需要版本 pinning 与回归测试 [GH:api][GH:release][GH:issues]。
3. 多入口增加维护面：Rust core、TUI、Axum API、React dashboard、Tauri、Python wrapper、MCP 和 Docker 同时存在，任何一层的 contract 漂移都可能影响另一层 [GH:architecture]。
4. Web 交付链存在断点：Dockerfile 没有构建 llmfit-web，缺少 dist 时 Rust build 可能嵌入 placeholder dashboard（本轮未对镜像运行验证）；本轮 Web build 虽成功，但 App Vitest 仍有 7 个失败 [GH:docker][GH:local-scan][Local:web]。
5. 安全治理不完整：未发现 SECURITY.md；网络 provider、模型下载、GitHub token/device flow、REST/MCP 与外部运行时均扩大攻击面 [GH:local-scan][Docs:cli][GH:advisories]。
6. 不是 serving/control plane：它可以启动/探测部分 runtime，也有 node-level REST，但不等于多租户 serving、严格 scheduler、quota、audit 或 SLA 系统。

---

适合什么场景

• 本地工作站、笔记本、VPS 或边缘节点上筛选可运行的 LLM。
• coding agent、RAG 或自动化工具接入 local model 前，先按硬件、use case、runtime 和 license 过滤 [Docs:cli]。
• 比较 GPU/CPU/RAM 升级对模型可运行性的影响，生成 plan 或 DRA ResourceClaim 草案。
• 管理 Ollama、llama.cpp、MLX、LM Studio、Docker Model Runner 等多个本地 provider 的模型发现和下载入口 [Docs:providers]。
• 需要把“模型推荐”暴露给 agent 的 CLI、REST 或 stdio MCP consumer。
• 研究 model-fit scoring、MoE active parameters、quantization hierarchy、KV cache 和硬件带宽估算。
• 先用公式筛选，再用 bench 实测并共享结果，形成同硬件的经验基线 [Docs:benchmark]。

不适合什么场景

• 把估算 tok/s 当成采购、SLA 或高并发生产容量的唯一依据；应在目标硬件和目标 runtime 上实测。
• 需要 vLLM/SGLang/TensorRT-LLM 类高吞吐 serving、continuous batching、严格多租户隔离或分布式调度的场景。
• 需要完整模型质量评测、prompt safety、数据治理、权限审计和 billing 的平台。
• 将 llmfit serve --host 0.0.0.0 或 MCP 接口直接暴露公网而没有认证、网络隔离、rate limit 和审计的场景。
• 不能接受 Hugging Face、Ollama、GitHub、localmaxxing 或其他 provider 网络依赖的离线环境；fit 本身可本地计算，但下载、provider 检测和 benchmark sharing 不是全离线。
• 只想要最简洁的模型运行入口的普通用户；Ollama 等 facade 通常比理解 fit、quant、context 和 runtime 选择更直接。

与类似项目对比

项目	定位	相对本项目
llama.cpp	portable local inference runtime / GGUF engine	真正负责模型执行、量化与 backend；llmfit 负责在运行前评估 fit，并可把 llama.cpp 作为 provider
Ollama	local model provider facade	更偏安装、pull、serve 和 API 易用性；llmfit 更偏跨硬件比较、规划、过滤与解释
vLLM	high-throughput GPU serving engine	更偏 datacenter/并发 serving；llmfit 是节点/个人硬件的 selection and planning layer

上述项目按 ai-programs/agent-infrastructure 同类范围做定位级对比，依据本地 wiki 既有条目的功能定位而非本轮重新深审；未按同一 10 维度框架重审，也不是 benchmark 或质量优劣结论 [WikiLocal:comparisons]。

它能做什么

能力评分 4/5。

• 检测硬件：读取 RAM、CPU、GPU/VRAM、unified memory、GPU backend 和多 GPU 信息；实现覆盖 NVIDIA、AMD、Intel、Apple Silicon、Ascend、Vulkan 等路径 [Docs:how-it-works][GH:architecture]。
• 构建模型 fit：按 quality、speed、fit、context 组成综合分数，选择合适 quantization，并区分 Perfect/Good/Marginal/Too Tight 与 GPU/CPU/MoE/offload/tensor-parallel run mode [Docs:how-it-works]。
• 模型 catalog 管理：嵌入模型 metadata，支持 Hugging Face 更新 cache、自定义模型、GGUF/MLX/预量化模型和 use-case/capability/license 过滤；当前 binary list --json 实际返回 11271 条 catalog entry [GH:architecture][Local:catalog]。
• 反向规划：plan 估计特定模型、context、quant 和 target TPS 所需的 VRAM/RAM/路径，并可生成 Kubernetes DRA claim [Docs:cli][GH:readme]。
• 多种交互面：默认 TUI、classic CLI、JSON/CSV、Axum REST API、React dashboard、stdio MCP server、Tauri desktop 和 Python binary wrapper [GH:architecture][Docs:cli]。
• provider 与下载：探测/连接 Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio，并在 TUI/CLI 中处理部分模型下载和 installed detection；代码还包含 vLLM/RamaLama integration surface [Docs:providers][GH:architecture]。
• 基准与质量实验：对运行中的 provider 测 tok/s/TTFT，可做 role-based quality/routing benchmark，并可将 benchmark 以 GitHub PR 分享 [Docs:cli][Docs:benchmark]。

能力不是 5/5：它覆盖了选择和规划的主要路径，但不替代 inference engine、完整 benchmark harness、quality evaluator、cluster scheduler 或 model-serving control plane。

运行环境与资源占用

场景	CPU	内存	存储	说明
list / search / plan	普通 CPU	预计低；由 catalog 与进程状态决定	不需要模型权重	本轮未做 RSS/CPU 测量；catalog 是 compile-time/cache 数据
TUI / fit / recommend / REST	普通多核 CPU；GPU 可选	主要由 catalog、fit 计算和 dashboard/provider 状态决定	二进制、配置和日志	对大 catalog 要关注启动与重算成本；具体数值未 benchmark
bench / provider 下载	CPU + 目标 GPU/accelerator	由模型权重、KV cache、context、offload 和 runtime 决定	GGUF/MLX/Ollama cache 可达数 GB 以上	这是模型运行成本，不是 llmfit 本体成本
Docker node probe	容器 CPU；GPU 可选	依模型与调用模式	image + optional model/cache volume	Dockerfile 的默认命令是 recommend --json，本轮未运行镜像 [GH:docker]

• 运行时：Rust 2024 workspace；TUI 使用 ratatui/crossterm，REST 使用 Axum/Tokio，MCP 使用 rmcp；Web 是 React 18/Vite，Python 包只是二进制 wrapper [GH:architecture]。
• 操作系统：README/CI/release 覆盖 Linux、macOS、Windows 及多种 release target；GPU detection 依平台工具和 driver [GH:readme][GH:ci]。
• Docker：Dockerfile 与多架构 workflow 表明 GHCR image 是支持的交付路径；本轮未实际 build/pull/run 镜像。Dockerfile 不构建 Web dist，TUI dashboard 可能落到 build.rs 的 placeholder，而不是完整 React dashboard [GH:docker]。
• GPU：非必需；CPU-only path 存在。GPU/VRAM 对大模型、速度和 Perfect fit 影响显著 [Docs:how-it-works]。
• 外部依赖：可选 Hugging Face、Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio、vLLM/RamaLama、GitHub device flow、localmaxxing benchmark API；fit 的纯本地子集不需要全部依赖 [Docs:providers][Docs:cli]。
• 估计性质：frontmatter 的 CPU/RAM/storage 仅为结构性估计；本轮没有对 cold start、RSS、binary size、Docker image、tok/s 或吞吐做测量 [Local:verification]。

性能评分 3/5。Rust/native architecture 和单机 fit 计算看起来合理，且 core 测试/API smoke 已通过；但项目的关键价值是对真实推理性能作估算，本轮未跑 GPU/provider benchmark，不能按 README 的公式解释升到 4 或 5 [Docs:how-it-works][Local:verification]。

上手体验

评分 4/5。

安装入口多，llmfit 默认 TUI，recommend --json、plan、system、doctor 和 serve 让脚本/agent 不必进入交互界面；文档也给出了硬件 override、use-case、runtime、license 和 API 示例 [GH:readme][Docs:cli]。这使新用户通常可以在较短时间内得到第一轮模型列表。

扣一分来自配置与边界：要理解 quantization、context/KV cache、provider、GPU driver 和 benchmark 才能正确解释结果；实际下载/运行仍需另行安装 Ollama、llama.cpp、MLX 等运行时。当前 issue #932 还显示 Termux/Android 文档把 global --memory 放在 subcommand 后，示例会直接失败 [GH:issues]。

代码质量

评分 4/5。

代码按 llmfit-core、llmfit-tui、llmfit-desktop 分层，fit/hardware/providers/plan/benchmark 等领域模块相对清楚；TUI、REST 和 MCP 复用 core 类型，Rust 测试覆盖硬件 parser、fit/plan、provider mapping、schema、CLI smoke 和 MCP JSON shape [GH:architecture][GH:local-scan][Local:verification]。本地 cargo test 实际通过 565 tests，REST helper 的 9 项检查也通过 [Local:verification]。

不给 5 的原因是跨语言 surface 增加 contract 风险：cargo clippy --all-targets --all-features 虽退出 0，但仍报 dead code、doc comment、too-many-arguments、complexity 和 style warnings；Web App 测试在当前 jsdom 环境有 7 个失败，且 Docker build path 不自动生成完整 Web assets [Local:verification][Local:web][GH:docker]。这更接近“结构好、核心测试扎实、仍有维护债务”的 4/5。

可扩展性

评分 4/5。

扩展面不是单一 plugin registry，而是多层 integration surface：llmfit-core 可被多个 front-end 调用；CLI 有 JSON/CSV；REST 有过滤、硬件 override、plan/download/status；MCP 有 get_system_specs、recommend_models、search_models、plan_hardware、runtime/model discovery tools；provider 模块和可选 NATS/DRA paths 也留下了适配点 [GH:architecture][Docs:cli]。

不给 5，是因为深度扩展通常需要 Rust 类型、model schema、fit formula、provider mapping 和 UI 同步修改；没有成熟的外部 plugin API，也没有把 scheduler、policy、quality evaluator 和 runtime abstraction 完全解耦。对 agent 来说，MCP/REST 已足够好用；对大规模平台来说仍可能需要 fork 或外围 service。

文档质量

评分 4/5。

README 提供英/中/日入口，docs 进一步拆出 how-it-works、TUI、CLI、benchmarking、providers、platform support、custom models、development 等主题；CLI/API、模型评分与 benchmark sharing 的关键概念都有示例 [GH:readme][Docs:how-it-works][Docs:cli][Docs:benchmark]。AGENTS.md 还给出架构、数据流、测试、依赖和贡献约定，便于源码学习 [GH:architecture]。

不给 5 的原因是文档与实现仍有漂移风险：#932 已记录 global flag 顺序错误；README.zh.md 的 dashboard 段落仍写默认绑定 0.0.0.0，而当前 main.rs 的默认值是 127.0.0.1；Dockerfile 也没有把 Web build 步骤写进镜像构建 [GH:issues][GH:local-scan][GH:docker]。总体是“覆盖面好、边界说明不少，但需随快速迭代持续校准”的 4/5。

社区与成熟度

维度	评分	说明
社区活跃度	4/5	API snapshot 为 33606 stars、2101 forks；最近推送到 2026-08-22，当前 open issues=51、open PRs=34；本地 shallow clone 的 HEAD 是 community benchmark results 相关提交 [GH:api][GH:commit][GH:issues][GH:contributors]
成熟度	3/5	仓库创建于 2026-02-15，已发布到 v1.1.10，测试与跨平台 CI 具备；但项目不足一年、feature surface 仍快速扩张，issue/PR 与 provider/catalog 变化要求 pinning 和回归验证 [GH:api][GH:release][GH:ci]

社区不能只看 star：contributors first page 的最高贡献者主要是维护者与 automation，公开生态仍处在迅速形成阶段 [GH:contributors]。因此 community 可以给 4，maturity 仍保守给 3；二者不可混为一谈。

安全与风险

评分 3/5。

有利面：默认 dashboard host 在当前 Rust CLI 代码中是 127.0.0.1；download/status/plan REST endpoints 对非 loopback 请求返回 403；Unix socket path 使用 0660；文件名、provider URL 和硬件 parser 有测试覆盖 [GH:local-scan][Local:verification]。Dockerfile 也使用 non-root llmfit 用户 [GH:docker]。

主要风险：

• provider integration 会访问本地或远程 Ollama/LM Studio/Docker Model Runner/vLLM/llama.cpp endpoint，并可发起模型下载；--host 0.0.0.0 会把服务面扩大到网络。
• bench --share 使用 GitHub device flow 或 token，能 fork/commit/open PR；token cache、PR payload 和 benchmark metadata 需要按凭据与隐私边界管理 [Docs:cli][Docs:benchmark]。
• MCP stdio、REST API、外部 runtime process 和模型下载组合后，llmfit 不应被当作 sandbox 或 permission gateway。
• 当前 clone 没有 SECURITY.md；GitHub repository advisories endpoint 本轮为空，但 npm audit 对 Web dependency tree 报告 9 个漏洞（含 1 critical、4 high），应分别跟踪 dev dependency 与实际发布面 [GH:local-scan][GH:advisories][Local:web-audit]。
• MIT 只说明 repository code 的授权；Hugging Face/GGUF/MLX/model weights、tokenizer 和 benchmark data 的 license 仍需按具体资产核验 [GH:readme]。

因此 security=3/5：存在一些明确的 local-only/loopback/validation guard，但缺乏完整 security process，且外部服务、凭据、模型文件和 Web dependency 的风险不能被“无 GHSA”抵消。生产建议是 pin release/hash、默认 loopback、反代认证、限制 egress 与 download、隔离 provider credentials、谨慎启用 share/MCP，并对真实模型资产做 license/供应链审查。

学习价值

学习价值很高，尤其适合研究“模型选择不是字符串匹配，而是一个带硬件约束的估计问题”。它把 hardware detection、memory accounting、quantization hierarchy、MoE active parameters、KV cache/context、bandwidth-based throughput、provider discovery、REST/MCP contracts 和 benchmark calibration 串成一个可读的 Rust 项目 [GH:architecture][Docs:how-it-works]。

对 Develata 的工程与数学兴趣而言，值得重点看三条线：一是 fit level 与 resource feasibility 的状态划分；二是估算模型如何暴露假设、接受本地实测校准；三是同一 core state 如何被 CLI、TUI、HTTP、MCP、desktop 和 Python wrapper 多次投影。它未必是“最终生产平台”，却是观察 local AI infrastructure 如何从 heuristic 走向 evidence loop 的好样本。