6.6 Инфраструктура и эксплуатация ИИ

Обзор и мотивация

Инфраструктура и эксплуатация ИИ это дисциплина развёртывания, планирования и запуска специализированных вычислительных систем, систем хранения и обслуживания, которых требуют нагрузки ИИ, экономично, надёжно и наблюдаемо. Современный ИИ дорог в эксплуатации. Обучение и обслуживание больших моделей требуют дефицитных ускорителей (GPU и TPU), сетей с высокой пропускной способностью, крупномасштабного векторного хранилища для поиска (индексирования данных как числовых векторов, чтобы схожие элементы можно было быстро находить) и слоёв обслуживания, настроенных на задержку и пропускную способность. Правильная инфраструктура это разница между ИИ, масштабирующимся устойчиво, и ИИ, тихо потребляющим бюджет и недодающим.

Для больших команд основные проблемы масштаб, дефицит и цена. Ускорители ограничены и дороги, поэтому планирование и загрузка важны чрезвычайно. Простаивающие GPU сожжённые деньги, а плохо сгруппированный вывод умножает цену за запрос. Приложениям с интенсивным поиском нужны векторные базы данных, остающиеся быстрыми по мере роста. Приложениям генеративного ИИ нужны версионирование промптов, конвейеры оценки и наблюдаемость (иногда называемые LLMOps), чтобы безопасно работать и улучшаться со временем. Без общей инфраструктуры и эксплуатационной дисциплины каждая команда ведёт те же битвы, а затраты раскручиваются по спирали.

Государственные и регулируемые организации добавляют требования вокруг суверенитета данных, безопасности и предсказуемых расходов. Им может понадобиться локальное развёртывание или развёртывание в суверенном облаке, чтобы чувствительные данные и модели никогда не покидали контролируемых границ. Они должны прогнозировать и обосновывать расходы на инфраструктуру и соответствовать стандартам безопасности и доступности. Решения по инфраструктуре ИИ в этих условиях несут многолетние последствия, поэтому принимайте их с оглядкой на закупки, безопасность и выход.

Ключевые принципы

• Воспринимайте вычисления на ускорителях как дефицитный дорогой ресурс, который нужно планировать и загружать, а не копить.
• Оптимизируйте цену на полезную единицу работы, а не сырую мощность.
• Подбирайте размер моделей и оборудования под задачу; самый большой вариант редко самый экономичный.
• Проектируйте обслуживание под задержку и пропускную способность, с группировкой и кэшированием как первоклассными техниками.
• Делайте системы ИИ наблюдаемыми: отслеживайте стоимость, задержку, качество и ошибки непрерывно.
• Версионируйте и оценивайте промпты и модели с той же строгостью, что и код.
• Планируйте переносимость и избегайте привязки в выборе инфраструктуры и обслуживания.

Рекомендации

Планируйте и контролируйте вычисления на ускорителях

Прогнозируйте спрос на обучение и вывод отдельно, поскольку у них разная форма. Обучение всплесковое и поддаётся планированию; вывод непрерывный и чувствителен к задержке. Используйте планировщики и квоты, чтобы делить дефицитные GPU и TPU между командами, приоритизировать нагрузки и повышать загрузку. Измеряйте загрузку и воспринимайте хроническое простаивание как проблему для исправления. Смешивайте зарезервированную мощность для базовой нагрузки с мощностью по требованию или спотовой для всплесков, чтобы контролировать цену. Рассмотрите, не хватило бы более дешёвых или меньших ускорителей или вывода на CPU для лёгких моделей. Выбирайте между облаком, локальным и гибридным размещением по цене в вашем масштабе, потребностям суверенитета данных и шаблонам всплесков и сохраняйте путь выхода.

Стройте инфраструктуру поиска: эмбеддинги и векторные базы данных

Для приложений с дополнением поиском поднимите инфраструктуру для порождения эмбеддингов (числовых векторных представлений, размещающих схожие элементы рядом) и хранения их в векторной базе данных, поддерживающей быстрый приближённый поиск ближайших соседей (нахождение наиболее схожих векторов без исчерпывающего сравнения каждого) в вашем масштабе. Планируйте три вещи: цену и задержку порождения эмбеддингов, свежесть индекса по мере изменения документов и эксплуатационное бремя поддержания согласованности индексов. Оцените, лучше ли подходит вашему масштабу и терпимости к привязке выделенная векторная база данных, векторное расширение существующей базы или управляемый сервис. Мониторьте задержку и полноту поиска, потому что качество поиска напрямую определяет качество приложения.

Оптимизируйте обслуживание моделей: группировка, кэширование и задержка

Обслуживание это то, где решаются цена вывода и пользовательский опыт. Используйте группировку (batching) для совместной обработки нескольких запросов и повышения пропускной способности ускорителя, балансируя размер группы против задержки. Используйте кэширование агрессивно: кэшируйте идентичные или семантически схожие запросы, кэшируйте эмбеддинги и используйте кэширование промпта или префикса там, где платформа это поддерживает, чтобы не пересчитывать общий контекст. Задавайте ясные цели по задержке и измеряйте хвостовую задержку, а не только средние. Направляйте запросы к моделям подходящего размера: малая модель для простых случаев, большая только когда нужно. Автомасштабируйте обслуживание под спрос и проводите нагрузочное тестирование до запуска, чтобы знать вашу мощность и кривую цены.

Практикуйте LLMOps: версионирование промптов, конвейеры оценки и наблюдаемость

Воспринимайте промпты как версионируемые артефакты в системе контроля версий с рецензией и возможностью отката. Стройте конвейеры оценки, автоматически запускающие офлайн-наборы тестов всякий раз, когда меняются промпты или модели, чтобы ловить регрессии до выпуска. Инструментируйте эксплуатацию полностью: журналируйте входы, выходы, задержку, расход токенов, стоимость и ошибки с выборкой и защитами приватности. Отслеживайте сигналы качества и обратную связь пользователей онлайн. Эта наблюдаемость позволяет ловить деградацию, контролировать цену, отлаживать отказы и безопасно улучшать системы: эксплуатационный хребет генеративного ИИ в эксплуатации.

Управляйте стоимостью неустанно и наблюдаемо

Относите расходы на ИИ на команды и случаи использования, чтобы стоимость была видимой и имела владельца. Задавайте бюджеты и оповещения, мониторьте стоимость на запрос и на результат и регулярно пересматривайте крупнейшие драйверы стоимости. Тяните рычаги, которые у вас есть: подбор размера модели, кэширование, группировка, обрезка промпта и контекста и выбор дешевейшего развёртывания, удовлетворяющего требованиям. Цена ИИ может масштабироваться с использованием неожиданными способами, поэтому непрерывная наблюдаемость стоимости существенна, чтобы избежать неприятных сюрпризов.

Компромиссы: плюсы и минусы

Решение	Вариант A	Вариант B	Компромисс
Расположение вычислений	Облако	Локально	Эластичность и малая предварительная цена против контроля, суверенитета и установившейся экономики
Мощность	Зарезервированная	По требованию/спот	Предсказуемая цена против гибкости и риска прерывания
Размер группы	Большие группы	Малые группы	Пропускная способность и цена против задержки
Размер модели	Большая модель	Малая модель	Качество против цены и скорости
Векторное хранилище	Выделенная база данных	Расширение существующей базы данных	Производительность в масштабе против простоты и меньшего числа систем
Кэширование	Агрессивное	Минимальное	Меньшая цена и задержка против свежести и сложности

Доминирующий компромисс это цена против задержки и качества. Группировка, кэширование и меньшие модели снижают цену, но могут добавлять задержку или снижать качество. Правильный баланс зависит от терпимости вашего приложения. Локальное против облака меняет контроль и установившуюся экономику на эластичность и малое обязательство, решение, сильно определяемое потребностями суверенитета данных и масштабом.

Вопросы для обсуждения с командой

1. Какова наша цена на полезный результат сегодня и какой рычаг сдвинул бы её больше всего? Сырая мощность и средние значения на запрос скрывают число, которое важно: во сколько обходится поставка одной реальной единицы ценности и как это масштабируется с использованием. Для большой команды разрыв между оптимизированным и неоптимизированным развёртыванием нередко в несколько раз по расходам, поэтому этот вопрос превращает смутную тревогу о счёте в ранжированный список исправлений. Принесите текущее отнесение затрат по командам и случаям использования, тренды на запрос и на результат и крупнейшие драйверы стоимости. Обсудите рычаги в порядке отдачи: подбор размера модели, кэширование (включая кэширование префикса и семантическое), группировка и обрезка промпта или контекста. В государстве добавьте давление прогнозировать и обосновывать многолетние расходы. Ответ должен назначить каждому главному драйверу стоимости владельца и рычаг, а не пожимание плеч.

2. Если бы наш текущий провайдер вывода удвоил цену или упал завтра, как быстро мы могли бы переключиться? Молчаливую привязку легко построить и больно покидать, а стеки обслуживания то место, где она прячется глубже всего. Для корпораций и особенно государства переносимость требование закупок и непрерывности, а не любезность. Принесите вашу архитектуру: сидят ли модели за внутренним интерфейсом, переносимы ли промпты и наборы оценки и на сколько специфичного для провайдера поведения обслуживания вы опираетесь. Сигнал, за которым стоит следить: запускал ли кто-либо ваш набор оценки против второго провайдера или второй цели развёртывания. Если переключение заняло бы месяцы и переписало основные пути, воспринимайте это как проектный дефект для устранения сейчас, поскольку суверенные и локальные варианты могут стать обязательными без особого предупреждения.

3. Какова загрузка наших ускорителей прямо сейчас и сколько сжигают простаивающие GPU и несгруппированный вывод? Ускорители дефицитны и дороги, поэтому хроническое простаивание и обслуживание по одному запросу тихо истощают бюджеты, которые могли бы финансировать больше возможностей. Для большой организации, делящей GPU между командами, этот вопрос выявляет, удерживают ли планирование, квоты и приоритеты загрузку высокой или копившееся недоиспользуемое оборудование норма. Принесите реальные числа загрузки, вашу позицию по группировке и кэшированию и измерения хвостовой задержки, а не только средние, поскольку пользователи чувствуют медленный хвост. Обсудите, прогнозируются ли спрос на обучение и вывод отдельно, учитывая их разные формы, и хватило бы меньшей модели или вывода на CPU для лёгких случаев. Ответ должен указать на конкретную простаивающую мощность для возврата и конкретные запросы для группировки или направления к модели подходящего размера.

4. Когда выходит изменение промпта или модели, что мешает молчаливой регрессии качества или стоимости достичь пользователей? Стек обслуживания может выглядеть здоровым по задержке и времени безотказной работы, пока возвращаемые им ответы тихо ухудшаются или новый промпт удваивает расход токенов на запрос. Для большой команды, где многие группы независимо редактируют промпты и меняют модели, изменение без барьера инцидент в эксплуатации, ждущий своего часа, а радиус поражения растёт с каждой командой на общей платформе. Принесите ваше покрытие оценки: у каких промптов и моделей есть офлайн-наборы тестов, запускаются ли эти наборы автоматически на каждое изменение, какие пороги качества и стоимости управляют выпуском и как быстро вы можете откатить. Обсудите, живут ли промпты в системе контроля версий с рецензией или кто-то всё ещё может править живой системный промпт вручную. В корпоративной и государственной среде привязывайте каждое изменение к следу аудита и названному утверждающему, потому что регулятору, спрашивающему «кто это изменил и что вы тестировали», нужен ответ записанный, а не запомненный.

5. Как мы решаем между облаком, локальным и суверенным развёртыванием и оценили ли мы реальную установившуюся экономику, а не пилот? Выбор расположения вычислений задаёт вашу кривую цены, позицию по суверенитету данных и варианты выхода на годы, но он нередко делается по счёту облака пилота, не имеющему ничего общего с эксплуатацией в масштабе. Для большой организации эластичная облачная мощность дёшева в начале и может стать самой большой отдельной строкой, когда вывод работает непрерывно, тогда как локальное меняет малое обязательство на контроль и установившуюся экономику. Принесите прогнозные объёмы обучения и вывода, точку безубыточности, где зарезервированное или собственное оборудование побеждает по требованию, ваши ограничения местонахождения данных и безопасности и шаблоны всплесков, говорящие в пользу гибрида. В государственной и регулируемой среде взвесьте требования суверенного облака или локального развёртывания, которые могут стать обязательными без особого предупреждения, и подтвердите, что архитектура держит модели за внутренним интерфейсом, чтобы вынужденный переход не переписывал основные пути.

6. Владеем ли мы нашими расходами на ИИ на самом деле и может ли каждая команда видеть и отвечать за стоимость, которую она порождает? Цена ИИ масштабируется с использованием способами, удивляющими людей, а без отнесения счёт приходит одним непрозрачным числом, которое ни одна команда не чувствует ответственной уменьшать. В большой организации стоимость, которой никто не владеет, стоимость, которую никто не оптимизирует, поэтому вопрос в том, помечены ли расходы командами и случаями использования с бюджетами, оповещениями и трендами на результат или обнаруживаются, только когда финансы эскалируют. Принесите вашу модель отнесения затрат, крупнейшие драйверы по командам и рычаги, которыми управляет каждый владелец: подбор размера, кэширование, группировка и обрезка контекста. Для корпоративных и государственных бюджетов добавьте дисциплину прогнозирования и обоснования многолетних расходов на инфраструктуру, поскольку государственному органу, не способному объяснить свой счёт за вычисления построчно, будет трудно защищать его при рецензии.

Взгляд по секторам

Стартап. Не владейте никакой инфраструктурой, без которой можно обойтись. Вызывайте размещённый API вывода, направляйте простые запросы к малой дешёвой модели и оставляйте большую для трудных случаев и кэшируйте агрессивно, чтобы повторные промпты не стоили ничего. Используйте управляемую векторную базу данных вместо эксплуатации своей, держите промпты в git с коротким скриптом оценки перед каждым изменением и журналируйте стоимость на запрос, чтобы убежавший счёт проявился, пока не навредил. Ваш самый дефицитный ресурс инженерное внимание, поэтому покупайте эксплуатируемость и держите переключение дешёвым.

Малый бизнес. Без платформенной команды воспринимайте обслуживание, поиск и наблюдаемость как то, что вы покупаете внутри уже используемых инструментов, а не системы, которыми вы комплектуете. Отдавайте предпочтение управляемому выводу и управляемому векторному поиску с прозрачной предсказуемой ценой и задайте жёсткий потолок расходов и оповещение о счёте с первого дня. Формулируйте решение как «купить или построить» честно: эксплуатация GPU или векторного индекса редко окупается на вашем объёме, а малая модель за размещённым API обычно удовлетворяет потребность за долю усилий.

Крупная организация. Проблема общая платформа «проторённой дороги» по многим командам: объединённые ускорители с планировщиками, квотами и приоритетами для повышения загрузки, стандартные группировка и кэширование, маршрутизаторы подбора размера и стоимость, отнесённая на каждую команду и случай использования. Управляйте изменениями промптов и моделей автоматическими наборами оценки, стандартизируйте слой интерфейса, чтобы провайдеры и цели развёртывания оставались заменяемыми, и управляйте ценой на результат как первоклассной метрикой, а не позволяйте каждой группе изобретать дорогую недоиспользуемую инфраструктуру заново.

Государственный сектор. Суверенитет данных, безопасность и предсказуемые расходы определяют каждый выбор. Отдавайте предпочтение локальному развёртыванию или развёртыванию в суверенном облаке, чтобы чувствительные данные и модели оставались внутри контролируемых границ, планируйте дефицитные GPU между отделами с квотами, которые можно обосновать в закупках, и прогнозируйте мощность, чтобы защищать многолетние расходы построчно. Версионируйте и оценивайте промпты и модели с записанным следом аудита, сохраняйте полную наблюдаемость стоимости и качества и держите модели за внутренним интерфейсом, чтобы вынужденный переход к новому провайдеру или суверенной платформе не оставил вас без опоры.

Примеры

Стартап. Небольшой стартап, ведущий функцию ИИ-письма, держал счёт в разумных пределах, не владея ни одним GPU. Он вызывал размещённый API вывода, направлял простые запросы к более дешёвой малой модели и сохранял большую для трудных случаев и кэшировал ответы на повторные промпты. Он хранил промпты в git с коротким скриптом оценки, запускаемым перед каждым изменением, использовал управляемую векторную базу данных для поиска, чтобы не эксплуатировать свою, и журналировал стоимость на запрос, чтобы основатели видели рост расходов, пока он не стал сюрпризом.

Крупная организация. Медиакомпания, ведущая высоконагруженную функцию на LLM, существенно сократила цену вывода. Она направляла простые запросы к малой модели и оставляла большую модель для трудных. Она кэшировала ответы на повторные запросы и включила кэширование префикса для общего системного промпта. Она вела GPU через общий планировщик, чтобы держать загрузку высокой, версионировала все промпты в git с автоматическим набором оценки, управляющим изменениями, и инструментировала стоимость на запрос, чтобы каждая продуктовая команда владела своими расходами.

Государственный сектор. Национальное ведомство со строгими правилами суверенитета данных развернуло свои системы ИИ локально, чтобы чувствительные данные и модели никогда не покидали его контролируемую среду. Оно планировало дефицитные GPU между отделами с квотами и приоритетами, прогнозировало мощность для обоснования многолетних закупок и построило платформу векторного поиска для поиска по официальным документам. Промпты и модели версионировались и оценивались перед выпуском. Полная наблюдаемость отслеживала стоимость и качество, а архитектура держала модели за внутренним интерфейсом, чтобы сохранить путь выхода и избежать привязки.

Бизнес-обоснование: мотивы, ROI и TCO

Мотивация дисциплинированной инфраструктуры ИИ проста. ИИ в масштабе дорог, а разрыв между оптимизированным и неоптимизированным развёртыванием нередко в несколько раз по расходам. ROI приходит от более высокой загрузки ускорителей, меньшей цены на запрос через группировку и кэширование, моделей подходящего размера и избегания избыточного выделения. Наблюдаемость и конвейеры оценки окупаются предотвращением дорогих инцидентов и обеспечением безопасной итерации.

TCO охватывает вычисления на ускорителях (самая большая строка для многих нагрузок), векторное хранилище, инфраструктуру обслуживания, сети и платформенный и эксплуатационный персонал. Взвесьте это против цены невложения: убежавшие счета за вывод, плохая задержка, подрывающая принятие, и неспособность масштабироваться. Для государства добавьте цену невыполнения требований суверенитета или безопасности. Обосновывайте перед руководством, показывая тренды цены на результат и платформу «проторённой дороги», позволяющую многим командам эффективно развёртывать ИИ, вместо того чтобы каждая строила дорогую недоиспользуемую инфраструктуру.

Антипаттерны и ловушки

• Простаивающие ускорители. Выделение дефицитных GPU командам, оставляющим их недоиспользованными.
• Нет группировки или кэширования. Обслуживание каждого запроса по отдельности и пересчёт общего контекста.
• Самая большая модель по умолчанию. Использование дорогой модели там, где справилась бы малая.
• Слепота к стоимости. Нет отнесения, бюджетов или видимости цены на запрос, пока не придёт счёт.
• Промпты без версий. Изменение промптов в эксплуатации без версионирования или барьера оценки.
• Пренебрежение хвостовой задержкой. Оптимизация средней задержки, пока пользователи страдают от медленных хвостов.
• Молчаливая привязка. Глубокое построение на стеке обслуживания одного провайдера без переносимости.

Модель зрелости

1. Начальный. Стихийное выделение GPU в ответ на того, кто просит громче, нет группировки или кэширования, нет видимости стоимости, пока не придёт счёт, промпты правятся вживую без версий, минимальный мониторинг.
2. Развитие. Некоторые команды принимают общее планирование, кэширование и версионируемые промпты, но практика непоследовательна по организации: одна группа группирует и оценивает, а другая всё ещё обслуживает каждый запрос по отдельности и меняет промпты вручную.
3. Стандартизация. Документированная платформа «проторённой дороги» принуждается по организации: общее планирование с квотами и приоритетами, стандартные группировка, кэширование и подбор размера, векторная инфраструктура для поиска, автоматические конвейеры оценки, управляющие каждым изменением промпта или модели, и отнесение стоимости на команды и случаи использования.
4. Управление. Платформа измеряется и контролируется относительно базовых значений: загрузка ускорителей, цена на полезный результат, хвостовая задержка, полнота поиска и регрессии качества на изменение отслеживаются с оповещениями и порогами, стоимостью владеет каждая команда, а «пускать или нет» по изменению решается по свидетельствам, а не интуиции.
5. Оркестрация. Инфраструктура непрерывно улучшается и адаптируется: маршрутизация, группировка и масштабирование сами настраиваются по живым сигналам стоимости и качества, мощность перебалансируется между командами и между облачными, локальными и суверенными целями по мере сдвигов спроса и ограничений, переносимость репетируется, а планирование инфраструктуры интегрировано с продуктом, безопасностью и закупками.

Идеи для обсуждения

• Как повышать загрузку ускорителей, не обделяя приоритетные нагрузки?
• Где правильный баланс группировки и кэширования для ваших требований к задержке?
• Когда локальное или суверенное развёртывание оправдывает свою цену по сравнению с облаком?
• Как относить и контролировать расходы на ИИ по многим командам?
• Что должно управлять допуском изменения промпта или модели в эксплуатацию?
• Как держать инфраструктуру обслуживания достаточно переносимой для смены провайдеров?

Главные выводы

• Ускорители дефицитны и дороги; планируйте, делите и загружайте их намеренно.
• Группировка, кэширование и подбор размера моделей основные рычаги цены и задержки.
• Приложениям с поиском нужна хорошо эксплуатируемая инфраструктура эмбеддингов и векторного поиска.
• LLMOps (версионирование промптов, конвейеры оценки и наблюдаемость) эксплуатационный хребет генеративного ИИ.
• Управляйте стоимостью наблюдаемо и сохраняйте переносимость, чтобы избежать привязки.

Источники и дополнительное чтение

• Chip Huyen, Designing Machine Learning Systems.
• Google, Site Reliability Engineering (Beyer, Jones, Petoff, Murphy, editors).
• Jared Kaplan et al., Scaling Laws for Neural Language Models.
• Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
• Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM).
• Andriy Burkov, Machine Learning Engineering.