В сообществе r/LocalLLaMA разбирают пост о looped-утечке GPT-6.1 Sol, где GPT-6 Astra называют вероятным носителем looped-архитектуры. Короткий ответ на главный вопрос: подтверждений нет ни одного. Официальных заявлений OpenAI об архитектуре Astra, Sol и Luna не публиковалось, а все числа проходов на токен взяты из неподтверждённых утечек. Но сама гипотеза полезна: она объясняет, почему слухи о рекуррентных и вложенных архитектурах снова всплыли именно сейчас.
Суть предположения в двух предложениях. Looped-трансформер выдаёт токен не за один forward pass, а за несколько повторных проходов через одни и те же веса. Это увеличивает эффективную глубину модели за счёт дополнительных вычислений. Если GPT-6 Astra действительно устроена так, то разница между дорогой Astra и дешёвой Luna может сводиться к числу проходов, доле активных параметров или схеме батчинга, а не к разным наборам весов.
Для локального AI это важно по одной причине: looped-архитектуры обещают больше качества на единицу хранимых весов. Меньше параметров в памяти, больше вычислений на токен. Для домашнего сервера с ограниченной VRAM такой размен может оказаться выгоднее, чем гонка за гигантскими моделями. Ниже разбираем механику, конкретные цифры из слухов и то, что из них реально можно использовать.
Что такое looped-трансформер и почему о нём заговорили
Обычный трансформер тратит на токен ровно один проход по своей цепочке слоёв: вход, N слоёв, выход, следующий токен. Looped-вариант переиспользует те же слои: представление токена прогоняется через один и тот же блок 2, 3 или больше раз, и только потом модель выдаёт распределение вероятностей.
Чем looped-трансформер отличается от обычного
Ключевое отличие в том, что число слоёв остаётся неизменным, а число проходов растёт. Модель на условные 32 слоя с тремя проходами даёт эффективную глубину, близкую к 96 слоям, но хранит веса только для 32. Представьте цепочку слоёв, через которую один и тот же сигнал прогоняют трижды, каждый раз уточняя его состояние, и вы получите рабочую аналогию.
Это не то же самое, что увеличить число слоёв. При росте глубины растёт и объём весов, а значит и требования к VRAM. Looped-подход оставляет веса прежними: меняется только вычислительный бюджет на инференсе. Источник гипотезы прямо описывает механику так: рекуррентность даёт модели больше эффективной глубины и позволяет выжимать пользы из имеющихся весов ценой дополнительных вычислений.
Почему это может быть выгодно на масштабе
Экономика простая. Хранение параметров стоит памяти, а инференс стоит вычислений. Если перенести часть «интеллекта» из объёма весов в повторные проходы, то на больших объёмах запросов можно снизить требования к памяти и переиспользовать одни и те же веса эффективнее. На масштабе датацентра это может давать существенную экономию: меньше параметров нужно держать и передавать, больше работы делают имеющиеся блоки.
Есть и обратная сторона. Каждый лишний проход увеличивает время генерации токена и нагрузку на вычислительные блоки. Looped-архитектура не отменяет закон сохранения: она перекладывает стоимость из памяти в вычисления. Родственные идеи уже проверяются в открытом поле. Например, 20B Looping Model обучалась в 10 раз эффективнее Qwen3 Coder 30B, потратив 3,5 трлн токенов вместо 35 трлн. Пока это не доказывает, что так работает GPT-6, но показывает, что looped-подход масштабируется хотя бы на обучении.
Слухи об Azure Foundry: 3 прохода у GPT-6-Sol и 2 у 6.1-Sol
Конкретика в слухах появилась из так называемых утечек Azure Foundry. Согласно им, GPT-6-Sol работал с 3 проходами инференса на токен, а GPT-6.1-Sol обходится 2 проходами. В сообществе эти числа стали отправной точкой для дальнейших построений.
Что именно говорят утечки
Цифры выглядят так: 3 прохода на токен у GPT-6-Sol и 2 прохода у GPT-6.1-Sol. Часть комментаторов считает, что речь могла идти об ASTRA, а не о 6-Sol, и тогда 6.1-Sol оказывается по сути той же моделью, но с двумя проходами вместо трёх. Автор поста прямо пишет, что не может ничего доказать, и это меняет статус всей информации: перед нами гипотеза, собранная из обрывков.
Официального подтверждения утечек нет. Ни один источник не показал ни конфигурацию инференса, ни архитектурные детали. Числа проходов существуют только в виде пересказа, а значит их можно использовать как повод для размышления, но не как основание для выводов.
Почему к таким утечкам стоит относиться осторожно
Утечка может быть неполной, устаревшей или неверно понятой. Даже если числа реальны, они способны относиться к тестовой конфигурации, а не к продакшену. Компания могла экспериментировать с разным числом проходов и остановиться на другом варианте к моменту релиза. Число проходов на токен легко спутать с числом шагов рассуждения, повторами промпта или структурой батча, и внешне это будет выглядеть одинаково.
Практический вывод простой: держите такие данные в отдельной категории «непроверенное». Они полезны для понимания тренда и для чтения следующих новостей, но не годятся как аргумент в спорах о том, как именно устроена модель.
Скорость инференса из Artificial Analysis: цифры и что они могут значить
Второй слой доказательств в обсуждении — это скорости инференса из Artificial Analysis. Здесь данные конкретнее и хотя бы измеримы, поскольку это замеры на одинаковой методологии, а не пересказ утечек.
Сравнение скоростей GPT-6-Sol, 6.1-Sol, Astra и Luna
| Модель | Скорость по Artificial Analysis |
|---|---|
| GPT-6-Sol | около 100 tok/s |
| GPT-5.6-Sol | около 100 tok/s |
| GPT-6.1-Sol | около 60 tok/s |
| GPT-6-Astra | около 60 tok/s |
| Luna 5.6 | 126-137 tok/s |
| Luna 6.0 | 110-115 tok/s |
Здесь и начинается загадка. Если 6.1-Sol требует 2 прохода, а 6-Sol работал с 3, логично ожидать, что новая версия окажется быстрее. По данным Artificial Analysis выходит ровно наоборот: 6.1-Sol и Astra держатся около 60 tok/s, тогда как 6-Sol и 5.6-Sol показывают примерно 100 tok/s, то есть в 1,6 раза быстрее. Скорость Luna тоже просела: с 126-137 tok/s у 5.6 до 110-115 tok/s у 6.0.
Совпадение скоростей 6.1-Sol и Astra на уровне 60 tok/s выглядит подозрительно похожим на общий ограничитель, а не на случайность. Именно это наблюдение подтолкнуло автора к гипотезе общих весов и батчированного инференса.
Почему скорость не всегда прямо связана с числом проходов
На tok/s влияет несколько факторов сразу: размер батча, загрузка GPU, оптимизация ядер под конкретное железо, кэширование промпта и длина контекста. Одна и та же модель на разных конфигурациях может давать разницу в разы. Поэтому 60 против 100 tok/s нельзя однозначно записать в минус числу проходов.
Автор поста предлагает другую трактовку: если Astra, Sol и часть Luna используют близкие веса, разница может объясняться схемой батчированного инференса. Тогда Sol вынуждена ждать лишний цикл, пока запросы Astra завершат генерацию токена, и обе модели упираются в один и тот же потолок скорости. Это объяснило бы, почему более «дешёвая» версия не оказалась быстрее. Подчеркнём: это версия из обсуждения, а не установленный факт.
Гипотеза общих весов: Astra, Sol и Luna как одна модель
Идея, к которой сходятся все предыдущие наблюдения, звучит так: Astra, Sol и Luna могут быть одними и теми же весами, а различия между ними достигаются числом проходов, долей активных параметров или настройками батчинга. Luna в этой схеме может быть Astra или Sol с половиной активных параметров либо с одним проходом на токен, что снижает стоимость обслуживания бесплатных пользователей.
Как батчированный инференс может влиять на скорость
Батчированный инференс обрабатывает запросы группами, чтобы эффективнее загружать GPU. Если у моделей общий набор весов, но разное число проходов, возникает конфликт расписания. Запрос, которому нужно 3 прохода, занимает вычислительные блоки дольше, чем запрос с 2 проходами. Группе приходится ждать самый долгий элемент батча, иначе синхронизация теряется. Так «быстрая» модель внутри одного батча с «медленной» начинает тормозить до её уровня.
Это и есть механизм, который мог бы объяснить одинаковые 60 tok/s у 6.1-Sol и Astra. Никакой мистики: обычная плата за совместное использование железа.
Что такое чередующиеся запросы и зачем они нужны
Чередующиеся запросы (interleaved requests) — это приём, при котором в паузах между циклами одной модели подставляются запросы другой, чтобы вычислительные блоки не простаивали. Если Sol ждёт завершения токена на своём дополнительном цикле, часть мощностей можно занять запросами Astra и выжать больше полезной работы из того же оборудования.
С практической стороны это означает, что различие между «моделями» на уровне API может быть не архитектурным, а сервисным: одна и та же база обслуживает разные тарифы разными режимами инференса. Гипотеза аккуратная, но пока недоказуемая снаружи.
Вложенные модели и демонстрация NVIDIA: связь со слухами
Отдельная нить обсуждения ведёт к демонстрации NVIDIA, где меньшие модели работают внутри одной большой в едином фреймворке. Речь о конструкции, в которой несколько моделей помещаются под общий «зонтик» и запускаются как единое целое, а не как отдельные сервисы. Это концепция вложенных архитектур: большая модель содержит меньшие, и они делят общий вычислительный след.
Если совместить вложенность с рекуррентностью, получается схема, которая могла бы объяснить экономию на масштабе. Большая модель задаёт общий каркас, меньшие модули внутри обслуживают лёгкие запросы, а повторные проходы добавляют глубину там, где она нужна. Автор слуха прямо говорит, что не может это доказать, но картина намекает на одновременное использование рекуррентных и вложенных архитектур. Это возможная интерпретация, а не подтверждённый факт.
Что это значит для локального AI: практические выводы
Практическая ценность слухов не в самих числах, а в сигнале: крупные лаборатории могут двигаться в сторону рекуррентных и вложенных архитектур. Для локального сообщества это важно, потому что такой тренд меняет критерии выбора моделей.
Потенциальные плюсы для локального запуска
Главный плюс, если looped-архитектуры действительно масштабируются, это меньший объём весов при той же эффективной глубине. Модель, которая сегодня не помещается в 24 ГБ VRAM, могла бы уложиться туда при looped-дизайне, а нужную глубину давали бы дополнительные проходы. Для домашнего AI-сервера это означает шанс запускать более способные модели на имеющемся железе.
Второй эффект косвенный: если OpenAI, а вслед за ней DeepSeek, Qwen и GLM начнут экспериментировать с такими архитектурами, локальные варианты могут появиться быстрее, чем ожидается. Гонка за гигантскими моделями давно упирается в память, и идея собирать рабочие решения из более компактных компонентов уже обсуждается как альтернатива. Looped-подход логично ложится в ту же логику.
Возможные ограничения и на что обратить внимание
Ограничения тоже реальны. Каждый дополнительный проход увеличивает время генерации токена, а значит снижает tok/s на том же железе. Нагрузка на GPU растёт пропорционально числу проходов даже при том же объёме весов. Если сегодня модель выдаёт 30 токенов в секунду и вы добавляете второй проход, вы можете получить 15, а не 30. Плюс возможны сложности с оптимизацией под разные бэкенды: не каждый загрузчик и не каждая библиотека одинаково хорошо поддерживают циклический проход через одни слои.
Ещё один нюанс при выборе модели — это баланс памяти и вычислений. Модель, которая комфортно помещается в 16-24 ГБ VRAM, часто оказывается полезнее в повседневной работе, чем крупная модель на multi-GPU. Подробнее об этом разборе с чек-листом выбора есть материал про квантованные модели в 16-24 ГБ VRAM. Looped-дизайн может усилить этот тренд, но только если вычислительный бюджет на токен остаётся приемлемым для вашего GPU.
Итог: слухи как сигнал, а не доказательство
Что мы знаем точно. GPT-6 Astra, Sol и Luna существуют как продукты, а Artificial Analysis показывает разные скорости: около 100 tok/s у 6-Sol и 5.6-Sol, около 60 tok/s у 6.1-Sol и Astra, 126-137 против 110-115 tok/s у двух поколений Luna. Эти цифры измеримы.
Что мы не знаем. Числа проходов на токен из Azure Foundry не подтверждены, гипотеза общих весов не доказана, а связь между 3 или 2 проходами и падением скорости может оказаться совпадением. Ни одна из версий не подтверждена официально.
Что делать с этим практически. Не строить планы на основе слухов, но и не игнорировать направление. Looped- и вложенные архитектуры — это один из немногих путей снизить требования к памяти без потери глубины, и если тренд подтвердится, локальные модели получат более выгодный баланс между VRAM и качеством. Разумный шаг уже сейчас: следить за анонсами DeepSeek, Qwen и GLM, тестировать новые архитектуры на своём железе и смотреть не только на число параметров, но и на реальные tok/s и замеры памяти. Цифры из этого материала стоит перепроверить, когда появятся официальные данные, а до тех пор относиться к ним как к индикатору направления, а не как к факту.