ModCon 2026: кроссаппаратная поддержка MAX

Не меняйте производственную платформу вывода сразу после ModCon 2026: на этой неделе сохраните текущий стек и запустите двойную проверку MAX на собственных моделях. Переход оправдан только после того, как официально доступны нужные компоненты, целевая модель запускается на каждой выбранной архитектуре, результаты повторяются, а аварийный откат занимает заранее согласованное время.

Последнее обновление: 18 августа 2026 года. Факты о мероприятии и заявленных направлениях сверены с официальной страницей ModCon 2026, документацией MAX, официальным репозиторием и сообщением Qualcomm о приобретении Modular.

Эта статья предназначена для трёх групп: инфраструктурных руководителей, планирующих закупки или расширение мощностей NVIDIA и AMD; команд, поддерживающих собственные сервисы открытых моделей; инженеров, которым интересен Mojo 1.0, но нужна не презентационная формулировка, а производственный результат.

Решение до просмотра демонстраций

ModCon 2026 важен как повод повторно проверить архитектурные решения, но не как самостоятельное основание для миграции. На официальной странице мероприятия заявлены единый вычислительный слой, MAX, Mojo 1.0, работа с несколькими типами чипов, Qualcomm NPU и отдельная сессия «Inside the MAX Inference Stack». Там же указаны дата 18 августа 2026 года, площадка в Сан-Франциско и бесплатная трансляция для удалённых зрителей. (modular.com)

Для закупочного или эксплуатационного решения мы разделяем три уровня:

1. Демонстрация — модель или kernel запускаются в подготовленном сценарии на сцене.
2. Доступность продукта — опубликованы пакет, контейнер, версия, лицензия и инструкция.
3. Производственная переносимость — команда может повторить запуск, выдержать длительную нагрузку, наблюдать ошибки и вернуться на прежний стек.

Именно третий уровень определяет, можно ли менять сервис. Минимальный порог следует зафиксировать до теста:

• официальный пакет или контейнер можно скачать без ручного доступа к закрытой демонстрационной среде;
• нужная модель есть в поддерживаемом перечне либо имеет документированный путь импорта;
• тест воспроизводится на двух независимых запусках;
• результаты измеряются на собственном трафике и собственных ограничениях памяти;
• сохранён прежний контейнер, маршрут запросов и способ отката.

Если хотя бы один пункт не выполнен, решение должно быть «двойной контур», а не «немедленная замена».

ModCon 2026 и кроссаппаратная поддержка MAX

Главная ошибка при чтении обещания «один слой для каждого чипа» — считать одинаковыми все уровни программного стека. В действительности нужно отдельно проверить модель, граф вычислений, kernel, драйвер, контейнер и способ оркестрации.

Официальная документация MAX прямо описывает поддержку NVIDIA и AMD GPU, а в руководстве по сравнению производительности приведены отдельные контейнеры и отдельные команды запуска для этих архитектур. Для NVIDIA используется контейнер modular/max-nvidia-full, для AMD — modular/max-amd; различаются параметры доступа к устройствам и требования к программной среде. (документация MAX)

Это уже полезное доказательство переносимости, но не доказательство полной взаимозаменяемости. Для каждой пары необходимо установить статус:

Особенно осторожно следует трактовать Apple Silicon. В одних официальных материалах Modular описывается запуск MAX-моделей на новых Apple GPU, а в текущей документации одновременно сохраняется ограничение для крупного GenAI-инференса на Apple Silicon. Changelog также отмечает, что поддержка развивается, а часть возможностей может зависеть от версии и конкретной модели. Поэтому Mac подходит для локальной проверки графов, API и небольших моделей, но не должен автоматически считаться заменой серверного GPU. (обсуждение поддержки Apple Silicon)

Для AMD и NVIDIA вопрос формулируется практичнее: «один ли это сервис», а не «работает ли один и тот же файл». Нужно проверить:

• одинаковый формат входа и выхода;
• одинаковую токенизацию и версию весов;
• наличие одинаковых attention, cache и quantization kernels;
• одинаковую схему batching;
• одинаковые health-check и метрики;
• возможность переключить контейнер без изменения маршрутизации запросов.

До тех пор пока это не проверено, правильнее говорить о едином направлении разработки, а не о готовом универсальном runtime.

Порог совместимости для конкретной модели

Совместимость модели нельзя выводить из списка архитектур GPU. В документации MAX отдельно указаны поддерживаемые модели, требования к памяти и возможность работы на нескольких GPU. Даже при наличии подходящей архитектуры конкретной системе может не хватить памяти либо необходимый граф может быть доступен только для одной аппаратной ветки. (пакеты и поддерживаемые модели MAX)

При проверке мы рекомендуем вести матрицу не «AMD против NVIDIA», а «модель плюс версия плюс контейнер»:

Публичная инструкция benchmark для MAX предлагает тестировать пропускную способность, задержку и загрузку GPU, а также использовать подготовленный endpoint и скрипт измерений. Это хороший базовый сценарий, но его нельзя подменять собственным тестом: benchmark показывает поведение эталонной модели, тогда как эксплуатационные проблемы часто появляются на пользовательских kernels, длинном контексте или нестандартной квантовании. (руководство по benchmark MAX)

Можно ли запускать одну модель на AMD и NVIDIA

Да, для части моделей это уже выглядит реалистично, но формулировка «один и тот же сервис» требует ограничений. Официальные материалы Modular описывают отдельные контейнеры для NVIDIA и AMD, а публикация о версии 25.6 заявляла поддержку NVIDIA Blackwell, AMD MI355X, AMD MI325X, Apple Silicon и других GPU. При этом часть результатов была обозначена как ранняя или развивающаяся, особенно для новых аппаратных направлений. (публикация Modular о версии 25.6)

В рабочем проекте следует создать два независимых профиля:

• model-id, commit весов и параметры генерации;
• batch size, максимальная длина входа и лимит нового вывода;
• число параллельных запросов;
• размер KV-cache;
• контейнер и digest;
• версия драйвера;
• схема мониторинга;
• критерий остановки теста.

Нельзя сравнивать одну систему при batch size 8 с другой при batch size 1, даже если модель и промпт одинаковы. Нельзя также сопоставлять разовый прогон на пустом сервере с длительным тестом после прогрева кэша.

Воспроизводимость производительности

Производительность MAX должна проверяться на четырёх показателях: пропускная способность, время до первого токена, стабильность при длительной нагрузке и пиковое потребление памяти. Числа из презентации полезны как гипотеза для теста, но не как бюджетная модель.

Публикация Modular о 25.6 утверждала, что результаты на NVIDIA B200 и AMD MI355X можно воспроизводить публичным benchmark-скриптом. Это сильнее обычной презентационной цифры, однако даже такой результат нужно повторить на собственной версии модели, контейнера и клиента.

Практический порядок проверки:

1. Зафиксировать commit модели, tokenizer и формат весов.
2. Записать версию MAX, контейнера, драйвера и операционной системы.
3. Провести прогрев до стабильного состояния и отдельно измерить cold start.
4. Выполнить тест с одинаковыми входными и выходными длинами.
5. Повторить тест при нескольких уровнях параллелизма.
6. Провести длительный прогон до появления деградации, ошибок памяти или роста очереди.
7. Сохранить логи, показатели GPU, ошибки компилятора и фактические параметры запуска.

Для команд с жёстким SLA важнее не максимальное значение токенов в секунду, а нижний процентиль задержки при рабочей нагрузке. Если MAX показывает высокий throughput только после увеличения batch size, но ухудшает время до первого токена, такой результат может быть неприемлем для интерактивного помощника.

Важное ограничение: одинаковый запуск модели не означает одинаковую стоимость запроса. Электроэнергия, аренда ускорителя, время прогрева, простои, объём памяти и работа инженера по сопровождению входят в полную стоимость сервиса вывода.

Переносимость кода и скрытая стоимость

Миграция обычно ломается не на базовом вызове модели, а на периферии. OpenAI-совместимый API может сохраниться, но изменятся таймауты, структура потоковых ответов, обработка отменённых запросов или формат диагностических заголовков.

Перед пилотом нужно оценить пять групп изменений:

• Код — пользовательские операторы, кастомные kernels, постобработка и обработка ошибок.
• Модели — формат весов, квантование, tokenizer, LoRA и загрузка адаптеров.
• Образы — базовый Linux-слой, системные библиотеки, драйверный runtime и кэш компиляции.
• Эксплуатация — health-check, метрики, алерты, логирование и автоскейлинг.
• Откат — сохранённый образ старого сервиса, совместимый контракт API и правило переключения трафика.

Разработку и производственное переключение нужно считать двумя разными проектами. В первом проверяется, запускается ли модель. Во втором требуется доказать, что обновление можно остановить, неисправный узел убрать из пула, а старую версию вернуть без ручного восстановления окружения.

Влияние Mojo 1.0 на решение

Mojo 1.0 может изменить оценку долгосрочных рисков, но сам номер версии не доказывает зрелость всей платформы вывода. На странице ModCon отдельная сессия посвящена «Mojo 1.0 and the Open Road Ahead», однако окончательные сведения об API, компиляторе, лицензии и составе открытого кода необходимо проверять по версии, репозиторию и опубликованным release notes. (официальная программа ModCon)

Для руководителя платформы важны следующие вопросы:

• какой API имеет стабильную гарантию совместимости;
• какие функции остаются experimental или nightly;
• можно ли зафиксировать версию компилятора;
• как публикуются исправления безопасности;
• где отслеживаются регрессии;
• возможно ли собрать прежний binary после обновления;
• распространяются ли используемые kernels на условиях, совместимых с политикой организации.

Открытый исходный код снижает зависимость от закрытой реализации, но добавляет обязанность самостоятельно следить за лицензиями, сборками и изменениями ABI. Поэтому Mojo 1.0 следует учитывать как фактор поддерживаемости, а не использовать как автоматический аргумент для замены текущего сервиса.

Версионная дисциплина и отказоустойчивость

В production-оценке MAX важны не только поддерживаемые устройства, но и граница между stable и nightly. Официальный репозиторий указывает отдельные ветки для стабильных MAX и Mojo, а основная ветка синхронизируется с nightly и может содержать новые ошибки.

Перед испытанием зафиксируйте:

• точную версию MAX и Mojo;
• digest контейнера вместо тега latest;
• версию драйвера;
• commit модели и конфигурации;
• дату последнего успешного теста;
• процедуру возврата на прежний образ.

Отдельно следует проверить многокарточный режим, повторный запуск после сбоя, восстановление после нехватки памяти, сохранность кэша компиляции и поведение при отключении одного узла. Если эти процедуры описаны только в issue или обсуждении сообщества, а не в официальном руководстве, их следует считать инженерным риском, а не зрелой функцией.

Приобретение Modular компанией Qualcomm создаёт предпосылки для расширения экосистемы CPU, GPU и NPU. В официальном сообщении Qualcomm говорится о развитии открытой программной экосистемы и силикон-независимого вычислительного слоя. Однако это заявление о направлении и инвестициях, а не доказательство того, что конкретный Qualcomm NPU уже имеет нужный контейнер, модель, мониторинг и SLA.

Оценка решений по метрикам

Ниже — рабочая шкала, которую мы рекомендуем применять после публикации материалов ModCon. Оценка не заменяет нагрузочный тест, но помогает не смешивать маркетинговую привлекательность с готовностью к эксплуатации.

Интерпретация должна быть консервативной:

• высокий балл по поддержке и модели, но низкий по эксплуатации — только ограниченный пилот;
• preview для ключевого ускорителя — двойной контур;
• неподдерживаемый оператор или обязательный SLA — пауза;
• подтверждённая производительность без стоимости переноса — не основание для закупки.

Проверка перед первым пилотом

Перед тем как включать MAX в реальный маршрут, мы советуем пройти этот список и сохранить его как часть архитектурного решения:

• [ ] Зафиксирована модель, версия весов, tokenizer и параметры квантования.
• [ ] Получены официальные ссылки на совместимость целевого GPU и выбранной модели.
• [ ] Скачан конкретный контейнер или пакет, а не только показан пример на сцене.
• [ ] Записаны версия MAX, версия Mojo, драйвер и операционная система.
• [ ] Проверены отдельные контейнеры для NVIDIA и AMD.
• [ ] Выполнен одинаковый тест на двух аппаратных средах.
• [ ] Сравнены throughput, время до первого токена, p95-задержка и память.
• [ ] Проведён длительный прогон с рабочим уровнем параллелизма.
• [ ] Проверены потоковые ответы, отмена запросов, таймауты и health-check.
• [ ] Подключены логи, метрики GPU, ошибки компиляции и алерты.
• [ ] Проверен запуск после очистки кэша.
• [ ] Подготовлен прежний контейнер и описана процедура rollback.
• [ ] Для nightly определён запрет на автоматическое обновление.
• [ ] Указан владелец решения и дата повторной проверки после выхода новой версии.

Итог для планирования мощностей

MAX уже имеет признаки серьёзной кроссаппаратной стратегии: официальные сценарии для NVIDIA и AMD, отдельные контейнеры, benchmark-инструменты, открытые компоненты и расширяющуюся поддержку Apple Silicon. Но эти признаки не отменяют различий между GPU, моделями, драйверами и производственными режимами.

Для команды, которой нужно снизить зависимость от одного поставщика ускорителей, разумный план выглядит так:

1. сохранить действующий производственный сервис;
2. выбрать одну модель с минимальным количеством пользовательских kernels;
3. протестировать её на текущей и альтернативной архитектуре;
4. перенести только часть некритичного трафика;
5. измерить стоимость и стабильность;
6. принять решение после проверки отката, а не после просмотра презентации.

Если требуется оценить модели на коротком цикле, без немедленной закупки оборудования, сначала полезнее использовать руководство по проверке AI-среды на Apple Silicon и чек-лист развёртывания открытых моделей. Для более широкого выбора между собственной инфраструктурой и внешней средой можно начать с русскоязычной страницы JexMac.

Текущая схема на одном NVIDIA или AMD-кластере обычно проигрывает не только из-за цены ускорителей: она создаёт зависимость от одного драйверного стека, усложняет расширение при дефиците конкретного GPU и оставляет меньше вариантов для временной проверки новых моделей. При этом немедленный переход на MAX тоже не бесплатен — придётся оплачивать тестовую миграцию, повторять валидацию и поддерживать запасной маршрут. Поэтому для краткосрочной проверки гипотезы аренда Mac-среды через JexMac может быть удобнее покупки отдельной рабочей станции: она позволяет быстро проверить совместимость, контейнеры и локальные сценарии без преждевременного отказа от действующей производственной платформы.