Stable Yogi 模型DevOps实践Linux环境下的持续集成与监控最近和几个做AI应用落地的朋友聊天大家普遍有个头疼的问题模型好不容易训出来了效果也不错但一到生产环境就各种水土不服。服务动不动就挂GPU资源时高时低出了问题还得半夜爬起来查日志。这感觉就像造了一辆好车但没修好路也没配导航和维修站跑起来总是提心吊胆。其实这就是典型的“模型交付”与“工程运维”之间的断层。我们今天要聊的就是把Stable Yoji这类大模型像对待一个标准软件服务一样用DevOps的思路管起来。核心目标很简单让它能在Linux服务器上7x24小时稳定、可靠地跑着出了问题我们能第一时间知道甚至能自动恢复。这篇文章我就结合实际的工程经验聊聊怎么在Linux环境下为Stable Yogi模型搭建一套从部署、集成到监控的完整运维体系。我们会用到Docker Compose、CI/CD流水线、Prometheus、Grafana这些工具但重点不是工具本身而是它们如何串联起来解决我们实际遇到的那些运维痛点。1. 为什么大模型服务需要DevOps你可能觉得模型服务不就是启动一个Python脚本挂个API接口吗为什么搞得这么复杂这里面的区别就像个人项目和企业级应用的区别。个人玩玩服务挂了重启一下就行。但在生产环境尤其是对外提供服务的场景每一分钟宕机都可能意味着用户流失和直接的经济损失。Stable Yogi模型本身可能很稳定但它依赖的组件比如CUDA驱动、特定版本的Python包、它消耗的资源尤其是昂贵的GPU内存、以及它对外提供的API都可能成为故障点。DevOps的核心思想是“开发”和“运维”的协同与自动化。对于大模型服务这意味着环境一致性确保开发、测试、生产环境一模一样避免“在我机器上好好的”这种问题。自动化部署一键或自动将新版本的模型或代码部署上线减少人为失误。持续监控实时掌握服务的健康状态、资源消耗和性能指标而不是等用户投诉了才发现。快速反馈与恢复出现问题能快速定位、告警甚至自动执行恢复操作。接下来我们就从环境搭建开始一步步构建这套体系。2. 基础环境搭建用Docker Compose固化服务第一步我们要解决环境依赖的“幽灵”问题。最稳妥的方法就是使用Docker进行容器化封装。2.1 编写Dockerfile构建可复现的模型环境为Stable Yogi模型编写一个Dockerfile目的是将模型、代码及其所有依赖包括特定版本的PyTorch、CUDA库、系统工具等打包成一个独立的镜像。# 使用带有CUDA基础镜像确保GPU支持 FROM nvidia/cuda:12.1.1-runtime-ubuntu22.04 # 设置工作目录并安装系统依赖 WORKDIR /app RUN apt-get update apt-get install -y \ python3-pip \ python3-dev \ git \ rm -rf /var/lib/apt/lists/* # 复制模型代码和依赖声明文件 COPY requirements.txt . COPY stable_yogi_app ./stable_yogi_app # 安装Python依赖使用国内镜像加速 RUN pip3 install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt # 暴露API服务端口假设你的服务运行在7860端口类似Gradio EXPOSE 7860 # 定义容器启动命令 CMD [python3, stable_yogi_app/server.py]这个Dockerfile做了几件关键事固定了基础操作系统和CUDA版本明确了Python依赖并定义了服务的启动方式。构建出的镜像在任何支持Docker和NVIDIA Container Toolkit的Linux主机上运行行为都是一致的。2.2 使用Docker Compose编排多服务一个完整的模型服务可能不止一个应用。比如你可能还需要一个数据库来记录请求日志或者一个Redis来做缓存。Docker Compose可以轻松定义和管理多个关联的容器。创建一个docker-compose.yml文件version: 3.8 services: stable-yogi-api: build: . container_name: stable-yogi-service ports: - 7860:7860 # 将宿主机的7860端口映射到容器 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] # 声明需要GPU资源 volumes: - ./model_weights:/app/models # 将宿主机上的模型权重挂载进容器便于更新 - ./logs:/app/logs # 挂载日志目录 restart: unless-stopped # 设置自动重启策略 networks: - stable-yogi-net # 示例可以添加一个PostgreSQL容器用于存储数据 # postgres-db: # image: postgres:15 # environment: # POSTGRES_PASSWORD: example_password # volumes: # - postgres_data:/var/lib/postgresql/data # networks: # - stable-yogi-net networks: stable-yogi-net: driver: bridge # volumes: # postgres_data:现在只需要在服务器上执行一句linux常用命令大全里最让人安心的命令之一整个服务栈就能启动docker-compose up -d-d参数代表后台运行。要停止服务则用docker-compose down。这种编排方式使得服务的启停、重建变得极其简单和标准化。3. 自动化流水线CI/CD让部署像喝水一样简单环境固化了接下来就要解决部署流程的自动化。我们不想每次更新代码或模型都手动登录服务器去执行一堆命令。这里以 GitLab CI 为例展示如何构建一个简单的CI/CD流水线。在项目根目录创建.gitlab-ci.yml文件。stages: - test - build - deploy variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA # 使用提交哈希作为镜像标签 # 阶段1测试例如运行单元测试或API接口测试 run-tests: stage: test image: python:3.10 script: - pip install -r requirements.txt - pytest tests/ --tbshort # 假设你有测试用例 # 阶段2构建并推送Docker镜像到私有仓库 build-image: stage: build image: docker:latest services: - docker:dind # 使用Docker in Docker服务 script: - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE only: - main # 仅当推送到main分支时触发构建 # 阶段3部署到生产服务器 deploy-to-prod: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client # 安装ssh客户端 - eval $(ssh-agent -s) - echo $SSH_PRIVATE_KEY | ssh-add - # 加载预配置的SSH私钥 - mkdir -p ~/.ssh - chmod 700 ~/.ssh script: # 通过SSH连接到生产服务器执行部署脚本 - ssh -o StrictHostKeyCheckingno useryour-production-server.com cd /path/to/your/app ./deploy.sh $DOCKER_IMAGE only: - main needs: [build-image] # 依赖build阶段成功这个流水线定义了三个阶段测试、构建镜像、部署。当开发者向main分支推送代码时流水线自动触发。它会运行测试通过后构建一个新的Docker镜像并推送到仓库最后通过SSH连接到生产服务器执行一个部署脚本。生产服务器上的deploy.sh脚本可能长这样#!/bin/bash # deploy.sh NEW_IMAGE$1 echo 拉取最新镜像: $NEW_IMAGE docker pull $NEW_IMAGE echo 停止旧容器并启动新容器... cd /path/to/your/app docker-compose down docker-compose up -d echo 清理旧的Docker镜像... docker image prune -f这样一次代码提交就能自动完成从测试到上线的全过程实现了持续集成和持续部署。4. 监控与告警为模型服务装上“眼睛”和“耳朵”服务跑起来了也能源源不断地自动更新了。但我们怎么知道它是否健康GPU用满了怎么办API响应突然变慢了谁负责这就需要监控系统。我们采用经典的 Prometheus Grafana 组合。4.1 暴露模型服务指标首先需要在Stable Yogi的API服务中集成Prometheus客户端库如prometheus-flask-exporter用于Flask应用暴露一些关键指标比如请求次数、请求延迟、错误率等。同时对于GPU监控我们可以在服务器上安装nvidia_gpu_exporter它会将GPU的使用率、显存占用、温度等指标暴露给Prometheus。4.2 配置Prometheus抓取修改docker-compose.yml加入Prometheus和Grafana服务services: # ... 原有的 stable-yogi-api 服务 ... prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml # 配置文件挂载 - prometheus_data:/prometheus # 数据持久化 ports: - 9090:9090 networks: - stable-yogi-net restart: unless-stopped grafana: image: grafana/grafana-enterprise:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning # 预配置仪表盘和数据源 ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请在生产环境修改 networks: - stable-yogi-net restart: unless-stopped nvidia-exporter: image: nvidia/dcgm-exporter:latest container_name: nvidia-exporter runtime: nvidia # 需要nvidia运行时 environment: - NVIDIA_VISIBLE_DEVICESall ports: - 9400:9400 networks: - stable-yogi-net restart: unless-stopped # ... 网络和卷定义 ...Prometheus的配置文件prometheus.yml需要配置抓取目标global: scrape_interval: 15s # 每15秒抓取一次数据 scrape_configs: - job_name: stable-yogi-api static_configs: - targets: [stable-yogi-api:7860] # 抓取API服务指标 - job_name: nvidia-gpu static_configs: - targets: [nvidia-exporter:9400] # 抓取GPU指标4.3 创建Grafana仪表盘启动服务后访问Grafanahttp://服务器IP:3000添加Prometheus作为数据源然后就可以创建仪表盘了。你可以创建几个关键面板API健康面板请求率、平均响应时间、错误率5xx状态码。GPU资源面板GPU利用率、显存使用量、温度。系统资源面板服务器CPU、内存、磁盘IO。当GPU显存使用率超过90%或API错误率飙升时一目了然。4.4 设置告警规则光有仪表盘还不够我们需要主动告警。在Prometheus的配置中或Grafana中定义告警规则。例如在Prometheus的规则文件中定义groups: - name: stable_yogi_alerts rules: - alert: HighGPUMemoryUsage expr: avg_over_time(nvidia_gpu_memory_used_bytes[5m]) / avg_over_time(nvidia_gpu_memory_total_bytes[5m]) * 100 90 for: 2m labels: severity: warning annotations: summary: GPU显存使用率过高 (实例 {{ $labels.instance }}) description: GPU {{ $labels.gpu }} 显存使用率持续2分钟高于90%当前值 {{ $value }}%。 - alert: HighAPIErrorRate expr: rate(http_requests_total{status~5..}[5m]) / rate(http_requests_total[5m]) * 100 5 for: 1m labels: severity: critical annotations: summary: API错误率过高 description: 过去5分钟内API错误率超过5%当前值 {{ $value }}%。告警可以通过Grafana集成邮件、Slack、钉钉、Webhook等方式通知到运维人员。5. 日志聚合与追踪监控指标告诉我们“哪里出了问题”而日志则告诉我们“发生了什么”。对于分布式容器环境我们需要一个中心化的地方来收集和查看所有容器的日志。可以将Docker容器的日志驱动配置为json-file或journald然后使用Fluentd、Logstash或Loki等日志收集器将日志统一发送到Elasticsearch或Grafana Loki中存储和索引。最后在Kibana或Grafana中实现统一的日志查询界面。这一步配置相对复杂但对于排查复杂问题至关重要。一个简单的起步方案是直接使用docker-compose logs -f service_name命令查看实时日志但对于生产环境集中式日志管理是必不可少的。6. 总结走完这一整套流程你会发现Stable Yogi模型服务从一个“脆弱的实验品”变成了一个“健壮的生产系统”。我们通过Docker Compose解决了环境一致性和服务编排问题通过CI/CD流水线实现了部署自动化通过PrometheusGrafana建立了全方位的监控和告警能力。这套实践的价值不在于用了多少时髦的工具而在于它形成了一套可重复、可验证、可观测的工程规范。它让模型的迭代和运维变得可控把运维人员从繁琐的日常救火中解放出来更专注于服务本身的优化和业务价值的挖掘。当然这只是企业级DevOps实践的冰山一角后续还可以考虑加入蓝绿部署、金丝雀发布来降低发布风险或者集成更复杂的链路追踪来分析请求性能瓶颈。但无论如何从0到1建立起这套基础框架已经能为你的大模型服务保驾护航让它真正稳定、可靠地跑起来。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Stable Yogi 模型DevOps实践：Linux环境下的持续集成与监控
Stable Yogi 模型DevOps实践Linux环境下的持续集成与监控最近和几个做AI应用落地的朋友聊天大家普遍有个头疼的问题模型好不容易训出来了效果也不错但一到生产环境就各种水土不服。服务动不动就挂GPU资源时高时低出了问题还得半夜爬起来查日志。这感觉就像造了一辆好车但没修好路也没配导航和维修站跑起来总是提心吊胆。其实这就是典型的“模型交付”与“工程运维”之间的断层。我们今天要聊的就是把Stable Yoji这类大模型像对待一个标准软件服务一样用DevOps的思路管起来。核心目标很简单让它能在Linux服务器上7x24小时稳定、可靠地跑着出了问题我们能第一时间知道甚至能自动恢复。这篇文章我就结合实际的工程经验聊聊怎么在Linux环境下为Stable Yogi模型搭建一套从部署、集成到监控的完整运维体系。我们会用到Docker Compose、CI/CD流水线、Prometheus、Grafana这些工具但重点不是工具本身而是它们如何串联起来解决我们实际遇到的那些运维痛点。1. 为什么大模型服务需要DevOps你可能觉得模型服务不就是启动一个Python脚本挂个API接口吗为什么搞得这么复杂这里面的区别就像个人项目和企业级应用的区别。个人玩玩服务挂了重启一下就行。但在生产环境尤其是对外提供服务的场景每一分钟宕机都可能意味着用户流失和直接的经济损失。Stable Yogi模型本身可能很稳定但它依赖的组件比如CUDA驱动、特定版本的Python包、它消耗的资源尤其是昂贵的GPU内存、以及它对外提供的API都可能成为故障点。DevOps的核心思想是“开发”和“运维”的协同与自动化。对于大模型服务这意味着环境一致性确保开发、测试、生产环境一模一样避免“在我机器上好好的”这种问题。自动化部署一键或自动将新版本的模型或代码部署上线减少人为失误。持续监控实时掌握服务的健康状态、资源消耗和性能指标而不是等用户投诉了才发现。快速反馈与恢复出现问题能快速定位、告警甚至自动执行恢复操作。接下来我们就从环境搭建开始一步步构建这套体系。2. 基础环境搭建用Docker Compose固化服务第一步我们要解决环境依赖的“幽灵”问题。最稳妥的方法就是使用Docker进行容器化封装。2.1 编写Dockerfile构建可复现的模型环境为Stable Yogi模型编写一个Dockerfile目的是将模型、代码及其所有依赖包括特定版本的PyTorch、CUDA库、系统工具等打包成一个独立的镜像。# 使用带有CUDA基础镜像确保GPU支持 FROM nvidia/cuda:12.1.1-runtime-ubuntu22.04 # 设置工作目录并安装系统依赖 WORKDIR /app RUN apt-get update apt-get install -y \ python3-pip \ python3-dev \ git \ rm -rf /var/lib/apt/lists/* # 复制模型代码和依赖声明文件 COPY requirements.txt . COPY stable_yogi_app ./stable_yogi_app # 安装Python依赖使用国内镜像加速 RUN pip3 install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt # 暴露API服务端口假设你的服务运行在7860端口类似Gradio EXPOSE 7860 # 定义容器启动命令 CMD [python3, stable_yogi_app/server.py]这个Dockerfile做了几件关键事固定了基础操作系统和CUDA版本明确了Python依赖并定义了服务的启动方式。构建出的镜像在任何支持Docker和NVIDIA Container Toolkit的Linux主机上运行行为都是一致的。2.2 使用Docker Compose编排多服务一个完整的模型服务可能不止一个应用。比如你可能还需要一个数据库来记录请求日志或者一个Redis来做缓存。Docker Compose可以轻松定义和管理多个关联的容器。创建一个docker-compose.yml文件version: 3.8 services: stable-yogi-api: build: . container_name: stable-yogi-service ports: - 7860:7860 # 将宿主机的7860端口映射到容器 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] # 声明需要GPU资源 volumes: - ./model_weights:/app/models # 将宿主机上的模型权重挂载进容器便于更新 - ./logs:/app/logs # 挂载日志目录 restart: unless-stopped # 设置自动重启策略 networks: - stable-yogi-net # 示例可以添加一个PostgreSQL容器用于存储数据 # postgres-db: # image: postgres:15 # environment: # POSTGRES_PASSWORD: example_password # volumes: # - postgres_data:/var/lib/postgresql/data # networks: # - stable-yogi-net networks: stable-yogi-net: driver: bridge # volumes: # postgres_data:现在只需要在服务器上执行一句linux常用命令大全里最让人安心的命令之一整个服务栈就能启动docker-compose up -d-d参数代表后台运行。要停止服务则用docker-compose down。这种编排方式使得服务的启停、重建变得极其简单和标准化。3. 自动化流水线CI/CD让部署像喝水一样简单环境固化了接下来就要解决部署流程的自动化。我们不想每次更新代码或模型都手动登录服务器去执行一堆命令。这里以 GitLab CI 为例展示如何构建一个简单的CI/CD流水线。在项目根目录创建.gitlab-ci.yml文件。stages: - test - build - deploy variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA # 使用提交哈希作为镜像标签 # 阶段1测试例如运行单元测试或API接口测试 run-tests: stage: test image: python:3.10 script: - pip install -r requirements.txt - pytest tests/ --tbshort # 假设你有测试用例 # 阶段2构建并推送Docker镜像到私有仓库 build-image: stage: build image: docker:latest services: - docker:dind # 使用Docker in Docker服务 script: - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE only: - main # 仅当推送到main分支时触发构建 # 阶段3部署到生产服务器 deploy-to-prod: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client # 安装ssh客户端 - eval $(ssh-agent -s) - echo $SSH_PRIVATE_KEY | ssh-add - # 加载预配置的SSH私钥 - mkdir -p ~/.ssh - chmod 700 ~/.ssh script: # 通过SSH连接到生产服务器执行部署脚本 - ssh -o StrictHostKeyCheckingno useryour-production-server.com cd /path/to/your/app ./deploy.sh $DOCKER_IMAGE only: - main needs: [build-image] # 依赖build阶段成功这个流水线定义了三个阶段测试、构建镜像、部署。当开发者向main分支推送代码时流水线自动触发。它会运行测试通过后构建一个新的Docker镜像并推送到仓库最后通过SSH连接到生产服务器执行一个部署脚本。生产服务器上的deploy.sh脚本可能长这样#!/bin/bash # deploy.sh NEW_IMAGE$1 echo 拉取最新镜像: $NEW_IMAGE docker pull $NEW_IMAGE echo 停止旧容器并启动新容器... cd /path/to/your/app docker-compose down docker-compose up -d echo 清理旧的Docker镜像... docker image prune -f这样一次代码提交就能自动完成从测试到上线的全过程实现了持续集成和持续部署。4. 监控与告警为模型服务装上“眼睛”和“耳朵”服务跑起来了也能源源不断地自动更新了。但我们怎么知道它是否健康GPU用满了怎么办API响应突然变慢了谁负责这就需要监控系统。我们采用经典的 Prometheus Grafana 组合。4.1 暴露模型服务指标首先需要在Stable Yogi的API服务中集成Prometheus客户端库如prometheus-flask-exporter用于Flask应用暴露一些关键指标比如请求次数、请求延迟、错误率等。同时对于GPU监控我们可以在服务器上安装nvidia_gpu_exporter它会将GPU的使用率、显存占用、温度等指标暴露给Prometheus。4.2 配置Prometheus抓取修改docker-compose.yml加入Prometheus和Grafana服务services: # ... 原有的 stable-yogi-api 服务 ... prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml # 配置文件挂载 - prometheus_data:/prometheus # 数据持久化 ports: - 9090:9090 networks: - stable-yogi-net restart: unless-stopped grafana: image: grafana/grafana-enterprise:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning # 预配置仪表盘和数据源 ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请在生产环境修改 networks: - stable-yogi-net restart: unless-stopped nvidia-exporter: image: nvidia/dcgm-exporter:latest container_name: nvidia-exporter runtime: nvidia # 需要nvidia运行时 environment: - NVIDIA_VISIBLE_DEVICESall ports: - 9400:9400 networks: - stable-yogi-net restart: unless-stopped # ... 网络和卷定义 ...Prometheus的配置文件prometheus.yml需要配置抓取目标global: scrape_interval: 15s # 每15秒抓取一次数据 scrape_configs: - job_name: stable-yogi-api static_configs: - targets: [stable-yogi-api:7860] # 抓取API服务指标 - job_name: nvidia-gpu static_configs: - targets: [nvidia-exporter:9400] # 抓取GPU指标4.3 创建Grafana仪表盘启动服务后访问Grafanahttp://服务器IP:3000添加Prometheus作为数据源然后就可以创建仪表盘了。你可以创建几个关键面板API健康面板请求率、平均响应时间、错误率5xx状态码。GPU资源面板GPU利用率、显存使用量、温度。系统资源面板服务器CPU、内存、磁盘IO。当GPU显存使用率超过90%或API错误率飙升时一目了然。4.4 设置告警规则光有仪表盘还不够我们需要主动告警。在Prometheus的配置中或Grafana中定义告警规则。例如在Prometheus的规则文件中定义groups: - name: stable_yogi_alerts rules: - alert: HighGPUMemoryUsage expr: avg_over_time(nvidia_gpu_memory_used_bytes[5m]) / avg_over_time(nvidia_gpu_memory_total_bytes[5m]) * 100 90 for: 2m labels: severity: warning annotations: summary: GPU显存使用率过高 (实例 {{ $labels.instance }}) description: GPU {{ $labels.gpu }} 显存使用率持续2分钟高于90%当前值 {{ $value }}%。 - alert: HighAPIErrorRate expr: rate(http_requests_total{status~5..}[5m]) / rate(http_requests_total[5m]) * 100 5 for: 1m labels: severity: critical annotations: summary: API错误率过高 description: 过去5分钟内API错误率超过5%当前值 {{ $value }}%。告警可以通过Grafana集成邮件、Slack、钉钉、Webhook等方式通知到运维人员。5. 日志聚合与追踪监控指标告诉我们“哪里出了问题”而日志则告诉我们“发生了什么”。对于分布式容器环境我们需要一个中心化的地方来收集和查看所有容器的日志。可以将Docker容器的日志驱动配置为json-file或journald然后使用Fluentd、Logstash或Loki等日志收集器将日志统一发送到Elasticsearch或Grafana Loki中存储和索引。最后在Kibana或Grafana中实现统一的日志查询界面。这一步配置相对复杂但对于排查复杂问题至关重要。一个简单的起步方案是直接使用docker-compose logs -f service_name命令查看实时日志但对于生产环境集中式日志管理是必不可少的。6. 总结走完这一整套流程你会发现Stable Yogi模型服务从一个“脆弱的实验品”变成了一个“健壮的生产系统”。我们通过Docker Compose解决了环境一致性和服务编排问题通过CI/CD流水线实现了部署自动化通过PrometheusGrafana建立了全方位的监控和告警能力。这套实践的价值不在于用了多少时髦的工具而在于它形成了一套可重复、可验证、可观测的工程规范。它让模型的迭代和运维变得可控把运维人员从繁琐的日常救火中解放出来更专注于服务本身的优化和业务价值的挖掘。当然这只是企业级DevOps实践的冰山一角后续还可以考虑加入蓝绿部署、金丝雀发布来降低发布风险或者集成更复杂的链路追踪来分析请求性能瓶颈。但无论如何从0到1建立起这套基础框架已经能为你的大模型服务保驾护航让它真正稳定、可靠地跑起来。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
