Проектирование ML-платформы
Тема дорожной карты · MLOps
Внутренняя ML-платформа — это набор общей инфраструктуры, инструментов и абстракций, позволяющих дата-сайентистам и ML-инженерам строить, обучать и деплоить модели без управления сырыми облачными примитивами. Хорошее проектирование следует принципу «мощёной дороги»: мнения по умолчанию для типовых сценариев (шаблоны training job, стандартные serving-образы, CI/CD pipeline) с возможностью отступления для продвинутых пользователей. Основные слои: compute (Kubernetes с GPU), storage (feature store, artifact store, model registry), workflow (оркестратор), experimentation (experiment tracker) и serving (online/batch inference). Команды платформы уделяют приоритет developer experience, self-service онбордингу и видимости затрат.
Как это работает
Проектирование ML-платформы: построение shared инфры, позволяющей ML-командам self-serve. Куски platform-архитектуры: control plane (job submission, scheduling), training-инфра (GPU pools, distributed training), data plane (feature store, storage), serving plane (inference services, routing), tooling (notebooks, IDE integrations). Multi-tenancy: изоляция команд через Kubernetes namespaces, quotas, RBAC. Self-service: определите стандартные абстракции ("model deployment" = один YAML), пользователи не трогают Kubernetes/Spark/etc.
Когда применять
Платформу строите только когда 3+ команды используют overlapping ML-инфру — раньше каждая сама. Старт: paving cow paths — что пользователи делают чаще всего + вручную? Это автоматизируйте первым. Не стройте multi-tenant Kubeflow до 10+ пользователей — operational + maintenance цена реальна. Прочтите writeups ML-платформ Google + Meta + Netflix до проектирования своей.
Типичные ошибки
Ловушки Проектирование ML-платформы: платформа до спроса (platform team становится engineering blocker); слишком много абстракций (пользователи учат ваш custom DSL вместо переносимых навыков); не меряют успех платформы (build-and-pray); игнор "platform tax" — каждая абстракция имеет debugging-цену.