Короткий ответ: что имеет смысл запускать на двух RTX 5080 и 128 ГБ RAM
На двух RTX 5080 и 128 ГБ DDR5 рабочая схема - держать не одну универсальную модель, а набор из двух-трёх под разные задачи. Первая: средняя модель класса 20-30B в квантовании около 5-6 бит на вес с контекстом 96-131k для интерактивного кодинга, правок и автодополнения. Вторая: более крупная MoE-модель в агрессивном квантовании, когда нужна широта анализа в агентном прогоне. Третья: тяжёлая модель с контекстом порядка миллиона токенов, которую запускают редко и под конкретную задачу: разбор большого репозитория, длинный лог, пакет документов.
Оговорка, без которой любой такой совет превращается в гадание: проверяемых бенчмарков именно под связку 2×RTX 5080 + 128 ГБ DDR5 в открытых источниках нет. В research pack по этой конфигурации есть единственный публичный материал: пользовательский пост в r/LocalLLaMA, где автор описывает свой стек и приводит собственные замеры. Поэтому дальше речь о критериях выбора и проверяемой арифметике, а не о готовом рейтинге моделей.
Вот что автор обсуждения называет своим текущим стеком (значения pp и decode - его личные замеры, а не результаты тестирования редакции):
| Модель | Квантование | Контекст | pp, tps | decode, tps |
|---|---|---|---|---|
| Qwen3.8-Flash-Next | Q5_K_XL | 262k | ~150-200 | ~15 |
| Qwen3.8-27B | EXL3 6bpw, H6 | 131k | ~2000-3000 | ~60-80 |
| DeepSeek-V4-Flash | EXL3 3.04bpw | 1M | ~100-900 | ~15-20 |
Источник этих цифр - обсуждение What did I miss? What should I be running on 2x16Gb VRAM and 128Gb RAM?. Показательна не абсолютная скорость, а разброс: у 27B-модели decode в 4-5 раз выше, чем у Flash-вариантов, зато контекст в 8 раз короче. Это типичный размен на двух картах, и его стоит считать заранее.
Как читать конфигурацию 2×RTX 5080 + 128 ГБ DDR5: где реальные ограничения
Потребительская RTX 5080 по официальной спецификации NVIDIA несёт 16 ГБ GDDR7, то есть две карты дают около 32 ГБ VRAM. Этого достаточно для 27B-модели в 6-битном квантовании, но мало для крупной MoE с длинным контекстом в высоком кванте. 128 ГБ DDR5 спасают ситуацию: слои или KV-cache можно держать в системной RAM, и модель запустится. Только платить за это придётся скоростью, потому что каждый обработанный токен придётся гонять по PCIe между RAM и GPU.
Второе ограничение - обмен между картами. У потребительских GeForce нет NVLink, весь трафик идёт через PCIe. При layer split это терпимо: карты обмениваются активациями на границе разделения. При tensor parallel трафик кратно выше, и на PCIe 5.0 x8/x8 он становится узким местом сильнее, чем сама арифметика. Практический вывод: для домашней сборки из двух карт начинайте с layer split и только потом пробуйте tensor parallel, если движок его поддерживает.
Порядок расчёта спасает от лишних скачиваний: сначала бюджет VRAM под веса плюс KV-cache под нужный контекст, затем квантование, и только потом движок. Считать в обратном порядке, от понравившейся модели, значит упереться в нехватку памяти на этапе, когда 60 ГБ уже скачаны. Разбор бюджета памяти на одной RTX 5080 с 16 ГБ есть в материале про Qwen3.8-27B в true Q4_K_M на RTX 5080: там та же логика, только без второй карты.
Сколько VRAM съедает контекст: почему 262k, 131k и 1M это разные истории
KV-cache растёт линейно по длине контекста. Объём считается так:
байт на токен = 2 × слоёв × KV-голов × head_dim × байт на элемент
Множитель 2 - это ключи и значения. Дальше умножаем на число токенов и делим на степень tensor parallel, если модель разрезана по головам.
Иллюстративный расчёт с условными числами: 64 слоя, 8 KV-голов, head_dim 128, кэш в F16. Получаем 256 КиБ на токен. На 128k токенов это 32 ГиБ, то есть весь объём двух карт целиком, без весов модели. Переход на Q8 делит эту цифру пополам, тот же контекст стоит уже 16 ГиБ. Для 1M токенов при тех же параметрах нужно около 256 ГиБ, и в 32 ГБ VRAM такое не помещается никак.
Отсюда практика: длина контекста и точность KV-cache связаны крепче, чем кажется. Современные модели часто используют GQA или MLA, где KV-голов меньше, поэтому реальные цифры ниже иллюстрации, иногда в разы. Свою модель нужно считать по её config.json, а не по общим прикидкам. Правило простое: контекст 1M держите как режим редких задач, 131k - как рабочий режим агента, 32-64k - как комфортный повседневный кодинг.
Выбор квантования: GGUF/Q5_K_XL против EXL3 и что значит bpw
GGUF - это контейнер и семейство квантований, которые читает llama.cpp и совместимые с ним движки. EXL3 - отдельный формат с явной метрикой «бит на вес» (bpw). Смешивать их в одном сравнении нельзя: Q5_K_XL и EXL3 6bpw описывают похожие компромиссы, но живут в разных экосистемах, и поддержка зависит от движка.
bpw - самый удобный ориентир при планировании памяти. Вес модели в гигабайтах примерно равен числу параметров в миллиардах, умноженному на bpw и делённому на 8. Для 27B на 6bpw это около 20 ГБ только под веса: в одну карту на 16 ГБ не влезает, в две - с запасом на KV-cache и буферы. Тот же расчёт на 4bpw даёт около 13,5 ГБ, но качество на сложных задачах просядет.
Q5_K_XL: когда 5-битное GGUF-квантование - разумный компромисс
Q5_K_XL относится к k-quants со смешанной точностью: часть тензоров хранится в 5 битах, отдельные чувствительные блоки - точнее. Для моделей среднего размера это обычно спокойный баланс размера и качества. Ставьте на него, когда нужен быстрый кодинг-ассистент с предсказуемым поведением: автодополнение, правки в файле, короткие объяснения. Скорость отклика здесь важнее максимальной точности на многошаговых рассуждениях.
Ограничение прямое: на длинных агентных цепочках, где модель десятки раз перечитывает собственный вывод, погрешность квантования накапливается, и модель начинает терять формат вызова инструментов. Это гипотеза, которую нужно проверять на своих задачах, а не аксиома. Тест простой: дайте модели 15-20 шагов агентного прогона с вызовами функций и посчитайте, на каком шаге она первый раз сломает схему.
EXL3 и bpw: зачем 6bpw у 27B и 3.04bpw у тяжёлой модели
Логика из пользовательского стека читается легко. У 27B берут 6bpw, потому что модель небольшая и можно позволить себе качество: 20 ГБ весов делятся на две карты, остаётся место под 131k контекста. У тяжёлой Flash-модели берут 3.04bpw, потому что иначе она просто не запустится на 32 ГБ VRAM: это ставка на сам факт работы модели, а не на её пиковое качество.
Это пример конкретного пользователя под его задачи, а не рекомендация редакции. Проверять качество нужно самостоятельно: 3 с половиной бита на вес у крупной модели часто дают результат лучше, чем 6 бит у мелкой, но зависят от архитектуры и от того, насколько аккуратно сделан конкретный квант. Ещё один фактор - поддержка формата движком. EXL3 читают далеко не все движки, тогда как GGUF поддерживается почти везде.
llama.cpp, Strata и другие движки: что выбрать в 2026
Про llama.cpp отвечу без драматизма: движок зрелый, с широкой поддержкой GGUF и большой экосистемой, но вопрос «устарел ли он» задан неверно. Правильнее спрашивать, поддерживает ли он ваш формат квантования, умеет ли нужный вам сплит по двум GPU, как ведёт себя на длинном контексте и есть ли в нём нужные вам агентные возможности. Ответ на эти четыре вопроса важнее даты последнего коммита.
Про Strata в research pack нет проверяемых данных о возможностях и производительности, поэтому категорично советовать переход нельзя. Известно, что движок развивается: в материале про поддержку Qwen 3.6 35B в Strata разбирается, что даёт такая совместимость на практике и почему единственный отзыв о скорости на MI50 ничего не доказывает про сравнение с llama.cpp. Вывод: Strata стоит рассматривать как второй движок для эксперимента, а не как замену вслепую.
Чек-лист перед сменой движка
- Поддерживает ли движок ваш формат квантования (GGUF, EXL3) без конвертации и потери точности.
- Умеет ли резать модель по двум GPU и какой режим сплита у него по умолчанию.
- Как ведёт себя на вашем рабочем контексте: 131k - это уже проверка на прочность, а не синтетика.
- Работает ли offload в DDR5 и насколько предсказуемо при этом падает decode.
- Держит ли формат вызова инструментов на длинных агентных цепочках.
- Как часто выходят обновления и чинят ли проблемы длинного контекста.
Порядок миграции: один и тот же промпт, одна и та же длина выхода, один и тот же сплит на старом и новом движке. Сравнивайте pp, decode и качество ответа. Если новый движок не выигрывает хотя бы по двум из трёх пунктов, выходные потрачены зря.
Как честно сравнивать модели: pp, decode и что ещё мерить
Prompt processing (pp) - скорость чтения промпта, decode - скорость генерации. Разница принципиальная. pp определяет, как быстро вы получите первый токен на большом промпте: вставили 40k токенов кода, и агент минуту думает, прежде чем что-то сказать. decode определяет, насколько комфортно читать ответ. Для интерактивного кодинга критичен decode, для RAG и агентов с длинными входами - pp.
Цифры из обсуждения на 2×RTX 5080 хорошо показывают этот размен: у Qwen3.8-27B в EXL3 6bpw пользователь получил pp около 2000-3000 tps и decode 60-80 tps, у Qwen3.8-Flash-Next в Q5_K_XL - pp 150-200 tps и decode около 15 tps, у DeepSeek-V4-Flash в EXL3 3.04bpw - pp 100-900 и decode 15-20 tps (личные замеры автора поста). Это не тесты редакции и не бенчмарк: другая материнская плата, другие настройки, другая версия движка дадут другие числа.
Методика замера pp и decode на двух GPU
- Зафиксируйте промпт и длину выхода. Меняете один параметр за раз, иначе цифры несравнимы.
- Замеряйте отдельно время до первого токена и скорость генерации. Смешанная метрика скрывает узкое место.
- Запишите конфигурацию: движок и его версию, квантование, длину контекста, режим сплита, объём offload в RAM.
- Сделайте 3-5 прогонов и возьмите медиану, а не первый результат: кэш экспертов и прогрев карт дают заметный разброс.
- Прогоните тест на двух длинах контекста, например 8k и 100k, и сравните падение.
- Отдельно оцените качество: одинаковое задание с проверяемым результатом, например исправление бага в тестовом файле.
Скорость без оценки качества бесполезна. Модель, которая выдаёт 80 tps и ломает схему вызова инструментов каждый пятый шаг, обойдётся дороже медленной и аккуратной.
Длинный контекст 131k-1M на двух GPU: когда он нужен и чем платить
Длинный контекст оправдан в трёх сценариях: агентная цепочка с большим числом шагов, где нужно помнить всю историю; работа с крупным репозиторием целиком; RAG с длинными документами, которые не хочется резать. Во всех трёх случаях выигрыш реальный, но платить приходится трижды: объёмом KV-cache, падением pp и риском деградации внимания на дальних участках текста.
Практика, которая экономит нервы: держите две конфигурации одной и той же модели. Одна с контекстом 32-64k для повседневной работы, вторая с 131k или больше для тяжёлых прогонов. Переключение занимает секунды, а разница в скорости ощутима. Второй приём - квантование KV-cache: Q8 вместо F16 экономит половину памяти под кэш при небольшой потере точности.
Полезно сравнить два подхода на одном задании: высокий квант с умеренным окном против низкого кванта с длинным окном. Разбор про выбор между высоким квантом и длинным контекстом на 20 ГБ VRAM показывает, что качество модели на рабочем окне часто важнее запаса длины. Проверять стоит на своих задачах, потому что порог деградации у каждой архитектуры свой.
Практический план: как собрать свой стек под кодинг и агентов
- Разделите задачи. Интерактивный кодинг и агентные прогоны предъявляют разные требования: первому нужен decode, второму - pp и удержание формата на длинной цепочке.
- Посчитайте бюджет VRAM: веса по формуле из bpw плюс KV-cache под нужный контекст плюс запас 2-3 ГБ на буферы и графы.
- Выберите два-три класса моделей: средняя 20-30B в 5-6 битах, крупная MoE в 3-4 битах, при необходимости тяжёлая модель с длинным окном для редких задач.
- Подберите квантование под движок. Если работаете в llama.cpp, это GGUF-кванты; если движок читает EXL3, появляется выбор по bpw.
- Замерьте pp и decode по методике выше и обязательно проверьте качество на реальном задании.
- Оставьте только то, чем действительно пользуетесь. Три модели, каждая из которых запускается раз в месяц, съедают диск и время на обновления.
Отдельно про выбор модели для кодинга: не доверяйте названиям с приставкой coder, пока не проверили поведение на своих файлах. В материале про Qwen 3.8 Flash Coder разбирается именно эта ситуация: публичных подтверждённых данных о модели нет, поэтому есть смысл сравнивать её с текущим рабочим вариантом на своём наборе задач и своём железе.
Что изменилось за несколько недель и как не утонуть в новинках
После паузы в локальном AI легко решить, что всё поменялось. На деле смотреть нужно на четыре вещи: новые релизы моделей (число параметров, длина контекста, лицензия), обновления движков (поддержка форматов, исправления длинного контекста), изменения в поддержке квантований и поведение драфтеров вроде MTP, которые могут как ускорять, так и замедлять генерацию в зависимости от архитектуры.
Без проверяемых данных нельзя утверждать, что конкретная модель или движок «устарел». Такое заявление требует сравнения на вашей конфигурации. Из обсуждений видно и другое: поколение модели часто важнее её номинального размера, а смена движка иногда даёт больше, чем апгрейд железа. Обратная сторона тоже встречается: пользователь на RTX 5090 ушёл с Qwen 3.8 27B в NVFP4 на Flash Next из-за проблем со следованием AGENTS.md и agent skills, о чём разбирается в материале про опыт перехода между Qwen 3.8 27B и Flash Next. Это единичный опыт конкретного человека, а не закономерность.
Рабочее правило: не меняйте стек ради новинки, пока она не обгонит текущий вариант на ваших задачах по pp, decode и качеству ответа одновременно. Проверка занимает пару часов и стоит дешевле, чем неделя на переезд и откат.