Что реально влезает в 48 ГБ VRAM на двух AMD-картах
На 48 ГБ VRAM разумно пробовать три группы открытых моделей: dense-модели класса 24-34B в квантовании Q4-Q6, MoE-модели с 30-50B общих и 3-12B активных параметров, а также 70B в Q3-Q4, если вы готовы к частичному offload и ограничению контекста. Модели меньше 14B на такой памяти запускаются без проблем, но потенциал железа не раскрывают: разница в удержании агентных инструкций и качестве вызовов инструментов проявляется как раз на классе 27B и выше.
Речь идёт о сборке из Radeon R9700 на 32 ГБ и RX 7800 на 16 ГБ, суммарно 48 ГБ VRAM при 64 ГБ RAM. Владелец уже экспериментирует с Qwen 27B и лёгким вариантом fn, а основным сценарием называет работу с агентом Hermes (обсуждение на r/LocalLLaMA). Значит, альтернативы нужно искать не по принципу «кто лучше пишет текст», а по пригодности к многошаговым циклам с вызовом функций.
Замеров скорости именно на паре R9700 плюс RX 7800 в открытых данных нет. Дальше речь пойдёт о бюджете памяти, критериях совместимости с агентом и порядке проверки моделей. Обещать конкретные токены в секунду для этой связки было бы выдумкой: результат зависит от квантования, длины контекста, версии рантайма и драйвера.
Сколько VRAM уходит на веса и KV-cache
Бюджет считается в два действия. Веса примерно равны числу параметров, умноженному на биты на параметр и поделённому на восемь. Модель на 27B в Q4 занимает порядка 14-16 ГБ, в Q8 уже 27-28 ГБ, и это только веса. Сверху добавляется KV-cache, и часто именно он решает, влезет модель целиком в VRAM или нет.
Размер KV-cache определяется числом слоёв, количеством голов, длиной контекста и типом квантизации самого кэша. На контексте 32k он съедает несколько гигабайт, на 128k уходит в десятки. Как это считается на нескольких GPU с разным объёмом памяти, подробно разобрано в материале про 2× Radeon AI PRO R9700, подсчёт VRAM и KV-кэша.
Две карты разного объёма не образуют единый пул. Рантайм раскладывает слои по устройствам, и если на быстрой карте места не хватило, часть слоёв уезжает на вторую или в RAM. Каждый выгруженный слой бьёт по скорости сильнее, чем кажется: агент генерирует короткие структурированные ответы, и накладные расходы на передачу данных заметны сразу.
Обратная сторона видна в тестах на 16 ГБ: там модель работает ровно до момента, пока KV-кэш помещается в память, а дальше начинаются таймауты (разбор 11/15 против 15/15 на 16 ГБ VRAM). На 48 ГБ запас больше, но принцип тот же: считайте веса и кэш до запуска, а не после первых ошибок.
Почему 64 ГБ RAM - не замена VRAM
Offload в оперативную память работает, но платите вы скоростью. Пропускная способность DDR5 в разы ниже, чем у памяти видеокарты, плюс добавляется шина PCIe. Для одиночного запроса разница может быть терпимой, для агента с десятком последовательных вызовов инструментов она накапливается в минуты ожидания.
64 ГБ RAM расходуются на операционную систему, рантайм, страницы кэша и небольшой запас. Этого хватает, чтобы держать систему и часть KV-кэша, но не чтобы комфортно выгрузить туда 70B. Практическое правило для Hermes: модель и её кэш должны целиком помещаться в VRAM, а RAM пусть остаётся буфером, а не рабочим объёмом.
Критерии выбора модели под агента Hermes
Для агента важны четыре свойства: корректный вызов инструментов, стабильный JSON, удержание инструкций на длинном контексте и предсказуемое поведение в многошаговых циклах. Размер модели и качество свободного текста стоят после них. Модель, которая пишет красиво, но игнорирует tools, в Hermes бесполезна.
Tool calling и function calling: что проверять
Разница между генерацией текста и вызовом функции принципиальна. В первом случае модель возвращает строку, во втором - структурированный объект с именем функции и аргументами, который рантайм парсит и передаёт дальше. Смотреть нужно на шаблон чата модели: поддерживает ли он роль tool, как оформляет ответ с вызовом, что происходит при ошибке инструмента.
Типичный провал выглядит так: вместо вызова функции модель пишет «я бы поискал информацию». Для Hermes это остановка цепочки. Второй по частоте дефект - валидный JSON с выдуманными аргументами или с именем функции, которого нет в описании. Третий - модель не умеет продолжать работу после возврата результата и начинает диалог заново.
Проверка занимает минут десять: два инструмента, один запрос, требующий их вызова, и один запрос, где вызов не нужен. Модель должна справиться с обоими сценариями. Если на первом шаге вы видите текст вместо структуры, дальше идти незачем.
Контекст и удержание инструкций
Агенту нужен контекст 16k-64k: история шагов, описания инструментов, результаты вызовов и системный промпт занимают место быстро. KV-кэш растёт вместе с длиной последовательности, поэтому увеличение окна вдвое увеличивает и расход памяти. Три рабочих приёма: квантизация KV-кэша, обрезка истории с сохранением последних шагов, суммаризация старых результатов инструментов.
Удержание инструкций на длинном контексте у моделей одного размера различается заметно. Проверяется просто: поставьте правило в системный промпт, например обязательный формат ответа или запрет на определённое действие, и посмотрите, соблюдается ли оно на тридцатом шаге диалога. Модели, теряющие инструкции к середине окна, в агентных сценариях работают нестабильно.
Классы открытых моделей, сопоставимых с Qwen 27B/fn
Дальше речь о классах, а не о списке конкретных релизов: подбор семейства зависит от того, какие версии выйдут к моменту чтения и как быстро авторы добавят шаблоны под tools. Рамка поиска одна: открытые веса, заявленная поддержка function calling, шаблон чата с ролью tool, размер, который укладывается в бюджет памяти с запасом под контекст.
Dense-модели 24-34B: что ожидать
Dense-модели того же размера, что Qwen 27B, дают предсказуемое потребление памяти: одна и та же модель всегда занимает один и тот же объём, а раскладка по двум картам считается заранее. В Q4-Q5 они обычно помещаются в 48 ГБ с запасом под контекст 32k-64k. Плюс в том, что их проще квантизовать и отлаживать, минус - меньше знаний на параметр, чем у MoE при том же расходе памяти.
Смотреть стоит на модели, где поддержка tools заявлена в карточке и есть готовый шаблон чата. Базовая модель без инструкт-версии для агента не подойдёт: она не обучена на диалоге с инструментами.
MoE-модели: больше параметров при меньшей активности
MoE держит в памяти все параметры, но активирует на каждом токене только часть экспертов. Это даёт скорость dense-модели меньшего размера при большем объёме знаний. Общий размер таких моделей начинается от 30-50B, поэтому квантование обычно Q4, а раскладка по двум картам требует внимания: эксперты распределяются между устройствами, и баланс влияет на скорость заметно.
Как это устроено на нескольких GPU и в каких случаях часть экспертов выгоднее держать в оперативной памяти, разобрано в статье про KTransformers и llama.cpp для MoE-моделей на нескольких GPU. Для вас там важна логика распределения, а не абсолютные цифры: конфигурация другая, объём памяти тоже.
Отдельная сложность: поддержка tool calling у MoE-моделей варьируется от релиза к релизу сильнее, чем у dense. Даже если предыдущая версия семейства работала с инструментами, новая может требовать обновлённого шаблона в рантайме. Проверяйте на своей версии, а не по описанию в карточке.
70B в сильном квантовании: когда имеет смысл
70B в Q3-Q4 занимает примерно 30-40 ГБ и формально влезает в 48 ГБ. Дальше начинается арифметика: под KV-кэш остаётся 8-18 ГБ, и на контексте 32k это тесно. Часть слоёв придётся выгружать, а выгрузка в RAM для агентных задач с длинными цепочками обходится дорого.
Вариант оправдан в одном случае: модель явно поддерживает tools, вы готовы держать контекст 16k-32k и мириться с просадкой скорости на длинных шагах. Если цель - быстрый отклик Hermes, dense 24-34B или MoE дадут более ровный результат при меньшем риске.
Квантование и архитектура: как это влияет на выбор
Квантование определяет, сколько моделей вообще помещается в 48 ГБ и насколько просядет качество. Ориентир по уровням: Q4_K_M - частый компромисс, Q5-Q6 - когда памяти хватает и хочется запаса по качеству, Q8 - почти без потерь, но веса модели на 27B вырастают до 27-28 ГБ. Q3 и ниже для агентной работы стоит брать только как эксперимент: на вызове инструментов деградация проявляется раньше, чем в свободном тексте.
GGUF vs GPTQ/AWQ на AMD
GGUF удобнее для связки с llama.cpp, Ollama или LM Studio: формат поддерживает гибкие уровни квантования и нормально переживает распределение слоёв между GPU. GPTQ и AWQ рассчитаны на GPU-инференс и часто быстрее на совместимом рантайме, но набор доступных уровней там уже, а поддержка на AMD зависит от версии стека.
Практический порядок такой: сначала GGUF, потому что на нём проще проверить совместимость с Hermes и раскладку по картам. Если модель и формат подходят, можно пробовать GPU-специфичные варианты и сравнивать их по времени до первого токена и стабильности JSON.
Квантизация KV-cache для длинного контекста
KV-кэш квантизуется отдельно от весов, например в Q8 или Q4. Это освобождает гигабайты на длинном контексте, но может влиять на качество, особенно на задачах с точным соблюдением формата. Для агента с контекстом 32k и выше квантизация кэша часто единственный способ обойтись без offload.
Проверять эффект нужно на своих сценариях: возьмите типовую задачу с вызовом инструмента, прогоните её с кэшем в FP16 и в Q8, сравните корректность аргументов и потребление памяти. Общие утверждения про «незаметную потерю качества» здесь мало помогают, поскольку результат зависит от модели и длины контекста.
Запуск на двух AMD-видеокартах: распределение и софт
Две карты разного объёма - несимметричный пул. Рантайм позволяет задать пропорции распределения слоёв, но по умолчанию он не знает, что 32 ГБ быстрее, чем 16 ГБ в паре с ними. Логика простая: заполнять R9700 первой, вторую карту использовать как дополнение, а в RAM не выгружать ничего, что вызывается на каждом шаге агента.
Tensor split и offload: практические ориентиры
Проверьте, что KV-кэш распределяется вместе со слоями, а не остаётся целиком на одной карте: на длинном контексте он занимает существенную долю памяти. Логи рантайма показывают, сколько слоёв ушло на какое устройство и сколько выгружено в RAM. Если выгрузка видна на старте при пустом диалоге, дальше будет хуже.
Полезно заранее ограничить контекст параметром запуска и увеличивать его по мере необходимости. В статье про настройку llama.cpp для длинного контекста разобраны split-mode, fit-ctx и выгрузка эмбеддингов: это те же рычаги, которыми вы будете управлять памятью на своей связке.
ROCm, Vulkan и драйверы: что учесть
На AMD есть два основных пути: ROCm и Vulkan-бэкенд в llama.cpp. ROCm даёт лучшую производительность на поддерживаемых картах, но список совместимых моделей GPU и версий ограничен, а потребительские карты попадают в него не всегда. Vulkan обычно проще заводится на смешанной конфигурации, хотя по скорости может уступать.
Поддержка меняется от релиза к релизу, поэтому сверяйтесь с документацией конкретной версии рантайма и драйвера, а не со статьями годичной давности. Если модель не стартует или падает при загрузке весов, это чаще вопрос стека, чем модели. Держите под рукой второй бэкенд как запасной вариант.
Как тестировать модели под Hermes без выдуманных бенчмарков
Чужие цифры с другой конфигурации не переносятся: скорость зависит от квантования, длины контекста, версии рантайма и раскладки по картам. Рабочий подход - фиксированный набор задач и свои замеры. Ниже минимальный сценарий проверки.
Минимальный тест tool calling
Соберите два инструмента: поиск по локальному файлу и калькулятор. Первая задача требует вызова поиска, вторая - арифметики через калькулятор, третья не требует инструментов вовсе. Запустите модель через llama.cpp, Ollama или LM Studio и посмотрите на три вещи: вызывает ли модель функцию вообще, правильно ли заполняет аргументы, обрабатывает ли результат вызова и продолжает ли работу.
Отдельно проверьте поведение при ошибке: верните инструментом сообщение о неудаче и посмотрите, пробует ли модель другой путь или повторяет тот же вызов по кругу. Для Hermes второй вариант означает зацикливание агента.
Что смотреть в логах и метриках
Набор сигналов небольшой, но по нему видно, стоит ли доводить модель до продакшена в агентной роли.
| Сигнал | Что означает |
|---|---|
| Слои на каждом GPU | Сколько модели легло на R9700, сколько на RX 7800, есть ли перекос на медленную карту |
| VRAM под веса и кэш | Запас до переполнения и место под рост контекста |
| Выгрузка в RAM | Прямой признак просадки скорости на каждом шаге агента |
| Время до первого токена | Насколько долго Hermes ждёт ответа на длинном промпте с описанием инструментов |
| Доля корректных вызовов | Основная метрика пригодности модели: сколько раз JSON и имя функции оказались верными |
| Поведение на 20-30 шаге | Держит ли модель системные инструкции к середине диалога |
Сравнивайте модели на одинаковом сценарии и одинаковом контексте, иначе сравнение ничего не значит. Результаты удобно держать в таблице: модель, квантование, контекст, раскладка по картам, время до первого токена, доля корректных вызовов инструментов.
Ограничения конфигурации и что делать дальше
64 ГБ RAM - главное ограничение сборки. Их хватает системе и небольшому кэшу, но не на полноценный offload 70B. Две карты разного объёма создают асимметрию: слои, попавшие на RX 7800, тормозят общий шаг. Поддержка tool calling зависит от модели и шаблона чата, а не от железа, и обновление рантайма иногда ломает то, что работало вчера.
Ещё один фактор - шина. Если карты стоят в слотах с урезанным числом линий PCIe, пересылка данных между устройствами становится узким местом. Проверьте, как устройства видны системе, прежде чем винить модель в медленной работе.
Порядок действий: начать с dense-модели 24-34B с подтверждённой поддержкой function calling, прогнать тест инструментов, подключить к Hermes и замерить время до первого токена и долю корректных вызовов. Затем попробовать MoE с 3-12B активных параметров и сравнить на тех же задачах. К 70B в Q3-Q4 переходить последним и только с ограниченным контекстом. Если упор в RAM станет постоянным, добавление памяти даст больше, чем смена модели.