Yatai

想象一下：你刚用 PyTorch 训好了一个图像分类模型，想把它部署成在线 API 给前端调用，结果发现要写 Dockerfile、配 Kubernetes、写 YAML、做灰度发布——代码 5 分钟写完，部署搞了三天。Yatai 就是来解决这个痛点的，它是 BentoML 官方出品的 Kubernetes 原生存算一体部署平台，把 ML 模型部署门槛从「运维工程师专属」拉低到「有基本 Docker 经验的开发者也能玩转」的水准。

背景：BentoML 生态的最后一环

BentoML 是一个开源的模型服务框架，专注于把训练好的 ML 模型打包成标准化的「Bento」（便当盒），兼容 PyTorch、TensorFlow、XGBoost、scikit-learn 等主流框架。开发者在本地写好预测逻辑，bentoml build 一键打包，之后可以部署到 Docker、Kubernetes、SageMaker 等多种环境。

但原始的 BentoML 部署依赖手动写 YAML 配置、多步 kubectl 命令，缺乏集中管理界面——当团队有几十个模型服务同时运行时，纯命令行的管理方式就成了噩梦。BentoML 团队正是看到了这个需求，设计了 Yatai（屋台，意为街边的美食餐车），作为 BentoML 的 Kubernetes 部署层，提供 Web UI、GitOps 集成和自动扩缩容能力。

图1：BentoML 官方 logo

核心功能：Kubernetes 原生的 ML 部署平台

Bento 集中管理

Yatai 提供一个 Web Dashboard，支持浏览、搜索和管理团队推送的所有 Bento 包。模型开发者不需要登录服务器，在本地用 bentoml push 即可将模型上传到 Yatai 存储（MinIO/S3），由平台统一管理版本和元数据。

BentoDeployment CRD：声明式的部署

Yatai 通过 Kubernetes 自定义资源定义（CRD）来描述部署。开发者只需写一份 YAML，声明目标 Bento 镜像、副本数、资源限制和扩缩容策略，Yatai 控制器自动完成 Pod 创建、Service 暴露和 Ingress 配置。相比手动写 Deployment + Service + Ingress，效率提升显著。

自动镜像构建（yatai-image-builder）

Yatai 的镜像构建组件（BentoRequest CRD）可以接收一个 Git 仓库地址，自动触发镜像构建。用户不需要提前准备好 Docker 镜像，推送代码后平台自动处理构建流程，真正实现 GitOps 风格的 CI/CD 自动化。

多集群支持与灵活存储

Yatai 支持对接 PostgreSQL 作为元数据库、MinIO 或 AWS S3 作为模型 Artifact 存储，既可以在本地 Minikube 体验完整功能，也可以对接云厂商的托管 K8s 服务，在生产环境横向扩展。

技术架构：前后端分离的 Go+React 系统

Yatai 的代码库采用清晰的前后端分离架构。

后端（api-server/）： 使用 Go 语言开发，基于 Gin Web 框架，提供 RESTful API 供前端和 bentoml CLI 调用。依赖 Kubernetes Go Client 与集群交互，使用 GORM 操作 PostgreSQL，通过 MinIO Go SDK 管理对象存储。路由层将请求分发到 controllers/services 结构，模块职责清晰。

前端（dashboard/）： 基于 Create React App 构建（React 17），使用 Styletron（Uber 开源的 CSS-in-JS 引擎）作为样式方案，配合 Base Web（Uber 设计系统）提供统一 UI 组件。集成 Monaco Editor（代码编辑）、i18next（国际化）、React Router（路由）等主流前端库，UI 质量对标商业产品。

部署架构： API Server 通过 kubectl port-forward 或 Ingress 暴露，Dashboard 为纯静态 SPA（Build 后打包进 API Server 的 Docker 镜像），无需独立部署。Helm Chart 负责 K8s 资源编排，一个 helm install 即可拉起完整系统。

主要技术栈汇总：

| 层级 | 技术选型 |

|------|---------|

| 后端语言 | Go 1.19 |

| Web 框架 | Gin v1.8 |

| 数据库 | PostgreSQL + GORM |

| K8s 交互 | k8s.io/client-go |

| 对象存储 | MinIO Go SDK / AWS S3 |

| 前端框架 | React 17 + TypeScript |

| UI 组件库 | Base Web (Uber) |

| 样式方案 | Styletron |

| 构建工具 | Create React App |

| 部署方式 | Helm Chart + Docker |

部署体验：从零到跑起来要多久？

Yatai 提供了一键安装脚本，对 Minikube 体验场景非常友好——一行命令拉起 PostgreSQL、MinIO 和 Yatai 本身。但这里有一个关键的门槛：必须有 Kubernetes 集群。本地需要 Minikube（4核8G起步），云上则需要 EKS/AKS/GKE。安装完成后，还需要通过 kubectl port-forward 或 Ingress 暴露服务，第一次配置略为繁琐。

生产环境部署则更加复杂：需要单独准备 PostgreSQL（不能使用一键脚本内置的）、配置 MinIO 桶策略、设计 Ingress/TLS 终端、管理初始化 Token——这套流程对有 K8s 经验的 DevOps 工程师不难，但对 ML 研究者或数据科学家来说，仍然是一个不小的障碍。

图2：BentoML 官方团队

局限与争议：当前版本的现实约束

需要注意的是，Yatai 当前版本（基于 BentoML 1.2 之前）是「功能建设中」状态（README 明确标注 ⚠️）。BentoML 官方正在设计 Yatai 2.0 版本，对架构有较大的重新规划。现有版本适合尝鲜和生产评估，但若要用于关键业务，建议关注 Yatai 2.0 的进展。

此外，Yatai 不支持 docker-compose 一键启动——它本质上是为 Kubernetes 设计的，缺少轻量级的本地容器编排方案。同时，自动扩缩容依赖 K8s HPA，当前版本对 GPU 资源的弹性扩缩容支持有限。

行业意义：MLOps 部署层的成熟化标志

Yatai 代表了 MLOps 工具链的一个重要趋势：从「算法工程师自己部署」走向「平台统一托管」。类似 KubeFlow、Triton Inference Server、SageMaker 等商业方案，Yatai 通过 CRD 抽象将 ML 部署纳入 GitOps 工作流，降低了团队协作成本。

从增长角度看，BentoML 本身社区活跃（GitHub 16k+ stars），Yatai 作为其官方部署层受益于生态红利。随着 BentoML 2.0 的推进，Yatai 2.0 预计会有更成熟的架构设计。对于正在构建内部 ML 平台的团队，Yatai 的 CRD 设计理念和前后端分离架构都是值得参考的实现样本。