Вайб-кодинг

NVIDIA, возможно, решила главный компромисс современных LLM

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

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

Именно эту проблему попытались решить исследователи NVIDIA.

Они взяли 30B-модель и разделили её на две части, чтобы генерировать токены параллельно, а не по одному.
Так появилась Nemotron-Labs-TwoTower — диффузионная языковая модель от NVIDIA Research, адаптированная на базе Nemotron-3-Nano-30B-A3B.

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

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

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

TwoTower решает эту проблему, не заставляя одну сеть выполнять обе задачи. Вместо этого предварительно обученную авторегрессионную модель разделяют на две башни.

1. Context Tower — замороженная часть модели, которая считывает весь уже сгенерированный текст точно так же, как это делала исходная модель. Её больше не обучают, поэтому интеллектуальные способности модели полностью сохраняются.
2. Denoiser Tower — обучаемая часть модели, которая параллельно генерирует каждый новый блок токенов. Чтобы не терять контекст, она постоянно использует cross-attention к Context Tower.

Самое интересное — как взаимодействуют эти две башни. Они соединены послойно: пятый слой Denoiser Tower взаимодействует с пятым слоем Context Tower, шестой — с шестым и так далее.
Благодаря этому Denoiser получает доступ ко всему многоуровневому представлению контекста базовой модели, а не только к её финальному скрытому представлению.

Результаты:
> В 2,42 раза выше пропускная способность генерации
> Сохраняется 98,7% качества исходной модели
> Архитектура построена на базе гибридной 30B-модели Mamba–Transformer MoE
> Для обучения использовано всего около 2,1 трлн токенов — лишь часть от 25 трлн токенов, использованных при предобучении исходной модели

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

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

Веса, код и методика обучения опубликованы в открытом доступе.

Статья: https://arxiv.org/pdf/2606.26493

13.6K views06:10

Вайб-кодинг

Anthropic описала четыре типа циклов, которые можно строить с помощью Claude. Каждый из них передаёт агенту разную часть процесса принятия решений.

Термин loop engineering сейчас используется настолько широко, что стоит чётко понимать, чем именно отличаются эти четыре варианта: что запускает цикл и что определяет момент его завершения.

> Цикл на основе запросов. Вы отправляете запрос, Claude выполняет задачу, самостоятельно проверяет результат и возвращает его вам. Именно этот цикл работает практически при каждом вашем сообщении, независимо от того, называете вы его так или нет.
> Цикл на основе цели (/goal). Вы заранее задаёте измеримый критерий завершения. Каждый раз, когда Claude пытается завершить работу, модель-оценщик проверяет, достигнута ли поставленная цель. Если нет, Claude отправляется продолжать работу.
> Цикл на основе времени (/loop, /schedule). Вместо пользовательского запроса запуск происходит по таймеру. Команда /loop повторно выполняет проверку через заданные интервалы, но прекращает работу, если останавливается ваша машина. Команда /schedule переносит ту же идею в облако, поэтому цикл продолжает работать независимо от вашей текущей сессии.
> Проактивный цикл. Это комбинация /schedule, /goal и рабочего процесса, которая запускается по событию без какого-либо запроса со стороны пользователя в момент выполнения. Каждый элемент доводится до собственной цели, а сам процесс продолжает работать, пока кто-нибудь его не отключит.

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

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

Вот статья, где разобрали все четыре типа циклов, привели примеры и предложили подход к выбору между /goal и /loop. 🎉

Please open Telegram to view this post