Да, open weight модели, которых хватает для помощи в разработке, запускаются и на 48, и на 64, и на 96 ГБ RAM. Разница в классе модели, длине контекста и скорости. 48 ГБ закрывают модели 7-14B в квантовании Q4-Q8, 64 ГБ - 30-34B в Q4/Q5 и часть 70B в Q2/Q3, 96 ГБ - 70B в Q4 и большинство домашних MoE-конфигураций.
Все оценки ниже выведены из двух величин: числа параметров и бит на вес. Публичных замеров RAM-футпринта именно для 48, 64 и 96 ГБ пока мало, поэтому воспринимайте цифры как стартовую точку и проверяйте на своём железе.
Разбор вырос из вопроса пользователя /u/bryancostanich в r/LocalLLaMA. Он описывает 128 ГБ RAM как комфортную конфигурацию для локальных моделей разработки, особенно когда планированием занимается внешняя frontier-модель, и просит подтвердить, что реально работает на меньших объёмах (обсуждение в r/LocalLLaMA).
Короткий ответ: какой минимум RAM нужен для локальной модели разработки
Расчётные ориентиры по классам моделей. В столбце весов указан только объём весов, без KV-кэша и оверхеда рантайма.
| RAM | Класс модели | Квантование | Расчётный вес весов |
|---|---|---|---|
| 48 ГБ | 7B dense | Q8_0 | ~7 ГБ |
| 48 ГБ | 14B dense | Q4_K_M | ~8 ГБ |
| 48 ГБ | 30-32B dense | Q3 | ~12-13 ГБ |
| 48 ГБ | 70B dense | Q2 | ~18-20 ГБ |
| 64 ГБ | 32B dense | Q5_K_M | ~20-22 ГБ |
| 64 ГБ | 70B dense | Q3 | ~26-28 ГБ |
| 96 ГБ | 70B dense | Q4_K_M | ~35-40 ГБ |
| 96 ГБ | 70B dense | Q5_K_M | ~44 ГБ |
| 96 ГБ | MoE 8x22B | Q4 | ~70-80 ГБ |
Разница между объёмами видна на одной строке: 70B в Q4 требует около 40 ГБ, что на 48 ГБ оставляет 8-10 ГБ на всё остальное, а на 96 ГБ - почти 56 ГБ. Этот запас и определяет, с каким контекстом и с какой скоростью вы сможете работать.
Почему 128 ГБ RAM - не единственный рабочий вариант
Формула для грубой оценки: RAM-футпринт ≈ число параметров × бит на вес / 8 + KV-кэш + оверхед рантайма. Для 14B в Q4 это 14 × 4 / 8 = 7 ГБ весов. Для 70B в Q4 - 35 ГБ. Оверхед llama.cpp или Ollama измеряется единицами гигабайт и зависит от размера батча и загруженных буферов.
70B в Q4 влезает в 48 ГБ только формально. 35-40 ГБ весов плюс 3-5 ГБ оверхеда оставляют 3-8 ГБ на KV-кэш и операционную систему, то есть контекст придётся держать коротким. Часть слоёв можно выгрузить в VRAM, если GPU даёт 16-24 ГБ: тогда планка RAM снижается на несколько миллиардов параметров. На 64 ГБ та же модель идёт в Q3, и запас на контекст растёт до 25-30 ГБ.
Что считать приемлемым результатом для разработки
Локальная модель на 48-96 ГБ закрывает конкретный список задач:
- автодополнение в редакторе;
- генерация boilerplate и типовых блоков;
- рефакторинг отдельных функций;
- объяснение незнакомого кода в одном файле;
- написание unit-тестов по существующей функции;
- составление SQL и разбор ошибок в запросах;
- перевод комментариев и документации.
Автономные многошаговые задачи, где нужно держать в голове десятки файлов и планировать архитектуру, на этих объёмах обычно проседают. Практическая ценность растёт, когда рутину отдают локальной модели, а сложное планирование оставляют внешней frontier-модели.
Как считать RAM-футпринт модели: параметры, квантование, контекст
Память модели складывается из трёх частей: веса, KV-кэш и оверхед рантайма. Веса считаются из числа параметров и бит на вес. KV-кэш зависит от длины контекста и архитектуры внимания. Оверхед даёт сам движок инференса.
Квантование: Q4, Q5, Q8 и что это даёт на практике
Шкала бит на вес определяет объём весов напрямую. FP16 или BF16 - 16 бит, то есть 2 байта на параметр. Q8_0 - около 8 бит. Q5_K_M - около 5 бит. Q4_K_M - около 4,5 бита с поправкой на метаданные. Q3 и Q2 сжимают сильнее, и для кода потеря точности заметнее, чем для свободного диалога, потому что модель должна воспроизводить точный синтаксис и имена.
Одна и та же 32B-модель: в FP16 около 64 ГБ, в Q8_0 около 34 ГБ, в Q5_K_M около 22 ГБ, в Q4_K_M около 20 ГБ с оверхедом. Разница между Q4 и Q8 почти двукратная, и именно она определяет, влезет модель в 48 ГБ или нет.
Форматов два семейства: GGUF для llama.cpp, Ollama и LM Studio, а также AWQ и GPTQ для GPU-ориентированных рантаймов вроде vLLM. GGUF удобнее для запуска на CPU и гибридного оффлоада, AWQ и GPTQ быстрее на GPU. Как выбирать между Q4, Q5 и Q6 на конкретном железе, показано в разборе квантования Qwen 3.8 Flash Next на 6 ГБ VRAM.
KV-кэш и длина контекста: скрытый пожиратель RAM
Формула KV-кэша: 2 × число слоёв × число KV-голов × размер головы × байт на элемент × число токенов в контексте. Множитель 2 - это отдельные тензоры для ключей и значений.
Пример для 70B-модели с 80 слоями, 8 KV-головами (GQA) и головой размером 128: 2 × 80 × 8 × 128 × 2 байта = 327 680 байт на токен, то есть около 0,33 МБ. На контексте 32k это примерно 10,5 ГБ, на 8k - около 2,6 ГБ. Без GQA, с 80 KV-головами, те же 32k потребовали бы больше 100 ГБ. GQA, который используют Llama 3.3, Qwen и Mistral, снижает аппетит KV-кэша примерно в 8-10 раз.
Практический вывод для 48-64 ГБ: держите контекст в районе 8k-16k, если не готовы отдавать половину RAM под кэш. Часть рантаймов умеет квантовать KV-кэш до 8 или 4 бит, что сокращает его в 2-4 раза, но влияет на качество и доступно не во всех сборках.
Модели для разработки на 48 ГБ RAM: что реально влезает
Расчёт по классам, которые укладываются в 48 ГБ:
- Qwen2.5-Coder 7B: Q4 - около 4 ГБ, Q8_0 - около 7,5 ГБ;
- Qwen2.5-Coder 14B: Q4_K_M - около 8 ГБ, Q8_0 - около 15 ГБ;
- Gemma 2 9B: Q4 - около 6 ГБ;
- Llama 3.1 8B: Q4 - около 5 ГБ;
- Codestral 22B: Q4 - около 13 ГБ;
- DeepSeek-Coder-V2-Lite: 16B всего параметров при ~2,4B активных, Q4 - около 10 ГБ.
Qwen2.5-Coder и DeepSeek-Coder-V2-Lite: рабочие варианты для 48 ГБ
Qwen2.5-Coder в вариантах 7B и 14B - практичная отправная точка: семейство поддерживается в llama.cpp, Ollama и vLLM, а размеры весов оставляют запас на контекст. DeepSeek-Coder-V2-Lite построена как MoE: 16B параметров, из которых на каждом токене активны около 2,4B. Это даёт скорость модели меньшего размера при памяти под всё дерево экспертов. В Q4 веса занимают около 10 ГБ, но KV-кэш считается по полному набору слоёв, так что экономия памяти меньше, чем кажется по активным параметрам.
Из свежих семейств стоит смотреть сравнение Qwen3.8-27B IQ3_XXS и Qwen3.6-35B-A3B Q4_K_M: там выбор модели для кода, скрапинга и tool use строится на трёх осях: битность квантования, MoE против плотной архитектуры и требования задачи.
Когда 48 ГБ мало: честные ограничения
70B в Q2 расчётно влезает (около 18-20 ГБ весов), но сильное квантование бьёт по точности кода, а скорость на CPU падает до единиц токенов в секунду. Многошаговые агентные задачи, длинный контекст и работа с крупными репозиториями на 48 ГБ упираются в стену. Для автодополнения и небольших функций 48 ГБ достаточно. Если нужна автономная агентная разработка, смотрите на 96 ГБ или на внешнюю модель.
Модели для разработки на 64 ГБ RAM: золотая середина
64 ГБ снимают главное ограничение 48 ГБ: появляется запас на KV-кэш и контекст. Комфортный класс - 30-34B в Q4/Q5:
- Qwen2.5-Coder 32B: Q4_K_M - около 20 ГБ, Q5_K_M - около 22 ГБ;
- DeepSeek-Coder 33B: Q4 - около 18 ГБ;
- CodeLlama 34B: Q4 - около 19 ГБ;
- Mixtral 8x7B: Q4 - около 26 ГБ.
Qwen2.5-Coder 32B и аналоги: что даёт переход с 14B на 32B
32B-модели лучше держат несколько файлов в одном запросе, аккуратнее делают рефакторинг и реже теряют структуру при генерации длинных блоков. По памяти 20 ГБ весов на 64 ГБ оставляют 40+ ГБ на кэш, операционную систему и оверхед. Скорость на CPU будет ниже, чем у 14B, но с оффлоадом части слоёв на GPU остаётся рабочей. Конкретные токены в секунду зависят от модели, квантования и числа выгруженных слоёв, поэтому проверяйте на своих задачах.
70B в Q2/Q3 на 64 ГБ: стоит ли овчинка выделки
70B в Q3 занимает около 26-28 ГБ весов, в Q2 - около 18-20 ГБ. Формально места хватает. Проблема в том, что сильное квантование сильнее всего бьёт по задачам с точным синтаксисом и многошаговой логикой, то есть именно по кодингу. Скорость добавляет своё: на CPU 70B в Q2 может давать 1-3 токена в секунду, а интерактивная работа на такой скорости неудобна. Если выбирать между 32B в Q4 и 70B в Q2, для кода чаще выигрывает 32B в Q4.
Модели для разработки на 96 ГБ RAM: что открывается
96 ГБ делают реальным класс 70B в нормальном квантовании, а не в предельно сжатом виде.
Llama 3.3 70B и другие 70B-модели в Q4: реальный сценарий
Llama 3.3 70B в Q4_K_M занимает около 35-40 ГБ весов. На 96 ГБ это оставляет 50+ ГБ на KV-кэш, операционную систему и оверхед, то есть контекст 32k и выше перестаёт упираться в память. 70B-модели лучше держат длинный контекст, следуют составным инструкциям и реже теряют структуру при генерации больших кусков кода. В Q5 веса вырастают до ~44 ГБ, в Q6 - до ~52 ГБ, и оба варианта всё ещё укладываются.
Для чисто кодинговых задач специализированная 32B может не уступать универсальной 70B на конкретных языках и фреймворках. Разница проявляется на общем планировании, объяснении нестандартного кода и задачах со смешанным контекстом, где больше параметров даёт преимущество.
MoE-модели на 96 ГБ: Mixtral и другие
MoE требуют памяти под все эксперты, даже когда активна только часть. Mixtral 8x7B в Q4 занимает около 26 ГБ и влезает с большим запасом. Mixtral 8x22B - это 141B параметров всего, в Q4 около 70-80 ГБ, и на 96 ГБ остаётся всего 16-25 ГБ на KV-кэш и систему. Такая конфигурация работает, но контекст придётся ограничивать. Взамен MoE дают высокую скорость генерации при качестве, близком к плотной модели большего размера: на каждом токене считаются только активные эксперты.
Сценарий «frontier-модель планирует - локальная выполняет»
Этот подход снижает требования к качеству локальной модели. Внешняя frontier-модель разбивает задачу на шаги, пишет план, формулирует точные промпты и проверяет результат. Локальная open weight модель выполняет рутинные операции: пишет код по готовому описанию, делает рефакторинг, генерирует тесты. Автор исходного вопроса описывает именно такую схему как эффективную на своей машине со 128 ГБ RAM (обсуждение).
Какие задачи отдавать локальной модели, а какие - внешней
- Локальной: генерация boilerplate, автодополнение, правки в пределах одной функции, тесты по готовой сигнатуре, объяснение кода, запросы к SQL.
- Внешней: планирование архитектуры, сложная отладка, ревью, задачи с длинным контекстом и многошаговой логикой, работа с незнакомым стеком.
Граница подвижна. Чем крупнее локальная модель, тем больше шагов она тянет сама, но даже на 96 ГБ разрыв с frontier-моделями в сложных сценариях остаётся. Экономику такого разделения, стоимость токенов и точку перехода между своим железом и подпиской разбирали в материале про локальный AI против облака.
Инструменты для оркестрации: что использовать
Локальный инференс обычно держат на llama.cpp, Ollama или vLLM. Для связки двух моделей подходят Aider и Continue.dev: они поддерживают гибридные режимы, где локальная модель отвечает за автодополнение, а внешняя - за сложные запросы. Для собственных пайплайнов используют LangChain, LlamaIndex или обычные скрипты, которые вызывают локальный сервер по HTTP и внешний API параллельно. Универсально лучшего инструмента нет: выбор зависит от того, пишете вы в редакторе или строите агента.
Как выбрать модель под своё железо: пошаговый алгоритм
1) Посчитайте доступный объём RAM и VRAM, оставив 4-8 ГБ запаса под систему. 2) Определите класс модели по таблице: 7-14B для 48 ГБ, 30-34B для 64 ГБ, 70B для 96 ГБ. 3) Начните с Q4_K_M как компромисса по качеству и размеру. 4) Посчитайте веса по формуле параметры × бит на вес / 8 и добавьте оверхед рантайма. 5) Прикиньте KV-кэш под нужную длину контекста и ограничьте её, если запас мал. 6) Проверьте, что выбранный формат (GGUF, AWQ, GPTQ) поддерживается вашим рантаймом. 7) Прогоните модель на своих задачах: качество на чужом бенчмарке ничего не говорит о вашем коде.
RAM vs VRAM: что важнее для локального инференса
GPU-инференс быстрее, но VRAM ограничена: 8-24 ГБ на типичной домашней карте. RAM измеряется десятками гигабайт. Поэтому большие модели запускают гибридно: несколько слоёв и KV-кэш живут в VRAM, остальное - в RAM. Скорость определяется не только объёмом, но и пропускной способностью памяти, а также тем, сколько слоёв удалось выгрузить на GPU. Пример такого баланса на слабом железе - запуск Gemma 26B QAT на 8 ГБ VRAM и 16 ГБ RAM с выгрузкой слоёв (разбор на 8 ГБ VRAM): та же логика оффлоада масштабируется и на 48-96 ГБ.
Минимальные требования к железу для LLM: чек-лист
- RAM: 48 ГБ под 7-14B, 64 ГБ под 30-34B, 96 ГБ под 70B в Q4.
- VRAM: желательно 16-24 ГБ, чтобы выгрузить часть слоёв и поднять скорость.
- Пропускная способность памяти: для CPU-инференса она часто важнее объёма, особенно в серверных платформах с несколькими каналами.
- CPU: поддержка AVX2 или AVX-512 ускоряет расчёты на процессоре.
- Диск: свободное место под веса (от 5 ГБ для 7B Q4 до 80 ГБ для крупных MoE).
- Драйвер GPU: актуальная версия, иначе часть слоёв не выгрузится.
Для 48 ГБ RAM и модели 14B в Q4 достаточно и CPU, а для 70B в Q4 нужны 96 ГБ и желательно GPU. Как выбрать семейство модели без перебора всех карточек, разбирали в отдельном материале про выбор модели для vLLM: там про типы обучения, safetensors и GGUF, квантование, VRAM и RAM, KV cache и совместимость с рантаймом.
Ограничения и подводные камни: что не расскажут в обзорах
Скорость vs качество: где проходит граница комфорта
Ориентиры по скорости: для автодополнения комфортно 10-20 токенов в секунду и выше, для генерации кода в диалоге приемлемо 5-10, ниже 3 токенов в секунду интерактивная работа превращается в ожидание. На CPU 70B в Q4 даёт единицы токенов в секунду, 7-14B в Q4 - заметно больше. GPU-оффлоад меняет картину, но требует VRAM и совместимого рантайма.
Почему данные о RAM-футпринте могут расходиться
Футпринт зависит от квантования, рантайма (llama.cpp, Ollama и vLLM считают буферы по-разному), длины контекста, настроек KV-кэша и версии модели. Два человека на одинаковом железе получат разные цифры, если один держит контекст 4k, а другой 32k. При обмене опытом полезно указывать четыре вещи: имя модели, тип квантования, рантайм и длину контекста.
Отдельная сложность: публичных замеров RAM-футпринта для 48, 64 и 96 ГБ пока мало, и большая часть данных - это расчётные оценки и отдельные сообщения пользователей, а не воспроизводимые тесты (исходный вопрос). Проверяйте на своём железе и делитесь результатами.
Итог: какой объём RAM выбрать под задачи разработки
48 ГБ - стартовый уровень. Хватает на 7-14B в Q4-Q8, автодополнение, рефакторинг отдельных функций, тесты и SQL. Автономной агентной разработки здесь не будет.
64 ГБ - комфортная точка. 30-34B в Q4/Q5, запас на контекст, реальный помощник в ежедневной работе. 70B возможна в Q2/Q3, но для кода это обычно шаг назад.
96 ГБ - уровень 70B в Q4 с длинным контекстом и часть MoE-моделей. Для многих задач разработки такой локальный инференс приближается к внешним API, но в сложных сценариях всё ещё уступает frontier-моделям.
Выбор зависит от задач и от того, готовы ли вы держать внешнюю модель как планировщика. Если да, 48-64 ГБ закрывают заметную часть рутины. Если нет, ориентируйтесь на 96 ГБ. Расчётные цифры проверяйте на своём железе: расскажите, какие модели и на каком объёме RAM работают у вас.