ИИ-платформа начинается не с GPU

Представим обычный старт. Команда собрала помощника для работы с документами, дала его нескольким коллегам и увидела правдоподобные ответы. Коллегам нравится демо. В следующем обсуждении появляются вопросы о собственной модели, локальном инференсе и GPU. Так разговор о пользовательской задаче незаметно превращается в разговор о железе.

Это опасная перестановка. Ускоритель исполняет вычисления, но не отвечает, какие документы разрешено читать, какой ответ допустим, кто принимает риск ошибки и что делать при деградации. Если эти решения не зафиксированы, более быстрый инференс лишь быстрее воспроизводит неопределённость.

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

Сценарий задаёт границу системы

Фраза «нам нужен корпоративный ассистент» слишком широка для архитектурного решения. Один ассистент находит фрагмент в публичной базе знаний. Другой предлагает изменить запись в рабочей системе. Третий вызывает инструмент, который записывает данные. Интерфейс похож, а цена ошибки, права и способ проверки различаются.

Первый рабочий артефакт здесь не список моделей. Это карточка сценария с коротким контрактом:

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

Такой контракт отсекает лишнее. Если сценарий допускает обработку у внешнего провайдера, не требует особой сетевой границы и имеет небольшой нерегулярный поток, MaaS может оказаться разумным первым execution path. Если данные нельзя выводить за выбранный контур, а нагрузка и команда оправдывают владение serving-стеком, появляется основание разбирать self-hosted. Между ними остаётся hybrid: разные маршруты для разных классов данных и задач.

Решение пока не принято, и это нормально. Зато инженеры уже сравнивают варианты по одному сценарию, а не спорят о GPU в вакууме.

Сначала данные и безопасность

LLM-запрос редко состоит только из фразы пользователя. В него попадают system-инструкции, история, найденные документы, tool schemas, результаты инструментов и служебные поля. Каждый блок имеет владельца, срок жизни и границу доступа. Архитектура обязана сохранить эти различия после сериализации, маршрутизации, логирования и повторного использования кэша.

Полезно пройти запрос как посылку через сортировочный центр. На каждом участке задайте четыре вопроса: что внутри, кто вправе открыть, где остаётся копия, как доказать соблюдение правила. Если ответ «разберёмся после пилота», пилот уже создаёт долг.

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

Локальное размещение модели само по себе не защищает систему: сервис может получить чрезмерные права, чувствительные данные — попасть в лог, а вредная инструкция из документа — дойти до исполнения. Внешний API, напротив, иногда укладывается в требования благодаря договорной, технической и организационной границе. Сравнивать надо полный поток данных и ответственности. NIST AI Risk Management FrameworkВнешняя ссылка, откроется в новой вкладке полезен как публичная рамка для фиксации риска, а не как готовая архитектура конкретной команды.

Качество должно пережить демо

Демо отвечает на вопрос «система иногда приносит пользу». Production требует другого: команда понимает допустимый диапазон поведения и замечает выход за него.

Начните с набора представительных задач. В нём нужны обычные запросы, трудные границы, запрещённые действия и случаи, где правильный ответ состоит в отказе или передаче человеку. Для каждого примера фиксируется критерий приёмки. Автоматический grader помогает масштабировать прогон, но не снимает обязанность проверить, что grader согласован с задачей.

Одна итоговая оценка скрывает поломки. Ассистент способен лучше выдерживать стиль и хуже извлекать обязательное поле. Среднее растёт, пользовательская операция ломается. Поэтому quality contract связывает метрики с типами ошибок: полнота извлечения, доля подтверждённых цитат, корректность выбора инструмента, соблюдение схемы, безопасный отказ. Набор зависит от сценария; универсальной панели качества нет.

Изменения тоже получают identity. Версия модели без версии prompt template, tool registry, retrieval settings и маршрута мало что объясняет. Release record должен позволять воспроизвести конфигурацию, сопоставить её с eval run и откатить целиком. Иначе расследование превращается в археологию по логам.

SLO описывает пользовательский результат

Инфраструктурная метрика ещё не обещание потребителю. Низкая загрузка GPU не гарантирует короткую очередь. Быстрый первый токен не спасает агентный шаг, который трижды вызывает инструмент. Успешный HTTP-ответ не означает принятого результата.

SLO стоит строить от операции. Для интерактивного ответа важны доступность, time to first token, полное время и доля результатов, прошедших проверку. Для фонового извлечения полей важнее deadline, полнота пакета и доля повторной обработки. Для агента добавляются лимит шагов, доля успешных вызовов инструментов, остановка и восстановление после частичного сбоя.

У каждого SLO есть окно измерения, источник данных и правила реакции на сбой. Если внешняя модель недоступна, система ждёт, переключает маршрут, снижает качество или возвращает честный отказ? Fallback без такого решения часто маскирует инцидент: запрос формально успешен, но цена, задержка или качество изменились.

Классическая практика SRE предлагает начинать с того, что важно пользователю, а затем выбирать индикаторы и бюджет ошибок. Публичная глава Implementing SLOsВнешняя ссылка, откроется в новой вкладке описывает этот ход мысли без привязки к LLM. Для AI-сценария к надёжности исполнения добавляется качество результата; смешивать их в одну цифру не стоит.

Ownership нельзя отдать платформе целиком

Слово «платформа» иногда используют как удобный контейнер для чужой ответственности. Продуктовая команда приносит неясный сценарий, служба безопасности ждёт идеальной фильтрации, SRE получает непрозрачный workload, а platform team должна «сделать AI надёжным». Получается очередь взаимных ожиданий.

Разделите решения явно. Владелец продукта отвечает за полезность сценария, критерии принятия и пользовательскую деградацию. Владелец данных определяет допустимые источники и использование. Security задаёт обязательные меры контроля и процесс оценки остаточного риска. Остаточный риск принимает назначенный владелец. Platform team держит общий контракт доступа к моделям, маршрутизацию, execution capabilities, наблюдаемость и release mechanics. SRE или operational owner отвечает за эксплуатационный контур там, где это закреплено.

Граница меняется от организации к организации. Важен не идеальный RACI, а отсутствие безымянного решения. У каждого риска и SLO должен быть назначенный владелец с полномочиями сказать «выпускаем», «откатываем» и «останавливаем».

Ownership проявляется и в бюджете. GPU оплачивает компания, но capacity не возникает из счёта. Кто прогнозирует спрос? Кто решает, какой workload важнее при дефиците? Кто принимает простой во имя резерва? Кто проверяет, что экономия на токенах не ухудшила принятый результат? Без ответов локальный инференс превращается во внутреннего провайдера без договора и правил обслуживания.

Теперь выбираем execution path

После сценария, данных, качества, SLO и ownership выбор модели становится содержательным. Появляется тестовый набор, ограничения контекста, требования к structured output и tools, классы задержки, география данных и политика деградации. Кандидатов сравнивают на своём контракте. Лидер общего бенчмарка способен проиграть более простой модели на узкой операции.

Дальше решается способ исполнения. MaaS снимает часть работы по serving, capacity и обновлениям, но оставляет интеграцию, качество, данные, лимиты и зависимость от внешнего контракта. Self-hosted даёт больше контроля над runtime и размещением, одновременно передавая команде scheduler, batching, KV memory, обновления, наблюдаемость, дежурство и capacity planning. Hybrid добавляет маршрутизацию и необходимость объяснить, почему запрос ушёл именно туда.

Только теперь разговор о GPU попадает на своё место. Ускоритель подбирают под проверенный workload: модель, точность, контекст, batch shape, prefill/decode профиль, concurrency и резерв. Одних спецификаций устройства без профиля запросов недостаточно для расчёта. Среднюю утилизацию тоже нужно сопоставлять с очередью и SLO. Потребность подтверждает нагрузочный прогон на целевой конфигурации, а не уверенный слайд.

Порядок не обязан быть строго водопадным. Команда способна параллельно проверять модель и уточнять data boundary. Но решения должны сходиться к одному контракту. Если эксперимент с моделью меняет качество или стоимость, это возвращается в сценарий. Если security запрещает маршрут, вариант исключается. Если SLO требует другой execution path, меняется архитектура.

Карта вместо списка покупок

Production AI удобнее рассматривать как систему областей ответственности. Strategy & Boundaries задаёт решение об инвестиции. Control Plane управляет доступом, registry и routing. Inference Plane исполняет workload. Context & Agent Runtime собирает контекст и действия. Quality & Lifecycle доказывает изменения. Operations & Economics связывает SLO, capacity и стоимость. Security & Ownership удерживает границы и владельцев.

Эти области пересекаются. Prefix cache, например, живёт в inference runtime, но зависит от формы агентного запроса, маршрута, tenant isolation и телеметрии. Именно поэтому локальная оптимизация редко остаётся локальной.

Начать можно с одного сценария и одной страницы решений. Не покупайте архитектуру целиком. Зафиксируйте контракт, найдите пробелы ответственности и выберите следующее проверочное действие. Для этого собрана карта AI Platform: она ведёт от вопроса «что мы строим» к компонентам и проверяемым данным, а не от логотипа модели к перечню серверов.