Команда Azure Kubernetes Service открыла исходный код TauGrid — платформы для запуска ИИ-нагрузок на Kubernetes. Обычно платформенным командам приходится собирать вручную систему очередей, распределённый рантайм, проверки здоровья GPU-узлов, дашборды и слой скриптов для отправки заданий. TauGrid сворачивает эту сборку в одну установку Helm.
Проект распространяется под лицензией MIT, образы контейнеров и Helm-чарты опубликованы как публичные OCI-артефакты в Microsoft Container Registry. Кодовая база написана преимущественно на Go.
Что входит в стек
TauGrid объединяет пять компонентов, которые платформенные команды обычно интегрируют по отдельности:
- CLI
tau; - очередь и допуск нагрузок через Kueue;
- оркестрацию кластеров Ray через KubeRay;
- мониторинг здоровья GPU на уровне узла;
- наблюдаемость кластера и нагрузок.
Ключевая идея — разделение ответственности. Платформенная команда владеет рабочими пространствами, очередями, профилями вычислений, хранилищем, идентификацией и наблюдаемостью. Исследователи работают из репозитория и через CLI, отправляя задания без прямой настройки Kubernetes.
Как задание проходит через платформу
Нагрузка описывается в файле tau.yaml. Опубликованный Microsoft пример обучения на GPU запускает задание PyTorch на одном A100:
schema_version: 1
name: aks-gpu-quickstart
run:
entrypoint: train.py
workload_kind: rayjob
compute:
gpus: 1
workers: 1
cpus: 16
memory: 64Gi
runtime:
image: mcr.microsoft.com/aks/ai-runtime/ray:py3.12-ray2.56.0-cuda13.0
pip:
- torch>=2.4.0
По команде tau run TauGrid применяет политику платформы, рендерит Kubernetes Job или KubeRay RayJob и отправляет его через Kueue. Microsoft документирует шесть стадий: отправка, постановка в очередь, выполнение, мониторинг, восстановление и доказательства. Восстановление охватывает повтор, возобновление с контрольной точки и диагностику сбоев. Записи доказательств фиксируют метаданные нагрузки, конфигурацию, логи, метрики, контрольные точки и историю выполнения — именно это делает запуск воспроизводимым и проверяемым задним числом.
Когда кластер делят несколько команд, их задания попадают в общую очередь Kueue ClusterQueue. Kueue допускает каждое из них по квоте и приоритету, а Kubernetes размещает его на здоровых GPU.
Установка и требования
Для развёртывания нужен кластер Kubernetes 1.30 или новее с GPU-узлами, а также kubectl и Helm 3.0+. Установка выполняется чартом прямо из MCR:
helm install taugrid \
oci://mcr.microsoft.com/aks/ai-runtime/helm/taugrid \
--version 0.4.2 \
--namespace tau-system \
--create-namespace
Собственные образы Microsoft поставляет по пути mcr.microsoft.com/aks/ai-runtime/ — для Tau, TauGrid Portal и основного контроллера tau. Вендор советует закреплять версионные теги или неизменяемые дайджесты вместо latest. CLI ставится из GitHub Releases на Linux и macOS, для Windows amd64 есть установщик PowerShell; установщик проверяет контрольную сумму релиза и не изменяет PATH.
Что важно при оценке вне Azure
Есть две операционные детали. Во-первых, по умолчанию TauGrid не отправляет телеметрию в Microsoft, а удалённый экспорт остаётся выключенным, пока оператор не настроит назначение. Во-вторых, часть интеграций пока привязана к Azure — прежде всего наблюдаемость через Azure Data Explorer. Заявленная цель — поддерживать облачный и локальный Kubernetes без зависимости от Azure, и вклад в этом направлении открыт.
Для российских команд, которые гоняют обучение и инференс на собственных GPU-кластерах, ценность здесь в первую очередь архитектурная: TauGrid показывает, как развести зоны ответственности между платформенной командой и исследователями и не заставлять последних разбираться в Kubernetes. Отсутствие телеметрии по умолчанию и открытая лицензия MIT снимают часть вопросов при развёртывании в закрытом контуре, но привязка наблюдаемости к Azure Data Explorer означает, что этот слой придётся заменять самостоятельно.
По теме: Microsoft уже открывала генератор юнит-тестов code-testing-generator, а Perplexity показывала свой стек эмбеддингов с CUDA-графами.
Частые вопросы
Что именно открыла Microsoft?
TauGrid — self-hosted платформу для запуска ИИ-нагрузок на Kubernetes под лицензией MIT. Она объединяет CLI tau, очереди Kueue, оркестрацию KubeRay, мониторинг здоровья GPU и наблюдаемость.
Какие требования к кластеру?
Kubernetes 1.30 или новее с GPU-узлами, установленные kubectl и Helm версии 3.0 или выше. Образы и чарты тянутся из Microsoft Container Registry как публичные OCI-артефакты.
Чем это отличается от ручной сборки стека?
Раньше команды собирали очереди, рантайм, проверки GPU и дашборды по отдельности. TauGrid ставится одной командой Helm и сразу связывает эти компоненты между собой.
Нужно ли исследователям знать Kubernetes?
Нет. Они описывают нагрузку в tau.yaml и запускают её командой tau run, а разрешение политик, рендеринг Job или RayJob и постановку в очередь платформа берёт на себя.
Как задания делят кластер между командами?
Задания попадают в общую очередь Kueue ClusterQueue. Kueue допускает их по квоте и приоритету, после чего Kubernetes размещает нагрузку на здоровых GPU.
Что такое записи доказательств?
Это фиксируемые данные о запуске: метаданные нагрузки, конфигурация, логи, метрики, контрольные точки и история выполнения. Они позволяют позже воспроизвести и проверить запуск.
Уходит ли телеметрия в Microsoft?
По умолчанию нет. Удалённый экспорт остаётся выключенным, пока оператор явно не настроит назначение.
Можно ли использовать TauGrid вне Azure?
Заявленная цель — поддержка облачного и локального Kubernetes без зависимости от Azure. Однако часть интеграций пока привязана к Azure, в частности наблюдаемость через Azure Data Explorer.
Какую версию чарта ставить?
В примере Microsoft указана версия 0.4.2. Вендор рекомендует закреплять версионные теги или неизменяемые дайджесты, а не использовать тег latest.
Источник: marktechpost.com