FitLLM Engine

在线：https://fitllm.run · 双语 · 免费 · 无广告 · 无需登录

开源引擎： fitllm-engine (MIT · npm fitllm-engine · npx fitllm)

零依赖。一个可读文件：engine.js。通过一致性向量测试。MIT。

npx fitllm "GLM-4.7-Flash" --gpu 4090     # ✓ FITS — 21.9/24 GB, free 2.1 GB
npx fitllm "gpt-oss-120b" --mac 64        # ✗ WON'T FIT → what to change to make it fit
npx fitllm "Qwen 3.6 35B" --gpu "5090 + 3090"   # multi-GPU rig — VRAM pools (56GB), even mixed cards
npx fitllm --top --detect                 # what CAN this machine run? — best quant per model
npx fitllm --detect                       # reads this machine's real hardware

为什么用 CLI？ “能跑吗？”这个问题诞生于终端——在 ollama pull 之前的一行。无需安装，无需切换标签页，它通过 --detect 读取你的实际硬件，而不是让你知道自己的显存。退出码 0/1 使其成为下载前守卫：

# in your model-pull script — stop BEFORE the 40 GB download:
npx fitllm "gpt-oss-120b" --detect || { echo "won't fit — aborting pull"; exit 1; }

这是 FitLLM 的开放计算核心。数学是开放的，你可以审计它。

问 LLM “Qwen 3.6 能装进我的 GPU 吗？”它会根据训练截止时的架构进行模式匹配——通常回答不。基于目录的计算器滞后于新版本。FitLLM 实时读取每个模型的官方 config.json，因此在发布当天以及朴素公式会出错的混合 / 滑动窗口 / MoE 架构上都是正确的。

涵盖 Apple Silicon 统一内存（M1–M5，Pro/Max/Ultra——最高 512GB Mac Studio）、NVIDIA GPU（RTX 20/30/40/50，工作站 RTX 6000 Ada / RTX PRO 6000，数据中心 A100/H100/H200/B200）、AMD Radeon（RX 7000/9000，PRO W7900）以及多 GPU 预设（2×3090，2×4090，4×3090）——GGUF Q 级权重量化与 KV 缓存量化分开处理。每个硬件数字都经过**≥2 个独立来源**交叉验证（来源 URL 嵌入在 engine.js 中的每个值中）。

为什么大多数 LLM 内存计算器是错误的

几乎每个“我能运行这个 LLM 吗？”的计算器都用教科书公式估算 KV 缓存：

KV ≈ 2 × num_layers × num_kv_heads × head_dim × context_length × bytes

这假设**每一层都保留一个具有统一头形状的全上下文 KV 缓存。**对于 Llama-1/2 是正确的——但对于大多数 2025–2026 模型是错误的：

11 倍的误差会翻转结论：朴素计算器说 Gemma 4 31B 在长上下文下装不进 64 GB，而它轻松装下。

他们忽略的五件事

1. 滑动窗口注意力（Gemma 2/3/4，gpt-oss）：大多数层只保留最后 N 个 token，因此它们的 KV 停止增长。只有全局层随完整上下文扩展。

2. 混合 / 线性注意力（Qwen 3.6 / 3.8，许多 2026 模型）：线性注意力层使用固定大小的循环状态，而不是增长的 KV 缓存。该状态也被建模为独立组件（linearState）——它是每个序列的常量，因此永远不会使上下文曲线膨胀。

3. MLA——多头潜在注意力（GLM-5.2，GLM-4.7-Flash，DeepSeek 系列）：缓存是一个跨所有头共享的低秩潜在变量（kv_lora_rank + RoPE 维度）——每个头的“2 × 头数 × 头维度”公式会高估一个数量级。已根据 DeepSeek-V2 论文（arXiv:2405.04434）和官方 DeepSeek-V3 推理代码验证。

4. 异构头维度 + MoE：全局层可以使用不同的 head_dim（Gemma 4：512 对 256）。MoE 将每个专家保留在内存中，而每个 token 只激活少数几个。

5. PLE——逐层嵌入（Gemma 4 e2b/e4b）：llama.cpp 默认将 per_layer_token_embd 张量保留在系统 RAM 中，无论 -ngl 如何（对于 K 量化 GGUF，强制将其放到 CUDA 会崩溃；只有非 K 量化可以选择——ggml-org/llama.cpp#14430），因此只有非 PLE 权重需要显存。将所有 5.1B 参数计入 GPU 会高估 e2b 的驻留权重约 ~1.9 倍，并翻转小卡结论。在 Apple Silicon 上，系统 RAM 就是加速器内存，因此总参数在那里保持正确。（注意事项：vLLM 将 PLE 完全加载到 GPU 上——本引擎的 GPU 数学以默认 GGUF/llama.cpp 行为为基础，其量化层级来自该行为；驻留测量来自 E 系列 PLE 堆栈，欢迎在 issue #7 中对 Gemma 4 GGUF 进行直接测量。）

该引擎分别对每种层类型建模，并已根据官方 HuggingFace config.json 文件验证。

Related MCP server: VisualAI MCP Server

它计算什么

Total = Parameters (quantization-adjusted)
      + KV cache (per layer kind: sliding / global / linear / dense)
      + Runtime overhead (quant metadata + KV block padding + activations + fixed)
      + macOS base (Apple Silicon unified memory)

加上一个 parseHfConfig()，可将任何 HuggingFace 配置转换为上述模型形状。（没有 token/s 预测——这是故意的：速度取决于运行时/后端，静态模型无法诚实声称。适配是可验证的声明；速度不是。）

用法

import { simulate, LOCAL_MODELS, parseHfConfig } from './engine.js';

const model = LOCAL_MODELS.find((m) => m.name === 'Gemma 4 31b');
const sim = simulate(model, /*ram*/ 64, /*ctx*/ 131072, /*bits*/ 8);
// → { used, free, verdict: 'yes'|'tight'|'no', param, kv, rt, os, maxContext, ... }

// any HuggingFace model:
const m = parseHfConfig('Qwen/Qwen3-32B', configJson, totalSizeBytes);

验证

• 架构值已根据官方 HuggingFace config.json 检查。

• Gemma 4 31B 全上下文 KV 重现 20.78 GiB，与已发布的架构分析一致。手动重现：

global: 10 layers × 2(K,V) × 4 heads × 512 dim × 2 B × 262,144 = 21,474,836,480 B
local:  50 layers × 2(K,V) × 16 heads × 256 dim × 2 B × 1,024  =    838,860,800 B
total = 22,313,697,280 B ÷ 1024³ = 20.78 GiB

• 校准：Qwen 3.6 35B-A3B @128K，8 位 ≈ 54 GB（与真实本地运行匹配）。

• MLA 每 token 成本：GLM-4.7-Flash = (512 + 64) × 2 B × 47 层 = 54,144 B/token——由一致性向量固定。

所有数字都是估计值——实际使用因运行时（MLX/Ollama/llama.cpp）、操作系统状态和量化方案而异。

一致性向量

vectors/fit-vectors-v1.json 固定了 16 个语言无关的测试向量（精确的 KV 字节、每 token 成本、适配结论），这些向量是根据官方 config.json 值手工推导的——例如 “Gemma 4 31B 在 262,144 上下文，bf16 = 恰好 22,313,697,280 字节”。任何语言的任何实现，只要每个向量通过，就符合标准——使用 node vectors/run.mjs 运行我们的实现。

为什么这很重要：公式很容易复制；但经过验证的答案键不是。如果你将此引擎移植到 Python、Rust 或 Go，你不会成为不可信的 fork——通过向量，你就是同一标准的符合实现。移植引擎，保留向量。

Fit 普查——每个模型 × 每个设备，一张真值表

census/ 包含 8,000+ 条结论（24 个模型，包括草稿层 × 88 个 GPU/Mac × 量化层级），由该引擎计算——以 CSV/JSON 格式提供，可导入、绘图或引用，外加一个入门矩阵（“每个设备上舒适容纳的最大模型”）。自行重新生成：npm run census。真实世界测量通过 fixtures/ PR 与预测并列——预测与实测，公开进行。

嵌入适配徽章

显示模型是否能在给定硬件上运行——实时来自引擎，任何 README 或模型卡中的一行：

![fits](https://img.shields.io/endpoint?url=https%3A%2F%2Ffitllm.run%2Fapi%2Fbadge%3Fmodel%3DGLM-4.7-Flash%26gpu%3D4090)

参数：model（名称，模糊），gpu（名称，模糊）或 ram（GB，Apple 统一内存），可选 quant（GGUF 层级 / 4|8|16），ctx，kv。结论颜色：绿色适配 · 黄色紧张 · 红色不适用。

为什么嵌入它？*每个模型卡和本地 AI 教程下的头号问题是“它能在我的机器上运行吗？”*徽章实时从引擎**回答——数据更新时重新计算，而不是冻结在 README 中的过时声明。如果你发布模型或编写指南：一行替换整个 FAQ 段落，并在“我的 8GB 卡上 OOM”问题提交之前就减少它们。

询问你的 AI 助手（MCP）

该引擎作为公共 MCP 服务器运行在 https://fitllm.run/api/mcp——连接一次，你的助手就会用该引擎的数学回答*“我能在我的 Y 上运行 X 吗？”*，而不是根据过时的训练数据猜测（LLM 经常弄错 KV 缓存数学——见上面 17.8× 的表）。

• Claude（网页 / 桌面 / 移动）：设置 → 连接器 → 添加自定义连接器 → 粘贴 https://fitllm.run/api/mcp

• Claude Code：claude mcp add --transport http fitllm https://fitllm.run/api/mcp

• Cursor / Windsurf：添加到 mcp.json → { "mcpServers": { "fitllm": { "url": "https://fitllm.run/api/mcp" } } }

• ChatGPT：设置 → 应用 → 高级 → 开发者模式 → 添加 MCP 服务器（Plus/Pro）

工具：check_llm_fit（结论 + 完整内存分解 + 修复建议——支持多 GPU 配置，如 "RTX 5090 + RTX 3090"），what_fits_on_hardware（针对你的机器的排名列表），list_supported。资源：fitllm://models，fitllm://hardware，fitllm://census，fitllm://engine。有意开放：只读、无状态、无认证、无秘密——每次调用都是公共数据的纯函数。

列于：官方 MCP 注册表（run.fitllm/fitllm）· Glama · mcp.so · Smithery

面向代理和脚本——纯 HTTP API

没有 MCP 客户端？一个 GET，无需认证，无需密钥——默认 JSON，curl 用纯文本：

curl 'https://fitllm.run/api/check?model=gemma%204%2031b&gpu=4090'
# multi-GPU rigs: gpu=5090%2B3090 · Mac: ram=64 · usage: curl https://fitllm.run/api/check

开放数据：完整的 Fit 普查（8,000+ 条结论，CC0）位于 fitllm.run/data 和 Hugging Face Datasets。在浏览器中试用引擎：HF Space 演示。

原则

**无广告。无需登录。无联盟链接。输出永不出售。**适配是一个可赢得、可验证的声明；原始 tok/s 则不是——因此该引擎拒绝速度预测，而不是将猜测伪装成精确。

帮助校准

运行过模型并测量了实际峰值内存？报告测量结果——它将改善每个人的估计。

由谁构建

yongha — GitHub。为 fitllm.run 提供支持。

许可证

MIT © click6067-ship-it