Сколько RAM нужно для Llama 3

MAATRIX

Llama 3 8B весит 4,9 ГБ — значит, восьми гигабайтов хватит. На коротких запросах это даже работает. Проблема вылезает позже: у Llama 3 самый прожорливый KV-кэш в своём классе, и обещанное окно на 128 тысяч токенов просит ещё 16 ГБ — втрое больше весов. Ниже — требования Llama 3 к RAM по всем тегам Ollama, арифметика кэша и границы, за которыми пора менять тариф.

Короткий ответ: сколько RAM требует Llama 3

Память ест не рантайм, а модель: сама Ollama в покое занимает 90–150 МБ. Остальное — веса, кэш внимания и вычислительный буфер:

RAM ≈ вес файла × 1,1 + KV-кэш под ваш контекст + 1,5 ГБ на систему

Коэффициент 1,1 закрывает буферы графа, полтора гигабайта — это Ubuntu 24.04 с SSH и systemd. Open WebUI в контейнере рядом добавит ещё 0,7–1,5 ГБ.

Ориентиры при Q4_K_M, контексте 8192 токена и одном пользователе:

• 4 ГБ — llama3.2:1b, классификация и автодополнение;
• 6–8 ГБ — llama3.2:3b, черновая работа и короткие ответы;
• 8 ГБ — llama3.1:8b, рабочий минимум, но впритык: 7,9 из 8;
• 16 ГБ — тот же 8B с окном 32k или llama3.2-vision:11b;
• 32 ГБ — 8B на полном окне 128k;
• 64 ГБ — llama3.3:70b со скоростью полтокена в секунду;
• 384 ГБ — llama3.1:405b. Это не опечатка и не про VPS.

Речь про инференс на CPU; с видеокартой лимитом становится VRAM.

Пять моделей под одним именем: какой тег вы качаете

ollama pull llama3 в 2026 году всё ещё отдаёт релиз апреля 2024 года с окном 8192 токена. Отсюда самое частое расхождение расчёта с реальностью: память планируют под 128k, которых модель не умеет.

Модель сама сообщает своё окно и геометрию:

curl -s http://127.0.0.1:11434/api/show -d '{"model":"llama3.1:8b"}' | jq -c \
 '.model_info | {ctx:.["llama.context_length"], layers:.["llama.block_count"],
   kv:.["llama.attention.head_count_kv"], vocab:.["llama.vocab_size"]}'

{"ctx":131072,"layers":32,"kv":8,"vocab":128256}

У любого тега llama3: без десятичной части в поле ctx будет 8192. Поставите таким весам num_ctx: 32768 — llama.cpp предупредит и продолжит, а качество после восьми тысяч токенов развалится:

llama_context: n_ctx_per_seq (32768) > n_ctx_train (8192) -- possible training context overflow

Вывод: указывайте версию явно — llama3.1:8b, а не голое llama3. И помните про лицензию: Llama 3 Community License требует упоминания «Built with Llama», а лицензия Llama 3.2 не даёт прав на мультимодальные модели компаниям с домицилем в ЕС; текстовые 1B и 3B под ограничение не попадают.

Таблица RAM по всем тегам Llama 3

Минимум посчитан по формуле при окне 8192 токена, комфорт — при 32 768.

Три строки требуют пояснения.

• llama3.1:8b на 8 ГБ помещается впритык: 5,4 + 1,0 + 1,5 = 7,9 ГБ из восьми. Работает, если сервер занят только этим — Open WebUI или второй пользователь уже не влезут.
• llama3.2:1b качается в Q8_0, а не в Q4 — отсюда 1,3 ГБ вместо 0,8: матрица эмбеддингов 128 256 × 2048 занимает у 1B пятую часть параметров и от сжатия ломается заметнее остального.
• У llama3.2-vision:11b контекст платный вдвойне: каждое изображение разворачивается в 6404 визуальных токена и добавляет около 0,2 ГБ в кэш кросс-внимания.

Как цифры меняются при другом сжатии — в разборе какое квантование выбрать для Llama 3, сравнение с остальной библиотекой — в таблице RAM для Ollama.

KV-кэш: 128 КБ на токен и почему окно 128k стоит 16 ГБ

У всех размеров Llama 3 ровно восемь KV-голов, поэтому расход кэша зависит только от числа слоёв и размерности головы:

KV = 2 × слои × 8 × head_dim × токены × 2 байта

Для llama3.1:8b: 2 × 32 × 8 × 128 × 8192 × 2 — ровно 1 ГиБ на восемь тысяч токенов, на полном окне 131 072 это 16 ГиБ. Кэш дороже весов в 3,3 раза. Отсюда правило: память под Llama 3 берут не по размеру модели, а по длине окна. Два следствия.

Уменьшать модель ради экономии кэша бесполезно. У 3B кэш всего на 12 % легче: 112 КБ против 128 КБ на токен. Переход с 8B на llama3.2:3b экономит 2,9 ГБ весов и жалкие 0,5 ГБ кэша при 32k. Упёрлись в контекст — режьте окно, а не модель.

Llama 3 дороже ровесников по кэшу. У Qwen 2.5 7B четыре KV-головы на 28 слоёв — 56 КБ на токен, у Llama 3 8B восемь на 32 — 128 КБ, в 2,3 раза больше при тех же весах. Тариф, на котором Qwen жил с окном 32k, для Llama 3 окажется тесным.

Русский текст и словарь на 128 256 токенов

Токенизатор Llama 3 построен на tiktoken и вчетверо больше, чем у Llama 2, но набирался на английском и коде. Для русского это значит: тот же документ занимает в окне в полтора раза больше токенов. Замер на одном тексте, счёт через prompt_eval_count:

Проверить на своём тексте:

jq -Rs '{model:"llama3.1:8b", prompt:., raw:true, stream:false,
         options:{num_predict:1}}' text.txt \
  | curl -s http://127.0.0.1:11434/api/generate -d @- | jq .prompt_eval_count

Флаг raw: true обязателен: иначе приклеится шаблон чата и счёт уедет на сотню токенов.

В пересчёте: окно 8192 вмещает около 20 000 знаков по-русски и 34 000 по-английски. Договор на десять русских страниц — это 12–14 тысяч токенов, то есть окно 16k и полтора гигабайта кэша сверху.

Тот же словарь раздувает вычислительный буфер: выходной слой при батче 512 весит 512 × 128256 × 4 байта, и в логе видно CPU compute buffer size = 296.01 MiB.

И честно про язык: официально Llama 3.1 и 3.3 поддерживают восемь языков, русского среди них нет. Модель по-русски говорит, но с падежами справляется хуже, чем Qwen 2.5 того же размера, а токенов тратит на треть больше. Для русскоязычной задачи Llama 3 — не самый экономный выбор ни по качеству, ни по памяти.

Нехватка памяти: что пишут логи и что делать

Ollama считает требования до загрузки и пишет их в журнал:

journalctl -u ollama -n 200 --no-pager | grep -o 'memory\.[a-z.]*="[^"]*"'

memory.available="[15.4 GiB]"
memory.required.full="21.4 GiB"
memory.weights.total="4.9 GiB"

Здесь llama3.1:8b попросили с окном 128k: веса 4,9 ГБ, required.full — 21,4 ГБ, разница целиком в KV-кэше. Если required.full больше available, Ollama откажется либо урежет окно с записью truncating input prompt. Второй маркер — буфер кэша от llama.cpp:

llama_kv_cache_unified: CPU KV buffer size = 16384.00 MiB

«Влезло» и «работает» — разные вещи. Генерация на CPU упирается в полосу памяти: на каждый токен процессор читает все веса. Замер на 8 vCPU / 32 ГБ DDR5, Ubuntu 24.04, mbw -n 5 1024 показывает AVG Method: MEMCPY 31 ГБ/с, окно 8k:

Отдельно — чтение промпта, про которое забывают. Вход обрабатывается на восьми ядрах со скоростью около 30 tok/s: длинный контекст надо сначала прожевать, и 8000 токенов документа — это четыре с половиной минуты до первого слова ответа. Общий префикс Ollama кэширует, поэтому второй вопрос по тому же тексту отвечается сразу; первый — нет. Подробнее — в разборе медленной работы Ollama.

Порядок действий, от дешёвого к дорогому:

1. Сузьте окно: Environment="OLLAMA_CONTEXT_LENGTH=8192" через systemctl edit ollama. Клиент перебивает переменную своим options.num_ctx — Open WebUI шлёт значение из профиля модели.
2. Включите OLLAMA_FLASH_ATTENTION=1 и OLLAMA_KV_CACHE_TYPE=q8_0 — минус половина кэша. Без флеш-аттеншена вторая переменная игнорируется.
3. Ограничьте слоты: OLLAMA_NUM_PARALLEL=1, OLLAMA_MAX_LOADED_MODELS=1 — иначе кэш умножается на их число.
4. Уберите лишние веса с диска: модели лежат в /usr/share/ollama/.ollama/models, ненужные сносятся через ollama rm, каталог переносится переменной OLLAMA_MODELS.
5. Берите размер меньше в Q4_K_M, а не тот же в Q3. llama3.2:3b в Q4_K_M отвечает связнее, чем llama3.1:8b в Q3_K_S.
6. И только потом добавляйте RAM. Своп страхует от падения при загрузке, но в работе превращает 5 tok/s в доли токена. Остальные симптомы — в частых ошибках Llama 3 на сервере.

Какой сервер под Llama 3 взять в MAATRIX

Локальная модель никуда не ходит по сети: веса лежат у вас, запросы не покидают машину. Локацию выбирают по пользователям и юрисдикции, а не по доступности чужих API. Лондон (UK) — базовый вариант: 15–30 мс до Европы, 45–60 мс из Москвы, европейское правовое поле для клиентских данных. Сетевая задержка на фоне генерации не видна — вы ждёте секунды, а не миллисекунды. Великобритания вдобавок не входит в ЕС, так что пункт лицензии Llama 3.2 про мультимодальные модели британской площадки не касается. Россия нужна ради 152-ФЗ.

Минимум — 4 vCPU / 8 ГБ RAM / 80 ГБ NVMe. Это llama3.1:8b с окном 8k и 5 токенами в секунду. Ограничения честные: 7,9 ГБ из 8 заняты, Open WebUI рядом уже не поставить — только API, и для живого чата это медленно. Нужен веб-интерфейс — берите llama3.2:3b, останется запас в три гигабайта.

Комфорт — 8 vCPU / 16 ГБ RAM / 160 ГБ NVMe. Рабочая точка: llama3.1:8b с окном 32k плюс Open WebUI либо llama3.2-vision:11b для сканов и картинок. Запас снимает нужду считать кэш вручную; три-четыре модели этого класса займут 20–25 ГБ диска.

Полное окно 128k у 8B — 32 ГБ RAM: 5,4 ГБ весов, 16 ГБ кэша, полтора системе; дешевле включить q8_0 и уложиться в 24 ГБ. llama3.3:70b — 16 vCPU / 64 ГБ: влезает, отвечает 0,55 tok/s, то есть ночная пакетная обработка, а не диалог. Это и есть потолок процессорного инференса — llama3.1:405b с его 243 ГБ весов на VPS не запускается вовсе, дальше только видеокарта: что брать, разобрано в подборе GPU-сервера под инференс LLM.

Ollama из каталога apps.maatrix.io ставится на сервер автоматически при заказе — вставлять команды не нужно, автоустановка работает на Ubuntu и Debian. Доступы появляются в личном кабинете, раздел «Доступ»; дальше остаётся ollama pull llama3.1:8b и правка переменных под ваш контекст. Путь от чистой машины до первого ответа — в статье как запустить Llama 3 на VPS. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: зарубежная карта для Лондона не нужна. Не уверены в размере — напишите задачу и длину документов, посчитаем.

Частые вопросы