Skip to main content
Glama

FitLLM Engine

npm conformance license zero deps

npx fitllm — one-line fit verdict with the full memory breakdown

Онлайн: 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, вместо того чтобы просить вас знать свой VRAM. Код выхода 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), GPU NVIDIA (RTX 20/30/40/50, рабочая станция RTX 6000 Ada / RTX PRO 6000, датацентр A100/H100/H200/B200), AMD Radeon (RX 7000/9000, PRO W7900) и пресеты multi-GPU (2×3090, 2×4090, 4×3090) — с квантованием весов GGUF Q-tier, отделённым от квантования 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 годов:

Модель

Что наивные формулы упускают

Наивный KV

FitLLM KV

Ошибка в

Gemma 4 31B @131K, 8-bit

50 из 60 слоёв — со скользящим окном (хранят только последние 1024 токена); 10 глобальных слоёв используют другую форму головок (4 KV-головы × 512, а не 16 × 256)

~60 GB

~5.4 GB

11×

Qwen 3.6 27B @131K, 8-bit

48 из 64 слоёв — линейное внимание (Gated DeltaNet) — без растущего KV-кэша

~16 GB

~4 GB

Qwen 3.8 27B @256K, F16 KV

та же форма, новейшее поколение: KV живёт только на 16 из 64 слоёв

64.0 GiB

16.0 GiB

GLM-4.7-Flash @128K, bf16

MLA: K/V сжаты в один общий латент (512+64 измерений, кэшируется один раз — не по-головные K и V)

~117 GB

~6.6 GB

17.8×

Обычный плотный (Llama, Mistral…)

ничего — стандартный трансформер

same

same

1× ✅

Ошибка в 11× меняет вердикт: наивный калькулятор говорит, что Gemma 4 31B не поместится в 64 ГБ при длинном контексте, хотя она помещается с комфортом.

Пять вещей, которые они игнорируют

  1. Внимание со скользящим окном (Gemma 2/3/4, gpt-oss): большинство слоёв хранят только последние N токенов, поэтому их 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 × головы × head_dim» завышают на порядок. Проверено по статье DeepSeek-V2 (arXiv:2405.04434) и официальному коду инференса DeepSeek-V3.

  4. Гетерогенные размерности голов + MoE: глобальные слои могут использовать другой head_dim (Gemma 4: 512 против 256). MoE держит в памяти каждого эксперта, активируя лишь несколько на токен.

  5. PLE — послойные эмбеддинги (Gemma 4 e2b/e4b): llama.cpp по умолчанию хранит тензор per_layer_token_embd в системной RAM независимо от -ngl (принудительное размещение на CUDA вызывает сбой для K-quant GGUF; только non-K квантизации могут включить — ggml-org/llama.cpp#14430), поэтому только веса без PLE требуют VRAM. Подсчёт всех 5,1B параметров против GPU переоценивает резидентные веса e2b примерно в ~1,9× и меняет вердикты для малых карт. На Apple Silicon системная RAM является памятью ускорителя, поэтому общие параметры там остаются корректными. (Оговорки: vLLM загружает PLE полностью на GPU — математика этого движка для GPU привязана к поведению по умолчанию GGUF/llama.cpp, из которого взяты его уровни квантования; измерения резидентности взяты из стека PLE серии E, и прямое измерение на GGUF Gemma 4 приветствуется в issue #7.)

Этот движок моделирует каждый тип слоя отдельно, проверено по официальным файлам 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 в описанную выше форму модели. (Никакого предсказания токенов/с — намеренно: скорость зависит от рантайма/бэкенда так, что статическая модель не может честно это утверждать. Вместимость — проверяемое утверждение; скорость — нет.)

Использование

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-bit ≈ 54 GB (соответствует реальным локальным запускам).

  • Стоимость MLA на токен: GLM-4.7-Flash = (512 + 64) × 2 B × 47 слоёв = 54,144 B/токен — зафиксировано конформными векторами.

Все цифры — оценки; реальное использование зависит от рантайма (MLX/Ollama/llama.cpp), состояния ОС и схемы квантования.

Конформные векторы

vectors/fit-vectors-v1.json закрепляет 16 языконезависимых тестовых векторов (точные байты KV, стоимость на токен, вердикты о вместимости), выведенных вручную из официальных значений config.json — например, «Gemma 4 31B при 262,144 ctx, bf16 = ровно 22,313,697,280 байт». Любая реализация на любом языке соответствует стандарту, если все векторы проходят — запустите нашу с помощью node vectors/run.mjs.

Почему это важно: формулы легко скопировать; проверенный ключ ответов — нет. Если вы портируете этот движок на Python, Rust или Go, вы не становитесь недоверенным форком — пройдите векторы, и вы конформная реализация того же стандарта. Портировать движок — сохранить векторы.

Fit Census — каждая модель × каждое устройство, одна таблица истинности

census/ содержит более 8 000 вердиктов (24 модели, включая черновой уровень × 88 GPU/Mac × уровни квантования), вычисленных этим движком — в формате CSV/JSON, которые можно импортировать, строить графики или цитировать, плюс стартовая матрица («самая большая модель, которая комфортно помещается на устройство»). Перегенерируйте сами: npm run census. Реальные измерения попадают рядом с предсказаниями через PR в fixtures/предсказано против измеренного, публично.

Встраиваемый бейдж вместимости

Покажите, запускается ли модель на данном оборудовании — вживую из движка, одной строкой в любом README или карточке модели:

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

fits

Параметры: model (имя, нечёткое), gpu (имя, нечёткое) или ram (ГБ, унифицированная память Apple), опционально quant (уровень GGUF / 4|8|16), ctx, kv. Цвет вердикта: зелёный — помещается · жёлтый — впритык · красный — не поместится.

Зачем встраивать? Вопрос №1 под каждой карточкой модели и руководством по локальному ИИ — «запустится ли это на моей машине?». Бейдж отвечает вживую из движка — пересчитывается при обновлении данных, а не устаревшее утверждение, замороженное в вашем README. Если вы публикуете модели или пишете руководства: одна строка заменяет целый абзац FAQ и сокращает проблемы «у меня OOM на 8GB карте» до их появления.

Спросите вашего ИИ-ассистента (MCP)

Движок работает как публичный MCP-сервер по адресу https://fitllm.run/api/mcp — подключите его один раз, и ваш ассистент ответит на вопрос «могу ли я запустить X на моём Y?» с помощью математики этого движка, а не догадок из устаревших обучающих данных (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 (вердикт + полная разбивка памяти + предложение по исправлению — поддерживает multi-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 Census (более 8 000 вердиктов, CC0) на fitllm.run/data и на Hugging Face Datasets. Попробуйте движок в браузере: демо HF Space.

Принципы

Без рекламы. Без входа. Без партнёрских ссылок. Результат никогда не продаётся. Вместимость — достижимое, проверяемое утверждение; сырые ток/с — нет — поэтому этот движок отказывается от предсказаний скорости, а не выдаёт догадку за точность.

Помогите с калибровкой

Запускали модель и измерили реальную пиковую память? Сообщите об измерении — это улучшит оценки для всех.

Создано

yonghaGitHub. Питает fitllm.run.

Лицензия

MIT © click6067-ship-it

Related MCP Connectors

Related MCP Servers