GPT-6 Astra: новые возможности искусственного интеллекта

Мы уже рассказывали, что представляет собой GPT-6 Astra, чем эта модель отличается от предшественников и какие возможности открывает перед пользователями. Однако за привычным окном чата и живым голосовым общением скрывается сложнейшая технологическая система.

Как устроена мультимодальность? За счет чего достигается высокая скорость ответа? Что происходит, когда пользователь перебивает искусственный интеллект, и какие вычислительные ресурсы нужны для поддержки такой системы?

О внутреннем устройстве нейросети корреспондент «Бакинского рабочего» продолжает беседу с доктором экономических наук, профессором Салехом Мамедовым.

- Сегодня много говорят о мультимодальности как о следующем этапе развития искусственного интеллекта. Что на самом деле меняется, когда система одновременно работает с текстом, голосом и изображением?

- Мультимодальность нельзя сводить к простому добавлению нескольких функций к языковой модели. В привычной архитектуре голос пользователя сначала преобразуется системой распознавания речи в текст. Затем текст поступает в языковую модель, а готовый ответ снова превращается в речь с помощью синтеза. Получается последовательная цепочка: аудио - текст - языковая модель - текст - аудио.

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

Нативная мультимодальность предполагает совместную обработку разных типов информации. Модель может учитывать не только слова, но и другие характеристики поступающего сигнала, а различные модальности могут быть представлены в общем внутреннем пространстве.

Однако слово «нативная» не означает, что вся техническая инфраструктура исчезает. Физический аудиосигнал по-прежнему необходимо захватить, закодировать, передать по сети и обработать. Видео требует выборки кадров, сжатия и передачи. На этом уровне работают кодеки, буферы, системы подавления эха, обнаружения речи, синхронизации и другие компоненты.

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

Если говорить конкретно о GPT-6 Astra, здесь также необходимо соблюдать техническую точность. В публичном описании модели указаны текстовый ввод и вывод, а также обработка изображений. Непосредственная работа с аудио и видео как входными модальностями для самой Astra не заявлена. Голосовое взаимодействие обеспечивается специализированной realtime-системой. Поэтому нельзя автоматически считать все возможности голосового интерфейса свойствами самой языковой модели.

Отдельно нужно различать GPT-6 Astra OpenAI и Project Astra Google DeepMind. Несмотря на одинаковое слово в названии, это разные разработки. Project Astra представляет исследовательское направление Google, связанное с визуальным пониманием окружающего пространства, памятью, взаимодействием через камеру и голосовым общением. Часть этих разработок интегрируется в продукты Gemini.

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

- Если система умеет работать с изображениями и может реагировать на происходящее перед камерой, возникает естественный вопрос: действительно ли искусственный интеллект видит окружающий мир непрерывно, как человек?

- Не обязательно. Здесь тоже существует распространенное заблуждение. Наличие визуального режима еще не означает, что языковая модель получает и анализирует каждый кадр видеопотока с частотой 30 или 60 кадров в секунду.

Во многих системах видео обрабатывается разреженно. Модель получает отдельные кадры или события, имеющие значение для текущей задачи. Такой подход позволяет значительно уменьшить объем передаваемых и обрабатываемых данных. Например, если человек показывает документ, системе нет необходимости анализировать десятки кадров в секунду, если изображение практически не меняется.

В документации некоторых realtime-систем прямо предусмотрена передача последовательности изображений с ограниченной частотой кадров. Поэтому демонстрация, в которой пользователь двигает камерой и получает ответ, не означает, что большая языковая модель непрерывно обрабатывает полноценный видеопоток на уровне человеческого зрения.

Кроме того, визуальное понимание и пространственная ориентация - разные задачи. Если речь идет о роботе, автомобиле или другом физическом устройстве, одной языковой модели недостаточно. Необходимы компьютерное зрение, сенсоры, системы локализации и картирования пространства, в том числе технологии класса SLAM.

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

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

Поэтому корректнее говорить, что мультимодальная система анализирует наблюдаемые визуальные сигналы и может использовать их для адаптации диалога. Утверждение, будто ИИ надежно определяет, что человек чувствует, было бы гораздо сильнее, чем позволяют сделать такие данные.

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

- При этом для пользователя естественный разговор с ИИ выглядит очень просто: человек говорит, система почти сразу отвечает. Что на самом деле происходит между этими двумя моментами и от чего зависит скорость реакции?

- В realtime-взаимодействии задержку нельзя свести к скорости генерации самой языковой модели. Между репликой пользователя и первым звуком ответа проходит целая цепочка операций.

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

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

Здесь используется VAD, система определения голосовой активности. В простом варианте она анализирует энергию сигнала и продолжительность тишины. Более продвинутый подход, semantic VAD, пытается определить уже не только наличие звука, но и завершенность высказывания. Это позволяет отличать короткую естественную паузу от момента, когда человек действительно закончил фразу.

На задержку влияет и сеть. Передача аудио туда и обратно зависит от качества соединения, маршрута и загрузки. Добавляются очереди на сервере. Если системе нужно обработать большой контекст, подготовка к генерации также может занять дополнительное время.

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

Показатель скорости также нельзя оценивать только по средней задержке. Для realtime-систем важны распределения, например p50, p95 и p99. Среднее значение может выглядеть хорошо, но если каждый двадцатый или сотый запрос значительно замедляется, пользователь это заметит.

В 2024 году OpenAI сообщала для GPT-4o минимальную задержку аудиоответа около 232 миллисекунд и среднюю около 320 миллисекунд. Однако эти цифры относятся к историческим данным GPT-4o и не являются гарантированными показателями для GPT-6 Astra или современных realtime-систем. Публичного универсального SLA с текущими значениями p50 и p95 для конкретного региона нет.

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

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

- Интересно такое различие: в обычном разговоре человек может перебить собеседника в любой момент. Что должна сделать realtime-система, если пользователь начинает говорить, пока ИИ еще произносит ответ?

- Для естественного диалога это принципиальный момент. Система должна не просто обнаружить новый звук, а правильно изменить состояние разговора.

Сначала VAD фиксирует новую речь пользователя. После этого сервер должен отменить текущую генерацию ответа, а клиент - остановить воспроизведение уже подготовленного аудио. Затем история диалога должна быть скорректирована с учетом того, какую часть предыдущего ответа пользователь действительно успел услышать.

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

В realtime-архитектурах это решается через отмену генерации и усечение аудио до реально воспроизведенного фрагмента. При использовании WebRTC или SIP часть такой логики может автоматически обрабатываться инфраструктурой. При работе через WebSocket клиенту требуется самостоятельно остановить аудиобуфер и передать событие, сообщающее системе, где именно произошло усечение.

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

Кроме обычного VAD существует semantic VAD. Он может оценивать, закончил ли человек мысль, и тем самым уменьшать количество неестественных прерываний. Это особенно важно в ситуациях, когда человек делает паузу посреди длинного предложения.

Есть и другой подход: пользователь может явно сообщить системе, что хочет остановить ее. Команда вроде «стоп» дает дополнительный сигнал управления. В хорошо организованном интерфейсе голос пользователя должен иметь приоритет над продолжающимся ответом системы.

Google в своих realtime-решениях также сочетает автоматическое определение голосовой активности с возможностью явно передать системе сигнал окончания активности. Такой механизм позволяет разработчику выбирать между более автоматическим и более управляемым сценарием.

Перебивание - это не просто команда «остановить звук». После него необходимо синхронизировать несколько состояний: что сказал пользователь, что успела сгенерировать модель, что было передано клиенту и какую часть ответа человек реально услышал. Только после этого можно продолжать разговор с корректным контекстом.

Вот почему в realtime-системах корректность перебивания является отдельной инженерной метрикой. Быстро ответить недостаточно. Нужно еще правильно понять момент окончания реплики, не перепутать речь с шумом, своевременно остановить текущий ответ и не оставить в истории разговора информацию, которой пользователь не слышал.

- Но ведь за быстрым голосовым ответом и работой с большими объемами информации стоит серьезная вычислительная инфраструктура. Какое оборудование требуется для таких моделей?

- Прежде всего нужно отделять опубликованные характеристики от инженерных оценок. Для GPT-6 Astra публично не раскрыты количество параметров, точный формат хранения весов, число активных экспертов, объем используемой VRAM и конфигурация вычислительного кластера. Поэтому называть конкретное количество GPU, необходимое именно для Astra, было бы спекуляцией.

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

Память под веса можно условно представить формулой: M = N × b / 8, где N - количество параметров, а b - число бит на параметр. Например, для гипотетической модели на 175 млрд параметров потребуется около 350 ГБ при формате BF16, 175 ГБ при INT8 и 87,5 ГБ при 4-битном представлении. Для модели на один триллион параметров эти значения составят соответственно около 2 ТБ, 1 ТБ и 0,5 ТБ.

Но веса только часть общей картины. При большом контексте очень существенным становится KV-cache, где хранится состояние обработки последовательности. Его объем зависит от количества слоев, числа KV-голов, размерности головы, длины контекста и точности хранения.

Если взять исключительно иллюстративный пример: 80 слоев, 8 KV-голов, размер головы 128, контекст в один миллион токенов и BF16, то только KV-cache составит примерно 327,7 ГБ на одну активную последовательность. Это не оценка характеристик GPT-6 Astra, а демонстрация того, почему миллион токенов контекста - серьезная вычислительная задача.

Для самой генерации также нужны вычислительные мощности. В упрощенной оценке для плотной модели можно использовать порядок 2N операций с плавающей точкой на токен. Но такая формула не отражает всей реальной нагрузки: отдельно существуют подготовка длинного контекста, работа с KV-cache, мультимодальные энкодеры и декодеры, передача данных, внешние инструменты и другие компоненты.

Современные ускорители позволяют размещать большие модели распределенно. Например, NVIDIA H100 выпускается с 80 или 94 ГБ HBM-памяти, а специализированные системы объединяют несколько ускорителей с высокоскоростными соединениями. Восьми-GPU система DGX H100 имеет суммарно 640 ГБ HBM. У Google есть собственная линейка TPU, включая TPU v6e, конфигурации которой могут объединяться в крупные системы.

Однако сервер для frontier-модели - это не просто набор GPU или TPU. Необходимы сетевое оборудование, высокоскоростные межсоединения, системы хранения и кэширования, компоненты для обработки аудио и изображений, охлаждение, электропитание, мониторинг и механизмы распределения нагрузки.

Поэтому правильнее говорить не о «компьютере, на котором работает GPT-6 Astra», а о распределенной вычислительной инфраструктуре. Пользователь видит один интерфейс и получает один ответ, тогда как внутри может работать большое количество взаимосвязанных компонентов.

- Возникает закономерный вопрос: если такие модели требуют настолько серьезных ресурсов, смогут ли они работать непосредственно на компьютере или смартфоне, без постоянного обращения к облаку?

- Для самых мощных frontier-моделей полноценное выполнение на обычном пользовательском устройстве сегодня не является типичным сценарием. Клиентское устройство не загружает в себя все веса такой модели. Обычно оно устанавливает защищенную сессию, получает ограниченный по времени токен, после чего через WebRTC, WebSocket или другой протокол передает серверу необходимые данные и получает обратно текст, аудио, события или результаты действий.

Это означает, что основная вычислительная работа происходит в облаке. Серверная сторона хранит состояние сессии, распределяет нагрузку, проверяет права пользователя, доступные инструменты и лимиты. При работе с файлами, сообщениями или финансовыми действиями дополнительно требуется авторизация и подтверждение операций, имеющих материальные последствия.

При этом полностью локальный искусственный интеллект тоже развивается. Здесь особый интерес представляют SLM - небольшие языковые модели. Они требуют значительно меньше ресурсов и могут выполнять часть задач непосредственно на устройстве или внутри организации.

Например, модели семейства OpenAI gpt-oss показывают, что модель на 20 миллиардов параметров может работать на системе с 16 ГБ памяти, а вариант на 120 миллиардов параметров - на одном GPU с 80 ГБ. У локальных моделей Google Gemma также существуют компактные варианты, а при 4-битном представлении объем памяти под веса может составлять от нескольких до десятков гигабайт в зависимости от конкретной модели. Но к памяти под веса нужно добавлять KV-cache и другие расходы runtime.

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

Для сложного рассуждения, анализа больших документов, сложной мультимодальной обработки или работы с мощными инструментами целесообразнее подключать облачную frontier-модель. При этом необязательно отправлять в облако все данные целиком. Гибридная архитектура позволяет передавать только необходимый контекст, а сами корпоративные данные и вычислительные инструменты держать ближе к источнику.

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

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

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

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

Поэтому вопрос «облако или устройство» постепенно превращается в вопрос распределения функций. Не обязательно выбирать что-то одно. Наиболее практичная архитектура может сочетать локальные быстрые и чувствительные операции, облачное сложное рассуждение и специализированные инструменты, которые отвечают за точные вычисления и работу с данными.

(окончание следует)