38-минутный доклад Joseph Stein на QCon San Francisco оказался не про очередной «AI-платформенный» слоган, а про довольно приземленную задачу: как заставить нагрузки GPU в частном облаке работать без простоев, конфликтов и вечного ручного приоритизирования. Для русскоязычных команд, которые строят внутренние AI-сервисы и не готовы бесконечно покупать новые ускорители, это почти универсальный сюжет: денег на GPU всегда меньше, чем желающих ими воспользоваться.
Как пишет InfoQ, Stein рассказал, как в SS&C Technologies строили AI-as-a-Service внутри собственных дата-центров компании. Речь идет не о стартапе с одной моделью и парой стендов, а о гибридной облачной среде, где у компании есть частное облако, API, Terraform-провайдер, Kubernetes-кластеры и потоковые интеграции через Kafka. На таком фоне AI-сервис перестает быть игрушкой для одной команды и превращается в инфраструктурный слой, который должен одновременно выдерживать real-time-нагрузку, batch-задачи, требования безопасности и корпоративный комплаенс.
Не новые GPU, а нормальная оркестрация
Главная мысль доклада звучит почти обидно просто: проблема часто не в том, что GPU мало, а в том, что они плохо распределены. Stein описал ситуацию, знакомую многим крупным компаниям: разные команды резервируют ускорители под свои нужды, но используют их неравномерно. В итоге где-то образуется дефицит, а где-то дорогой ресурс простаивает. Чтобы выжать из этой схемы больше, команда пошла в сторону multi-namespace scheduling, то есть механизма, который позволяет перераспределять нагрузки GPU между разными пространствами и типами задач, не ломая изоляцию и управляемость.
Подход особенно интересен тем, что он рассчитан не только на интерактивные сценарии, где пользователь ждет ответ модели здесь и сейчас, но и на пакетную обработку. В реальной корпоративной среде эти два мира неизбежно сталкиваются: одни команды хотят inference с минимальной задержкой, другие запускают тяжелые batch-пайплайны для индексации, классификации, обогащения данных или подготовки RAG-контекста. Если развести эти режимы на уровне политики и очередей, а не просто надеяться на дисциплину пользователей, нагрузки GPU начинают использоваться заметно рациональнее.
Отдельно Stein остановился на том, как они организовали приоритеты и обратное давление в очередях. Вместо попытки собрать все на тяжеловесном оркестраторе команда использовала Valkey и Lua. Связка понадобилась для атомарной работы с приоритетными очередями: когда в системе одновременно живут real-time- и batch-задачи, нельзя допускать состояния, в котором одна категория тихо съедает все слоты, а другая превращается в бесконечный хвост. Lua-скрипты в этом случае дают предсказуемую атомарность на уровне операций очереди, а сама очередь становится не просто буфером, а инструментом контроля нагрузки.
Для разработчиков здесь важен не сам выбор Valkey вместо чего-то более модного, а архитектурный принцип. Когда GPU-пул общий, любая ошибка в диспетчеризации быстро превращается в дорогостоящий хаос: latency у real-time-сервисов улетает, batch-процессы не укладываются в окна, а команды начинают вручную выбивать себе приоритет. Stein фактически предлагает антидот против такой деградации: приоритеты должны быть централизованы, атомарны и понятны платформенной команде, а backpressure надо проектировать заранее, а не после первого инцидента.
Безопасность LLM как обязанность платформы
Вторая сильная часть выступления связана не с производительностью, а с безопасностью. Stein прямо говорит: если компания дает разработчикам доступ к генеративному ИИ, она не может рассчитывать, что каждая продуктовая команда самостоятельно разберется с рисками уровня OWASP Top 10 for LLM Applications. Поэтому защиту вынесли в центральные proxy-gateway. Это важный сдвиг в мышлении: безопасность LLM здесь рассматривается не как набор рекомендаций в wiki, а как обязанность платформенного слоя.
Логика понятна. Если пропускать обращения к моделям через единый прокси, можно централизованно навесить политики, аудит, ограничения на типы запросов и защиту от части типовых атак, включая злоупотребление ресурсами и опасные сценарии использования. Для компании из финансового сектора это не теоретическая аккуратность, а вопрос допустимости самого сервиса. Stein напомнил, что при проектировании им пришлось учитывать регуляторные ограничения: например, нельзя просто разрешить системе давать финансовые советы, если на это накладываются отраслевые правила. Он также описал, что еще на раннем этапе команда собирала требования по governance и compliance, причем в момент, когда нормативный ландшафт вокруг генеративного ИИ еще только формировался.
Здесь у доклада есть полезный, хотя и не самый приятный вывод для рынка. Внутренний AI-as-a-Service в крупной компании не взлетает усилиями одной сильной ML-команды. Stein перечисляет весьма прозаические зависимости: нужно выбить бюджет на сами GPU, получить людей в постоянное партнерство, договориться с командой частного облака, провести железо через стандартный контур дата-центра, доставить его до Kubernetes и встроить в существующие операционные процессы. Иными словами, bottleneck находится не только в модели или драйверах NVIDIA, но и в том, готова ли компания относиться к ИИ как к инфраструктуре, а не как к витрине для презентаций.
Наконец, для масштабирования batch-нагрузки команда использовала собственный прокси между S3 и Kafka. Это, пожалуй, самый показательный инженерный штрих во всем рассказе. В корпоративной среде данные редко лежат там и в том виде, как удобно платформенной команде. Поэтому вместо надежды на «родную» совместимость сервисов SS&C построила прослойку, которая помогает масштабировать пакетные пайплайны и связывать объектное хранилище с событийной шиной. Для команд, работающих с ingestion, это хороший сигнал: узкие места AI-платформы часто находятся вовсе не в инференсе, а на стыке хранения, транспорта и управления скоростью потребления.
Для российской и вообще русскоязычной IT-аудитории в этой истории важнее всего одно: зрелая платформа для AI внутри компании начинается не с выбора очередной модели, а с дисциплины вокруг ресурса. Нагрузки GPU, централизованные очереди, прокси для безопасности, понятный backpressure и отдельный контур для batch-задач звучат менее эффектно, чем демо с чат-ботом, зато именно это отличает сервис, который можно показать на конференции, от сервиса, который реально живет в проде. Следующий большой вопрос для корпоративного рынка звучит уже не «нужен ли нам AI-as-a-Service», а «кто в компании готов взять на себя скучную, дорогую и неизбежную работу по превращению GPU в нормальный внутренний продукт».