Сравнил предсказания калькулятора с реальными запусками 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
Комментарии (15)

TomskDiver
16.05.2026 09:14Жалко что похоже считается только квантование Q4_K_M и Q8_0. Поэтому калькулятор считает что я не могу у себя на 5060 Ti 16Gb запустить Qwen3.6 или Gemma 4. Но нет, они прекрасно работают. Хотя кто-то скажет что они отупели... Для себя больше ориентируюсь на калькулятор Hugging Face.

Weron2
16.05.2026 09:14Я согласен. В 2026 считать влезет ли llama 3.1 ну такое. Тут последнее время чуть не раз в неделю новое появляется. Вот недавно mtp модель qwen - у меня что-то не стабильная скорость, быстрее не стало как будто... Может что-то не так делаю. Буду пробовать. Но вот допустим 35b модель работает отлично. 27т/с для этого качества неплохо для моих 8+32озу

Ernesto
16.05.2026 09:14Земляк привет.
Какую модель юзаешь Qwen3.6 ? У меня похожая конфа 32/506016gb. Хочу попробовать отдать все ресурсы под LLM, а кодить на ноуте.
TomskDiver
16.05.2026 09:14Если чтобы всё влезало в GPU:
llama-server --host 0.0.0.0 -m Qwen3.6-27B-UD-IQ3_XXS.gguf -ngl 99 -t 7 -c 131072 --prio 2 --temp 0.6 --min-p 0.0 --top-k 20 --top-p 0.95
иllama-server --host 0.0.0.0 -m Qwen3.6-35B-A3B-UD-IQ2_M.gguf -ngl 99 -t 7 -c 131072 --prio 2 --temp 0.6 --min-p 0.0 --top-k 20 --top-p 0.95
Если не надо чтобы было быстро, то квант лучше брать больше (часть слоёв будет в CPU/RAM). Ну и возможно стоит попробовать MTP (еще не пробовал).
Но 16Gb VRAM конечно мало:(

yellow79
16.05.2026 09:14Выбрал M3 Max 36Gb, говорят Qwen3.5 397B A17B запустится, да ещё и скорость ~152 ток/с. Странная математика 397b в Q4_K_M это 244Gb как предполагается вместить это в 36Gb?

Mersavets
16.05.2026 09:14Что такое мое архитектура почитай, и лучше запусти qwen3.6:27b с хорошей скоростью, эта модель новее и лучше, весит меньше

yellow79
16.05.2026 09:14Что такое MOE я в курсе. Даже если предположить, что неактивные слои будут лежать на диске(потому что в RAM они все точно не влезут), то их копирование на каждый токен в VRAM будет занимать как минимум вечность и никакими 152 ток/с тут не пахнет. Но даже если представить, что весь инференс потребует только те 17B что были изначально загружены в память, то для 17B активных мой девайс не в состоянии выдать 152 ток/с.
Qwen3.6 конечно же прекрасен, хоть в 27b хоть в 35b, комент был про математику сервиса

zartdinov
16.05.2026 09:14Если правильно помню, то ollama больше не использует llama.cpp, там длинная история почему. И поэтому проседает по некоторым параметрам.

Mersavets
16.05.2026 09:14Длинная история это сказать "автор оллама не хотел показывать что всё сделано на ллама.cpp, поэтому скрывал это, из за чего получил претензии и быстро заменил самописной фигнёй"?

zartdinov
16.05.2026 09:14Да, точно сказано. Тут хотел сказать, что эти калькуляторы для всего подряд вряд ли будут правильно скорость считать.
Там еще надо уточнить, что автор llama.cpp сказал, что фигня

past
16.05.2026 09:14Есть ещё вот такой проект
https://github.com/AlexsJones/llmfit
Запускаешь на железе и lllmfit выдает длинный список моделей с оценкой. Но по факту это всё сферическая модель в вакууме. Надо писать реальный бенчмарк

DamirMur
16.05.2026 09:14Сегодня делал инструмент который у трёх провайдеров nvidia, openrouter, google, ищет условно бесплатные модели, получилось 74 штуки. Зачем тебе локальная модель?
WondeRu
А есть ли где-то выложенные бенчмарки на реальном железе? Можно обучить простую нейронку, которая будет давать точнее результаты «без математики».
nlaik Автор
Можно попробовать, как будет результат дам обратную связь в виде новой статьи