[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"tool-kubeflow--mpi-operator":3,"similar-kubeflow--mpi-operator":152},{"id":4,"github_repo":5,"name":6,"description_en":7,"description_zh":8,"ai_summary_zh":8,"readme_en":9,"readme_zh":10,"quickstart_zh":11,"use_case_zh":12,"hero_image_url":13,"owner_login":14,"owner_name":15,"owner_avatar_url":16,"owner_bio":17,"owner_company":18,"owner_location":18,"owner_email":18,"owner_twitter":18,"owner_website":19,"owner_url":20,"languages":21,"stars":38,"forks":39,"last_commit_at":40,"license":41,"difficulty_score":42,"env_os":43,"env_gpu":44,"env_ram":45,"env_deps":46,"category_tags":52,"github_topics":54,"view_count":62,"oss_zip_url":18,"oss_zip_packed_at":18,"status":63,"created_at":64,"updated_at":65,"faqs":66,"releases":96},9797,"kubeflow\u002Fmpi-operator","mpi-operator","Kubernetes Operator for MPI-based applications (distributed training, HPC, etc.)","mpi-operator 是专为 Kubernetes 环境设计的开源工具，旨在简化基于 MPI（消息传递接口）的分布式应用部署与管理。它主要解决了在容器化集群中运行大规模分布式训练和高性能计算（HPC）任务时，手动配置复杂、资源调度困难以及进程通信管理繁琐等痛点。\n\n通过引入自定义的 `MPIJob` 资源，mpi-operator 让用户只需定义一份简单的配置文件，即可自动协调多个节点间的启动器（Launcher）与工作器（Worker），轻松实现类似 Allreduce 模式的高效分布式训练。无论是多节点 TensorFlow 训练还是其他 MPI 兼容的科学计算任务，都能在该工具的帮助下快速上线并稳定运行。\n\n这款工具特别适合需要在云原生架构上进行深度学习模型训练的 AI 研究人员、算法工程师以及负责构建 MLOps 平台的开发者。其核心技术亮点在于深度集成 Kubeflow 生态，支持灵活的副本策略与状态监控，能够自动处理底层复杂的 MPI 环境初始化与故障恢复，让团队可以更专注于算法优化而非基础设施运维。","# MPI Operator\n\n[![Build Status](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fworkflows\u002Fbuild\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Factions?query=event%3Apush+branch%3Amaster)\n[![Docker Pulls](https:\u002F\u002Fimg.shields.io\u002Fdocker\u002Fpulls\u002Fmpioperator\u002Fmpi-operator)](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fmpioperator\u002Fmpi-operator)\n\nThe MPI Operator makes it easy to run allreduce-style distributed training on Kubernetes. Please check out [this blog post](https:\u002F\u002Fmedium.com\u002Fkubeflow\u002Fintroduction-to-kubeflow-mpi-operator-and-industry-adoption-296d5f2e6edc) for an introduction to MPI Operator and its industry adoption.\n\n## Installation\n\nYou can deploy the operator with default settings by running the following commands:\n\n- Latest Development Version\n\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fmaster\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\n- Release Version\n\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fv0.8.0\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\nAlternatively, follow the [getting started guide](https:\u002F\u002Fwww.kubeflow.org\u002Fdocs\u002Fstarted\u002Fgetting-started\u002F) to deploy Kubeflow.\n\nAn alpha version of MPI support was introduced with Kubeflow 0.2.0. You must be using a version of Kubeflow newer than 0.2.0.\n\nYou can check whether the MPI Job custom resource is installed via:\n\n```\nkubectl get crd\n```\n\nThe output should include `mpijobs.kubeflow.org` like the following:\n\n```\nNAME                                       AGE\n...\nmpijobs.kubeflow.org                       4d\n...\n```\n\nIf it is not included, you can add it as follows using [kustomize](https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fkustomize):\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\ncd mpi-operator\nkustomize build manifests\u002Foverlays\u002Fkubeflow | kubectl apply -f -\n```\n\nNote that since Kubernetes v1.14, `kustomize` became a subcommand in `kubectl` so you can also run the following command instead:\n\nSince Kubernetes v1.21, you can use:\n\n```bash\nkubectl apply -k manifests\u002Foverlays\u002Fkubeflow\n```\n\n```bash\nkubectl kustomize base | kubectl apply -f -\n```\n\n## Creating an MPI Job\n\nYou can create an MPI job by defining an `MPIJob` config file. See [TensorFlow benchmark example](examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml) config file for launching a multi-node TensorFlow benchmark training job. You may change the config file based on your requirements.\n\n```\ncat examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n```\n\nDeploy the `MPIJob` resource to start training:\n\n```\nkubectl apply -f examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n```\n\n## Monitoring an MPI Job\n\nOnce the `MPIJob` resource is created, you should now be able to see the created pods matching the specified number of GPUs. You can also monitor the job status from the status section. Here is sample output when the job is successfully completed.\n\n```\nkubectl get -o yaml mpijobs tensorflow-benchmarks\n```\n\n```\napiVersion: kubeflow.org\u002Fv2beta1\nkind: MPIJob\nmetadata:\n  creationTimestamp: \"2019-07-09T22:15:51Z\"\n  generation: 1\n  name: tensorflow-benchmarks\n  namespace: default\n  resourceVersion: \"5645868\"\n  selfLink: \u002Fapis\u002Fkubeflow.org\u002Fv1alpha2\u002Fnamespaces\u002Fdefault\u002Fmpijobs\u002Ftensorflow-benchmarks\n  uid: 1c5b470f-a297-11e9-964d-88d7f67c6e6d\nspec:\n  runPolicy:\n    cleanPodPolicy: Running\n  mpiReplicaSpecs:\n    Launcher:\n      replicas: 1\n      template:\n        spec:\n          containers:\n          - command:\n            - mpirun\n            - --allow-run-as-root\n            - -np\n            - \"2\"\n            - -bind-to\n            - none\n            - -map-by\n            - slot\n            - -x\n            - NCCL_DEBUG=INFO\n            - -x\n            - LD_LIBRARY_PATH\n            - -x\n            - PATH\n            - -mca\n            - pml\n            - ob1\n            - -mca\n            - btl\n            - ^openib\n            - python\n            - scripts\u002Ftf_cnn_benchmarks\u002Ftf_cnn_benchmarks.py\n            - --model=resnet101\n            - --batch_size=64\n            - --variable_update=horovod\n            image: mpioperator\u002Ftensorflow-benchmarks:latest\n            name: tensorflow-benchmarks\n    Worker:\n      replicas: 1\n      template:\n        spec:\n          containers:\n          - image: mpioperator\u002Ftensorflow-benchmarks:latest\n            name: tensorflow-benchmarks\n            resources:\n              limits:\n                nvidia.com\u002Fgpu: 2\n  slotsPerWorker: 2\nstatus:\n  completionTime: \"2019-07-09T22:17:06Z\"\n  conditions:\n  - lastTransitionTime: \"2019-07-09T22:15:51Z\"\n    lastUpdateTime: \"2019-07-09T22:15:51Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks is created.\n    reason: MPIJobCreated\n    status: \"True\"\n    type: Created\n  - lastTransitionTime: \"2019-07-09T22:15:54Z\"\n    lastUpdateTime: \"2019-07-09T22:15:54Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks is running.\n    reason: MPIJobRunning\n    status: \"False\"\n    type: Running\n  - lastTransitionTime: \"2019-07-09T22:17:06Z\"\n    lastUpdateTime: \"2019-07-09T22:17:06Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks successfully completed.\n    reason: MPIJobSucceeded\n    status: \"True\"\n    type: Succeeded\n  replicaStatuses:\n    Launcher:\n      succeeded: 1\n    Worker: {}\n  startTime: \"2019-07-09T22:15:51Z\"\n```\n\nTraining should run for 100 steps and takes a few minutes on a GPU cluster. You can inspect the logs to see the training progress. When the job starts, access the logs from the `launcher` pod:\n\n```\nPODNAME=$(kubectl get pods -l training.kubeflow.org\u002Fjob-name=tensorflow-benchmarks,training.kubeflow.org\u002Fjob-role=launcher -o name)\nkubectl logs -f ${PODNAME}\n```\n\n```\nTensorFlow:  1.14\nModel:       resnet101\nDataset:     imagenet (synthetic)\nMode:        training\nSingleSess:  False\nBatch size:  128 global\n             64 per device\nNum batches: 100\nNum epochs:  0.01\nDevices:     ['horovod\u002Fgpu:0', 'horovod\u002Fgpu:1']\nNUMA bind:   False\nData format: NCHW\nOptimizer:   sgd\nVariables:   horovod\n\n...\n\n40\timages\u002Fsec: 154.4 +\u002F- 0.7 (jitter = 4.0)\t8.280\n40\timages\u002Fsec: 154.4 +\u002F- 0.7 (jitter = 4.1)\t8.482\n50\timages\u002Fsec: 154.8 +\u002F- 0.6 (jitter = 4.0)\t8.397\n50\timages\u002Fsec: 154.8 +\u002F- 0.6 (jitter = 4.2)\t8.450\n60\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.1)\t8.321\n60\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.4)\t8.349\n70\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.0)\t8.433\n70\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.4)\t8.430\n80\timages\u002Fsec: 154.8 +\u002F- 0.4 (jitter = 3.6)\t8.199\n80\timages\u002Fsec: 154.8 +\u002F- 0.4 (jitter = 3.8)\t8.404\n90\timages\u002Fsec: 154.6 +\u002F- 0.4 (jitter = 3.7)\t8.418\n90\timages\u002Fsec: 154.6 +\u002F- 0.4 (jitter = 3.6)\t8.459\n100\timages\u002Fsec: 154.2 +\u002F- 0.4 (jitter = 4.0)\t8.372\n100\timages\u002Fsec: 154.2 +\u002F- 0.4 (jitter = 4.0)\t8.542\n----------------------------------------------------------------\ntotal images\u002Fsec: 308.27\n```\n\nFor a sample that uses Intel MPI, see:\n\n```bash\ncat examples\u002Fpi\u002Fpi-intel.yaml\n```\n\nFor a sample that uses MPICH, see:\n\n```bash\ncat examples\u002Fpi\u002Fpi-mpich.yaml\n```\n\n## Exposed Metrics\n\n| Metric name | Metric type | Description | Labels |\n| ----------- | ----------- | ----------- | ------ |\n|mpi\\_operator\\_jobs\\_created\\_total | Counter  | Counts number of MPI jobs created | |\n|mpi\\_operator\\_jobs\\_successful\\_total | Counter  | Counts number of MPI jobs successful | |\n|mpi\\_operator\\_jobs\\_failed\\_total | Counter  | Counts number of MPI jobs failed| |\n|mpi\\_operator\\_job\\_info | Gauge | Information about MPIJob | `launcher`=<launcher-pod-name> \u003Cbr> `namespace`=<job-namespace> |\n\n### Join Metrics\n\nWith [kube-state-metrics](https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkube-state-metrics), one can join metrics by labels.\nFor example `kube_pod_info * on(pod,namespace) group_left label_replace(mpi_operator_job_infos, \"pod\", \"$0\", \"launcher\", \".*\")`\n\n## Docker Images\n\nWe push Docker images of [mpioperator on Dockerhub](https:\u002F\u002Fhub.docker.com\u002Fu\u002Fmpioperator) for every release.\nYou can use the following Dockerfile to build the image yourself:\n\n- [mpi-operator](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FDockerfile)\n\nAlternative, you can build the image using make:\n\n```bash\nmake RELEASE_VERSION=dev IMAGE_NAME=registry.example.com\u002Fmpi-operator images\n```\n\nThis will produce an image with the tag `registry.example.com\u002Fmpi-operator:dev`.\n\n## Contributing\n\nLearn more in [CONTRIBUTING](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FCONTRIBUTING.md).\n","# MPI 运算符\n\n[![构建状态](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fworkflows\u002Fbuild\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Factions?query=event%3Apush+branch%3Amaster)\n[![Docker 拉取次数](https:\u002F\u002Fimg.shields.io\u002Fdocker\u002Fpulls\u002Fmpioperator\u002Fmpi-operator)](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fmpioperator\u002Fmpi-operator)\n\nMPI 运算符使在 Kubernetes 上运行 allreduce 风格的分布式训练变得容易。请查看 [这篇博客文章](https:\u002F\u002Fmedium.com\u002Fkubeflow\u002Fintroduction-to-kubeflow-mpi-operator-and-industry-adoption-296d5f2e6edc) ，了解 MPI 运算符及其行业采用情况。\n\n## 安装\n\n您可以通过运行以下命令以默认设置部署运算符：\n\n- 最新开发版本\n\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fmaster\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\n- 发布版本\n\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fv0.8.0\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\n或者，您可以按照 [入门指南](https:\u002F\u002Fwww.kubeflow.org\u002Fdocs\u002Fstarted\u002Fgetting-started\u002F) 部署 Kubeflow。\n\nKubeflow 0.2.0 引入了 MPI 支持的 alpha 版本。您必须使用高于 0.2.0 的 Kubeflow 版本。\n\n您可以通过以下命令检查是否已安装 MPI 作业自定义资源：\n\n```\nkubectl get crd\n```\n\n输出应包含 `mpijobs.kubeflow.org`，如下所示：\n\n```\nNAME                                       AGE\n...\nmpijobs.kubeflow.org                       4d\n...\n```\n\n如果未包含，您可以使用 [kustomize](https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fkustomize) 按照以下步骤添加：\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\ncd mpi-operator\nkustomize build manifests\u002Foverlays\u002Fkubeflow | kubectl apply -f -\n```\n\n请注意，自 Kubernetes v1.14 起，`kustomize` 已成为 `kubectl` 中的一个子命令，因此您也可以运行以下命令：\n\n自 Kubernetes v1.21 起，您可以使用：\n\n```bash\nkubectl apply -k manifests\u002Foverlays\u002Fkubeflow\n```\n\n```bash\nkubectl kustomize base | kubectl apply -f -\n```\n\n## 创建 MPI 作业\n\n您可以通过定义一个 `MPIJob` 配置文件来创建 MPI 作业。请参阅 [TensorFlow 基准示例](examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml) 配置文件，用于启动多节点 TensorFlow 基准训练作业。您可以根据自己的需求修改该配置文件。\n\n```\ncat examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n```\n\n部署 `MPIJob` 资源以开始训练：\n\n```\nkubectl apply -f examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n```\n\n## 监控 MPI 作业\n\n一旦创建了 `MPIJob` 资源，您现在应该能够看到与指定 GPU 数量匹配的 Pod。您还可以从状态部分监控作业状态。以下是作业成功完成时的示例输出。\n\n```\nkubectl get -o yaml mpijobs tensorflow-benchmarks\n```\n\n```\napiVersion: kubeflow.org\u002Fv2beta1\nkind: MPIJob\nmetadata:\n  creationTimestamp: \"2019-07-09T22:15:51Z\"\n  generation: 1\n  name: tensorflow-benchmarks\n  namespace: default\n  resourceVersion: \"5645868\"\n  selfLink: \u002Fapis\u002Fkubeflow.org\u002Fv1alpha2\u002Fnamespaces\u002Fdefault\u002Fmpijobs\u002Ftensorflow-benchmarks\n  uid: 1c5b470f-a297-11e9-964d-88d7f67c6e6d\nspec:\n  runPolicy:\n    cleanPodPolicy: Running\n  mpiReplicaSpecs:\n    Launcher:\n      replicas: 1\n      template:\n        spec:\n          containers:\n          - command:\n            - mpirun\n            - --allow-run-as-root\n            - -np\n            - \"2\"\n            - -bind-to\n            - none\n            - -map-by\n            - slot\n            - -x\n            - NCCL_DEBUG=INFO\n            - -x\n            - LD_LIBRARY_PATH\n            - -x\n            - PATH\n            - -mca\n            - pml\n            - ob1\n            - -mca\n            - btl\n            - ^openib\n            - python\n            - scripts\u002Ftf_cnn_benchmarks\u002Ftf_cnn_benchmarks.py\n            - --model=resnet101\n            - --batch_size=64\n            - --variable_update=horovod\n            image: mpioperator\u002Ftensorflow-benchmarks:latest\n            name: tensorflow-benchmarks\n    Worker:\n      replicas: 1\n      template:\n        spec:\n          containers:\n          - image: mpioperator\u002Ftensorflow-benchmarks:latest\n            name: tensorflow-benchmarks\n            resources:\n              limits:\n                nvidia.com\u002Fgpu: 2\n  slotsPerWorker: 2\nstatus:\n  completionTime: \"2019-07-09T22:17:06Z\"\n  conditions:\n  - lastTransitionTime: \"2019-07-09T22:15:51Z\"\n    lastUpdateTime: \"2019-07-09T22:15:51Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks is created.\n    reason: MPIJobCreated\n    status: \"True\"\n    type: Created\n  - lastTransitionTime: \"2019-07-09T22:15:54Z\"\n    lastUpdateTime: \"2019-07-09T22:15:54Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks is running.\n    reason: MPIJobRunning\n    status: \"False\"\n    type: Running\n  - lastTransitionTime: \"2019-07-09T22:17:06Z\"\n    lastUpdateTime: \"2019-07-09T22:17:06Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks successfully completed.\n    reason: MPIJobSucceeded\n    status: \"True\"\n    type: Succeeded\n  replicaStatuses:\n    Launcher:\n      succeeded: 1\n    Worker: {}\n  startTime: \"2019-07-09T22:15:51Z\"\n```\n\n训练应运行 100 步，在 GPU 集群上大约需要几分钟。您可以查看日志以了解训练进度。当作业开始时，从 `launcher` Pod 访问日志：\n\n```\nPODNAME=$(kubectl get pods -l training.kubeflow.org\u002Fjob-name=tensorflow-benchmarks,training.kubeflow.org\u002Fjob-role=launcher -o name)\nkubectl logs -f ${PODNAME}\n```\n\n```\nTensorFlow:  1.14\nModel:       resnet101\nDataset:     imagenet (synthetic)\nMode:        training\nSingleSess:  False\nBatch size:  128 global\n             64 per device\nNum batches: 100\nNum epochs:  0.01\nDevices:     ['horovod\u002Fgpu:0', 'horovod\u002Fgpu:1']\nNUMA bind:   False\nData format: NCHW\nOptimizer:   sgd\nVariables:   horovod\n\n...\n\n40\timages\u002Fsec: 154.4 +\u002F- 0.7 (jitter = 4.0)\t8.280\n40\timages\u002Fsec: 154.4 +\u002F- 0.7 (jitter = 4.1)\t8.482\n50\timages\u002Fsec: 154.8 +\u002F- 0.6 (jitter = 4.0)\t8.397\n50\timages\u002Fsec: 154.8 +\u002F- 0.6 (jitter = 4.2)\t8.450\n60\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.1)\t8.321\n60\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.4)\t8.349\n70\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.0)\t8.433\n70\timages\u002Fsec: 154.5 +\u002F- 0.5 (jitter = 4.4)\t8.430\n80\timages\u002Fsec: 154.8 +\u002F- 0.4 (jitter = 3.6)\t8.199\n80\timages\u002Fsec: 154.8 +\u002F- 0.4 (jitter = 3.8)\t8.404\n90\timages\u002Fsec: 154.6 +\u002F- 0.4 (jitter = 3.7)\t8.418\n90\timages\u002Fsec: 154.6 +\u002F- 0.4 (jitter = 3.6)\t8.459\n100\timages\u002Fsec: 154.2 +\u002F- 0.4 (jitter = 4.0)\t8.372\n100\timages\u002Fsec: 154.2 +\u002F- 0.4 (jitter = 4.0)\t8.542\n----------------------------------------------------------------\ntotal images\u002Fsec: 308.27\n```\n\n有关使用 Intel MPI 的示例，请参阅：\n\n```bash\ncat examples\u002Fpi\u002Fpi-intel.yaml\n```\n\n有关使用 MPICH 的示例，请参阅：\n\n```bash\ncat examples\u002Fpi\u002Fpi-mpich.yaml\n```\n\n## 暴露的指标\n\n| 指标名称 | 指标类型 | 描述 | 标签 |\n| ----------- | ----------- | ----------- | ------ |\n|mpi\\_operator\\_jobs\\_created\\_total | 计数器  | 统计创建的 MPI 作业数量 | |\n|mpi\\_operator\\_jobs\\_successful\\_total | 计数器  | 统计成功的 MPI 作业数量 | |\n|mpi\\_operator\\_jobs\\_failed\\_total | 计数器  | 统计失败的 MPI 作业数量| |\n|mpi\\_operator\\_job\\_info | 状态量 | 关于 MPIJob 的信息 | `launcher`=<launcher-pod-name> \u003Cbr> `namespace`=<job-namespace> |\n\n### 联接指标\n\n借助 [kube-state-metrics](https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkube-state-metrics)，可以通过标签对指标进行联接。\n例如 `kube_pod_info * on(pod,namespace) group_left label_replace(mpi_operator_job_infos, \"pod\", \"$0\", \"launcher\", \".*\")`\n\n## Docker 镜像\n\n我们为每次发布都会在 Docker Hub 上推送 [mpioperator 的 Docker 镜像](https:\u002F\u002Fhub.docker.com\u002Fu\u002Fmpioperator)。\n您也可以使用以下 Dockerfile 自行构建镜像：\n\n- [mpi-operator](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FDockerfile)\n\n或者，您也可以使用 make 命令来构建镜像：\n\n```bash\nmake RELEASE_VERSION=dev IMAGE_NAME=registry.example.com\u002Fmpi-operator images\n```\n\n这将生成一个标签为 `registry.example.com\u002Fmpi-operator:dev` 的镜像。\n\n## 贡献\n\n更多信息请参阅 [CONTRIBUTING](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FCONTRIBUTING.md)。","# MPI Operator 快速上手指南\n\nMPI Operator 是 Kubeflow 项目的一部分，旨在让在 Kubernetes 上运行 Allreduce 风格的分布式训练变得简单。它通过自定义资源 `MPIJob` 来管理分布式训练任务的生命周期。\n\n## 环境准备\n\n在开始之前，请确保满足以下前置条件：\n\n*   **Kubernetes 集群**：需要一个正在运行的 Kubernetes 集群（建议版本 1.14+）。\n*   **Kubeflow 版本**：如果您使用完整的 Kubeflow 平台，版本需高于 0.2.0。\n*   **kubectl 工具**：已安装并配置好 `kubectl`，且拥有集群的管理权限。\n*   **GPU 支持（可选但推荐）**：如果运行深度学习任务，集群节点需配备 NVIDIA GPU 并安装相应的 Device Plugin。\n*   **网络访问**：确保集群节点可以访问 Docker Hub 或配置了国内镜像加速器，以便拉取 `mpioperator` 相关镜像。\n\n## 安装步骤\n\n您可以直接通过 `kubectl` 应用 YAML 文件来部署 operator。\n\n### 1. 部署 Operator\n\n选择以下任一命令进行安装：\n\n**安装最新开发版本：**\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fmaster\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\n**安装稳定发布版本 (v0.8.0)：**\n```shell\nkubectl apply --server-side -f https:\u002F\u002Fraw.githubusercontent.com\u002Fkubeflow\u002Fmpi-operator\u002Fv0.8.0\u002Fdeploy\u002Fv2beta1\u002Fmpi-operator.yaml\n```\n\n> **提示**：如果在国内访问 GitHub _raw_ 地址较慢，可以先将 yaml 文件下载到本地，或使用国内镜像源托管的配置文件的地址。\n\n### 2. 验证安装\n\n检查自定义资源定义（CRD）是否已成功创建：\n\n```bash\nkubectl get crd\n```\n\n输出中应包含 `mpijobs.kubeflow.org`，如下所示：\n\n```text\nNAME                                       AGE\n...\nmpijobs.kubeflow.org                       4d\n...\n```\n\n如果未找到该 CRD，也可以通过源码使用 `kustomize` 安装：\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\ncd mpi-operator\n# Kubernetes v1.21+ 推荐使用以下命令\nkubectl apply -k manifests\u002Foverlays\u002Fkubeflow\n```\n\n## 基本使用\n\n以下以运行一个多节点 TensorFlow 基准测试任务为例，展示如何创建和监控 MPI 任务。\n\n### 1. 创建 MPI 任务\n\nMPI Operator 通过 `MPIJob` 资源定义任务。您可以直接使用官方提供的示例配置：\n\n```bash\n# 查看示例配置文件\ncat examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n\n# 部署任务\nkubectl apply -f examples\u002Fv2beta1\u002Ftensorflow-benchmarks\u002Ftensorflow-benchmarks.yaml\n```\n\n该示例配置会启动一个包含 Launcher（启动器）和 Worker（工作节点）的任务，利用 Horovod 进行分布式训练。\n\n### 2. 监控任务状态\n\n任务提交后，可以通过以下命令查看任务详情和状态：\n\n```bash\nkubectl get -o yaml mpijobs tensorflow-benchmarks\n```\n\n关注 `status` 部分，当 `type: Succeeded` 且 `status: \"True\"` 时，表示任务成功完成：\n\n```yaml\nstatus:\n  conditions:\n  - lastTransitionTime: \"2019-07-09T22:17:06Z\"\n    message: MPIJob default\u002Ftensorflow-benchmarks successfully completed.\n    reason: MPIJobSucceeded\n    status: \"True\"\n    type: Succeeded\n```\n\n### 3. 查看训练日志\n\n训练日志主要由 `launcher` Pod 输出。您可以使用以下命令实时查看训练进度（如每秒处理的图像数）：\n\n```bash\nPODNAME=$(kubectl get pods -l training.kubeflow.org\u002Fjob-name=tensorflow-benchmarks,training.kubeflow.org\u002Fjob-role=launcher -o name)\nkubectl logs -f ${PODNAME}\n```\n\n**预期输出示例：**\n```text\n...\n40\timages\u002Fsec: 154.4 +\u002F- 0.7 (jitter = 4.0)\t8.280\n...\n100\timages\u002Fsec: 154.2 +\u002F- 0.4 (jitter = 4.0)\t8.372\n----------------------------------------------------------------\ntotal images\u002Fsec: 308.27\n```\n\n### 其他示例\n\n除了 TensorFlow，MPI Operator 还支持其他 MPI 实现，您可以参考以下示例：\n\n*   **Intel MPI**: `cat examples\u002Fpi\u002Fpi-intel.yaml`\n*   **MPICH**: `cat examples\u002Fpi\u002Fpi-mpich.yaml`","某自动驾驶研发团队需要在 Kubernetes 集群上利用多节点 GPU 资源，训练基于 TensorFlow 的大规模感知模型以缩短迭代周期。\n\n### 没有 mpi-operator 时\n- **手动配置繁琐**：工程师需手动编写复杂的 Shell 脚本管理 `mpirun` 启动参数，并逐个创建 Pod，极易因环境变量（如 `LD_LIBRARY_PATH`）配置遗漏导致通信失败。\n- **故障恢复困难**：一旦某个计算节点在训练中途宕机，整个分布式任务立即中断，缺乏自动重试机制，数小时的训练成果付诸东流。\n- **资源调度低效**：无法声明式地定义所需 GPU 数量，难以确保所有工作节点在同一时间就绪，常出现部分节点空闲等待的“木桶效应”。\n- **状态监控黑盒**：缺乏统一的状态视图，运维人员需登录各个 Pod 查看日志才能判断任务是运行中、失败还是已完成，排查效率极低。\n\n### 使用 mpi-operator 后\n- **一键部署任务**：只需定义一个 `MPIJob` YAML 文件，mpi-operator 自动处理 Launcher 和 Worker 的编排及环境变量注入，将部署复杂度从小时级降至分钟级。\n- **弹性容错保障**：内置策略可自动检测节点故障并重启失败的任务副本，确保长周期的分布式训练任务稳定运行至完成。\n- **精准资源协同**：通过声明式配置指定 GPU 数量，mpi-operator 确保所有计算节点同步启动并建立 MPI 通信环，最大化集群算力利用率。\n- **可视化全链路监控**：直接通过 `kubectl get mpijobs` 即可查看任务整体状态（Running\u002FCompleted\u002FFailed），无需深入底层容器即可掌握训练进度。\n\nmpi-operator 将原本脆弱且手工密集型的 MPI 分布式训练流程，转化为云原生环境下稳定、可观测且易于管理的标准化作业。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fkubeflow_mpi-operator_bb297bb9.png","kubeflow","Kubeflow","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002Fkubeflow_2a631e53.png","Kubeflow is an open, community driven project to make it easy to deploy and manage an ML stack on Kubernetes",null,"https:\u002F\u002Fkubeflow.org","https:\u002F\u002Fgithub.com\u002Fkubeflow",[22,26,30,34],{"name":23,"color":24,"percentage":25},"Go","#00ADD8",94,{"name":27,"color":28,"percentage":29},"Makefile","#427819",2.9,{"name":31,"color":32,"percentage":33},"Shell","#89e051",1.8,{"name":35,"color":36,"percentage":37},"Dockerfile","#384d54",1.3,524,235,"2026-04-15T04:27:02","Apache-2.0",4,"Linux","运行分布式训练任务时需要 NVIDIA GPU（示例中配置为每节点 2 块），需安装 NVIDIA 设备插件；Operator 本身不强制要求具体型号或显存，取决于用户定义的 MPIJob 配置","未说明",{"notes":47,"python":45,"dependencies":48},"该工具是运行在 Kubernetes 集群上的控制器（Operator），而非本地运行的脚本。必须拥有可用的 Kubernetes 集群环境（建议 Kubeflow 0.2.0 以上版本）。实际硬件需求（如 GPU 数量、显存大小）由用户提交的 MPIJob YAML 配置文件决定，而非 Operator 本身固定要求。支持 OpenMPI、Intel MPI 和 MPICH 等多种 MPI 实现。",[49,50,51],"Kubernetes v1.14+","kubectl","kustomize (v1.21+ 内置于 kubectl)",[53],"开发框架",[55,56,14,57,58,59,60,61],"mpi","horovod","tensorflow","pytorch","apache-mxnet","distributed-computing","kubernetes",2,"ready","2026-03-27T02:49:30.150509","2026-04-20T07:17:16.480185",[67,72,77,82,86,91],{"id":68,"question_zh":69,"answer_zh":70,"source_url":71},43992,"v2 版本中 initContainer 无法以非 root 用户运行，导致 SSH 密钥权限报错怎么办？","这是由于 SSH 对私钥文件权限要求严格（不能过于开放）。如果挂载 Secret，可以尝试设置 `defaultMode: 0440` 或更高（非 root 用户不能使用 0400）。对于 `.ssh` 目录，权限 0777 通常不影响连接。如果移除 init container 后非 root 用户能工作但 root 用户报错 `Permissions 0644 for '\u002Froot\u002F.ssh\u002Fid_rsa' are too open`，这是因为 root 环境下权限检查更严。目前建议检测 securityContext 中的 `runAsUser` 并动态调整权限，或者避免在 root 模式下使用过宽的权限设置。","https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fissues\u002F407",{"id":73,"question_zh":74,"answer_zh":75,"source_url":76},43993,"MPI Operator v2 与 v1alpha2 相比有哪些主要架构差异？迁移时需要注意什么？","v2 的主要变化包括：将 Worker 从 StatefulSet 改为普通 Pod（Plain Pods），并原生支持 OpenSSH。迁移时，除了更改镜像标签指向 v2 外，还需注意配置兼容性。建议在 Job 配置中使用 `restartPolicy: OnFailure`（或省略该行，因为这是默认值），以避免任务失败后留下失败的 Pod。直接切换版本可能无法“即插即用”，需根据新架构调整自定义逻辑。","https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fissues\u002F443",{"id":78,"question_zh":79,"answer_zh":80,"source_url":81},43994,"部署 MPI Job 时 Launcher Pod 显示 `Init:ImagePullBackOff` 且无法拉取 `kubectl-delivery` 镜像，如何解决？","这通常是因为集群中同时存在 Kubeflow 自带的 mpi-operator（位于 kubeflow 命名空间）和用户自行部署的 standalone operator，两者竞争创建资源所致。Kubeflo 包中的 operator 可能仍依赖旧版镜像。解决方法是检查并禁用 Kubeflow 套件中不需要的 mpi-operator 组件，确保只有一个 operator 在运行。可以通过查看 kubeflow 命名空间下的 pod 确认是否存在冲突的 operator。","https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fissues\u002F471",{"id":83,"question_zh":84,"answer_zh":85,"source_url":81},43995,"如何在内部网络（无法访问互联网）的环境中修改 kubectl-delivery 镜像的注册表地址？","虽然 v2 文档声称不再强依赖 `kubectl-delivery` 镜像，但在某些配置或旧版本中仍可能被引用。如果必须使用该镜像且处于内网环境，需要在部署 YAML 中显式指定私有仓库的镜像地址（例如 `my-private-registry.com\u002Fmpioperator\u002Fkubectl-delivery:latest`）。如果是因为多 operator 冲突导致拉取错误，优先解决冲突（见相关问题），然后确保所有引用的镜像都指向可访问的私有仓库。",{"id":87,"question_zh":88,"answer_zh":89,"source_url":90},43996,"MPI Operator 是否支持 Coscheduling 插件以实现 Gang Scheduling（全有或全无调度）？","是的，MPI Operator 已支持通过 Kubernetes 官方的 `coscheduling plugin` (scheduler-plugins) 来实现 Gang Scheduling 语义。这使得用户无需额外部署 Volcano 等重型组件即可使用“全有或全无”的批处理调度逻辑。该功能已在相关版本中实现并通过了 E2E 测试，用户只需配置相应的调度器插件即可启用。","https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fissues\u002F500",{"id":92,"question_zh":93,"answer_zh":94,"source_url":95},43997,"当 Pod 失败时，MPI Operator 如何处理具有稳定主机名（Stable Hostname）需求的替换逻辑？","在计划迁移到原生 Job API 并保留稳定 Pod 名称的讨论中提到，如果 Pod 失败，由于需要保持名称稳定，必须先删除失败的 Pod 才能用同名新 Pod 替换。目前的实现逻辑（基于 StatefulSet 或自定义控制器）会处理这种状态转换。具体实现细节涉及监听 Pod 状态并在失败时执行删除重建操作，以确保主机名不变且任务能继续执行。","https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fissues\u002F315",[97,102,107,112,117,122,127,132,137,142,147],{"id":98,"version":99,"summary_zh":100,"released_at":101},351467,"v0.2.3","## 增强功能\n\n* 新增对 RH OCP4.1 和 RH OCP4.2 的支持\n* 增加了额外的安装方式：\n  * 使用 kustomize 和 [kubeflow\u002Fmanifests](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmanifests)\n  * 使用 [Helm Chart](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Ftree\u002Fmaster\u002Fhack\u002Fhelm\u002Fmpi-operator)\n* 支持 Go Modules，并移除了 vendor 目录\n* 为 init 容器添加了默认的临时存储\n* 覆盖 NVIDIA 环境变量，以避免在启动器上使用 GPU\n* 在各种 Leader 选举阶段增加了健康检查和回调机制\n* 尊重用户指定的 worker 命令\n* 将主容器名称暴露为可配置字段\n* 向 MPIJobSpec 添加了 RunPolicy，复用 [kubeflow\u002Fcommon](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fcommon) 规范\n* 允许指定 gang 调度器的名称以及 Pod 组的优先级\n* 当 Pod Spec 中没有任何容器时，增加错误日志记录\n* 切换到使用 distroless 镜像\n* 重构了 kubectl-delivery，以提升启动器性能\n* 增加了用于作业监控的 Prometheus 指标\n* 添加了 v1 版本 MPIJob 控制器及 API 的实验性版本\n* 支持 Volcano 作为调度器\n* 将启动器 Job 和 StatefulSet worker 改为使用 Pod\n* 日志系统切换为 klog\n* 标签与其他 Kubeflow Operator 更加一致\n\n## 修复\n\n* 修复了可能导致 Pod 意外重启的空指针异常\n* 更新状态仅在启动器处于活动状态且所有 worker 准备就绪时才设置为 Running\n* 修正了初始化 Informer 和 Leader 选举端点时的命名空间错误\n* 修复了 v1 控制器中 CRD 存在性检查的问题\n\n## 文档\n\n* 新增了 [采用者列表](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FADOPTERS.md)\n* 新增了 [路线图文档](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FROADMAP.md)\n* 重新修订了 [贡献指南](https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fblob\u002Fmaster\u002FCONTRIBUTING.md)\n* 在 Kubeflow 官网上新增了 [MPIJob API 参考页面](https:\u002F\u002Fwww.kubeflow.org\u002Fdocs\u002Freference\u002Fmpijob\u002F)\n* 发布了一篇博客文章 [Kubeflow MPI Operator 简介及行业应用](https:\u002F\u002Fmedium.com\u002Fkubeflow\u002Fintroduction-to-kubeflow-mpi-operator-and-industry-adoption-296d5f2e6edc)，介绍 MPI Operator 及其行业应用\n* 新增了一个仅使用 CPU 的示例\n* 补充了依赖项所使用的许可证信息","2020-05-19T14:16:39",{"id":103,"version":104,"summary_zh":105,"released_at":106},351468,"v0.2.2","* 为初始化容器添加了默认资源要求\n* 将多个部署配置文件合并为一个 YAML 文件\n* 改用 kubeflow\u002Fcommon 中的 `JobStatus`\n* 启动器和工作节点现在同时创建\n","2019-09-16T16:41:58",{"id":108,"version":109,"summary_zh":110,"released_at":111},351469,"v0.2.1","* 将 Docker 文件和示例切换为使用 `v1alpha2` 版本的 MPI Operator。","2019-07-15T13:08:51",{"id":113,"version":114,"summary_zh":115,"released_at":116},351470,"v0.2.0","## API 变更\n\n* 添加 MPI Operator 的 v1alpha2 版本，其 API 规范与其他 Kubeflow Operator 更加一致\n* 在 `MPIJobSpec` 中支持 `ActiveDeadlineSeconds`\n* 支持除 GPU 之外的自定义资源类型\n* 移除 `launcherOnMaster` 字段\n\n## 功能增强\n\n* 支持团伙调度\n* 在作业状态中添加 `StartTime` 和 `CompletionTime`\n* 添加领导者选举机制\n* 切换为使用 Pod 组进行团伙调度\n* 添加使用 v1alpha1 版本 MPI Operator 的 Apache MXNet 示例\n","2019-07-03T17:19:16",{"id":118,"version":119,"summary_zh":120,"released_at":121},351471,"0.1.0","Initial release of the MPI Operator.","2019-01-11T00:53:04",{"id":123,"version":124,"summary_zh":125,"released_at":126},351461,"v0.8.0","## 自 v0.7.0 以来的变更\n* 功能：\n  * 支持 [挂起作业的可变调度指令](https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fcontrollers\u002Fjob\u002F#mutable-scheduling-directives-for-suspended-jobs) 在 Launcher 作业上使用，这使得我们能够在 MPIJob Launcher 模板处于挂起状态时，将调度指令传播到 Launcher 的 batch\u002Fv1 作业中。(#772, @GonzaloSaez)\n* 清理工作：\n  * 将 Kubernetes 依赖升级至 v1.35。(#769, @tenzen-y)\n\n### 致谢\n感谢所有贡献者（排名不分先后）：@mimowo @terrytangyuan @GonzaloSaez @tenzen-y","2026-02-17T19:40:45",{"id":128,"version":129,"summary_zh":130,"released_at":131},351462,"v0.7.0","## v0.6.0 以来的变更\n* 功能：\n    * 在 MPI 主机文件生成中支持自定义集群域名。(#704, #707, #738, @tenzen-y)\n    * 当 `runLauncherAsWorker` 为 `true` 时，启用 Service 的 `publishNotReadyAddresses`，以改善 Worker 的 DNS 发现。(#703, @tenzen-y)\n    * 通过 Operator 标志公开 Job 控制器工作队列的速率限制配置，以优化可扩展性调优。(#674, @rotemelad)\n* Bug 修复：\n    * 修复当 `runLauncherAsWorker=true` 时 PodGroup 中的崩溃问题。(#669, @GonzaloSaez)\n    * 修复在 `runLauncherAsWorker=true` 时缺失的 ReplicaIndexLabel，使启动 Pod 能够获得预期的 Pod 索引标签（有助于 Kueue\u002FTAS 的排名发现）。(#690, @GonzaloSaez)\n* 代码清理：\n    * 将 Kubernetes 依赖升级至 v1.34。(#742, @tenzen-y)\n    * 修复清单文件中的 kustomize v5 警告信息。(#700, @vikas-saxena02)\n    * 将 Debian 版本升级至 trixie，并更新了以下 MPI 版本：(#685, @tenzen-y)\n      * OpenMPI：v4.1.4 -> v5.0.7\n      * MPICH：v3.4.1 -> v4.2.1\n\n### 致谢\n感谢所有贡献者（顺序不分先后）：@rotemelad @mimowo @terrytangyuan @GonzaloSaez @vikas-saxena02 @tenzen-y","2025-10-30T19:28:01",{"id":133,"version":134,"summary_zh":135,"released_at":136},351463,"v0.6.0","## v0.5.0 以来的变更\n\n* 功能：\n  * 支持 `ManagedBy` 特性（`.spec.runPolicy.managedBy`），灵感来源于 batch\u002Fv1 Job。\n    * 这使得我们可以将 MPIJob 分发到由 Kueue 的 MultiKueue 提供支持的多个集群中。（#650，@mszadkow）\n* 清理工作：\n  * 将 Kubernetes 库升级至 v1.31（#664，@ArangoGutierrez）\n  * 将 Debian 版本升级至 Bookworm，并更新了以下 MPI 版本：（#661，@tenzen-y）\n    * OpenMPI：v4.1.0 -> v4.1.4\n    * MPICH：3.4.1 -> 4.0.2\n\n### 致谢\n感谢所有贡献者（排名不分先后）：@mszadkow @mimowo @alculquicondor @terrytangyuan @ArangoGutierrez @tenzen-y \n\n**完整变更日志**：https:\u002F\u002Fgithub.com\u002Fkubeflow\u002Fmpi-operator\u002Fcompare\u002Fv0.5.0...v0.6.0","2024-10-16T16:13:49",{"id":138,"version":139,"summary_zh":140,"released_at":141},351464,"v0.5.0","## v0.4.0 以来的变更\r\n\r\n* 功能特性：\n  * 添加对 MPICH 的支持 (#562, @sheevy)\n  * Field `runLauncherAsWorker` 允许将启动器 Pod 作为工作节点添加到主机文件中 (#612, @kuizhiqing)\n  * 为 Volcano 集成添加 PodGroup 的 `minResources` 计算逻辑 (#566, @lowang-bh)\n* Bug 修复：\n  * 修复使用 PodGroups 和 PriorityClasses 时出现的 panic 问题 (#561, @tenzen-y)\n  * 修复 mpijob Python 模块的安装问题 (#579, @vsoch)\n  * 修复不同命名空间中作业名称相同情况下的主机文件生成问题 (#622, @kuizhiqing)\n* 代码清理：\n  * 将 Kubernetes 相关库升级至 v1.29 (#633, @tenzen-y)\n  * 如果 API 访问被拒绝，则使 mpi-operator 二进制文件失败 (#619, @emsixteeen)\n\n### 致谢\r\n感谢所有贡献者（排名不分先后）：@sheevy @alculquicondor @terrytangyuan @tenzen-y @kuizhiqing @lowang-bh @vsoch @emsixteeen @wang-mask @benash @yeahdongcn @xhejtman @pheianox @lianghao208","2024-04-18T18:38:04",{"id":143,"version":144,"summary_zh":145,"released_at":146},351465,"v0.4.0","## 0.3.0 版本以来的变更\r\n\r\n* 破坏性变更\r\n  * 移除了 v1 版本的 Operator。如果您希望使用 MPIJob v1，可以改用 training-operator。\r\n* 支持暂停语义。第三方控制器可以利用 `suspend` 字段为 MPIJob 实现排队和抢占功能。\r\n* 支持 scheduler-plugins 的共同调度插件。\r\n* Operator 现已支持多架构（amd64、aarch64 和 ppc64le）。\r\n* Bug 修复\r\n  * 修复了对弹性 Horovod 的支持问题。\r\n\r\n### 致谢\r\n\r\n特别感谢 @tenzen-y 的多次贡献。  \r\n同时感谢所有贡献者（排名不分先后）：@mimowo、@adilhusain-s、@davidLif、@ArangoGutierrez、@shaowei-su、@ggaaooppeenngg、@pugangxa、@HeGaoYuan、@Dimss、@alculquicondor、@terrytangyuan。","2023-04-05T20:54:14",{"id":148,"version":149,"summary_zh":150,"released_at":151},351466,"v0.3.0","## 版本 v0.3.0 发布\n\n* 可扩展性改进\n  * 工作节点启动时不再向 kube-apiserver 发起请求。\n  * 移除了 kubectl-delivery 初始化容器，从而减轻了 kube-apiserver 的负载。\n* 支持 Intel MPI。\n* 通过为启动器使用 Kubernetes Job，支持 `runPolicy`（`ttlSecondsAfterFinish`、`activeDeadlineSeconds`、`backoffLimit`）。\n* 提供纯 MPI 应用程序示例。\n* 生产就绪性改进：\n  * 提高了单元测试、集成测试和端到端测试的覆盖率。\n  * 增强了 API 验证的健壮性。\n  * 重新审视了 v2beta1 版本的 MPIJob API。\n  * 使用完全限定的标签名称，以与其他 Kubeflow Operator 保持一致。","2021-09-07T20:46:52",[153,165,173,182,190,199],{"id":154,"name":155,"github_repo":156,"description_zh":157,"stars":158,"difficulty_score":159,"last_commit_at":160,"category_tags":161,"status":63},4358,"openclaw","openclaw\u002Fopenclaw","OpenClaw 是一款专为个人打造的本地化 AI 助手，旨在让你在自己的设备上拥有完全可控的智能伙伴。它打破了传统 AI 助手局限于特定网页或应用的束缚，能够直接接入你日常使用的各类通讯渠道，包括微信、WhatsApp、Telegram、Discord、iMessage 等数十种平台。无论你在哪个聊天软件中发送消息，OpenClaw 都能即时响应，甚至支持在 macOS、iOS 和 Android 设备上进行语音交互，并提供实时的画布渲染功能供你操控。\n\n这款工具主要解决了用户对数据隐私、响应速度以及“始终在线”体验的需求。通过将 AI 部署在本地，用户无需依赖云端服务即可享受快速、私密的智能辅助，真正实现了“你的数据，你做主”。其独特的技术亮点在于强大的网关架构，将控制平面与核心助手分离，确保跨平台通信的流畅性与扩展性。\n\nOpenClaw 非常适合希望构建个性化工作流的技术爱好者、开发者，以及注重隐私保护且不愿被单一生态绑定的普通用户。只要具备基础的终端操作能力（支持 macOS、Linux 及 Windows WSL2），即可通过简单的命令行引导完成部署。如果你渴望拥有一个懂你",349277,3,"2026-04-06T06:32:30",[162,53,163,164],"Agent","图像","数据工具",{"id":166,"name":167,"github_repo":168,"description_zh":169,"stars":170,"difficulty_score":159,"last_commit_at":171,"category_tags":172,"status":63},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,"2026-04-05T11:01:52",[53,163,162],{"id":174,"name":175,"github_repo":176,"description_zh":177,"stars":178,"difficulty_score":62,"last_commit_at":179,"category_tags":180,"status":63},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",160784,"2026-04-19T11:32:54",[53,162,181],"语言模型",{"id":183,"name":184,"github_repo":185,"description_zh":186,"stars":187,"difficulty_score":62,"last_commit_at":188,"category_tags":189,"status":63},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",109154,"2026-04-18T11:18:24",[53,163,162],{"id":191,"name":192,"github_repo":193,"description_zh":194,"stars":195,"difficulty_score":62,"last_commit_at":196,"category_tags":197,"status":63},6121,"gemini-cli","google-gemini\u002Fgemini-cli","gemini-cli 是一款由谷歌推出的开源 AI 命令行工具，它将强大的 Gemini 大模型能力直接集成到用户的终端环境中。对于习惯在命令行工作的开发者而言，它提供了一条从输入提示词到获取模型响应的最短路径，无需切换窗口即可享受智能辅助。\n\n这款工具主要解决了开发过程中频繁上下文切换的痛点，让用户能在熟悉的终端界面内直接完成代码理解、生成、调试以及自动化运维任务。无论是查询大型代码库、根据草图生成应用，还是执行复杂的 Git 操作，gemini-cli 都能通过自然语言指令高效处理。\n\n它特别适合广大软件工程师、DevOps 人员及技术研究人员使用。其核心亮点包括支持高达 100 万 token 的超长上下文窗口，具备出色的逻辑推理能力；内置 Google 搜索、文件操作及 Shell 命令执行等实用工具；更独特的是，它支持 MCP（模型上下文协议），允许用户灵活扩展自定义集成，连接如图像生成等外部能力。此外，个人谷歌账号即可享受免费的额度支持，且项目基于 Apache 2.0 协议完全开源，是提升终端工作效率的理想助手。",100752,"2026-04-10T01:20:03",[198,162,163,53],"插件",{"id":200,"name":201,"github_repo":202,"description_zh":203,"stars":204,"difficulty_score":62,"last_commit_at":205,"category_tags":206,"status":63},4721,"markitdown","microsoft\u002Fmarkitdown","MarkItDown 是一款由微软 AutoGen 团队打造的轻量级 Python 工具，专为将各类文件高效转换为 Markdown 格式而设计。它支持 PDF、Word、Excel、PPT、图片（含 OCR）、音频（含语音转录）、HTML 乃至 YouTube 链接等多种格式的解析，能够精准提取文档中的标题、列表、表格和链接等关键结构信息。\n\n在人工智能应用日益普及的今天，大语言模型（LLM）虽擅长处理文本，却难以直接读取复杂的二进制办公文档。MarkItDown 恰好解决了这一痛点，它将非结构化或半结构化的文件转化为模型“原生理解”且 Token 效率极高的 Markdown 格式，成为连接本地文件与 AI 分析 pipeline 的理想桥梁。此外，它还提供了 MCP（模型上下文协议）服务器，可无缝集成到 Claude Desktop 等 LLM 应用中。\n\n这款工具特别适合开发者、数据科学家及 AI 研究人员使用，尤其是那些需要构建文档检索增强生成（RAG）系统、进行批量文本分析或希望让 AI 助手直接“阅读”本地文件的用户。虽然生成的内容也具备一定可读性，但其核心优势在于为机器",93400,"2026-04-06T19:52:38",[198,53]]