Большие языковые модели прочно засели в новостном пространстве, позволяя изменить подход к огромному количеству задач и дразня новой технологической революцией. Однако основной прогресс LLM сейчас происходит в компаниях, фокусирующихся на предоставлении LLM как сервиса, используя специфические технические и инфраструктурные решения. Это оставляет энтузиастам, собирающим своего собственного локального цифрового помощника, малые модели с открытыми весами. И модели эти, как кажется, будут отставать от старших братьев.
Однако это открывает интересное поле для рассуждений — какой могла бы быть архитектура модели, конкурирующей с передовыми облачными решениями на локальных потребительских GPU? Я погрузился в поиски статей на эту тему и хотел бы поделиться результатами и немного поспекулировать.
Ограничения и особенности использования потребительских GPU
При обработке единичного запроса LLM главным ограничением является как объем видеопамяти, так и ее пропускная способность. Современные модели задействуют приблизительно треть потенциальной вычислительной мощности видеокарты. Более того, модели, помещающиеся в память и полностью использующие пропускную способность ее памяти, все равно выдают большее количество токенов в секунду, чем человек способен прочитать или выслушать. Такие модели способны генерировать около 50-200 токенов в секунду, тогда как люди читают 7, а слушают и вовсе от силы 4 токена за то же время.
Таким образом, можно выписать список пожеланий к модели для частного локального пользования:
Количество параметров, позволяющее модели помещаться в память GPU или даже в ее малую часть.
Для сложных запросов средняя скорость генерации текста должна соответствовать скорости прочтения текста пользователем.
Модель должна утилизировать всю мощность GPU при обработке запроса.
Тут необходимо отметить основное расхождение между инженерными решениями оптимизации промышленных и локальных решений, поскольку те же самые задачи сервисы решают в других условиях:
Поскольку назначение серверных GPU другое, они могут иметь больший объем памяти и пропускную способность.
Много серверных GPU могут быть установлены на одном сервере для расширения объема и пропускной способности памяти. Также есть возможность дальнейшего масштабирования в кластере.
Некоторые методы, вроде батч процессинга, позволяют оптимизировать пропускную способность памяти при помощи параллельного расчета нескольких запросов.
Как видно из указанных методов оптимизации, сервисы могут иметь другие требования к используемым моделям. Это сильно влияет на выбор архитектуры модели ее разработчиками. Так, по эмпирическим законам масштабирования, большинству компаний, занимающихся LLM, для достижения наилучшего качества выгоднее тренировать модели, которые никак не разместятся в пользовательских GPU. Прямо сейчас можно заметить эволюцию архитектур в симбиоз малых локальных LLM с ограниченным набором возможностей, оптимизированных под NPU, и LLM-сервисов, которые могут использовать все преимущества параллельной обработки запросов и железа, недоступного потребителю. Можно сделать вывод, что свой собственный AGI на своей собственной видеокарте — несбыточная мечта.
Тексты, не предназначенные для чтения
В этом контексте очень интересно прозвучали новости от компании OpenAI, выпустившей свою новую линейку моделей o1-preview и o1-mini, про которые уже было хорошо написано на Хабре, предложивших новое направление через масштабирование вычислительных ресурсов во время генерации текста. Решение от OpenAI, хоть и закрытое, компоненты его хорошо угадываются: новые модели используют вычислительные мощности для генерации огромного количества текста внутреннего монолога модели, который затем сжимается для прочтения пользователем. Тут можно описать краткую историю развития этой идеи вне OpenAI.
Начало подобным методам положил опыт промпт-инженеров, которые выяснили, что если в запросе указать модели, как думать о задаче, и предложить выписать все действия явно, то модель будет решать задачу гораздо лучше. Буквально предоставленная возможность модели использовать свою собственную речь как черновик и как память для хранения промежуточных шагов показала эффективность этого подхода. После уже появились интерпретации, что люди сами используют свой внутренний монолог и черновики, но эти примеры далеко не всегда оказываются в тренировочных данных.
После этого инициация цепочки рассуждений через промптинг получила признание как метод и начала обрастать модификациями:
Метод генерации рассуждений не только последовательно, но и параллельно, с последующим выбором наиболее перспективных рассуждений.
Метод самокритики и оценки качества ответа самой моделью. Как ни удивительно, проверка рассуждений является гораздо более естественной для LLM задачей, чем их генерация.
Как для себя открыли впоследствии и исследователи, и энтузиасты, промптинг не является прямо необходимым для моделей, достаточно внимательно смотреть на выходные вероятности последующих токенов. Этих вероятностей достаточно, чтобы определить, что модель не уверена в своем ответе, и попытаться сгенерировать рассуждение снова в надежде, что следующая попытка выйдет лучше.
Естественно, все, что может быть в промпте и может генерировать правильные рассуждения, может быть зашито в саму модель в процессе тюнинга:
При помощи промпта направить модель на рассуждения шаг за шагом, бегло проверить рассуждения вручную и использовать полученные наборы для дальнейшего обучения.
Набрать таким же способом хорошие и плохие примеры рассуждений и на их основе обучить модель-критика (Direct Preference Optimisation), и уже с ее помощью тюнить результирующую модель.
Если уж речь зашла о тюнинге через модель-критика, то большие компании, вроде OpenAI, могут позволить себе добавить туда модерацию людьми, оценивая каждый шаг в процессе рассуждений.
Дальше доступные статьи больших лабораторий рассыпаются в разные стороны, но оперируют все теми же компонентами — генерацией цепочек рассуждений, построением моделей оценки качества цепочек через правильность ответа, построением моделей оценки качества отдельных шагов, применением этих моделей и для отбора тренировочных данных, и во время использования. Примеры 1, 2, 3, 4.
А теперь обратно к вопросу — дает ли это надежду энтузиастам локальных LLM? Скорее всего, да. Хотя пока такой моделью может похвастаться только OpenAI, можно ожидать, что подобные методы тюнинга будут применяться и к моделям с открытыми весами в будущем. Мало того, прецедент выпуска o1 во многом меняет взгляд индустрии на малые модели и их предназначение. Так, в интервью Андрей Карпати говорит о том, что, возможно, следует ожидать в языковых моделях уменьшения значимости "энциклопедического" функционала, так как в задачах, решаемых этими моделями, большинство зашитых туда знаний об интернете является явно излишними. И можно ожидать модели размером в 1-8 миллиардов параметров, способные к здравым рассуждениям на человеческом уровне, но обращающиеся к другим источникам для дополнительной информации.
Об уменьшенных больших моделях
Сложно говорить без спекуляций о количестве параметров моделей ChatGPT-o1, но все же стоит задать вопрос — если вдруг веса модели такого калибра будут доступны сообществу, какие методы могут позволить вместить ее в пользовательскую GPU? Ответов не так много — квантизация и дистилляция.
Квантизация моделей — это уменьшение размера моделей, изначально хранящих параметры с FP32 или FP16 точностью, посредством снижения точности индивидуальных параметров. Эта техника не является новой, квантизированные GGUF файлы уже являются стандартным форматом распространения моделей для индивидуального использования. С потерей точности модели теряют и в качестве, но комьюнити охотно экспериментирует с подбором размера изначальной модели и степенью ее сжатия для решения индивидуальных задач. Так что если фронтир-модель появится в открытом доступе, сразу же появятся ее менее точные аналоги. Главное, чтобы изначальная модель была разумного размера. Пока модели вроде llama 3 405B недоступны рядовым энтузиастам не только для GPU, но и для использования на CPU для большинства пользовательских машин.
Предельным случаем моделей с ограниченной точностью можно назвать однобитные модели. Майкрософт в начале прошлого года представил концепцию однобитных LLM, демонстрируя, что для функционирования подобным моделям достаточно лишь диапазона значений (-1, 0, 1). К сожалению, построить такую модель через квантизацию не выйдет, ее нужно изначально обучать для тернарной системы. Мало того, подобная модель достигает одинакового качества с классическими LLM лишь при десятикратном увеличении количества параметров, то есть используя тот же объем памяти. Основными победителями снова становятся обладатели специализированного оборудования, поэтому ожидания от выпущенных недавно библиотек для бинарных LLM следует иметь крайне скромные.
Другим способом демократизации больших моделей является дистилляция — метод, при котором малая модель обучается не на оригинальных данных, а на выходных предсказаниях (логитах) более мощной модели-учителя. Подобные данные являются гораздо более богатым источником информации, нежели текст, на котором обучалась изначальная модель. Примером дистиллированной модели могут быть 1B и 3B версии Llama 3.2, легко доступные для использования.
Дистилляция и квантизация дают надежду, что закрытые методы обучения, описанные в предыдущем разделе, имеют шанс дойти до энтузиастов в виде открытых весов и быть применимы на потребительском железе.
Альтернативные архитектуры
Все перечисленные ранее методы затрагивают в основном нюансы тренировки модели, данные, на которых она обучается, и оптимизацию инференса, но не изменяют саму по себе классическую архитектуру GPT. Поэтому интересно рассмотреть, какие изменения могли бы позволить подогнать архитектуру к особенностям локального инференса.
Тут надо сразу сделать одно замечание о том, что многие альтернативные архитектуры сейчас находятся буквально в патовом положении. Большинство идей, демонстрирующих результаты на малых моделях, не проявляют себя на промышленных объемах данных, что сильно затрудняет перенос академических исследований в индустрию. Примером может послужить статья о Mamba архитектуре, не прошедшая на конференцию, поскольку авторы "не проверили" траектории масштабирования для модели с более чем полутора миллиарда параметров. Поэтому большинство идей закономерно находятся в лимбе, не имея возможности быть ни подтвержденными, ни опровергнутыми.
Из архитектур, которые пробились в свет, можно выделить MoE (Mixture of Experts) модели, которые являются конструкцией из идентичных по архитектуре LLM, называемых экспертами, и модели-роутера, которая в зависимости от контекста выбирает, каких экспертов следует выбрать для предсказания следующего токена. Сама идея, что во время обработки токена модель может использовать лишь часть своих весов, позволяет не только ускорять обсчет модели, но и обходить ограничение по размеру модели, жонглируя весами экспертов, находящихся в конкретный момент в памяти GPU. Хотя объем перестает быть проблемой, они все еще ограничены скоростью доступа к памяти. Из несвязанных с этим хороших новостей — уже исследуются методы улучшения небольших моделей через превращение их в MoE модели.
Как кажется, для решения центральной проблемы эффективности утилизации GPU необходимо использовать меньше параметров, но использовать их несколько раз. Подобная идея уже упоминалась раньше в методах Tree of Thought, где из одного и того же промпта могло генерироваться несколько рассуждений, создавая независимые рассуждения параллельно. Но было бы здорово, если бы подобная идея была применена в более общем виде. Так, идея использования одних и тех же весов уже применялась в энкодер сетях ALBERT и Universal Transformers, но хоть для GPT работа ведется, каких-то прорывных результатов я не нашел.
Из идей этого направления хотелось бы отметить идею введения "пустых" токенов, основная цель которых не в предоставлении новой информации и не в генерации текста, а в том, чтобы предоставить текстовой модели дополнительное пространство для хранения промежуточных данных и произведения дополнительных вычислений. Довольно простой подход, предложенный в оригинальной статье, рассыпающий эти токены случайным образом по тексту, уже показывает хорошие результаты, но не дает пока ответа на вопрос как использовать подобную идею в более общем виде.
Заключение
Как видите, на сегодняшний день попытки перенести большие языковые модели на локальные пользовательские устройства сталкиваются с серьезными техническими ограничениями, однако успешность методов квантизации и дистилляции позволяет верить, что прогресс промышленных моделей будет доступен также и для локального пользования. Исследования, ведущиеся академическим сообществом и энтузиастами, также дают надежду на то, что сингулярность не наступит за закрытыми дверями.
Комментарии (4)
BlackSCORPION
22.10.2024 23:51Если бы был какой то проект распределеных вычислений, с удовольствием бы отдал 3090 на нужды народа ). Электричество у нас недорогое, лишнее тепло зимой не помешает, не шумит.
Да и весь комп можно отдать, с этой мобильностью он в основном пыль собирает )
Нужен такой проект способный раскидывать кусочки работы на весь мир и собирать обратно в идеале децентрализовано
Каждый сам выбирает какую работу делать какую нет, по любым своим причинам, истинная демократия
liquiddeath13
22.10.2024 23:51Когда-то хотел такой движок игровой написать.. "распределенный". В универские годы. Образовались долги по учёбе и пришлось вернуться к реальности.
Идея очень крутая, но..
Это не выгодно тем, кто каждый год штампует игровое железо. Это никогда не будет иметь поддержки
Kethate93
22.10.2024 23:51
VSAI
Не очень оптимистично. О когнитивных промптах, которые упростят работу на результат с ИИ лучше обсуждать с инженерными психологами, которых тут нет, как я понимаю, кроме меня. И самое важное, между ИИ и Человеком нужен современный интерфейс, а не просто токены и железо. Он нужен и для глубокого обучения, и для файнтюнинга, и для непосредственной работы, генерации. Это если коротко.. Мнения?