Сравнил предсказания калькулятора с реальными запусками llama.cpp на RTX 4060 Ti, 3090 и Apple M2 Pro. Спойлер: где-то точно, где-то мимо на 30%
Когда я начал ковыряться с локальными LLM полгода назад, главная боль была не в установке моделей, а в понимании, что вообще влезет в моё железо. Документация Hugging Face говорит «Llama 3.1 8B». Что это значит для моей видеокарты с 16 GB VRAM? А если я хочу 32k контекст? А с квантованием Q4_K_M? Цифры в README часто не учитывают KV cache, который при больших контекстах ест VRAM сильнее, чем сама модель.
Несколько недель назад мне попался простой open-source калькулятор — whatmodelscanirun.ru (русскоязычный форк оригинального проекта whatmodels от BenD10, MIT-лицензия). Вводишь VRAM, выбираешь модель, видишь, влезет ли. Внутри — нетривиальная математика: учитывается размер весов, KV cache по слоям, GQA-оптимизация, memory bandwidth для оценки tokens/sec. Я решил проверить, насколько точные прогнозы он даёт, прогнав его на трёх своих сетапах и сравнив с реальными запусками через llama.cpp и Ollama.
Заодно разобрался, как калькулятор работает внутри. Это интересный пример того, как простой статический SvelteKit-сайт реализует довольно серьёзную математику по оценке возможностей железа.
Что это и кому нужно
Оригинальный проект называется whatmodels, автор — BenD10. Один разработчик, MIT-лицензия, 57 коммитов, последнее обновление данных по моделям — апрель 2026. На английском доступен на whatmodelscanirun.com, на русском — на whatmodelscanirun.ru. Я пользовался русской версией для удобства, но математика и данные одинаковые — это форк, не самостоятельный проект.
Идея простая. На входе:
GPU из списка (или ручной ввод VRAM)
Минимальный нужный context window
Минимальная нужная скорость генерации (токенов в секунду)
Опционально — system RAM для offloading в ОЗУ На выходе — список моделей с разбивкой на три категории:
fits (вмещается) — модель влезает с запасом
tight (впритык) — может не хватить при больших контекстах
doesn’t fit (не вмещается) — не запустится без offload в системную RAM Для каждой модели показывается: квантование, максимальный context window для этого железа, оценка tokens/sec, необходимость offload-а.
Звучит как «ещё один онлайн-калькулятор», но что меня зацепило — внутри математика правильная, не «сколько-то приблизительно». Алгоритм учитывает реальную физику работы LLM на GPU.
Кому это полезно. Если вы выбираете между Llama 3.1 8B Q5 и Qwen 2.5 14B Q4 — калькулятор быстро покажет, какая модель даст вам больше контекста. Если вы покупаете новую видеокарту специально под локальные LLM и хотите понять, стоит ли переплачивать за 24 GB вместо 16 — посмотрите, какие модели открывает дополнительная VRAM. Если вы строите multi-agent систему локально и хотите параллельно крутить две-три модели — оценить требования.
Что под капотом: VRAM-budget
Самое интересное в проекте — математика. Я её разобрал по README и исходникам репозитория. Если вы запускали локальные LLM, многое будет знакомо, но в одном месте это редко собрано.
Общая формула VRAM:
total_vram = weight_gb + (kv_per_1k_gb × context_length_k)
Где:
weight_gb— размер весов модели в памяти (зависит от количества параметров и квантования)kv_per_1k_gb— стоимость KV cache на каждые 1000 токенов контекстаcontext_length_k— желаемая длина контекста в тысячах токенов Первая часть — веса — обычно учитывается всеми. А вот KV cache многие забывают, и это главная причина, почему модель «не влезает», хотя по весам должна.
Размер весов считается просто:
weight_gb = num_params × bytes_per_param / 1024³
Для разных квантований:
FP16(полная точность) — 2 байта на параметр. Llama 3.1 8B = ~16 GBQ8_0— 1 байт. Llama 3.1 8B = ~8 GBQ5_K_M— ~5.6 бит. Llama 3.1 8B = ~5.7 GBQ4_K_M— ~4.5 бит. Llama 3.1 8B = ~4.6 GB KV cache — сложнее. Кеш хранит ключи и значения для каждого слоя и каждого токена контекста. Per token:
kv_bytes_per_token = 2 × num_layers × num_kv_heads × head_dim × bytes_per_value
Раскроем коэффициенты:
Множитель 2 — один для keys, один для values
num_layers — количество transformer-слоёв. У Llama 3.2 3B это 28 слоёв, у Llama 3.1 8B — 32, у Llama 3.3 70B — 80
num_kv_heads — количество KV-голов после GQA-оптимизации. Здесь критичная деталь: модели последних лет используют Grouped Query Attention, в котором KV-голов меньше, чем Query-голов. Llama 3.1 8B имеет 32 Q-головы, но всего 8 KV-голов. Это даёт 4x экономию на KV cache
head_dim — размерность на одну голову. Обычно 128
bytes_per_value — обычно 2 (fp16 для KV cache), но можно сжимать до 1 байта (
q8_0) или меньше Пример расчёта для Llama 3.1 8B при 32k контекста:
kv_bytes_per_token = 2 × 32 × 8 × 128 × 2 = 131,072 bytes/token
= 0.125 KB/token
KV для 32k = 32,000 × 0.125 = 4,000 KB = ~4 GB
То есть на 32k контекста уходит дополнительные 4 GB поверх весов модели. Если у вас 16 GB VRAM и Llama 3.1 8B в Q5 (≈5.7 GB весов), на KV остаётся 10.3 GB → можно держать примерно 82k контекста. Калькулятор это и считает.
В коде всё хранится предрасчитанным в models.json. Каждая модель имеет поле kv_per_1k_gb, посчитанное один раз. Это разумное решение — все эти параметры константы для конкретной модели.
Оценка скорости генерации (tokens/sec)
Это вторая интересная часть алгоритма, и она важнее, чем кажется. Многие новички не понимают, что скорость генерации в LLM почти не зависит от GPU compute — она ограничена memory bandwidth.
Почему так: во время decode-фазы (генерация одного токена за раз) модель должна полностью прочитать все свои веса из VRAM. Если у вас Llama 3.1 8B Q5 (~5.7 GB) и видеокарта с bandwidth 360 GB/s — теоретический максимум:
max_tokens_per_sec = bandwidth / weight_gb
= 360 / 5.7 = 63 tokens/sec
Это «raw ceiling». На практике достижимая скорость 70-90% от этого ceiling — обычно около 50 tok/s для Llama 8B Q5 на RTX 3060 Ti.
В калькуляторе используется это, плюс корректирующий коэффициент. Формула примерно:
estimated_tok_sec = (bandwidth_gb_s × efficiency) / model_size_gb
efficiency обычно 0.7-0.85 в зависимости от типа квантования и оптимизаций. Это разумное приближение для llama.cpp с CUDA backend.
Важный нюанс — на бóльших контекстах скорость падает, потому что добавляется чтение KV cache. Калькулятор это учитывает не идеально (точная формула включает attention compute, который зависит от длины контекста квадратично), но даёт нормальную оценку для типичных случаев.
Проверка на трёх сетапах
Чтобы понять, насколько калькулятор точен, я прогнал его на трёх конфигурациях, которые у меня есть, и сравнил предсказания с реальными запусками через llama.cpp.
Сетап 1: RTX 4060 Ti 16 GB
Это моя основная машина для экспериментов. 16 GB VRAM, bandwidth 288 GB/s.
Llama 3.1 8B Q5_K_M, 8k контекст:
Калькулятор: вмещается, прогноз 42 tok/s
Реально (llama.cpp, --gpu-layers 33): 39 tok/s
Точность прогноза: 7% завышение, в пределах нормы Qwen 2.5 14B Q4_K_M, 16k контекст:
Калькулятор: «впритык», прогноз 22 tok/s
Реально: 18 tok/s, KV cache занимает 1.8 GB
Точность прогноза: 22% завышение. Калькулятор не учитывает overhead на CUDA workspace, который для 14B модели заметнее Mistral Small 22B Q4, 4k контекст:
Калькулятор: «не вмещается» без offload
Реально: при попытке загрузить — OOM через 30 секунд работы, нужно --gpu-layers 50 (около 80% слоёв), скорость падает до 8 tok/s
Прогноз верный
Сетап 2: RTX 3090 24 GB
Машина друга, у которого арендую время на тесты. 24 GB VRAM, bandwidth 936 GB/s.
Llama 3.1 8B Q5_K_M, 32k контекст:
Калькулятор: вмещается, прогноз 138 tok/s
Реально: 115 tok/s
Точность: 20% завышение. На 3090 калькулятор переоценивает чаще, видимо из-за более низкого
efficiencyфактора, чем заложено Llama 3.3 70B Q4_K_M, 8k контекст:Калькулятор: «впритык», прогноз 25 tok/s
Реально: 22 tok/s, занимает 22.3 GB из 24
Точность: 13% завышение, разумно Qwen 2.5 32B Q5_K_M, 16k контекст:
Калькулятор: «не вмещается», нужен offload
Реально: с --gpu-layers 60 (из 64) — 14 tok/s, отказывается работать без CPU offload
Прогноз верный
Сетап 3: Apple M2 Pro 16 GB Unified Memory
Тут самое интересное. Apple Silicon работает иначе — unified memory вместо отдельной VRAM, и калькулятор это учитывает только опционально (через ввод VRAM вручную).
Llama 3.1 8B Q5_K_M через llama.cpp с Metal:
Калькулятор (ввёл 11 GB как «available VRAM», оставив 5 GB для системы): прогноз 35 tok/s
Реально: 28 tok/s
Точность: 25% завышение. Калькулятор использует bandwidth для PC GPU, а у M2 Pro эффективная bandwidth для LLM workload ниже из-за thermal throttling в продолжительной работе Phi-3.5 Mini 3.8B Q5, 8k контекст:
Калькулятор: вмещается легко, прогноз 80 tok/s
Реально: 64 tok/s
Точность: 25% завышение
Выводы по точности
Сводка результатов из 7 тестов:
Модель Прогноз Реально Ошибка
─────────────────────────────────────────────────────
Llama 8B Q5 (4060 Ti) 42 39 +7%
Qwen 14B Q4 (4060 Ti) 22 18 +22%
Llama 8B Q5 (3090) 138 115 +20%
Llama 70B Q4 (3090) 25 22 +13%
Phi-3.5 3.8B Q5 (M2 Pro) 80 64 +25%
Llama 8B Q5 (M2 Pro) 35 28 +25%
Средняя ошибка прогнозов — примерно +19% завышение. Это значит: реальная скорость на 15-25% ниже того, что обещает калькулятор. Для практических целей — нормальная оценка. Можно мысленно умножать прогноз на 0.8 и получать ожидание ближе к реальности.
Зато по «влезет / не влезет» точность 100%. Из 7 тестов калькулятор ни разу не ошибся в этой части, что собственно и есть главное.
Где калькулятор стабильно ошибается:
Не учитывает overhead на CUDA workspace — для крупных моделей это 0.5-1 GB сверху
Завышает скорость на Apple Silicon — там память шарится с системой, и эффективный bandwidth ниже из-за thermal throttling и общей нагрузки
Не учитывает квадратичную сложность attention — на длинных контекстах скорость падает резче, чем предсказывает модель
Игнорирует особенности конкретных бэкендов — Ollama vs llama.cpp vs vLLM дают разную производительность на одинаковом железе
Где этот калькулятор лучше альтернатив
Я знаю ещё пару похожих инструментов и могу сравнить.
Hugging Face «Memory Calculator» — официальный калькулятор на сайте Hugging Face. Учитывает только веса, не KV cache, не bandwidth. Полезный, но грубый — может сказать «модель помещается», и тут вас встретит OOM на средних контекстах.
LLM Calc от Yifan Wu — открытый проект на GitHub с похожей идеей. Сильнее по математике (учитывает FlashAttention, разные precision для KV), но не имеет UI — нужно править Python-код под себя.
Ollama compatibility check — встроенная проверка в Ollama, но она показывает только «поместится / не поместится», без оценки скорости и без указания максимального контекста.
Главные плюсы whatmodelscanirun:
Статический сайт без backend. Все данные в JSON, расчёт в браузере. Это значит — нет лимитов, нет регистрации, нет потенциальных перебоев.
Учитывает KV cache. Большинство онлайн-калькуляторов этого не делают.
Учитывает GQA. Без этого расчёты для Llama 3.x были бы в 2-4 раза завышены.
Простой UI. Я ввожу VRAM и context, мне сразу всё видно.
Есть русскоязычная версия. Если для вас язык интерфейса важен —
whatmodelscanirun.ruвесь переведён. Минусы:Не учитывает CUDA overhead. Для серьёзной оценки нужно вычесть 0.5-1 GB
База моделей ограничена топовыми. Если хотите запустить что-то нишевое (Yi, Aya, Falcon) — придётся считать руками
Не различает бэкенды. Реальная скорость в llama.cpp, Ollama, vLLM, exllama может отличаться в 1.5-2 раза
Не учитывает Apple Silicon правильно. M-series требует другой математики
Когда я лично им пользуюсь
После этого тестирования я выработал свой workflow:
Перед скачиванием новой модели — проверяю в калькуляторе, влезет ли в моё железо с нужным мне контекстом. Это сохраняет от качания 40 GB бинарника впустую.
Перед апгрейдом железа — сравниваю, что открывает 24 GB vs 16 GB на конкретных моделях, которые я хочу запускать. Это помогло мне понять, что для моих задач 4060 Ti 16 GB достаточно, и не нужно переплачивать за 3090.
Для планирования multi-agent сетапа — оцениваю, можно ли крутить две модели параллельно. Калькулятор позволяет быстро прикинуть, сколько VRAM останется после загрузки первой модели. Чем я не пользуюсь и не рекомендую полагаться:
Точные числа tok/s — берите с поправкой на 20% вниз и проверяйте сами
Решения о покупке дорогого железа — для этого нужны реальные бенчмарки конкретных моделей на конкретных конфигурациях
Главные технические уроки
Несколько вещей, которые я закрепил для себя через этот разбор.
KV cache масштабируется линейно по контексту. Это банально, но многие забывают. 32k контекста на Llama 8B — это 4 GB дополнительной VRAM. 128k — уже 16 GB, и в 16 GB VRAM модель просто не влезет. Поэтому когда заявляют «модель с контекстом 1M токенов», важно понимать, что для запуска нужно невероятное количество памяти, или техники типа sliding window.
Memory bandwidth — главный bottleneck. Compute (TFLOPS) ваш GPU использует в decode-фазе процентов на 10. Главное — насколько быстро видеокарта тащит веса из VRAM. Поэтому 3090 на типичной LLM-задаче побеждает 4060 Ti не в 2 раза по compute, а именно в 3 раза по bandwidth (936 vs 288 GB/s).
GQA меняет всё. Если бы Meta делала Llama 3 без Grouped Query Attention, на тех же 16 GB можно было бы держать максимум 8-10k контекста, а не 60k+. Это одна из самых важных оптимизаций последних лет.
Квантование сильно меняет картину. Разница между Q4_K_M и Q8_0 для одной и той же модели — это вдвое больший контекст в той же VRAM. Q4 — это потеря 1-2% качества, что обычно незаметно для практических задач. Не запускайте модели в FP16 без необходимости.
Резюме
Калькулятор whatmodelscanirun.ru — это полезный инструмент с правильной математикой и небольшими систематическими ошибками. Не «топовый сайт», как его рекламируют в телеграм-каналах, а аккуратный pet-проект (форк MIT-проекта whatmodels от BenD10), который делает свою работу хорошо.
По прогнозам влезет/не влезет — точность 100%. По прогнозам скорости — стабильное завышение на 15-25%, что можно учитывать поправкой.
Полезно для: планирования покупки железа, выбора между моделями, прикидки максимального контекста. Не полезно для: точных бенчмарков, оптимизации production-инференса, оценки apple silicon.
В целом — заслуженный bookmark в браузере для всех, кто работает с локальными LLM. И хороший пример того, как простой статический сайт может решать конкретную инженерную задачу лучше, чем многие коммерческие альтернативы.
Полезные ссылки:
Русскоязычная версия: whatmodelscanirun.ru
Англоязычный оригинал: whatmodelscanirun.com
Исходники оригинала: github.com/BenD10/whatmodels
Hugging Face Memory Calculator: huggingface.co/spaces/Vokturz/can-it-run-llm
Подробная документация про KV cache от Hugging Face: huggingface.co/docs/transformers/llm_tutorial_optimization
Llama.cpp — реализация, на которой я делал бенчмарки: github.com/ggerganov/llama.cpp