На конференции Google Cloud Next, прошедшей в этом месяце в Лас-Вегасе, мы встретились с соучредителем и генеральным директором Finout Роем Равоном и Патиком Шармой, возглавляющим направление облачных FinOps в Google Cloud, чтобы поговорить о том, как финансовая дисциплина, сформировавшаяся вокруг управления затратами на облачные услуги, сейчас стремительно адаптируется к эпохе искусственного интеллекта.
«Нам нужно сделать для ИИ то же самое, что мы сделали для облачных технологий, но мы делаем это за год». — Рой Равхон, соучредитель и генеральный директор Finout
В этом выпуске наши два гостя рассказывают о том, почему токен-экономика заставляет FinOps развиваться быстрее, чем в эпоху облачных технологий, почему инструменты агентского FinOps нуждаются в детерминированных ограничителях, чтобы быть полезными, и почему оба по-прежнему рекомендуют новичкам в этой дисциплине начинать с FinOps Foundation, а не с поставщика FinOps.
Экономика токенов в условиях дефицита времени
У облачных технологий было десять лет, чтобы развиться вокруг FinOps. ИИ, как утверждает Равхон, имеет всего около года, потому что экономика эксплуатации ИИ в производственной среде разрушает старые предположения этой дисциплины.
Первое отличие заключается в том, что, несмотря на то, что цены на токены продолжают падать, затраты предприятий на ИИ продолжают расти. Компании Anthropic и OpenAI выпустили новые флагманские модели примерно в то время, когда мы записывали это интервью, но новые модели рассуждений «думают в три раза больше», — говорит Равон, — а это означает, что они используют больше токенов для выполнения той же задачи.
Другое важное отличие заключается в том, что стоимость одного и того же запроса не является фиксированной.
«Вы задаете один и тот же вопрос дважды и получаете разные показатели использования токенов для всего», — говорит Равон. «Так как же это масштабировать?»
Терпение финансовых директоров по отношению к такому уровню непредсказуемости на исходе. Равон говорит, что финансовые директора начали этот цикл с «неограниченными бюджетами […], давайте будем инновационными, потому что инновации — это очень важно». Теперь разговор вернулся к вопросу о рентабельности инвестиций.
Не хватайтесь за молот Тора, когда он вам не нужен. — Патик Шарма, специалист по облачным FinOps в Google Cloud
Шарма из Google подхватывает эту тему, приводя аналогию, которую, по его словам, он использует в разговорах с клиентами: не хватайтесь за молот Тора, если он вам не нужен.
«Мы начали использовать [модели] Gemini Pro для всего», — вспоминает он слова одного из клиентов. «Можете ли вы подготовить для меня резюме этого письма? Можете ли вы помочь мне писать более качественные письма?»
Но для большинства таких случаев вполне подходит Flash — более компактная и значительно более дешевая модель Gemini от Google. Суть дисциплины FinOps не в том, чтобы просить каждого сотрудника запомнить, какая модель подходит для какой задачи; суть в создании нижележащего уровня оркестрации, который направляет каждый запрос к самой дешевой модели, способной надежно на него ответить.
В более широком контексте Шармы расходы на LLM API — это лишь одна из составляющих счета за ИИ. Стоимость эксплуатации ИИ также распространяется на GPU и TPU (которые по-прежнему в дефиците), вычислительные ресурсы для обучения и инференса, хранение данных, которые их питают, а также организационные затраты на внедрение ИИ. Шарма также цитирует недавнее исследование Стэнфордского университета, которое подтверждает более ранний вывод: «На каждый доллар материальных инвестиций в технологии компании тратят до 10 долларов на нематериальные активы (перепроектирование процессов, переобучение персонала, организационную трансформацию)». На этот раз речь идет о технологии ИИ.
Другая половина ответа заключается в запуске более компактных моделей ближе к пользователю. Шарма говорит, что он установил на свой телефон Gemma, небольшую открытую модель Google. Ее размер не превышает 4 ГБ, и она способна выполнять резюмирование, OCR и перевод на устройстве. По его мнению, это показывает, что не каждый запрос требует передовой модели.
Не просите LLM исправить ваш Kubernetes
FinOps, по словам Равона, — это «все о мелких проблемах, которые нужно исправить». Крупное предприятие с тысячами разработчиков получает постоянный поток рекомендаций по оптимизации размера и аномалий в избыточной инфраструктуре, о которых никто не заботится индивидуально. Но для компании это обходится в большие деньги.
Традиционным решением было увеличение штата и продвижение культуры, чтобы заставить инженеров заботиться об этом.
В эпоху агентов возникает соблазн просто бросить LLM на проблему и позволить ему ее решить. Но это на самом деле не работает, утверждает Равхон. «FinOps — это частично детерминированная задача, поэтому нельзя на 100% полагаться на то, что LLM все сделает», — говорит он. Оптимизация имеет жесткие пороги, а за обнаружением аномалий стоит математика. Но, по его опыту, LLM могут «убедить себя, что они правы, когда хотят быть правыми».
Архитектура, которую Равхон описывает для агентного FinOps, в его представлении является детерминированной и немного похожа на сборку кубиков Lego. Скучные части остаются детерминированными, а агентный уровень соединяет их воедино. «Если вам нужно обнаружение, то обнаружение является детерминированным. Не пытайтесь изобретать велосипед», — говорит он. Обогащение и анализ контекста, напротив, являются «отличными рабочими нагрузками для агентов». Перед тем как предпринять что-либо разрушительное — например, завершить работу сервера — перед LLM должна быть предусмотрена детерминированная проверка или этап утверждения человеком.
Концепция Шармы заключается в том, чтобы думать о внедрении агента ИИ так же, как вы думали бы о приеме на работу нового SRE, уделяя особое внимание стандартам, ограниченным разрешениям и руководству по принятию решений командой.
В качестве примера он приводит оптимизацию размера Kubernetes на GKE. «Вы не говорите: «LLM, исправь мой Kubernetes», — говорит Шарма. Вместо этого, по его мнению, вы даете агенту те же сигналы, которые использовал бы SRE: золотые сигналы, соотношение запросов и лимитов, метрики наблюдаемости за последние 30 дней, использование vCPU p99, пиковую загрузку памяти. Затем агент формирует рекомендацию в виде запроса на изменение (pull request), который владелец приложения может одобрить или отклонить. «Теперь вы мгновенно завоевываете доверие, — говорит он. — Я знаю, откуда взята эта рекомендация. Я знаю, что она контекстуальна».
Дело никогда не было в инструменте
Когда их спросили, с чего следует начать новичку в FinOps, ни один из них не упомянул свой собственный продукт.
«Зарегистрируйтесь в FinOps Foundation», — говорит Равхон. «FinOps — это прежде всего организационная проблема, которую мы пытаемся решить. Просто покупка инструмента FinOps не решит проблему».
«FinOps — это прежде всего организационная проблема, которую мы пытаемся решить. Простое приобретение инструмента FinOps не решит проблему». — Рой Равхон, генеральный директор Finout
Инструменты идут на втором месте, утверждает Равхон. В первую очередь необходимо изменить культуру: обеспечить межкомандную подотчетность, создать инженерные команды, которые действительно заботятся о затратах, и сформировать отношение к расходам на облачные услуги как к инвестициям.
«Только когда вы поймете, что вам нужен инструмент для дальнейшего масштабирования, настанет время обратиться к Finout или аналогичному инструменту», — говорит он.
Шарма согласен с этим. «Независимо от того, кто вы, если вы работаете с облаком, у вас в руках ключи от королевства», — говорит он. «Как сказано в фильме о Человеке-пауке, с великой силой приходит великая ответственность».
Он утверждает, что если все, кто управляет инфраструктурой, начнут смотреть на нее с точки зрения ценности, а не с точки зрения чистых затрат, все остальное, включая подотчетность, эффективность и управление, последует автоматически.
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться