Читать книгу Собственная языковая модель. Когда, зачем и в каком масштабе - Ар'лан ис'Дрекхэм - Страница 15

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

А теперь — альтернатива. В архитектуре со «смесью экспертов» — MoE, Mixture of Experts — каждый токен проходит не через всю модель, а только через небольшую её часть. Модель устроена как коллегия специалистов: маленький внутренний «маршрутизатор» на каждом шаге решает, какие эксперты должны «включиться» для данного токена, и остальные остаются в покое. На один токен «включается» не вся модель, а, скажем, восьмая или шестнадцатая её часть. Это не уловка и не способ сэкономить на качестве; это архитектурный приём со своей инженерной и экономической логикой.

Картина становится понятнее через образ двух способов консультации. В dense на каждый вопрос отвечает вся команда целиком — все сотрудники вовлечены, независимо от того, разбираются они в теме или нет; получается равномерно и предсказуемо, но трудоёмко до неприличия. В MoE вопрос адресуется коллегии, устроенной как поликлиника: маршрутизатор на входе смотрит на запрос и отправляет его нужному специалисту. Те, кому вопрос понятен, отвечают; остальные молчат и не тратят времени. Клиника с сотней врачей способна принимать сложные случаи всех мастей, но каждый конкретный пациент занимает время лишь одного-двух специалистов, а не всей сотни разом.

Экономический смысл этого приёма прост и важен. Он позволяет иметь очень большую суммарную модель с умеренной стоимостью запуска. Суммарное число параметров исчисляется десятками или сотнями миллиардов; реально используемая на каждом шаге — только небольшая часть. Модель остаётся большой по ёмкости — коллегия специалистов в целом обладает огромным совокупным знанием, — но на каждый отдельный запрос она отвечает экономно. Для крупных моделей это принципиально: MoE делает возможной эксплуатацию того, что в плотном варианте стало бы неподъёмно дорогим в инференсе.

Именно этим путём пошли несколько заметных открытых моделей. DeepSeek V3 построена как MoE-архитектура: её суммарное число параметров исчисляется сотнями миллиардов, а реально активируется на каждом шаге заметно меньшая часть; этим удаётся удерживать стоимость инференса на уровне значительно меньшей плотной модели. Mixtral — другая открытая линейка того же семейства архитектурных решений, меньшего суммарного размера, но с той же идеей избирательной активации. Это не единственные примеры — MoE-архитектуры есть и у части фронтирных закрытых моделей, только без публичных технических отчётов, — но DeepSeek и Mixtral остаются двумя заметными точками, на которые удобно ориентироваться, когда заходит речь об этом архитектурном выборе.

Было бы слишком красиво, если бы у MoE не было обратной стороны. Она есть, и значительная. MoE сложнее в обучении: инженерам приходится отдельно учить маршрутизатор распределять токены между экспертами равномерно, не сваливая всё в одного «дежурного»; это обучение сопряжено со своей особой нестабильностью, с которой у индустрии постепенно копится опыт, но которая остаётся существенным фактором. MoE дороже в отладке: когда модель начинает вести себя странно, вопрос «что именно пошло не так» усложняется, потому что разные токены теперь идут разными маршрутами и разные эксперты специализируются на разных подзадачах. MoE менее предсказуема в качестве: при недостаточной осторожности одни эксперты остаются недозагруженными, а другие — перегружаются, и это плохо сказывается на итоговом поведении модели. И наконец, MoE требует больше памяти под веса: хранить нужно всех экспертов, даже если в конкретном шаге работает только часть. Экономия на вычислениях не означает автоматической экономии на инфраструктуре.

Отсюда — управленческий смысл этого выбора. Dense проще, надёжнее, с понятной экономикой, но дороже на большом масштабе. MoE экономичнее в инференсе на большом масштабе, но сложнее и требовательнее к команде. Какая сторона этой развилки правильнее, зависит от задачи и от команды: достаточно ли компетенций, чтобы справиться с тонкостями MoE; достаточно ли масштаб модели велик, чтобы экономия на инференсе оправдывала усложнение; достаточно ли предсказуемое качество важнее, чем итоговая стоимость. Это один из тех вопросов, на которые нельзя ответить за пределами конкретного проекта. В Главе 6 он неизбежно возникнет при разговоре о сценариях B (Собственная) и C (Фронтир); там же он будет обсуждаться предметно.

Одна сторона этой развилки заслуживает отдельного замечания. Для пользователя модели разница между dense и MoE практически незаметна: и та, и другая принимают на вход текст и выдают на выходе текст, и внешнее поведение может быть очень близким. Внутри же — это два разных мира разработки, инфраструктуры и эксплуатации: разные инженерные дисциплины, разные диагностические приборы, разные способы обучать, разные траектории ошибок. Это важно именно для руководителя: выбор, невидимый снаружи, формирует существенную часть того, как устроен проект изнутри, — кого и сколько нужно нанимать, какой кластер собирать, сколько времени закладывать на отладку. Архитектурная развилка транслируется в организационную прежде, чем в продуктовую.

Важно одно: выбор между dense и MoE — не техническая деталь, которую можно оставить команде на самом низу. Это одно из ключевых решений, определяющих экономику проекта и то, что именно будет построено в итоге. Для небольших специализированных моделей — тех, что в Главе 6 собраны в сценарий S (Малая), — этот вопрос обычно не стоит: dense достаточно, MoE избыточна. Для крупных проектов, где модель измеряется сотнями миллиардов суммарных параметров, — стоит всерьёз и заслуживает внимания на уровне, на котором принимаются стратегические архитектурные решения. И для команды, в которой опыта с MoE нет, честный ответ нередко такой: dense — не потому что он лучше в принципе, а потому что мы сейчас умеем с ним работать, и это само по себе половина качества будущей модели.

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