АТЛАНТА — Эти надоедливые ИИ-агенты. Вы никогда не узнаете, какие проблемы они причинят.
Хитрые и вредоносные программы повысят свои привилегии и причинят неизвестно какой ущерб реальным системам.
Однако Google LLC решила проблему с помощью песочницы агента Google Kubernetes Engine (GKE), в которой можно размещать код и инструменты, сгенерированные большой языковой моделью (LLM), в ограниченной среде.
Это одна из многих инициатив, которые компания предприняла для привлечения крупномасштабных рабочих нагрузок искусственного интеллекта на свою облачную платформу и демонстрирует ее на KubeCon + CloudNativeCon North America, проходившем в Атланте на этой неделе.
Компания также провела ряд оптимизаций своего облачного сервиса Kubernetes, чтобы он мог быстрее обрабатывать крупномасштабные задачи ИИ.
«Наши клиенты, особенно некоторые из клиентов, выполняющих рабочие нагрузки ИИ, требуют большего масштабирования, лучшей производительности, большей экономической эффективности, меньшей задержки», — сказал Натан Бич, директор по управлению продуктами Google, в интервью TNS.
По данным PricewaterhouseCoopers LLP, около 79% старших ИТ-руководителей внедрили агентов ИИ, а 88% планируют в этом году увеличить ИТ-бюджеты для внедрения агентов ИИ.
С этой целью компания выпустила в общий доступ свой GKE Inference Gateway — набор оптимизаций (на основе расширения вывода Kubernetes) для более быстрого выполнения рабочих нагрузок ИИ.
Первые результаты выглядят многообещающе. В производственной версии время ожидания первого токена (TTFT) сокращено на 96%, при этом используется на четверть меньше токенов по сравнению со стандартными реализациями GKE.
Более быстрое автоматическое масштабирование также является приоритетом для компании. Также было увеличено количество узлов, которые GKE может поддерживать, до 130 000 в одном кластере. Это должно справиться даже с самыми большими учебными нагрузками. Песочница для безопасности, управления и изоляции
«Agent Sandbox устраняет то, что мы считаем одним из самых больших пробелов в нынешней экосистеме агентов», — сказал Бич.
«Агентам необходимо делать больше, чем просто то, что может сделать существующий инструмент», — продолжил он. «Таким образом, агенту необходимо будет выполнить, например, код, сгенерированный LLM, которому нельзя полностью доверять».
GKE Sandbox использует gVisor для изоляции сред LLM от других рабочих нагрузок в сети. В «песочницу» были также встроены и другие возможности для создания снимков «песочницы» и вычислений, оптимизированных для контейнера.
Администратор устанавливает, какие привилегии может иметь LLM. У него может быть доступ к Интернету, хотя песочница не позволяет агенту рыться во внутренней системе.
А в случае, если что-то пойдет совсем не так, песочницы можно вернуть в исходное состояние менее чем за три секунды.
Шлюз вывода GKE
Шлюз вывода GKE был настроен для рабочих нагрузок ИИ, которые могут иметь характеристики балансировки нагрузки, отличные от большинства заданий Kubernetes, и, следовательно, могут задерживаться в работе.
Gateway оптимизировал два конкретных вида задач ИИ. По словам Google:
- Маршрутизация с учетом LLM для таких приложений, как многоходовой чат, который направляет запросы к одним и тем же ускорителям для использования кэшированного контекста, избегая скачков задержки.
- Дезагрегированное обслуживание, который разделяет этапы «предварительного заполнения» (оперативная обработка) и «декодирования» (генерация токенов) на отдельные оптимизированные машинные пулы.
«Шлюз позволяет клиентам значительно сократить задержку при обслуживании LLM и сделать это таким образом, чтобы увеличить пропускную способность и снизить стоимость вывода», — сказал Бич.
Улучшения автомасштабирования
В других местах автомасштабирование было пересмотрено: параллельно выполняется больше операций по выделению узлов. Google также может настроить буфер предварительно подготовленных узлов, которые можно подготовить практически мгновенно.
Даже на новейшем оборудовании запуск LLM может занять до 10 минут и более. Чтобы обойти эту проблему, Google разработал GKE Pod Snapshots или снимки памяти, которые можно использовать для перезапуска задания, экономя до 80 % времени запуска.
«Pod Snapshots идеально подходит для ситуаций, когда вы горизонтально масштабируете и создаете новые реплики», — сказал Бич.
Снимок включает в себя память ЦП и графического процессора, которая записывается в Google Cloud Storage.
«Мы восстанавливаем этот снимок из облачного хранилища, что значительно сокращает время, необходимое для масштабирования. [additional] случаев, потому что вам не придется начинать с нуля», — сказал он.
С помощью снимка модели с 70 миллиардами параметров можно загрузить за 80 секунд, а модель с 8 миллиардами параметров можно загрузить всего за 16 секунд.
Другие настройки, позволяющие сэкономить время, включают обновление потоковой передачи изображений контейнера GKE компании, позволяющее запускать контейнерные приложения до загрузки всего образа контейнера.
Компания открывает исходный код своего решения многоуровневой контрольной точки (MTC), которое предлагает возможность хранить различные контрольные точки на разных типах хранилищ, таких как локальные твердотельные накопители, оперативная память и резервное хранилище, что позволяет при необходимости быстрее восстанавливать рабочие нагрузки.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джоаб Джексон — старший редактор The New Stack, специализирующийся на облачных вычислениях и системных операциях. Он освещал вопросы ИТ-инфраструктуры и ее развития более 30 лет, в том числе работал в IDG и Government Computer News. До этого он… Подробнее от Джоава Джексона
