Кейс китайского банка показывает, почему обучение, дообучение и онлайн-инференс стоит запускать из общего пула ускорителей, но по разным правилам управления.
China Merchants Bank сообщил, что объединил обучение, LoRA-дообучение и онлайн-инференс на общей Kubernetes-платформе. По данным CNCF и банка, средняя загрузка почти 10 000 ускорителей выросла с 35% до более 60%, а стоимость инференса на миллион токенов снизилась более чем на 60%. Это внутренние результаты без независимого аудита; практический урок — считать и управлять обучением, инференсом, готовностью моделей и использованием ускорителей раздельно.
Это не рецепт, который можно перенести в любую компанию «как есть». Но кейс полезен руководителям ИИ-платформ и CIO: он разделяет три разные причины потерь — простаивающие ускорители, неподходящий режим планирования и дублирование базовых моделей при дообучении. Для каждой из них CMB использует отдельный механизм и отдельную метрику.
Что произошло
По описанию CNCF, общая платформа объединяет Kubernetes, Kueue, KEDA, Prometheus, HAMi и Fluid. Она даёт обучению, дообучению и онлайн-инференсу общий пул вычислений, данных и наблюдаемости, но не заставляет все нагрузки работать в одном режиме.
Это важное различие. Длительная распределённая тренировка не должна занимать часть дефицитного кластера, пока ждёт остальные ресурсы. Инференс, наоборот, должен быстро реагировать на очередь запросов и не держать избыточные реплики между всплесками спроса. В CMB эти контуры разделены: Kueue управляет очередями, квотами и допуском задач обучения, а KEDA и Prometheus масштабируют инференс по текущим сигналам нагрузки.
Это важное различие. Длительная распределённая тренировка не должна занимать часть дефицитного кластера, пока ждёт остальные ресурсы. Инференс, наоборот, должен быстро реагировать на очередь запросов и не держать избыточные реплики между всплесками спроса. В CMB эти контуры разделены: Kueue управляет очередями, квотами и допуском задач обучения, а KEDA и Prometheus масштабируют инференс по текущим сигналам нагрузки.
Задача: убрать не один, а три вида потерь
При росте корпоративных ИИ-нагрузок банк столкнулся не просто с дефицитом карт. Публичная архитектура CMB описывает три конфликтующие ситуации:
Вместо создания независимых кластеров под каждый тип нагрузки команда построила общий контрольный слой. Он сохраняет раздельные политики выполнения, но объединяет планирование, распределение ускорителей, доступ к датасетам и весам моделей, а также мониторинг.
- Обучающие задания требуют зарезервированной и предсказуемой мощности.
- Инференс чувствителен к задержке и меняющемуся трафику.
- Небольшие задачи и несколько арендаторов LoRA могут не нуждаться в отдельной полной копии базовой модели или целой карте ускорителя.
Вместо создания независимых кластеров под каждый тип нагрузки команда построила общий контрольный слой. Он сохраняет раздельные политики выполнения, но объединяет планирование, распределение ускорителей, доступ к датасетам и весам моделей, а также мониторинг.
Как устроено решение
Общая инфраструктура, разные правила выполнения
Kueue решает, когда обучающая задача допускается в кластер и получает квоту. Это снижает риск частичного старта, когда задача уже удерживает ресурсы, но не может начать работу из-за нехватки остальных воркеров или карт.
Для онлайн-инференса Prometheus собирает сервисные и нагрузочные показатели, а KEDA по ним добавляет или убирает реплики. Kubernetes и HAMi размещают поды и распределяют мощность ускорителей, а Fluid кэширует веса и данные ближе к вычислениям. Поэтому новая реплика не считается готовой только после запуска контейнера: она должна ещё получить модель.
Для онлайн-инференса Prometheus собирает сервисные и нагрузочные показатели, а KEDA по ним добавляет или убирает реплики. Kubernetes и HAMi размещают поды и распределяют мощность ускорителей, а Fluid кэширует веса и данные ближе к вычислениям. Поэтому новая реплика не считается готовой только после запуска контейнера: она должна ещё получить модель.
Совместное использование ускорителей и моделей — не одно и то же
HAMi выделяет ускорители дробно, чтобы небольшая задача не занимала целую карту. Отдельно от этого внутренний фреймворк CMB Twinkle позволяет нескольким арендаторам LoRA использовать один экземпляр базовой модели, сохраняя раздельные адаптеры, конфигурации и состояние.
Это практический нюанс для архитекторов. Деление GPU/NPU помогает загрузить «железо», но не устраняет расход памяти на повторные экземпляры модели. Совместное использование базового рантайма, наоборот, не заменяет контроль ресурсов. В кейсе оба механизма работают вместе.
Это практический нюанс для архитекторов. Деление GPU/NPU помогает загрузить «железо», но не устраняет расход памяти на повторные экземпляры модели. Совместное использование базового рантайма, наоборот, не заменяет контроль ресурсов. В кейсе оба механизма работают вместе.
Измеримые результаты — и что именно они означают
Почему это важно для бизнеса
Главный управленческий урок кейса — считать не «расходы на ИИ» вообще, а несколько связанных показателей:
Для малого и среднего бизнеса такая инфраструктура в масштабе CMB избыточна. Однако принцип переносим: сначала разделить типы ИИ-нагрузок и их метрики, затем проверить, где теряются деньги — в простаивании, дублировании моделей, медленном запуске или неудачных правилах очередей. В российских условиях доступность описанных сервисов, поддержка конкретных ускорителей, условия поставки, локализация данных и стоимость эксплуатации необходимо проверять отдельно: публичные источники CMB этого не раскрывают.
- загрузку ускорителей — чтобы видеть неиспользуемую мощность;
- стоимость на миллион токенов — чтобы сравнивать инференс при растущем объёме запросов;
- время ожидания обучения в очереди и долю частично зарезервированных ресурсов;
- задержку готовности реплики, включая загрузку весов;
- плотность дообучения и изоляцию арендаторов.
Для малого и среднего бизнеса такая инфраструктура в масштабе CMB избыточна. Однако принцип переносим: сначала разделить типы ИИ-нагрузок и их метрики, затем проверить, где теряются деньги — в простаивании, дублировании моделей, медленном запуске или неудачных правилах очередей. В российских условиях доступность описанных сервисов, поддержка конкретных ускорителей, условия поставки, локализация данных и стоимость эксплуатации необходимо проверять отдельно: публичные источники CMB этого не раскрывают.
Контраргумент: общая платформа усложняет управление
Общий пул не является бесплатной оптимизацией. Он требует зрелой политики квот, наблюдаемости, изоляции арендаторов, контроля доступа к данным и понятных SLO для моделей. Ошибка в общих правилах может затронуть и обучение, и работающий сервис. В CMB этот риск снижают именно раздельные политики выполнения, а не единый «универсальный» автоскейлер.
Перед подобным проектом стоит проверить четыре вопроса: действительно ли разные команды конкурируют за один и тот же парк ускорителей; есть ли надёжные базовые метрики; достаточно ли изолированы данные и модели; кто принимает решение, когда инференс и обучение спорят за ограниченную мощность. Без ответов экономический эффект из кейса нельзя переносить на свою организацию.
Перед подобным проектом стоит проверить четыре вопроса: действительно ли разные команды конкурируют за один и тот же парк ускорителей; есть ли надёжные базовые метрики; достаточно ли изолированы данные и модели; кто принимает решение, когда инференс и обучение спорят за ограниченную мощность. Без ответов экономический эффект из кейса нельзя переносить на свою организацию.
Почему это важно
CMB показывает, что эффективность ИИ-инфраструктуры складывается не из одной технологии и не из закупки новых карт. Практическая ценность появляется, когда единая платформа видит весь путь нагрузки — от очереди обучения и доступа к весам до токеновой стоимости работающего инференса — и применяет к каждому этапу подходящее правило.
«В этом кейсе ценен не сам Kubernetes, а управленческая дисциплина: обучение, дообучение и инференс измеряют разными метриками и не заставляют работать по одному правилу. Для бизнеса это превращает ИИ-инфраструктуру из статьи закупок в управляемую производственную систему.»
— Денис Баталин, Амбассадор Команды, Komanda.ai
Что дальше
CMB планирует динамически менять число арендаторов при дообучении, сочетать загрузку, состояние очереди, задержку и стоимость токенов в управлении мощностью, а также расширять поддержку гетерогенных ускорителей и движков. Это планы, а не достигнутые результаты. Для редакции стоит отслеживать публичную методологию измерений и независимую техническую оценку платформы, если она появится.
Источники:
1. CNCF: China Merchants Bank wins End User Case Study Contest — опубликовано 7 сентября 2026, 21:00 ET / 8 сентября 2026, 04:00 МСК. Первичный релиз CNCF, распространённый PR Newswire.
2. CNCF GitHub: reference architecture CMB — опубликована как открытая архитектура 28 июля 2026; техническое описание и результаты внутреннего сравнения, использовано только как фоновое подтверждение деталей архитектуры.
3. Linux Foundation APAC: программа KubeCon China — опубликовано 7 сентября 2026; независимое от пресс-релиза подтверждение участия CMB в программе конференции и описания производственного внедрения цифровых сотрудников. Не подтверждает заявленные показатели стоимости.
1. CNCF: China Merchants Bank wins End User Case Study Contest — опубликовано 7 сентября 2026, 21:00 ET / 8 сентября 2026, 04:00 МСК. Первичный релиз CNCF, распространённый PR Newswire.
2. CNCF GitHub: reference architecture CMB — опубликована как открытая архитектура 28 июля 2026; техническое описание и результаты внутреннего сравнения, использовано только как фоновое подтверждение деталей архитектуры.
3. Linux Foundation APAC: программа KubeCon China — опубликовано 7 сентября 2026; независимое от пресс-релиза подтверждение участия CMB в программе конференции и описания производственного внедрения цифровых сотрудников. Не подтверждает заявленные показатели стоимости.
Вопросы и ответы
Что именно оптимизировал China Merchants Bank?
Банк описывает общую Kubernetes-платформу для обучения, LoRA-дообучения и онлайн-инференса: она объединяет инфраструктуру и наблюдаемость, но использует разные политики для разных нагрузок.
Подтверждена ли экономия более 60% независимым аудитом?
Нет. Показатель опубликован CNCF со ссылкой на внутреннее сравнение CMB при сопоставимых модели и сервисных условиях. Открытых сырых данных и внешнего аудита нет.
Можно ли перенести архитектуру CMB в российскую компанию?
Полезен сам подход к метрикам и разделению политик. Совместимость с конкретными ускорителями, доступность компонентов, обработку данных, стоимость и поддержку нужно отдельно проверять для своей инфраструктуры.