128 ГБ унифицированной памяти на Strix Halo позволяют загрузить модель на 70B в квантизации Q4 целиком, без оффлоада весов по PCIe. Комфортно, то есть с отзывчивым интерфейсом, на этой платформе работают модели класса 27-35B в Q4 или Q5: они дают приемлемую скорость генерации и лучшее качество в задачах кодинга среди всего, что реально укладывается в бюджет по пропускной способности памяти. Все, что крупнее, запускается, но превращается в инструмент для пакетной обработки, а не для живого диалога.
Причина простая: объем памяти и скорость памяти решают разные задачи. Объем определяет, влезет ли модель вместе с KV-кэшем. Пропускная способность определяет, сколько токенов в секунду вы увидите на выходе. На Strix Halo с 256-битной шиной LPDDR5X-8000 потолок около 256 ГБ/с, а дискретные карты дают в 4-7 раз больше.
Дальше разбор по классам моделей, узким местам платформы и сценариям, где большой пул памяти дает реальную пользу, а где упирается в вычисления и CPU.
Что такое Strix Halo и почему 128 ГБ памяти не равны 128 ГБ VRAM
Strix Halo это кодовое имя APU AMD линейки Ryzen AI Max и Ryzen AI Max+. В одном корпусе собраны CPU на архитектуре Zen 5 (до 16 ядер и 32 потоков у Max+ 395), встроенная графика Radeon 8060S на 40 вычислительных блоках RDNA 3.5, NPU XDNA 2 и 256-битный контроллер памяти. Память LPDDR5X распаяна на плате и работает на частоте до 8000 МТ/с, что дает теоретический потолок около 256 ГБ/с.
Ключевое отличие от сборки с дискретной картой: пул памяти один. Процессор, iGPU и NPU берут данные из него же. В BIOS задается размер буфера, закрепленного за графикой, остальное достается системе. Отсюда и путаница: человек видит 128 ГБ и ждет поведения видеопамяти.
Unified memory vs VRAM: в чём разница на практике
Плюсов у общей памяти два. Первый: модель не нужно копировать через PCIe, нет узкого места шины при загрузке и переключении. Второй: нет лимита в 24 или 32 ГБ, который есть у потребительских карт, поэтому 70B в Q4 помещается без выгрузки части слоев на CPU.
Минус тоже один, но тяжелый: скорость. Верхний уровень дискретных решений на начало 2026 года: RTX 4090 с 24 ГБ GDDR6X дает порядка 1 ТБ/с, RTX 5090 с 32 ГБ GDDR7 около 1.8 ТБ/с. Это в 4-7 раз выше, чем 256 ГБ/с у Strix Halo.
Удобная аналогия: объем памяти это размер бака, пропускная способность это диаметр трубы. Бак на 128 литров с трубой толщиной в палец наполнится не быстрее, чем канистра с нормальным шлангом.
Следствие, которое многих удивляет: 70B в Q4 на Strix Halo вполне может генерировать текст медленнее, чем 8B на дискретной карте. Меньшая модель на быстрой памяти выигрывает по отзывчивости, хотя знаний у нее меньше.
Второй нюанс: пул общий, поэтому iGPU и CPU конкурируют за один и тот же контроллер. Когда параллельно с инференсом работает агентная логика (парсинг ответов, вызовы инструментов, работа с файлами), часть полосы забирают системные процессы.
Почему bandwidth важнее объёма при инференсе LLM
Запрос к модели проходит две стадии с разной природой нагрузки. Prefill обрабатывает весь промпт сразу, параллельно по всем токенам, и держится на вычислениях: упирается в шейдеры iGPU. Decode генерирует по одному токену, и на каждом шаге нужно прочитать веса активных параметров из памяти. Это memory-bound задача.
Отсюда простая оценка сверху: скорость decode примерно равна пропускной способности памяти, деленной на объем активных весов на токен. Посчитаем по Strix Halo (это расчет по bandwidth, а не результат замера):
- Модель 32B в Q4_K_M весит около 19 ГБ. 256 / 19 ≈ 13 токенов/с как верхняя граница.
- Модель 70B в Q4 около 40 ГБ. 256 / 40 ≈ 6 токенов/с как верхняя граница.
- Модель 8B в Q5 около 5.5 ГБ. Потолок выше 40 токенов/с.
Реальные цифры всегда ниже расчетных из-за накладных расходов, неполного использования шины, особенностей бэкенда и работы с KV-кэшем. Но соотношение сохраняется: рост модели вдвое снижает скорость генерации примерно вдвое.
Запас памяти позволяет модели загрузиться. Пропускная способность решает, будет ли ей приятно пользоваться.
Какие локальные модели реально запускаются на Strix Halo с 128 ГБ
Размер весов зависит от квантизации и архитектуры, поэтому цифры ниже ориентировочные, но порядок величин устойчивый.
| Класс модели | Размер в Q4_K_M | Скорость decode, ориентир | Для чего годится |
|---|---|---|---|
| 7-14B | 4-9 ГБ | десятки токенов/с | чат, автодополнение, мелкие правки |
| 24-35B | 14-22 ГБ | от единиц до десятков токенов/с | кодинг, агенты, повседневная работа |
| 70-72B | 40-45 ГБ | единицы токенов/с | batch, длинный контекст, RAG |
| MoE 100B+ с активными 3-20B | 55-70 ГБ | зависит от числа активных экспертов | эксперименты, batch, сложные рассуждения |
27-35B: рабочая лошадка для кодинга
Сюда попадают Qwen2.5-Coder-32B, Gemma 2 27B, Mistral Small, Command R. В Q4_K_M они занимают 18-20 ГБ, в Q5_K_M около 22-24 ГБ. Из 128 ГБ остаются десятки гигабайт под KV-кэш, контекст и системные задачи.
На кодинге этот класс закрывает большую часть повседневных задач: генерация функций, рефакторинг, разбор чужого кода, написание тестов, миграции. Модели на 7-14B на таких задачах чаще путаются в структуре проекта и теряют контекст файла, а 70B дает прирост качества, за который приходится платить скоростью.
Незадействованные десятки гигабайт это нормальная ситуация, а не сигнал срочно грузить модель побольше. Если 32B в Q5 уверенно решает ваши задачи, остаток памяти лучше отдать под длинный контекст и параллельные сессии, чем под веса, которые замедлят генерацию в разы.
70B и выше: влезает, но стоит ли
Llama 3.3 70B в Q4_K_M занимает около 40-43 ГБ, Qwen2.5-72B около 44 ГБ. С KV-кэшем на контекст 32-64K это 50-55 ГБ, то есть меньше половины пула. Памяти хватает с большим запасом.
Проблема в скорости. При потолке 256 ГБ/с decode упирается в единицы токенов в секунду, и ответ на 500 токенов растягивается на минуты. Для чата и интерактивного кодинга это тяжело: пока модель пишет функцию, вы успеваете переключиться на другую задачу и потерять нить.
Где 70B оправдана: пакетная суммаризация, разметка датасетов, оффлайн-анализ документов, генерация черновиков, где задержка не критична. Там более высокое качество ответов и меньше выдумок окупают ожидание.
Модели крупнее 100B тоже помещаются. gpt-oss-120B в MXFP4 занимает около 60 ГБ и стартует на 128 ГБ без выгрузки на диск. Ограничения те же: медленный prefill на длинном контексте и общая полоса памяти, которую делят iGPU и CPU. Как считать веса и KV-кэш, подробно разобрано в материале про расчет VRAM, весов и KV-кэша под конкретную модель.
MoE-модели: скрытый резерв Strix Halo
В моделях со смесью экспертов (Mixture of Experts) на каждый токен активируется лишь часть весов. Mixtral 8x7B задействует около 13B активных параметров, Qwen3-30B-A3B около 3B, gpt-oss-120B около 5B при общем объеме 117B.
Для bandwidth это выгодно: память хранит все эксперты, а на каждом шаге decode читается только активная часть. Эффективная скорость генерации получается заметно выше, чем у плотной модели того же общего размера. Именно поэтому MoE это самый разумный способ занять оставшиеся гигабайты на Strix Halo.
Оговорки, которые стоит держать в голове. Поддержка MoE в llama.cpp и других бэкендах требует свежих сборок, старые версии обрабатывают экспертов медленнее или некорректно. Если эксперты частично выгружаются, преимущество по скорости пропадает. Prefill у MoE остается тяжелым: роутеру нужно обработать весь промпт, а это снова упирается в вычисления iGPU. Итог: MoE выигрывает на генерации и проигрывает на обработке длинных промптов.
Скорость инференса на Strix Halo: чего реально ждать
Скорость зависит от четырех вещей: размера модели, квантизации, длины контекста и выбранного бэкенда. Конкретные tokens/s меняются от версии софта к версии, поэтому ориентируйтесь на диапазоны, а не на точные числа.
Ориентировочно: 7-14B дают десятки токенов в секунду, 27-35B от единиц до десятков в зависимости от квантизации и контекста, 70B уверенно уходят в единицы. Первый токен всегда приходит позже остальных, потому что до него идет prefill всего промпта.
Prefill vs decode: где именно тормозит Strix Halo
Prefill обрабатывает промпт целиком и держится на вычислениях. У Radeon 8060S 40 вычислительных блоков, у дискретных карт того же класса их в два-три раза больше, да и частота выше. Поэтому длинный системный промпт, большой RAG-контекст или чат с историей на несколько тысяч токенов заметно увеличивают время до первого токена.
Практический вывод: если интерфейс кажется зависшим после отправки запроса, это не сбой, а prefill. Сокращение системного промпта и разбиение тяжелых задач на короткие сессии дают больше эффекта, чем смена квантизации.
Как квантизация влияет на скорость и качество
Q4_K_M это стандарт для моделей от 30B: веса сжимаются примерно в четыре раза, decode ускоряется пропорционально, а потери качества на обычных задачах умеренные. Q5_K_M занимает на 15-20% больше памяти и дает небольшой прирост точности. Q6_K и Q8_0 почти не теряют в качестве, но требуют вдвое больше памяти и замедляют генерацию.
Для 27-35B на Strix Halo разумная отправная точка это Q4_K_M или Q5_K_M, если позволяет контекст. На кодинге потеря качества от агрессивного квантования видна сильнее, чем в свободном чате: модель начинает путать имена функций, терять типы и пропускать граничные случаи. Если код критичный, сравните Q4 и Q5 на своих задачах, разница может оказаться важнее лишних токенов в секунду.
Параллельный запуск агентов: почему CPU становится узким местом
Памяти на несколько инстансов хватает: две модели по 20 ГБ и KV-кэш к ним спокойно укладываются в пул. Проблема в том, что каждый агент требует не только decode, но и prefill, парсинг ответов, вызовы инструментов, работу с файловой системой и промежуточные проверки. Вся эта логика ложится на CPU и делит полосу памяти с iGPU.
Сколько агентов реально тянет Strix Halo
Ориентир по практике: один-два активных агента с моделями 27-35B работают предсказуемо. Три и больше приводят к очередям, когда агенты ждут не своей генерации, а освобождения ресурсов. Многое зависит от того, насколько одновременно они активны и насколько тяжелые у них промпты: два агента, которые по очереди думают по 20 секунд, ощущаются лучше, чем пять, дергающих модель каждые две секунды.
Полезная метрика для самопроверки: если время отклика отдельного агента выросло до секунд, параллелизм уже не экономит время. Проще выполнить задачи последовательно, чем ждать, пока пять процессов поделят между собой одну шину.
Как разгрузить CPU: архитектурные обходы
Вариант первый: одна модель с function calling вместо нескольких специализированных. Разные системные промпты дешевле, чем несколько загруженных весов. Вариант второй: кэшировать промежуточные результаты, чтобы агенты не пересчитывали одно и то же. Вариант третий: вынести оркестрацию (роутинг, RAG, вызовы инструментов) на отдельную машину, оставив на Strix Halo только инференс. Вариант четвертый: асинхронные пайплайны, где агенты не блокируют друг друга и работают на разных этапах.
Все это компромиссы, а не бесплатные улучшения: вы либо теряете в скорости одного ответа, либо усложняете архитектуру. Если вы переходите с облачных ассистентов на локальные обвязки, полезно заранее посмотреть, какие локальные инструменты дают привычный UX и что реально влезает в память.
Когда 128 ГБ unified memory дают реальную пользу
Объем важнее скорости в четырех сценариях: длинный контекст, RAG с большим индексом, пакетная обработка и эксперименты с крупными и MoE-моделями. Задачи с жесткими требованиями к задержке к ним не относятся.
Длинный контекст и RAG: где память реально решает
KV-кэш растет линейно по длине контекста. Для модели 32B с grouped-query attention на 128K токенов он занимает порядка 8-16 ГБ в зависимости от числа KV-голов и квантизации самого кэша. Плюс веса, плюс буферы. На карте с 24 ГБ такой сценарий невозможен без выгрузки, на Strix Halo он укладывается в память целиком.
Это один из немногих случаев, где 128 ГБ дают качественное преимущество: можно загрузить большой документ или индекс и не резать его на куски, теряя связи между разделами. Плата за это известна: prefill длинного контекста идет медленно, и первый ответ придется подождать.
Batch-задачи и оффлайн-обработка
Пакетная обработка не требует низкой задержки. Можно взять модель 70B, поставить ее на ночь и получить результат утром: суммаризация архива документов, классификация, разметка данных, генерация черновиков, извлечение структуры из текстов. Для домашнего или небольшого офисного сценария этого достаточно.
По суммарной пропускной способности такая машина уступает серверу с дискретными GPU, и это стоит признать сразу. Ее преимущество в другом: она помещается на столе, потребляет как обычный ПК и не требует отдельной стойки.
Настройка софта: что использовать на Strix Halo
Рабочих вариантов три: llama.cpp напрямую, Ollama и LM Studio. Ollama и LM Studio удобнее для быстрого старта, llama.cpp дает больше контроля над параметрами и раньше получает поддержку новых архитектур. Для агентных сценариев часто нужен llama.cpp или сервер с OpenAI-совместимым API.
Vulkan vs ROCm: что выбрать
Vulkan проще: ставится и работает без возни с драйверами, поддерживается основными сборками. ROCm может давать более высокую производительность на хорошо настроенной системе, но требует актуальных драйверов и времени на отладку. Утверждать, что один бэкенд всегда быстрее, нельзя: результат зависит от версии, модели и длины контекста, ситуация меняется с каждым релизом.
Практичный подход: начать с Vulkan, убедиться, что все работает, затем попробовать ROCm на своей задаче и сравнить время до первого токена и скорость генерации. Пошаговый разбор настроек платформы есть в отдельном материале про настройку Ryzen AI Max и параметров llama.cpp для локального инференса.
Параметры, которые реально влияют на скорость
- Context size. Прямо определяет размер KV-кэша и время prefill. Начните с 8-16K, увеличивайте только по необходимости.
- Batch size. Влияет на пропускную способность prefill: слишком большой упирается в память, слишком маленький оставляет iGPU без работы.
- Flash attention. Снижает расход памяти на KV-кэш и ускоряет работу с длинным контекстом, если бэкенд его поддерживает.
- Квантизация KV-кэша. Перевод кэша в Q8 сокращает его примерно вдвое, качество страдает слабее, чем при квантовании весов.
- Offload слоев. На общей памяти выгрузка на CPU не спасает от нехватки VRAM, зато может перераспределить нагрузку между CPU и iGPU.
Стартовая конфигурация для повседневной работы: модель 27-35B в Q4_K_M, контекст 16K, flash attention включен, все слои на iGPU. Дальше меняйте по одному параметру и смотрите на результат.
Strix Halo vs альтернативы: кому и зачем
Mac Studio с M4 Max и M3 Ultra тоже использует унифицированную память и тоже позволяет запускать крупные модели. Пропускная способность у старших конфигураций выше (порядка 500-800 ГБ/с), софт-стек зрелее, но выбор форматов квантизации и бэкендов уже. Дискретные карты RTX 4090 и 5090 дают в разы большую скорость при 24-32 ГБ VRAM: они выигрывают на моделях до 30B и проигрывают там, где модель просто не помещается.
Мини-ПК на GB10 с 128 ГБ общей памяти это еще один вариант с близкой идеологией и сопоставимым потолком по bandwidth. Платформа Threadripper Halo Station обещает другой баланс между числом ядер памяти и вычислительными блоками, но по ней пока не хватает данных для выводов. Если сравнивать с двумя дискретными картами среднего класса, у конфигурации вроде 2× Radeon AI PRO R9700 с 64 ГБ DDR5 будет выше скорость, но меньше суммарный доступный объем под одну модель.
Кому Strix Halo подходит
Разработчикам, которым нужны 27-35B для кодинга без отправки кода в облако. Тем, кто работает с длинным контекстом, большими документами и RAG-индексом в памяти. Тем, кто хочет экспериментировать с крупными и MoE-моделями, не покупая сервер с GPU. Тем, кому важны форм-фактор мини-ПК, тихая работа и умеренное энергопотребление.
Кому лучше смотреть в другую сторону
Тем, кому нужна максимальная скорость генерации и низкая задержка: дискретная карта даст кратный выигрыш на моделях, которые в нее влезают. Тем, кто запускает много параллельных агентов: понадобится связка CPU и GPU, а не одна APU. Тем, кто работает только с моделями до 14B: хватит более дешевого железа. Тем, кто не готов разбираться с бэкендами и драйверами: на старте это отнимает время.
Практические выводы: что запускать на Strix Halo с 128 ГБ
27-35B в Q4_K_M или Q5_K_M это оптимальный класс для повседневной работы, особенно в кодинге. Эти модели влезают с большим запасом под контекст, дают приемлемую скорость генерации и оставляют память для параллельных задач.
70B и крупнее имеет смысл держать для пакетной обработки, оффлайн-анализа и длинного контекста. Для диалога и автодополнения кода они слишком медленные: единицы токенов в секунду превращают работу в ожидание.
MoE это самый перспективный способ занять свободные гигабайты: активных параметров на токен мало, поэтому генерация остается быстрой. Нужны свежие сборки бэкендов и готовность к тому, что prefill будет тяжелым.
Параллельные агенты ограничены не памятью, а CPU и общей шиной. Реалистичный предел для интерактивной работы это один-два активных агента; остальное решается архитектурой, а не объемом ОЗУ.
Чек-лист под свою задачу:
- Определите, что критично: качество ответа или задержка. Для интерактивной работы выбирайте меньшую модель с более высоким квантованием.
- Начните с 27-35B в Q4_K_M, контекст 16K. Замерьте скорость на своих реальных запросах, а не на демо.
- Если качества не хватает, попробуйте Q5 для той же модели, прежде чем переходить на 70B.
- Свободную память отдавайте под длинный контекст и KV-кэш, а не под веса, которые замедлят генерацию.
- Для агентов ограничьте параллелизм двумя активными процессами и вынесите оркестрацию, если она съедает CPU.
- Проверяйте новую архитектуру модели на коротком сценарии, прежде чем строить на ней рабочий процесс.
128 ГБ унифицированной памяти это про возможность запустить модель, которая не влезает в VRAM, а не про скорость. Платформа окупается там, где важнее объем и автономность, чем токены в секунду.