Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито.
В конце июля мы с коллегами съездили в Иокогаму на KubeCon + CloudNativeCon Japan 2026. Ко второму дню я заметил, что слайды выступающих повторяются: спектр изоляции тенантов, квоты, bin packing, «GPU дорогие — давайте делить». Мы решаем в Авито ту же задачу, поэтому я разберу шесть докладов про GPU и LLM-инференс и расскажу, что из этого мы уже пробовали или собираемся попробовать. А в конце будет немного про саму Японию.
Содержание
Инференс обогнал обучение
Конференция шла в Pacifico Yokohama три дня. 28 июля были co-located-ивенты: ArgoCon, Community Day и другие. Основная программа заняла 29 и 30 июля. Каждое утро начиналось с keynote в главном зале, потом до вечера шли параллельные доклады и выставка спонсоров.
Каждый keynote состоял из пары больших выступлений от CNCF и десятка коротких, по 3–5 минут, в которых компании анонсировали собственные доклады. На открытии исполнительный директор CNCF Jonathan Bryce и CTO Chris Aniszczyk показали, как изменился AI-compute за два года, и рассказали о новостях проектов.
Сейчас две трети AI-compute уходит на инференс и треть — на обучение. Два года назад было наоборот.
К 2030 году инференсу понадобится больше 93 ГВт — это прогноз McKinsey. По словам Bryce, это больше, чем сегодня потребляют все вычисления в мире.
Kubeflow стал graduated-проектом, а HAMi перешёл в incubating. Нашей ML-платформе на Kubeflow приятно :)
llm-d Bryce привёл как пример того, как cloud native подстраивается под AI. Проекту чуть больше года. Он масштабирует vLLM горизонтально и за счёт кэширования и роутинга запросов выдаёт заметно больше, чем обычная балансировка по GPU.
NVIDIA стала Platinum member CNCF и показала AI Cluster Runtime (AICR) — версионированные рецепты GPU-кластера (драйвер, операторы, ядро, runtime). Они упакованы в бандлы для Helm, Argo CD или Flux.
CNCF запустила Kubernetes AI Conformance — сертификацию AI-платформ по образцу обычного conformance. Идея в том, что AI-нагрузка запустится на любой сертифицированной платформе без доработок.
Через все keynote проходили две темы: как масштабировать инференс и как делать это безопасно. Чуть реже говорили о распределённом инференсе и мультикластерности. Шесть докладов ниже — как раз об этом на практике.
Шесть главных, по моему мнению, докладов
За два дня я посетил десяток докладов, а потом с карандашом пересмотрел шесть. Первая тройка — как делить GPU между командами, вторая — LLM-инференс, DRA и платформу целиком.
1️⃣ Kueue TAS и переезд Meta
Michał Woźniak из Google, мейнтейнер Kueue, и Wei Huang из Meta рассказали, зачем Meta понадобился многоуровневый TAS в Kueue.
Проблема. Обычный Kueue смотрит только на квоты. Допустим, свободно 4 GPU, а джоба просит 4 GPU на одной ноде. Квота есть, и Kueue её пускает. Но свободные карты лежат на двух разных нодах, поэтому поды висят в Pending.
Topology-Aware Scheduling, или TAS, решает это так: администратор описывает CR Topology с уровнями из лейблов нод, например block → rack → hostname, а джоба аннотацией просит положить все её поды в один домен.
Кейс Meta. Meta Superintelligence Lab переезжает на Kubernetes в облаке, на GB200 и GB300. Kueue выбрали потому, что квоты, gang scheduling и TAS собраны в нём в одном слое, а ещё потому, что он работает поверх kube-scheduler и не требует его менять. Свой шедулер Meta писать не стала и взяла open source.
На GB300 одного уровня топологии уже мало. Стойка GB300 NVL72 — это 18 нод в одном NVLink-домене. Когда джоба не влезает в один data hall, однослойный TAS делит её как придётся, например 7 + 1, и одна стойка на отшибе тормозит весь all-reduce. Поэтому в Kueue v0.17 появился multi-layer TAS, пока в статусе alpha. В нём ограничения задаются списком уровней от крупного к мелкому.
Вот пример со слайда для 64 подов, по 32 на data hall и по 16 на стойку:
metadata: annotations: kueue.x-k8s.io/podset-required-topology: datacenter kueue.x-k8s.io/podset-slice-required-topology-constraints: | [ {"topology": "topology.k8s.io/datahall", "size": 32}, {"topology": "topology.k8s.io/rack", "size": 16} ]
Докладчики предупредили о двух граблях. Во-первых, taints учитываются, только если нижний уровень топологии — kubernetes.io/hostname. Во-вторых, поды, запущенные не через Kueue, вычитаются из ёмкости домена (#9992).
Как у нас. Kueue — основной шедулер AI-нагрузок на нашей ML-платформе. Очереди построены на иерархических когортах, подробно я писал в канале. У каждой команды две ClusterQueue. Regular живёт тем, что занимает чужие простаивающие GPU. Prod держит гарантию и через reclaimWithinCohort: Any забирает своё. Приоритеты внутри одной очереди мы тоже рассматривали, но они ломают изоляцию: критичную задачу уже нельзя гарантированно запустить. TAS у нас включён, HGX H100 пакуются по InfiniBand scalable unit.
→ Видео · Kueue · Документация по Topology
2️⃣ Шеринг GPU в SNOW и наш замер HAMi
Reza Jelveh из команды HAMi в Dynamia и Jeonghyun Kim из SNOW, дочки NAVER, рассказали, как SNOW делит GPU через HAMi и скейлит инференс через KEDA. У нас с HAMi своя история, так что было с чем сравнить.
Проблема. SNOW крутит генеративные фильтры на 1000+ A100, а трафик скачет вслед за трендами в соцсетях. Переезд из Docker в Kubernetes чуть не сорвался. Fine-tune на фото пользователя и инференс — это два контейнера в одном поде, а в Kubernetes «GPU is atomic», то есть карту нельзя отдать двум контейнерам сразу. HAMi снял проблему без правок кода. Его библиотека HAMi-core перехватывает вызовы CUDA и делит карту программно, тогда как MIG делит её аппаратно.
Автоскейлинг. DCGM utilization на разнородных нагрузках врёт, а длина очереди растёт слишком поздно: модель прогревается около 60 секунд. Поэтому SNOW скейлится через KEDA по доле занятых воркеров с порогом unacked / consumers > 0.7. Утилизацию GPU я считаю метрикой для отчётов, а инференс скейлил бы по насыщению сервиса. Об этом я писал в статьях про утилизацию GPU и про автоскейлинг инференса.
В итоге SNOW понадобилось в 2 раза меньше GPU, а восстановление сократилось примерно с 2 часов до 10 минут. Правда, сравнивали с ручным Docker.
Как у нас. Про оверхед в докладе сказали «under 4%», но это оверхед в рантайме, от перехвата CUDA. Про control plane не прозвучало ни слова, а мы его как раз мерили, когда сравнивали HAMi, gpu-operator и instaslice. HAMi прожил около суток на большом продовом кластере в несколько сотен нод:
Что мерили | Изменение с HAMi |
CPU kube-apiserver | ×3–4 |
p99 read-запросов к apiserver | ×10 |
Клиентский трафик etcd | ×20 |
Откуда такой рост? HAMi по умолчанию ставит собственный экземпляр kube-scheduler. На маленьких кластерах это незаметно, а на сотнях нод вылезает сразу. Лечится это подключением HAMi как extender к основному kube-scheduler (issue #359). После этого заметных отклонений мы уже не видели.
Всплыло и другое. Dynamic MIG оказался динамическим только наполовину. Геометрию нарезки задаёт первый под, который пришёл на ноду, а поменять её можно только на пустой ноде. Для real-time инференса это не подходит. В итоге мы выбрали gpu-operator со статической нарезкой MIG: он набрал 41 балл из 60, а HAMi 32. HAMi мне симпатичен, но на наших масштабах готовность к продакшену он пока не показал.
→ Видео · HAMi · Лаба HAMi без GPU на nvml-mock · KEDA
3️⃣ Как SoftBank делит один кластер между тремя видами тенантов
Yuto Hiraki из SoftBank и Yusuke Tanaka из CTC рассказали, как SoftBank делит один кластер между тенантами. С этого доклада мы унесли больше всего заметок.
Проблема. У SoftBank больше 10 000 GPU и очень разные пользователи. Если дать команде namespace, GPU будут общими, но свой оператор она не поставит. Если дать ей отдельный кластер, изоляция будет полной, но человек, которому нужны 1–2 карты, получит сервер на восемь. SoftBank сделал один хост-кластер с тремя моделями тенантности.
vCluster на private nodes — выделенные GPU-серверы, свои драйверы, доступ к ОС.
vCluster на shared nodes — свои операторы и CRD, но GPU общие.
Shared LLM Service — OpenAI-совместимый эндпоинт за общим AI Gateway.
vCluster — это лёгкий control plane со своим API server, хранилищем и CoreDNS. Он работает как набор подов в namespace хост-кластера. На хост спускаются только Pod, Service, ConfigMap и Secret, а Deployment'ы и CRD живут в виртуальном API.
Отдельный слайд был про bin packing. Дефолтный шедулер раскладывает две реплики по 4 GPU на два разных 8-GPU сервера, и под на 6 GPU уже никуда не влезает. Лечится это одной настройкой общего шедулера:
kind: KubeSchedulerConfiguration profiles: - pluginConfig: - args: scoringStrategy: type: MostAllocated # пакуем, а не размазываем resources: - name: nvidia.com/gpu weight: 10
Serverless-часть ближе всего к нашему стеку. В её основе KServe LLMInferenceService на llm-d. Перед ним стоят Envoy AI Gateway и Endpoint Picker (EPP) из Gateway API Inference Extension. EPP выбирает под по длине очереди и состоянию KV cache. Мультитенантность живёт на гейтвее: у каждого тенанта свой API-ключ, rate limiting и токен-метрики с лейблом tenant_id. Стоимость считают в токенах, потому что RPS для LLM её не отражает.
Ещё SoftBank изолирует prefix cache через cache_salt. Без этого тенант B может по TTFT понять, что такой префикс уже кто-то отправлял. vLLM подмешивает соль в хэш, и кэш переиспользуется только внутри «своих».
Замеры сделаны с включённой солью. С prefix-aware роутингом KV cache hit составил 63–66%, а TTFT P95 — 270–478 мс. С load-aware и random роутингом hit упал до 8–17%, а TTFT вырос до 2–7 секунд. Без KV-aware роутинга соль по тенантам почти убивает кэш.
Если у вас вместо Envoy AI Gateway стоит Istio, EPP работает и за ним: он есть в списке реализаций Inference Extension. Но ключи по тенантам и учёт токенов придётся собирать самим.
Как у нас. Мне ближе один кластер с изоляцией внутри: GPU дорогие, и разводить их по кластерам тяжело. У нас на Kubeflow тенант — это namespace-профиль. Но некоторым пользователям нужен полный доступ к своим нодам, и для них стоит присмотреться к vCluster на private nodes. А токен-метрики по тенантам пора заводить и нам.
При этом обучение и инференс мы всё-таки развели по отдельным кластерам — ради отказоустойчивости и гранулярности нод (инференсу нужно 3 ДЦ). Теперь думаю, как запускать ворклоуды ночью, когда GPU простаивают, и, возможно, vCluster тоже в этом поможет.
→ Видео · vCluster · KServe LLMInferenceService · Gateway API Inference Extension · cache_salt в vLLM
4️⃣ llm-d и KAITO как стандарт LLM-инференса
Kay Yan из DaoCloud, мейнтейнер llm-d, и Linbo He из Microsoft, мейнтейнер KAITO, рассказали, как устроен продовый LLM-инференс на этих двух проектах. Их доклад я дополнил прод-замерами LY Corporation из доклада How To Evolve Your LLM Self-Hosting Platform.
Главный тезис — «Running a model is easy. Operating an inference system is hard». Поднять vLLM одной командой умеет каждый, а дальше начинается смесь нагрузок: короткий Q&A, long context, RAG, агенты. Статичный конфиг под всё сразу не подстроится.
llm-d — фреймворк распределённого инференса поверх vLLM и Gateway API Inference Extension. В нём четыре проверенных рецепта: prefix-aware роутинг, иерархический KV cache на HBM, RAM и SSD, wide expert parallelism для MoE и P/D-дезагрегация, при которой prefill и decode идут на разных подах. KAITO отвечает за жизненный цикл модели: пользователь указывает модель и GPU SKU, а оператор сам считает число GPU и нод. Роли докладчики разделили одной фразой: «llm-d manages the traffic, KAITO manages the models».
Теперь прод. У LY Corporation 650 млрд токенов в месяц, 10 моделей и 30 тенантов. Вот что дали техники:
Техника | Результат у LY | Вердикт |
|---|---|---|
Квантизация FP8 | лучше и throughput, и latency, сложность нулевая | ADOPT |
Speculative decoding | выигрыш на реальных диалогах | ADOPT |
KV-aware routing (llm-d) | multi-turn TTFT с >1200 мс до ~200 мс | ADOPT |
P/D-дезагрегация | от FAIL до Improved в зависимости от соотношения P:D | ASSESS |
KV-aware routing почти даром даёт кратный выигрыш в агентских multi-turn сценариях. P/D в LY назвали «not a simple, plug-and-play optimization». Соотношение prefill и decode во входящем трафике вы не контролируете, поэтому P/D стоит включать только вместе с SLO-aware автоскейлингом.
Как у нас. llm-d упоминали в keynote CNCF, и в трёх докладах из моего топа он стоял под капотом. Мы используем KServe, а LLMInferenceService в нём построен на llm-d, так что KV-aware routing и P/D не требуют отдельной платформы. Порядок внедрения я записал такой: квантизация → speculative decoding → KV-aware routing → и только потом P/D.
→ Видео llm-d + KAITO · Видео LY · llm-d · KAITO
5️⃣ DRA в проектах NTT, SK Telecom и Fujitsu
Два доклада, NTT × SKT и CoHDI, сходятся в одном. На Dynamic Resource Allocation, или DRA, уже строят новые проекты.
DRA приходит в Kubernetes на смену device plugin. Через него запрашивают GPU, NIC, FPGA и другие устройства. Устройство перестаёт быть счётчиком nvidia.com/gpu: 4 и становится объектом с атрибутами, а kube-scheduler выбирает ноду и устройства одновременно.
NTT × SKT, «Beyond the DC Walls». NTT упёрлась в электричество и землю. GPU раскидали по 8 ДЦ от Саппоро до Фукуоки, это больше 2000 км, и склеили в один кластер поверх оптической сети IOWN APN. Японцы решили нехватку земли так же, как мы решаем нехватку GPU: размазали и назвали одним кластером :) Тенантам GPU выдаются как KubeVirt VM. Раньше нового тенанта заводили 5 рабочих дней, теперь хватает нескольких минут.
Во второй половине доклада SKT рассказала про топологию PCIe. GPU и сетевая карта должны висеть на одном PCIe-свитче, иначе GPUDirect RDMA идёт через CPU. Device plugin гарантировать это не может. Поэтому сейчас в Petasus AI Cloud от SKT ставят Jammer Pod — поды-глушилки, которые занимают все устройства ноды, а потом отпускают только нужную пару.
С DRA глушилки не нужны. Оба драйвера, GPU и SR-IOV, публикуют атрибут pcieRoot. Claim просит пары GPU + VF с ограничением matchAttribute на общий PCIe root. Шедулер берёт ноду, только если на ней можно собрать все пары.
Прод у Petasus пока работает на device plugin: поддержка DRA в KubeVirt ещё не вышла из alpha и beta.
CoHDI читается как «Коди». Это свежий проект в CNCF Sandbox от Fujitsu. Обычно GPU намертво привязан к ноде, и если нужна одна карта из восьми, семь простаивают. CoHDI подключает GPU, NVMe и CXL-память к нодам на горячую через PCIe/CXL-фабрику. Работает он поверх DRA: драйвер публикует плейсхолдеры свободных устройств из общего пула, и когда pending-под с ними сматчился, оператор просит фабрику подцепить карту.
Ограничений пока три: нужна настоящая PCIe/CXL-фабрика, оператор находится в стадии Proof of Concept, а у карт за свитчем нет NVLink.
Как у нас. Когда устройство становится объектом с атрибутами, поверх него можно строить то, что с device plugin было невозможно: топологию GPU + NIC, composable-железо, общие пулы. Два независимых доклада упёрлись в один и тот же pcieRoot, значит, стандарт работает. Мы переходим на DRA в Q4–Q1. Пока ноды под обучение мы отдаём целиком, а DRA даёт язык, чтобы описать варианты поинтереснее.
→ Видео NTT × SKT · Keynote NTT · Видео CoHDI · Keynote Fujitsu · CoHDI · NVIDIA DRA driver
6️⃣ Мультитенантная платформа PFN
Aya Igarashi из Preferred Networks выступала с keynote. Доклад шёл всего 10 минут, но в нём сошлось всё, что я видел на KubeCon за два дня.
PFN отдаёт мощности исследователям через платформу на Kubernetes и объясняет мультитенантность деньгами: «we cannot let them sit idle, so we share them». Но чем больше делишь, тем слабее изоляция.
PFN выбрала гибрид — namespace плюс выделенные ноды. Дальше ей пришлось решить три задачи:
Границы. Тенанты иерархичны, а namespace'ы плоские, поэтому иерархию строят на своём форке HNC. Граница складывается из нескольких слоёв: NetworkPolicy, admission-политики, ограничение scope контроллеров.
Справедливость. Квоты задаются в Kueue и HierarchicalResourceQuota. Ещё есть лимит на число объектов, чтобы один тенант не перегрузил control plane.
Эффективность. Против фрагментации работают gang scheduling и bin packing через тот же MostAllocated, что у SoftBank.
Без лимитов тенант A забирает почти всё, B и C голодают
Как у нас. Главный тренд конференции для меня — связка мультитенантности, упаковки ресурсов и мультикластера. PFN, SoftBank, NTT, SNOW и Meta решают одну задачу: как не держать дорогие GPU без дела и не дать тенантам мешать друг другу. По шкале PFN мы стоим слева: профили Kubeflow, общие ноды и иерархия гарантий в Kueue вместо HRQ.
Мультикластер — ветка того же тренда. LY Corporation, например, живёт с 1300+ кластерами. У нас кластеров два, и идею для ночных простоев GPU мы уже подсмотрели: гонять джобы ML-платформы на inference-кластере через MultiKueue.
→ Видео · HNC (архив)
Не всё влезло в подробный разбор. Держите табличку с кратким обзором остальных докладов:
Доклад | О чём | Мой комментарий |
Пять разнородных GPU-кластеров склеили в один через Liqo, а сверху поставили общую очередь Kueue | Ещё один голос за мультикластер | |
Свой KaaS у LY Corporation: 40 000+ нод на 15 инженеров. Рассказали, как ужимать кластеры, когда железо подорожало | Масштаб впечатляет, в остальном похоже на наш CAPI | |
SoftBank и Red Hat сделали add-on для Open Cluster Management. Он считает скор кластера по локальному Prometheus и отдаёт в hub одно число, а оптимизатор по нему переносит эндпоинты между кластерами | Тоже мультикластер, но управление сведено к одной метрике | |
Симулятор PFN проигрывает 160 дней трейса на 6212 GPU примерно за 25 секунд | Удобно сравнивать шедулеры на масштабе, а не на глаз | |
7 гейтов, которые деплой инференса проходит до прод-трафика. Для LLM Running ≠ Ready | Пригодится нашей inference-платформе | |
Замеры LY Corporation на проде: FP8, speculative decoding, KV-aware routing и P/D. Подробнее в разделе про llm-d | Бенчи llm-d на реальной нагрузке | |
Единый Python SDK, Trainer v2.2, OptimizationJob вместо Katib | Роадмап Kubeflow, в том числе Notebooks 2.0 | |
Кто, зачем и до какого времени держит GPU. Поверх DRA работают OIDC через Dex, admission-вебхуки с обязательным обоснованием и сроком аренды, SPIFFE/SPIRE и TTL-контроллер, который отбирает GPU | Прикольная подача с интерактивным запуском из консоли и хороший обзор RBAC. Но у нас это и так видно через профили Kubeflow и Grafana | |
Песочницы для агентов на agent-sandbox и Kata Containers | Мы тоже планируем такие в ML-платформе, на основе ноутбуков |
Впечатления о конференции
Русскоязычных на конференции было человек 10–20, а из России, кажется, приехали только мы, трое из Авито. Ребята, которые давно живут в Японии, сразу собрали русскоязычный чат, и дальше всё было как на хорошем админ-митапе: обсуждаешь кластеры и незаметно переходишь на жизнь.
Билет за свой счёт стоил около $250, то есть примерно 25 тысяч рублей. Примерно столько же стоит билет на наш PyCon.
Почти всё из докладов лежит в open source: послушал, открыл GitHub, потрогал руками. А вот живые демо падали почти у всех, и то и дело звучало «ой, давайте я переключусь на записанное видео». Европейцы и индийцы держались на сцене свободнее, а японские спикеры чаще читали с листа. Местные ребята объяснили это так. Типичная связка на японском рынке — интегратор, где инженеры по-настоящему разбираются в технологиях, и заказчик, который его нанимает. Спикеры от интеграторов отлично владели материалом и спокойно отвечали на вопросы, а с листа читали представители заказчиков: технология живёт у интегратора.
Запомнился Microsoft с мини-докладом про inference-платформу в Azure, где бэкенд можно выбрать самому из Dynamo, llm-d и vLLM. Шляпы Red Hat раздавали всем подряд. А на стенде Grafana стояла гача, автомат с капсулами. Подписываешься на рассылку по QR-коду, крутишь ручку и получаешь значки и стикеры. Маркетинг идеально попал в местную культуру.
Кормили бенто и фуршетом, а официальная afterparty оказалась скромной: одна бутылка пива в руки и мини-закуски. Всё интересное происходило на вечеринках партнёров. Мы попали к Cisco, которая купила Isovalent, авторов Cilium. Там был итальянский ресторан и конкурс, кто пройдёт больше лаб на labs.isovalent.com. Проходить лабы с iPad — то ещё удовольствие, зато всем подарили книгу What is eBPF? с автографом Liz Rice.
Чем KubeCon отличается от наших конференций:
KubeCon Japan | Российские конференции |
Доклады, сообщество, open source | Шоу, стенды, нетворкинг |
Почти всё можно потрогать на GitHub | Много «как мы у себя сделали» |
Одно пиво в руки, а веселье у партнёров | Масштабные вечеринки |
На KubeCon едут за open source, который можно забрать к себе, а наши конференции больше похожи на аттракцион. Хотя, говорят, американский KubeCon тоже с размахом.
И в целом про Японию
Жили мы в Иокогаме, и она неожиданно похожа на Питер: свой аналог ЗСД, колесо обозрения, только с дубайским вайбом. Все места, где я побывал, собрал в подборку на Google Картах.
Еда. Даже в самом неказистом 7-Eleven всё вкусно. Лучший рамен в моей жизни я съел в Ichiran, а вагю продаётся в обычном супермаркете. В дьюти-фри я впервые застрял у сладостей и не дошёл до лаунжа.
Инфраструктура. В аэропорту ездят кресла с автопилотом, а в лифте стоит аварийный унитаз. Конбини — отдельное место в сердечке: работают круглосуточно, и там есть всё, от покемонов до масок для лица. Не хватает только мусорок, а в час пик в метро толкотня.
Природа и погода. Берёшь поезд до Кавагутико у подножия Фудзи, там электровелосипед, и целый день катаешься вокруг озера. От жары спасают кондиционеры и охлаждающие спреи, но в любой момент может ливануть. А сама Фудзи два дня пряталась в облаках и так и не показалась целиком.
Короче
Инференс стал главным потребителем GPU. Две трети AI-compute уходит на инференс, и экосистема CNCF разворачивается к сервингу.
Все делят GPU, и слайды у всех одинаковые. Мультитенантность, квоты и плотная упаковка стали главным трендом конференции. Kueue, HAMi, vCluster и HNC — разные точки одной шкалы.
llm-d становится стандартом LLM-инференса. KV-aware routing почти даром даёт кратный выигрыш, а P/D без настройки легко делает только хуже.
DRA стал фундаментом для новых проектов. На нём уже строят топологию GPU + NIC и composable-железо, так что миграцию стоит закладывать уже сейчас.
На KubeCon едут за open source. Почти всё из докладов можно забрать к себе, а также поговорить с реальными мейнтейнерами проектов.
GPU мы делим в основном через MIG: статическая нарезка в gpu-operator, без программного шеринга. Мультитенантность держится на профилях Kubeflow, то есть на namespace'ах, а квоты и гарантии между командами раздаёт Kueue. Обучение и инференс живут в двух отдельных кластерах, ML-платформы и inference-платформы. Ночью трафик падает, и GPU на inference-кластере простаивают, поэтому сейчас думаем, стоит ли связать кластеры через MultiKueue и гонять на освободившихся картах ночные джобы ML-платформы. Если вы уже объединяли кластеры под такие задачи, расскажите в комментариях, как это у вас работает. И как вам Япония? :)
