Обслуживание крупных языковых моделей (LLMS) в масштабе представляет собой много проблем, помимо тех, с которыми сталкиваются традиционные веб -сервисы или более мелкие модели ML. Стоимость является основной проблемой для вывода LLM, который требует мощных графических процессоров или специализированного оборудования, огромной памяти и значительной энергии. Без тщательной оптимизации эксплуатационные расходы могут стремительно взлететь на услуги LLM с большим объемом.
Например, модель параметров 70 миллиардов, такая как Llama 70b, требует примерно 140 ГБ памяти графического процессора для загрузки в полуоперации, даже до учета дополнительных накладных расходов памяти от промежуточных результатов кэширования. Это иллюстрирует, как память и аппаратные ограничения могут стать узкими местами. Многие предприятия рискуют перерасходовать или недостаточно используются ресурсы, если их развертывание неэффективно.
Задержка представляет собой еще одну значительную проблему. Пользователи ожидают быстрых ответов, но LLMS генерирует последовательно текст, что приводит к задержкам. Этот процесс генерации часто оставляет графические процессоры между выходами токенов, а это означает, что необработанная вычислительная мощность не полностью используется. Достижение низкой задержки требует интеллектуального партии и параллелизма, чтобы удержать аппаратное обеспечение. В противном случае даже передовая модель может показаться вялой в живом приложении.
Пропускная способность, которая определяется как количество запросов или токенов, обрабатываемых в секунду, должна быть максимизирована, чтобы приспособить многих пользователей одновременно. Неэффективное использование графического процессора (например, обработка по одному запросу за раз на графическом процессоре, способном управлять большим количеством) приводит к плохому использованию оборудования, что еще больше снижает возврат инвестиций.
Помимо производительности и стоимости, сложность развертывания вырисовывается. Запуск LLM в масштабе не так просто, как загрузка модели на один сервер. Развертывания производства должны обрабатывать пики трафика, обновления модели и потенциальные сбои. Орчестнируя несколько экземпляров модели в кластере, управляя репликацией моделей в памяти и маршрутизации каждого запроса в соответствующий экземпляр — нетривиальные задачи. Организациям часто необходимо интегрировать вывод LLM с существующей инфраструктурой, обеспечить надежность и устойчивость к разломам, а также поддерживать безопасность и соответствие, все из которых добавляют сложность в трубопровод развертывания.
Таким образом, вывод LLM в масштабе сталкивается с «Бермудским треугольником» затрат, задержки и сложности, где улучшение одного аспекта может легко повлиять на другие. Это стимулировало поиск лучших решений на системном уровне.
Введите Aibrix: облачное собственное решение
Aibrix, запущенный китайским медиа -гигантом Bytedance в начале 2024 года, представляет собой значительный шаг вперед в оптимизации вывода LLM. Этот сервировочный стек VLLM на основе Kubernetes на основе Kubernetes оказался эффективным в различных бизнес-приложениях, демонстрируя его способность обрабатывать реальные, крупномасштабные варианты использования.
По своей сути Aibrix предоставляет необходимые строительные блоки для построения масштабируемой инфраструктуры вывода Genai, сосредоточив внимание на потребностях предприятия.
Фреймворк решает ключевые маршрутизации, автоматические узлы и надежность оборудования, создавая комплексную систему собственного локального вывода, оптимизированную для моделей крупных языков. Что делает Aibrix инновационным, так это сочетание модульного дизайна и глубокой интеграции с Kubernetes. Он разбивает рабочий процесс вывода LLM на микросервисы и компоненты, каждый из которых отвечает за кусок головоломки (например, маршрутизация запросов, планирование, кэширование или масштабирование).
Используя Kubernetes в качестве базовой платформы оркестровки, Aibrix может развернуть и управлять этими компонентами на стандартной облачной инфраструктуре, выиграв от встроенных примитивов Kubernetes, таких как планирование контейнеров, обнаружение услуг и автоматическое избирательство. Фактически, Aibrix определяет пользовательские ресурсы Kubernetes и контроллеры, адаптированные для рабочих нагрузок LLM, что означает, что он расширяет Kubernetes с логикой, специфичной для домена для обработки заданий LLM. Этот облачный собственный подход гарантирует, что решение может работать на любом кластере Kubernetes, развернутой в локальной или облачной среде, которая может беспроводится с существующими экосистемами DevOps.
Aibrix — это больше, чем просто инструментарий для вывода LLM. Он представляет собой сдвиг в сторону инфраструктуры ИИ, нативной облачной, облачной инфраструктуры.
Важно отметить, что Aibrix является открытым исходным кодом, который снижает барьер для организаций, чтобы экспериментировать с ним и адаптировать его к их потребностям. В отличие от проприетарных облачных сервисов, Aibrix дает инженерные команды полный контроль и прозрачность. Он также был разработан в сотрудничестве с отраслевыми экспертами. Инженеры из Google внесли свой вклад в стандартизацию того, как LLM обслуживание может подключаться к Kubernetes через новые API, и AnyScale, создатели Ray, одобрили подход Aibrix к производству VLLM. Этот импульс сообщества подчеркивает, что Aibrix не является изолированным инструментом. Он стремится стать частью появляющегося облачного стека ИИ, сидя вместе с такими проектами, как Kubeflow или Kserve, но сфокусировано на уникальных потребностях крупных языковых моделей.
Как aibrix оптимизирует вывод LLM
Итак, что отличает Aibrix от текущих решений для вывода? На высоком уровне он вводит функции и выбор дизайна, специально разработанных для вывода LLM в масштабе:
Архитектура микросервиса с оркестровкой Kubernetes
Aibrix содержит несколько микросервисов, которые работают в качестве контейнерных компонентов на Kubernetes. Каждый компонент служит определенной цели.
Например, существует модельный контроллер, который регистрирует новые модели или адаптеры и гарантирует активированные стручки, маршрутизатор запроса, который получает запросы от шлюза и отправляет их на модельный бэкэнд при соблюдении политики, а также для выполнения технического управления AI, инициализации модели и набора модели. Использование контейнеров позволяет каждый сегмент трубопровода масштабироваться и обновляться независимо. Если вам требуется увеличенная пропускная способность, вы можете масштабироваться, добавив больше модельных сервисных капсул.
Если у вас есть несколько моделей, плоскость управления может зарегистрировать их через пользовательские ресурсы Kubernetes, позволяя отдельно управлять для каждого. Эта модульная архитектура также означает, что Aibrix может быть адаптирована в будущем для работы с различными двигателями вывода. В настоящее время он жестко интегрируется с VLLM, но можно потенциально включить другой двигатель под капотом благодаря абстракции, предоставленной во время выполнения коляска и стандартизированными интерфейсами.
Динамическая модель и управление адаптерами
Адаптеры с низким уровнем адаптации (LORA) обеспечивают эффективную тонкую настройку LLMS, модифицируя только 0,1% -1,0% параметров посредством разложения матрицы с низким рейтингом. В отличие от традиционной тонкой настройки, которая обновляет все веса, Лора замораживает базовую модель и внедряет матрицы декомпозиции в обучении в трансформаторные слои, захватывая критические адаптации. Этот подход снижает требования к памяти в 3 раза по сравнению с полной точной настройкой, соответствующей или превышающей производительность в нижестоящих задачах, достигая снижения параметров на 99,8% за счет оптимизированных проекций ранга.
Aibrix облегчает обслуживание не только одной модели, но и, возможно, многих вариантов модели. Он обладает поддержкой LORA высокой плотности, позволяющей загружать несколько тонко настроенных адаптеров LORA на базовую модель в одном экземпляре порции. Это означает, что если у вас есть базовая модель, такая как Llama, и многие легкие адаптации для разных задач, Aibrix может эффективно размещать их, не выполняя отдельную тяжелую модель копирования для каждого. Каждая адаптация представляет собой тонкую модель, адаптированную для конкретной задачи, такой как классификация или анализ настроений. Этот подход динамической загрузки адаптеров LORA значительно улучшает использование графических процессоров и снижает стоимость при поддержке многих моделей или версий, специфичных для арендатора.
LLM API Gateway и интеллектуальная маршрутизация
Aibrix предоставляет открытый API-шлюз, который принимает запросы на вывод. Этот AI Gateway, который основан на послужении, включает в себя интеллектуальную логику маршрутизации, которая предназначена для ресурса и нагрузки, что означает, что он может направить каждый запрос на соответствующую реплику модели на основе текущей загрузки GPU, доступности кэша или типа аппаратного обеспечения. Это также обеспечивает соблюдение политики справедливости и ограничения ставок, которые имеют решающее значение в многопользовательских сценариях, гарантируя, что ни один из них не имеет большого пользователя или модели, умирающего других. Этот компонент по существу уравновешивает трафик через кластер модельных серверов. Это может сделать это со знанием LLM-специфических факторов (например, запросов на маршрутизацию с определенными длиной контекста для экземпляров, которые имеют необходимый теплый кэш).
Тонко настроенное автомассалирование для LLMS
Одной из сильных сторон Aibrix является автомасшюрист с LLM. Вместо того, чтобы полагаться исключительно на общие метрики, такие как использование ЦП, логика Aibrix рассматривает метрики, такие как количество запросов в очереди, пропускную способность генерации токена и даже состояние ключевого значения модели для принятия решений масштабирования. Он может развернуть новые экземпляры сервера моделей в течение нескольких секунд, чтобы отреагировать на шипы трафика и уменьшить их при простоя. Быть LLM Aware избегает общих ловушек. Например, это может предотвратить разжигание (ненужное масштабирование вверх и вниз) путем понимания взрывающей природы рабочих нагрузок языковой модели. Это приводит к более стабильной задержке и стоимости. Bytedance сообщил, что, используя эти стратегии, он достиг 79% улучшения задержки хвоста (P99) для своих услуг LLM и значительно снижает затраты в периоды с низким трафиком за счет сокращения накладных расходов (до 4,7 × снижение затрат в тихие периоды благодаря динамической загрузке адаптера).
Распределенный кеш ключей
Особенно новой особенностью Aibrix является его распределенный кеш KV для LLMS. В языковой модели обслуживаемой модели, кэширование промежуточных ключей внимания и значений из предыдущих запросов может значительно ускорить обработку оперативной обработки и позволить эффективное планирование партии многих запросов генерации. VLLM уже реализует быстрый кэш в памяти на одном узле; Aibrix расширяет эту концепцию на несколько узлов. По сути, он обеспечивает механизм для различных экземпляров сервера моделей для повторного использования записей друг друга в кешах или, по крайней мере, не пересказывая с нуля, когда разговор пользователя перемещается в новую копию. Это помогает в кластерной среде, в которой последующий запрос пользователя может достичь другой стручки, чем последний. Распределенный кэш предназначен для доступа к низкой задержке по всей сети и может значительно повысить эффективность для рабочих нагрузок с повторяющимся контекстом. Это пример того, как представление Aibrix по системному уровню открывает возможности, помимо того, что один экземпляр двигателя может сделать в одиночку.
Гетерогенное использование и планирование графического процессора
В реальных сценариях не каждый запрос на вывод требует лучшего графического процессора, а организации часто используют сочетание оборудования, включая различные поколения графических процессоров или комбинаций графических процессоров и процессоров. Aibrix имеет оптимизатор графического процессора, который разумно планирует задачи вывода по всему гетерогенному оборудованию, чтобы минимизировать затраты, придерживаясь целей уровня обслуживания. Например, он может направить короткие или низкие запросы на менее дорогие графические процессоры или даже узлы ЦП, если они способны зарезервировать самые высокие графические процессоры для наиболее требовательных или чувствительных к задержке задач. Кроме того, он может объединить несколько легких моделей или экземпляров адаптера на одном графическом процессоре, когда разрешают ресурсы, включенные в результате поддержки адаптера высокой плотности. Этот метод планирования учитывает производительность каждого устройства и текущую нагрузку, эффективно совместное использование и разделение ресурсов GPU, чтобы максимизировать эффективность на каждом сервере. Результатом является улучшение использования графических процессоров и снижение затрат на запрос, о чем свидетельствуют внутренние реализации Bytedance в области смешанной стратегии обслуживания Aibrix.
Aibrix — это больше, чем просто инструментарий для вывода LLM. Он представляет собой сдвиг в сторону инфраструктуры ИИ, нативной облачной, облачной инфраструктуры. Акцент на модульность, масштабируемость и экономическую эффективность решает реальные требования развертывания LLM в масштабе. Если он продолжит развиваться и собирать поддержку сообщества, Aibrix может стать эталонной архитектурой для обслуживания LLM, так же, как и Kubernetes для оркестровки контейнеров.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Janakiram MSV является основным аналитиком в Janakiram & Associates и адъюнкт -преподавателем Международного института информационных технологий. Он также является квалифицированным Google Cloud Developer, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon, … Подробнее от Janakiram MSV
