
Полная версия:
Сергей Кирницкий Собственная языковая модель. Когда, зачем и в каком масштабе
- + Увеличить шрифт
- - Уменьшить шрифт
У этих четырёх есть общий принцип. Если главное — быстро получить результат, альтернативы почти всегда правильнее. Своя LLM имеет смысл только там, где эти пути объективно не подходят, — а таких ситуаций меньше, чем обычно кажется. Практический критерий коротко звучит так: если задача формулируется как «быстрее и точнее отвечать клиентам с учётом наших документов», ответ почти наверняка в этом списке; если как «корпоративный ассистент, похожий на ChatGPT, но на наших данных», стоит проверить все четыре пути, прежде чем браться за свою LLM. Если к концу Главы 5 компания не прошла фильтр оснований и готовности — ответ, скорее всего, именно из этого короткого списка.
2.3. Миф «свой GPT за год»
Последнее распространённое заблуждение, которое стоит назвать прямо, — фраза «сделаем свой GPT за год». Она регулярно звучит на совещаниях, и произносящий её редко имеет в виду буквально GPT-4 или GPT-5. В массовом восприятии слово «GPT» давно оторвалось от конкретной линейки моделей и стало общим именем «сильной современной LLM» — примерно так же, как когда-то «ксерокс» стал именем для любой копировальной машины. За фразой «свой GPT» стоит амбиция вполне прозрачная: собственная модель фронтирного или около-фронтирного класса, с качеством, сопоставимым с тем, что продают лидеры рынка.
Проблема этой амбиции не в смелости, а в масштабе несоответствия. Фронтирные модели требуют сотен миллиардов параметров, многих триллионов токенов обучающих данных, тысяч современных GPU и сотен человек в команде; вся эта арифметика подробно развёрнута в Главе 6 в сценарии C. Реалистичный срок до первой осмысленной версии — минимум 24—36 месяцев, и это только начало: дальше модель требует непрерывной работы, без которой быстро теряет актуальность. Год в этой арифметике — не граница возможного, а граница разговоров, обычно заканчивающихся ничем. Разрыв между ожиданием «за год сделаем» и реальностью фронтирного проекта измеряется не процентами, а порядками. Чтобы увидеть это сопоставление наглядно: «свой GPT за год» означает одновременно ускорить мировой темп таких проектов в несколько раз и уменьшить нужные ресурсы на порядок. Каждое из двух требований по отдельности — героическое; вместе они означают, что фраза не описывает реальный проект, она его замещает.
Хорошая параллель — двое спорят, можно ли за год построить Boeing 747 в гараже. Правильный ответ — нет. Правильный вопрос — другой: какой самолёт вообще можно построить в своих условиях и за какой срок. Ответ будет скромнее, но он тоже будет самолётом.
Парадокс спора про Boeing в гараже в том, что сам вопрос «можно ли за год» тихо замещает настоящий — «с какими ресурсами и основаниями вы заходите в проект». Замена незаметна, и к моменту, когда её замечают, полгода уже ушло на разговоры.
Это и есть настоящий разговор о достижимом. Для компаний, у которых есть основания заходить в собственный проект, пространство возможного очерчено довольно ясно. Малая модель под узкую задачу — 2—4 месяца от решения до полезного результата. Адаптированная модель на основе открытой базы — 4—9 месяцев. Собственная модель среднего класса — 18—24 месяца. Каждая цифра здесь имеет свою природу. Малая быстра потому, что задача намеренно сужена: узкий домен, понятный критерий успеха, небольшая команда. Адаптированная опирается на то, что открытая база уже прошла многомесячное предобучение, и добавляет к нему смещение в сторону собственного корпуса. Собственная модель — это полное предобучение, но без амбиции на фронтирный размер: меньше параметров, меньше данных, меньше вычислений, и поэтому сроки укладываются в горизонт полутора-двух лет, а не растягиваются на три года и больше. Это настоящие варианты своей LLM для большинства компаний, принявших решение идти в проект; подробная развёртка каждого — в Главе 6. Такие варианты не дают результата «как у OpenAI». Но дают другое: владение собственным активом, заточенным под конкретную задачу. Это тоже своя LLM — просто не свой GPT.
Различие между «нашим GPT» и «нашей LLM» выглядит словесным, а на деле — стратегическим. Если у руководителя в голове продолжает жить «свой GPT за год», остаток книги читается против себя самого: каждая следующая глава будет звучать неубедительно, потому что читатель подсознательно будет искать короткий путь, недостающее средство, секретный приём, которого не существует. Этот несуществующий короткий путь обычно принимает вид «минимальной конфигурации», которая «на самом деле» даёт модель уровня лидеров; поиск такой конфигурации заменяет работу над реальным выбором и съедает первые месяцы проекта без видимого результата. Когда же масштаб откалиброван правильно, разговор о сценариях начинает попадать на свои места, а разговор о рисках перестаёт восприниматься как избыточный пессимизм — он становится естественной частью размера проекта.
У этой калибровки есть и обратный эффект. Когда со стола переговоров уходит фраза «свой GPT за год», вместе с ней уходит и главный источник управленческой тревоги в этой теме — ощущение, что компания опаздывает относительно чего-то невозможного. На месте тревоги остаётся задача: сопоставить собственные основания, готовность и масштаб с картиной поля. Задача тяжёлая, но решаемая. Именно в этом состоит работа книги и работа руководителя, который её читает.
Часть II. Устройство и процесс создания LLM
Не зная, из чего собрана модель и как её делают, сравнивать сценарии S/A/B/C можно только на слух. Дальнейший разговор о масштабе, ресурсах, командах и рисках держится именно на этом фундаменте.
Глава 3. Анатомия LLM
Описать LLM изнутри можно только учебником, к которому мы здесь не стремимся; задача скромнее и важнее — передать ощущение устройства. Модель — большое, тонко устроенное сооружение; в ней нет случайных деталей, и нет деталей, которые можно «просто увеличить», не потревожив всё остальное. Каждая «ручка», которую можно крутить, стоит денег — и не в переносном смысле, а в виде вполне конкретных счетов за вычисления, память и время.
К Главе 6 те же самые «ручки» соберутся в четыре целостных сценария: без чувства устройства они читаются как таблица, а должны читаться как разные масштабы одного реального сооружения.
3.1. Как модель видит текст
Прежде чем говорить о том, что происходит у модели внутри, стоит признать одно упрямое обстоятельство: с текстом она не работает вовсе. Строка букв, фраза, абзац — всё это живёт только на входе и на выходе, как упаковка. Внутри модель работает с токенами — минимальными кусками, на которые разрезан текст, и последовательностью этих кусков она и оперирует.
Токен — не слово и не буква, а что-то между ними. Длинное слово вроде «предложение» распадается на несколько коротких фрагментов; короткое и частое слово может остаться одним токеном целиком. Модель не видит ни букв в человеческом смысле, ни слов в школьном; она видит, в каком порядке друг за другом идут знакомые ей куски. То, что для нас — беглое чтение, для неё — перебор элементов заранее известного набора.
Сам этот набор — словарь модели. Одна из её фиксированных характеристик, такая же технически жёсткая, как размер алфавита в обычной письменности; только тут это «алфавит осмысленных фрагментов». Чем словарь больше, тем точнее модель умеет «говорить», тем тоньше нарезка, тем выше её гибкость, — но тем тяжелее внутренняя машинерия, дороже хранение, медленнее каждый шаг. Как и всё в этой истории, размер словаря — компромисс, а не оптимизация: выбор делается однажды, на самом старте, и потом живёт с моделью всю её жизнь.
На практике нарезка выглядит так: короткое частое слово оказывается одним куском целиком; слово средней длины распадается на два-три фрагмента; редкое, длинное или специфическое — на большее число мелких частей, иногда вплоть до отдельных букв. Нарезка не похожа на разбор по морфемам, как в школьной грамматике; это статистическая нарезка, подобранная так, чтобы наиболее частые сочетания в корпусе получили короткую запись, а редкие — удлинённую. Внутренняя логика тут инженерная, не лингвистическая: словарь не знает, где корень, а где приставка, он знает, что часто встречается в текстах, на которых его учили.
А теперь первое место, где абстракция встречается с экономикой. Стандартные словари, которыми пользуются открытые модели, собирались в основном на англоязычных корпусах. Английский в них лежит экономно: частые слова попадают в словарь целиком, редкие — дробятся аккуратно. Русский в тех же словарях лежит с перекосом. Кириллица расходует заметно больше токенов, чем латиница: тот же самый смысл на русском занимает в полтора-два раза больше кусков, чем на английском. Это не стилистическая особенность и не досадное неудобство — это множитель. Прямой, грубый множитель ко всем затратам: к стоимости обучения, к стоимости каждого ответа, к расходованию контекстного окна, в которое укладывается разговор.
У этого множителя есть осязаемые проявления, о которых не всегда вспоминают. Компания, работающая преимущественно с русскоязычным текстом через открытую модель, платит надбавку ежедневно и незаметно — в виде чуть более высоких счетов за каждый запрос. Длинный разговор с пользователем достигнет потолка контекстного окна раньше, чем тот же разговор на английском; при прочих равных русскоязычный ассистент «устаёт» и теряет нить диалога быстрее — просто потому, что каждый его шаг обошёлся дороже в токенах. На масштабе массового сервиса эта разница в полтора раза превращается в миллионы лишних токенов в день и в заметное сокращение того, что модель способна удержать в контексте за одно обращение.
Отсюда — первое осмысленное решение, которое приходится принимать всякому, кто собирается делать модель для русского языка. Имеет смысл собрать свой словарь — свой токенизатор, обученный на русских корпусах. Это короткий отдельный этап, предшествующий основному обучению, и детально он разбирается в разделе 4.2. Экономия, которую он даёт, окупается всей последующей жизнью модели: дешевле предобучение, дешевле инференс (работа модели после обучения, на каждом запросе пользователя), длиннее доступный контекст в тех же инженерных рамках. Поэтому собственный токенизатор — не пропускаемая деталь и не технический нюанс, который можно оставить команде на потом. Это один из первых выборов, определяющих экономику всего проекта; словарь, собранный на коленке, аккуратно тянется шлейфом через все последующие счета.
Теперь, когда понятно, в каком виде текст попадает внутрь, можно посмотреть, что с ним там происходит — куда попадают эти последовательности токенов и в каком пространстве начинает жить их смысл.
3.2. Как модель хранит смысл
Снаружи токен — номер в словаре. Внутри модели он живёт в другой форме: у каждого токена есть эмбеддинг (embedding) — длинный вектор, набор из сотен или тысяч чисел, в котором упакована информация о том, как этот токен связан с другими. Не «номер слова» и не «код буквы»; это координаты точки в многомерном пространстве, и именно с такими точками модель и работает. Токен на входе — как почтовый индекс; эмбеддинг — как сама точка на карте, со всей её географией.
Образ, который работает ближе к физике, чем к математике. Огромное пространство — не три измерения, как в нашем физическом мире, а тысячи. В этом пространстве каждый токен — точка, и расположены они не случайно: близкие по значению оказываются близкими геометрически, далёкие — удалёнными. «Король» и «королева» располагаются рядом; «тигр» и «лев» — тоже; «стол» и «ложка» оказываются ближе друг к другу, чем «стол» и «галактика». Это — в укороченном виде — действительно то, что происходит внутри модели. Главное здесь — идея: смысл в LLM устроен как геометрия. Близость слов есть расстояние, аналогия есть параллельный сдвиг, противоположность — направление.
Ближе всего это пространство по устройству напоминает звёздную карту. Есть плотные скопления — области, в которых слова «гравитационно» связаны множеством устойчивых смысловых нитей: бытовая речь, политика, международные новости, поп-культура. Есть разреженные окраины — области, в которых точек мало и расстояния между ними большие: редкие языки, узкие профессиональные жаргоны, специализированные технические темы. Есть и пустоты — области, куда обучающие данные почти не заглядывали, и где модель, вынужденная туда перемещаться, теряет уверенность шага. Эта карта — не абстрактная схема, а во многом портрет того, на чём модель училась: по плотности скоплений можно прочитать, какие темы были в её корпусе обильны, а какие — проходили поодаль.
Это пространство не возникает само по себе и не прописывается инженерами вручную; оно складывается в процессе обучения. Модель видит триллионы последовательностей токенов и постепенно размещает их в смысловом пространстве так, чтобы слова, встречающиеся в похожих контекстах, оказывались рядом. Геометрия смысла вытекает из статистики употребления: если два слова ведут себя в текстах одинаково, модель начинает считать их близкими. Это не тот способ хранить смысл, каким пользуется человек, и любые аналогии с человеческой памятью быстро подводят, — но это способ, эффективно работающий для текста. И ещё одно замечание, связанное с разговором из Главы 2: именно эта обученная геометрия — координаты всех точек и связи между ними — и есть значительная часть того, чем компания «владеет», когда речь идёт о владении весами. Веса — это, в том числе, и конкретное расположение «короля», «королевы» и всего остального в тысячах измерений; чужую модель можно развернуть приватно, но геометрию её внутреннего мира нельзя изменить — она у неё одна на всех.
Теперь — тонкий момент, который часто пропускают. Сам по себе механизм, работающий с эмбеддингами, последовательность токенов не видит. Казалось бы, странно: модель ведь читает текст слева направо, как мы, — разве порядок не заложен в устройство? На деле нет. Каждый токен модель рассматривает как точку в пространстве, и сам факт «этот токен идёт после того» для неё не существует, пока его отдельно не закодировать. Порядок слов — не побочный факт чтения, а инженерный сюжет, решаемый специально.
Способ, которым модели сообщают порядок токенов, — отдельная техническая задача, и от её решения зависит одна очень практическая вещь: на какую максимальную длину текста модель способна распространить свою работу. Одни способы кодирования хорошо переносятся на последовательности длиннее тех, на которых модель училась; другие ломаются уже на выходе за привычное окно. Существуют разные подходы; для руководителя их перечень неважен. Важно, что способность модели уверенно обрабатывать длинные документы — не «просто выкрутить ещё одну ручку», а следствие вполне конкретного инженерного решения, принятого на ранней стадии её конструирования.
Когда в рекламе новой модели звучит «контекстное окно в сотни тысяч или в миллион токенов», за этой цифрой стоит не общая магия масштаба, а в том числе выбор способа кодирования позиций — наравне с готовностью платить квадратичную стоимость центрального механизма. Два разных инженерных решения, принятых на ранних этапах, формируют то, что потом будет продаваться как свойство продукта.
И ещё одна линия, которую стоит дочертить, пока мы ещё в смысловом пространстве. Геометрия смысла — не только удобный образ для объяснения; это причина, по которой LLM ведут себя так, как ведут. Модель, отвечая на запрос, по сути перемещается в этом пространстве: выбирает направление, движется туда, шаг за шагом подбирая токены, которые ближе всего к текущему смысловому положению. Это объясняет и её сильные стороны, и её болезни. Модель хорошо попадает туда, где её смысловое пространство плотно заполнено, — где в обучающих корпусах было много близких примеров. И плохо — там, где в пространстве пустота: редкие темы, специализированные домены, узкие профессиональные контексты. Для компаний с собственной предметной областью эта геометрия важна в практическом смысле: там, где в смысловом пространстве открытой модели зияет пустота, нередко лежит самое ценное содержание бизнеса, — и именно эту пустоту имеет смысл заполнять специализированным обучением или собственной моделью. Этот сюжет вернётся в Главе 5, когда речь пойдёт об основаниях браться за проект, и в Главе 7 — о данных.
Пространство, в котором модель живёт, описано; порядок токенов в этом пространстве обозначен как отдельный инженерный выбор. Остаётся главный вопрос — как модель связывает эти точки между собой, какой механизм заставляет все они работать вместе. Здесь и находится центральный приём всех современных LLM и, одновременно, главная статья их расходов.
3.3. Сердце модели — механизм внимания
У всех современных LLM одно архитектурное сердце — трансформер (transformer). Модели отличаются масштабом, особенностями обучения, дополнительными инженерными хитростями, но основа у них общая. И в центре этого сердца — один приём, давший архитектуре её имя и всей области — её нынешний облик. По-английски он называется attention; по-русски — внимание.
Идея внимания описывается обманчиво просто. Каждый токен в последовательности «оглядывается» на все предыдущие и решает, кто из них важен для того, чтобы его самого понять. Местоимение в середине предложения ищет среди предыдущих токенов то существительное, к которому оно относится. Слово в конце длинного абзаца дотягивается до начала сюжетной нити. Глагол подбирает подходящее согласование. Всё, что мы воспринимаем как «модель что-то понимает в тексте» — удержание связей, улавливание смысла, чувствительность к стилистике, — работает именно через этот механизм. Без внимания связный текст распадается на бессвязные фрагменты; с вниманием — складывается в единое целое.
Это именно сердце конструкции, а не один из равноправных элементов. Остальные части трансформера существуют, по сути, чтобы обслуживать работу внимания — готовить для него представления токенов на входе, преобразовывать его выходы, передавать их следующему слою, где всё повторится снова. В любой современной LLM — десятки таких слоёв, и в каждом внимание работает заново. Биение сердца — не единичный акт: сотни последовательных биений на каждый сгенерированный токен, и каждое имеет свою цену.
Описывается просто; стоит — дорого. Словесное описание укладывается в один абзац; реализация в рабочей модели требует огромного количества вычислений и памяти. Именно здесь, в самом центре конструкции, модель оказывается наиболее прожорливой. Сердце бьётся — и на каждый его удар уходит непропорционально много топлива.
Причина — способ, которым стоимость внимания связана с длиной текста. Она растёт не линейно, а квадратично. Удвоить размер окна, в котором модель видит контекст, — значит увеличить вычисления примерно вчетверо. Утроить — увеличить вдевятеро. Это не технический артефакт, от которого можно избавиться простыми ухищрениями; это коренное свойство механизма, прямое следствие того, что каждый токен должен «посмотреть» на каждый другой. Существуют приближённые варианты, смягчающие квадратичность, — часть современных моделей их использует, — но в базовой форме эта квадратичность остаётся константой индустрии. Её нельзя отменить; можно только платить за неё.
Квадратичность касается не только счёта. Она касается и памяти: чтобы внимание работало, модели нужно хранить промежуточные таблицы «каждый с каждым», и размер этих таблиц тоже растёт как квадрат длины окна. На коротком контексте это — шум; на длинных окнах именно память, а не вычисления, становится узким горлом. Инженерные приёмы, позволяющие работать с большими окнами на ограниченном железе, существуют и активно развиваются, но все они выстроены вокруг одной задачи — как-то примириться с этим квадратичным аппетитом, не отменяя его.
Отсюда — одна из главных экономических констант всей области, и, пожалуй, центральная формула этой главы: длинный контекст — роскошь. И роскошь заметная. Поддерживать окна в сотни страниц текста технически можно; но каждая страница, добавленная к окну, умножается на стоимость — и в обучении, и в каждом последующем ответе модели. Когда в рекламе новой модели звучит эффектная цифра «окно в миллион токенов», за ней стоит не изящное улучшение алгоритма, а готовность платить квадратичную стоимость в большом объёме — на инфраструктуре, способной это выдержать. Длинный контекст — не очередная опция, добавленная в список возможностей; это отдельный бюджет и отдельная инженерная дисциплина.
Для руководителя, выбирающего направление для собственной модели, это соотношение имеет практический смысл. Если главная ценность, которую модель должна давать, требует работы с длинными документами целиком — анализом договоров на сотни страниц, сведением больших баз внутренней документации, обработкой долгих разговоров, — длинный контекст становится одной из определяющих характеристик проекта. А раз так, то и кластер под обучение, и размер команды, и сроки, и инференсная инфраструктура после запуска будут считаться уже с этим множителем внутри. Компании, для которых длинный контекст не критичен и задачу можно решать нарезкой документа на фрагменты с последующей сборкой, чаще всего на этом множителе экономят, — и поступают разумно. Это одно из тех редких мест в проекте LLM, где дорогую опцию не стыдно отложить: она не только стоит много денег, но и добавляет инженерной хрупкости.
Стоит закрыть разговор о сердце модели одним наблюдением — тем, как эта конструкция порождает текст. Сама генерация устроена честно и прямолинейно: модель предсказывает следующий токен, приписывает его к уже сказанному и делает следующий шаг — снова предсказывает один токен, снова приписывает. Шаг за шагом, слово за словом, до конца ответа. Никакого «планирования ответа целиком» не происходит; никакого наброска с последующей правкой; модель идёт вперёд по токенам, каждый раз опираясь только на то, что уже написано. Это и есть та самая непоседливая природа LLM, которую иногда списывают на «творческий характер»: небольшой сдвиг в первом же токене — другой выбор на развилке, другое направление в смысловом пространстве — способен увести весь ответ в другую сторону.
У этого свойства есть прямое продуктовое следствие. Любой контроль над тем, что модель скажет, выстраивается либо на входе — аккуратной формулировкой запроса, предварительной оснасткой, вспомогательными подсказками, — либо на выходе — проверкой уже сказанного и, при необходимости, новой попыткой. Промежуточного вмешательства нет; редактировать ответ «на ходу» не получится в принципе. Это свойство — фундаментальное, а не настроечное, и оно многое объясняет в том, как LLM ведут себя после запуска; в Главе 9 при разборе продуктовых рисков к этому ещё придётся вернуться.
Центральный механизм разобран. Остаётся посмотреть, какими ручками измеряют масштаб получившегося сооружения — что на самом деле стоит за цифрами, привычно звучащими в разговорах о моделях: «семь миллиардов параметров», «семьдесят слоёв».
3.4. Ручки масштаба
В любом разговоре о размере модели регулярно звучат две цифры — число параметров и количество слоёв. «Семь миллиардов параметров». «Семьдесят слоёв». Эти две величины и стоят за словами «большая модель» и «маленькая модель»; всё остальное — подробности, которые обычно настраиваются автоматически. Поэтому полезно усвоить их как две физические ручки, каждую из которых можно крутить, — и каждая крутится дорого.
Первая ручка — число параметров. Параметр — внутреннее число модели, одно из тех, которые настраиваются в процессе обучения, чтобы на выходе получался осмысленный ответ. Для управленческого разговора самая удобная интуиция такая: параметры — условно ёмкость памяти модели, сколько знаний в ней в принципе может уместиться. Большая модель запомнит больше фактов, стилей, языков, доменов; маленькая будет работать в узкой области, но всё остальное ей придётся оставить за скобками. Это не строгая метафора — параметры не хранят факты кусочками, как карточки в картотеке, — но для разговора о масштабе её достаточно.
Величины, о которых принято говорить, измеряются большими порядками. Открытые модели среднего размера — от семи до тринадцати миллиардов параметров. Крупные открытые модели — десятки миллиардов. Фронтирные модели — сотни миллиардов, а при использовании особой архитектурной схемы, о которой пойдёт речь чуть позже, — и триллионов. Когда в публикациях встречается сокращение «7B» или «70B», речь идёт именно об этом — о миллиардах параметров, с приписанной английской буквой B от billion. Два устойчивых якоря, которые удобно держать в голове: открытая линейка Llama — это разноразмерные модели, от небольших до крупных, с подробно опубликованными характеристиками; DeepSeek V3 — одна из крупнейших открытых моделей последнего времени, тоже с развёрнутым техническим отчётом. По этим двум маркерам легко сверять любые другие упоминания, избегая фактологических ошибок.





