Полная версия:
Сергей Кирницкий Собственная языковая модель. Когда, зачем и в каком масштабе
- + Увеличить шрифт
- - Уменьшить шрифт
Вторая ручка — количество слоёв. Слой — одна последовательная ступень обработки, на которой модель с помощью механизма внимания и нескольких других приёмов пересчитывает представления всех токенов. Каждый токен проходит через все слои по очереди; на каждом слое он получает чуть более точную картину того, чем окружён, и того, чем в итоге должен стать на выходе. Слои — условно глубина рассуждения, сколько последовательных шагов обработки проходит каждый токен, прежде чем модель решит, что сказать дальше. Простая реакция требует меньшей глубины; сложный вывод, длинная логическая цепочка, тонкий стилистический ход — большей.
Эти две ручки связаны, но не эквивалентны. Можно собрать широкую и плоскую модель — много параметров, мало слоёв; можно — узкую и глубокую; можно — сбалансированную. Практика показывает, что крайние пропорции работают хуже, и в обычных моделях соотношение подбирается в определённых инженерных рамках. Но это не значит, что выбор между «шире» и «глубже» — второстепенный: от того, как две ручки настроены относительно друг друга, зависит и скорость ответа, и способность модели к сложным задачам, и то, как хорошо она принимает последующее обучение.
Поворот любой из ручек вверх — не просто «сделать модель больше». Это разом изменить несколько вещей. Больше параметров — больше памяти под модель, больше вычислений на каждом шаге, большее количество данных, необходимых для того, чтобы модель научилась не на песке. Существует полезный инженерный якорь, известный как закон Chinchilla: в первом приближении на каждый параметр модели приходится примерно двадцать токенов обучающих данных. Для модели в тридцать миллиардов параметров этот ориентир означает порядка шестисот миллиардов токенов данных; для модели в триста миллиардов — уже шесть триллионов. Поворот ручки параметров на один порядок тянет за собой поворот ручки данных на тот же порядок. Этот же якорь связывает Главу 3 с Главой 7, где речь пойдёт о данных — где их брать, сколько они стоят, и почему к определённому масштабу модели «просто добрать данных» становится самостоятельной инженерной проблемой.
То же со второй ручкой. Добавить слоёв — не только сделать модель «умнее»; это умножить количество последовательных операций на каждый токен и, значит, напрямую замедлить и обучение, и каждый последующий ответ. Глубокая модель обычно умнее плоской, но дороже во всех смыслах — и в обучении, и в эксплуатации после запуска. Поэтому соотношение параметров и слоёв — не только техническая, но и экономическая настройка: две модели одного и того же суммарного размера могут иметь заметно разную стоимость инференса, в зависимости от того, как распределены их параметры между шириной и глубиной.
Всё остальное в модели — производное от этих двух ручек. Ширина внутренних представлений, количество «голов» внимания, размеры промежуточных преобразований между слоями — всё это связано с основными параметрами и обычно подбирается по отработанным правилам пропорций. Когда разработчики говорят «мы увеличили размер модели», в подавляющем большинстве случаев речь идёт именно о двух ручках, которые только что были описаны; остальные настраиваются автоматически вокруг них. У руководителя, читающего отчёт команды, нет нужды помнить десяток параметров — достаточно помнить две и понимать, что одна отвечает за ёмкость, другая за глубину, и обе дорого стоят в обе стороны.
Итог прост. Размер модели — не одна цифра и не цельная величина; это комбинация двух ручек, каждая со своей ценой. «Большая модель» сама по себе не означает «хорошая модель». Модель с большим числом параметров, обученная на недостаточном объёме данных, работает хуже, чем модель поменьше, но обученная как следует; модель с большой глубиной, но плохо сбалансированной архитектурой, теряет в качестве и одновременно дорожает в эксплуатации. В индустрии это хорошо известно, и именно поэтому серьёзные проекты тратят значительную часть подготовки на выбор конкретных значений двух основных ручек и пропорций вокруг них, а не просто «крутят побольше, пока позволяет бюджет».
Но две ручки задают только общий масштаб. Поверх них — ещё один выбор, уже не количественный, а архитектурный. Выбор, способный радикально изменить экономику того, что эти ручки построили.
3.5. Один архитектурный выбор, меняющий экономику
До сих пор мы говорили о модели как о цельной машине: вход, последовательность слоёв, механизм внимания, выход. Каждый токен идёт через всю конструкцию целиком, каждый параметр участвует в каждом шаге. Эта классическая, общепринятая схема называется 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.
3.6. Где в этой конструкции дорогие места
Две ручки — параметры и слои — задают общий масштаб. Но дорогие места конструкции ими не ограничиваются. К двум основным ручкам добавляются ещё две, и у каждой своя цена. Первая — длина контекста: та самая квадратичная история. Вторая — мультимодальность: способность модели работать не только с текстом, но и с изображениями, аудио, видео. Каждая из этих двух — не «приятное дополнение», а отдельная большая статья бюджета.
Не вариатор, где любая комбинация настраивается плавно и незаметно; а четыре больших переключателя, каждый со своим прайс-листом. Поворот любого из них вверх — прыжок, а не плавное нарастание. Параметры, слои, длина контекста, число модальностей — четыре рычага, и именно их положение определяет, во что обойдётся проект.
У длинного контекста своя экономика. Одна строчка в продуктовом описании модели — «окно в несколько сотен тысяч токенов» — стоит за собой отдельной инженерной программы, которую команда ведёт наравне с основной разработкой.
Мультимодальность устроена иначе, но стоит не меньше. Текстовая модель — это одна конструкция, работающая с одной последовательностью токенов. Мультимодальная модель — по сути, несколько конструкций, связанных общим рамочным приёмом: отдельные компоненты-энкодеры, которые переводят изображения, аудио или видео в ту же форму, в которой модель уже умеет работать; отдельные обучающие данные — парные корпуса «картинка — описание», «звук — транскрипт», «видео — разметка»; отдельные бюджеты на разметку; отдельные процедуры оценки; отдельные инженеры, разбирающиеся в соответствующей модальности. Мультимодальная модель — это, грубо говоря, несколько проектов, собранных в один. Стоимость растёт не сложением, а интегрально: команда больше, данные сложнее, оценка запутаннее, отладка дольше, и зависимости между модальностями создают собственный класс ошибок, которых в чисто текстовой модели не было.
К этому добавляется ещё одно обстоятельство, которое часто недооценивают. Каждая новая модальность — это не только больше данных и больше инженеров; это отдельные правовые и этические контуры. Изображения и видео несут в себе сложную историю согласий и прав на использование, заметно более запутанную, чем право на публикацию текста; звук приносит с собой вопросы голосовой идентификации; медицинские изображения — особый режим регулирования. Там, где текстовая модель работает с письменным корпусом, мультимодальная модель берёт на себя сразу несколько юридических миров, каждый со своими правилами. Для команды это — дополнительный пласт подготовки, которого в текстовом проекте просто не было.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
