Текущий статус: кто готов запускать Ling-3.0-flash прямо сейчас
Ling-3.0-flash от Ant Group - гибридная MoE-модель с вниманием KDA + MLA, которая уже доступна на OpenRouter с бесплатным API до 3 августа 2026 года. Мы проверили состояние поддержки в трёх основных инференс-фреймворках. SGLang заявил о day-0 поддержке и уже работает с командой Ant Group над интеграцией. vLLM отложил реализацию до публикации открытых весов. llama.cpp закрыл реквест на добавление BailingMoE V2.5 как not_planned, а предыдущий PR на Ling v2 пролежал неслитым почти три месяца. Порядок появления поддержки предсказуем: SGLang первым, затем vLLM, последним - gguf от llama.cpp.
Подробный разбор архитектуры модели и её бенчмарки мы уже публиковали в обзоре AntLing-3.0-flash. Здесь сфокусируемся на практическом вопросе: в каком фреймворке модель заработает быстрее всего и какие препятствия стоят перед разработчиками.
SGLang: day-0 поддержка и сотрудничество с Ant Group
SGLang публично объявил о готовности предоставить поддержку Ling-3.0-flash в день релиза. Команда фреймворка описывает архитектуру модели как гибридное внимание KDA + MLA и уже ведёт активную интеграцию с разработчиками из Ant Group. Это означает, что SGLang, вероятно, получил ранний доступ к спецификациям или весам модели до их публичного открытия.
Для пользователя это единственный вариант запустить Ling-3.0-flash локально в ближайшее время. Стратегия SGLang - инвестировать в раннюю интеграцию и становиться первым production-готовым решением для новых моделей. Плюс очевиден: вы получаете доступ раньше конкурентов. Минус - возможная нестабильность на старте, поскольку интеграция происходит в сжатые сроки.
vLLM: ожидание открытых весов
vLLM занял выжидательную позицию. Поддержка Ling-3.0-flash отложена до публикации открытых весов модели. Команда vLLM при этом одобрила паттерн «анонс до открытия весов» как желаемую практику для других вендоров - то есть сам подход не отвергается, но реализация начнётся только после появления публичных артефактов.
Прогноз: поддержка в vLLM появится вскоре после выхода весов. Фреймворк предпочитает стабильность и проверенные спецификации, что снижает риск сломанных билдов. Для production-окружений, где критична надёжность, это оправданный подход. Если вы уже используете vLLM в продакшене и не готовы переключаться на SGLang ради одной модели, придётся подождать.
llama.cpp: проблема не в KDA, а в Bailing MoE
Ситуация с llama.cpp наиболее проблемная. Реквест на добавление BailingMoE V2.5 - архитектуры, использованной в Ling 2.6 и, вероятно, в Ling 3.0 - закрыт как not_planned. Предыдущий PR на поддержку Ling v2 провисел неслитым почти три месяца. Ключевая проблема не в ядрах KDA - они уже реализованы в llama.cpp для других моделей. Препятствие - отсутствие конвертера для Bailing MoE.
Это задача, требующая добровольца из сообщества, а не фундаментально сложная техническая проблема. Пока никто не взялся написать конвертер, поддержка llama.cpp остаётся под вопросом. Подробнее о том, как архитектурные особенности MoE-моделей тормозят интеграцию в llama.cpp, мы разбирали на примере Minimax M3 - ситуация схожая.
Почему сроки публикации весов - ключевой фактор
Ant Group следует устоявшемуся паттерну: веса публикуются после окончания бесплатного доступа к API. Для Ling-3.0-flash этот период истекает 3 августа 2026 года. Это объясняет, почему vLLM и llama.cpp не могут начать интеграцию раньше - у них нет доступа к артефактам модели. SGLang, судя по заявлениям о day-0 поддержке, получил ранний доступ к спецификациям или находится в прямом контакте с командой Ant Group.
После 3 августа ситуация изменится быстро. vLLM, имея все необходимые спецификации, сможет добавить поддержку в течение дней или недель. llama.cpp потребуется больше времени - даже при наличии весов нужен конвертер для Bailing MoE, а его пока нет. Если вы планируете использовать Ling-3.0-flash в production, закладывайте в таймлайн именно эти сроки.
Сравнение подходов: почему SGLang вырывается вперёд
Разница в стратегиях трёх фреймворков становится очевидной на примере Ling-3.0-flash. SGLang инвестирует в раннюю интеграцию, работая напрямую с разработчиками моделей. Это даёт преимущество по времени, но требует ресурсов на поддержку предварительных спецификаций. vLLM предпочитает стабильность и ждёт публичных артефактов - меньше риска, но и доступ позже. llama.cpp полностью зависит от сообщества: если доброволец не найдётся, поддержка может не появиться вовсе.
Для пользователя выбор фреймворка под Ling-3.0-flash сводится к приоритетам. Нужна скорость - SGLang. Нужна стабильность и привычное окружение - vLLM после выхода весов. Хотите запускать модель на локальном оборудовании с квантованием - llama.cpp, но сроки неопределённые. Практический пример того, как выбор метода декодирования влияет на производительность в SGLang и vLLM, мы разбирали в бенчмарке спекулятивного декодирования - эти же принципы применимы и к Ling-3.0-flash.
Прогноз: порядок появления поддержки и что это значит для вас
На основе анализа текущего состояния интеграции порядок предсказуем: SGLang первым, vLLM вторым, llama.cpp последним. Конкретные сроки зависят от даты публикации весов, но общая последовательность не вызывает сомнений.
Если вам нужно «здесь и сейчас» - SGLang
SGLang - единственный вариант с гарантированной поддержкой в ближайшее время. Если вы участвуете в гонке AI-продуктов и каждая неделя на счету, это ваш выбор. Модель уже доступна через OpenRouter, а с day-0 поддержкой SGLang вы сможете развернуть её локально сразу после релиза весов. Готовьте окружение заранее - документация SGLang обновляется оперативно.
Если вы готовы подождать стабильности - vLLM
vLLM обеспечит поддержку сразу после выхода весов, в привычном для многих production-окружении. Если ваш стек уже построен на vLLM, переключение на SGLang ради одной модели может не окупиться. Подождите публикации весов - интеграция в vLLM, учитывая одобренный паттерн «анонс до открытия», будет быстрой. Ожидаемый срок - от нескольких дней до пары недель после 3 августа.
llama.cpp: надежда на сообщество
Без добровольца, готового написать конвертер для Bailing MoE, поддержка в llama.cpp может затянуться на месяцы. Ядра KDA уже реализованы, технических блокеров нет - нужен человек, который возьмётся за задачу. Если вы заинтересованы в запуске Ling-3.0-flash через llama.cpp, отслеживайте issues в репозитории проекта. По опыту с другими MoE-моделями, как только конвертер появляется, поддержка добавляется относительно быстро. Пример того, как сообщество решает похожие проблемы, мы разбирали в статье про оптимизацию инференса DeepSeek-V4-Flash - там тоже всё упёрлось в архитектурные нюансы MoE.
Технические детали: что нужно знать об архитектуре Ling-3.0-flash
Для понимания причин задержек и различий в подходах фреймворков полезно разобраться в архитектуре модели. Ling-3.0-flash использует два ключевых компонента: гибридное внимание KDA + MLA и архитектуру Bailing MoE.
KDA и MLA: гибридное внимание в деталях
KDA (Kernelized Dynamic Attention) - механизм динамического внимания, который оптимизирует вычисления за счёт ядерной аппроксимации. MLA (Multi-head Latent Attention) - латентное многоголовое внимание, снижающее размерность представлений. Гибридное сочетание KDA + MLA даёт модели высокую скорость инференса при сохранении качества. Ядра KDA уже реализованы в llama.cpp для других моделей - технически это не новинка. Проблема не в них.
Bailing MoE: корень проблемы для llama.cpp
Bailing MoE - архитектура Mixture of Experts, использованная в Ling 2.6 и, с высокой вероятностью, в Ling 3.0. MoE-модели требуют специальных конвертеров для преобразования весов в формат, совместимый с конкретным фреймворком. В llama.cpp уже есть поддержка других MoE-архитектур, например Mixtral, но Bailing MoE имеет свои особенности, под которые нужен отдельный конвертер.
Реквест на добавление BailingMoE V2.5 закрыт как not_planned - это означает, что мейнтейнеры llama.cpp не считают задачу приоритетной для себя. Реализация возможна только силами сообщества. Предыдущий PR на поддержку Ling v2 провисел неслитым почти три месяца - аналогичная судьба может ждать и Ling 3.0. Если вы разработчик с опытом в конвертерах моделей, это точка входа для контрибуции в проект.