Z-Image-Turbo_Sugar脸部Lora运维实践使用Shell脚本监控GPU服务与自动化重启做AI图像生成的朋友尤其是用Z-Image-Turbo_Sugar脸部Lora这类模型做长时间渲染或者批量处理的估计都遇到过这么个头疼事服务跑着跑着突然就卡住了或者直接没了。你这边正等着出图呢那边服务已经悄无声息地挂了不仅耽误事儿还得手动去服务器上查日志、重启特别麻烦。这种问题在GPU服务上还挺常见的。模型推理本身消耗资源就大长时间运行下来显存泄漏、进程假死、或者API响应超时都有可能发生。靠人工盯着既不现实效率也低。今天我就来聊聊我们是怎么用最朴素的Shell脚本给这类AI服务加上一个“自动保姆”实现服务状态的监控、异常告警和自动重启让运维工作轻松不少。1. 为什么需要给AI服务加监控你可能觉得服务部署好了能跑起来不就行了但对于生产环境尤其是提供在线服务的场景“能跑”和“稳定地跑”完全是两码事。想象一下你搭建了一个基于Z-Image-Turbo_Sugar脸部Lora的在线换脸或者风格化工具。用户上传照片等着生成结果。如果后台服务因为显存占满而卡死用户的请求就会一直转圈最终超时失败。这不仅影响用户体验还可能让你损失用户。手动运维的痛点很明显反应滞后通常都是用户反馈了你才知道服务挂了。排查费时需要登录服务器查进程、看日志、分析显存一套流程下来几分钟过去了。无法预防无法在服务出现性能下降的苗头时就进行干预。所以一个自动化的监控重启机制核心目标就三个提前发现问题、快速自动恢复、解放人力。接下来我们就看看怎么用Shell脚本实现这个目标。2. 监控脚本的核心设计思路我们的脚本不会搞得很复杂就聚焦几个最关键的检查点确保服务是真的在“健康工作”而不仅仅是进程还在。2.1 监控什么—— 三大健康指标进程是否存在这是最基础的检查。如果连进程都没了那肯定出问题了。GPU显存是否健康很多AI服务挂掉不是因为进程消失而是因为显存被占满后新请求无法分配资源导致服务“假死”。监控显存使用率能提前发现隐患。API服务是否可响应进程在显存也够但服务接口可能因为内部错误已经不响应了。所以直接调用一个简单的健康检查接口比如/health或/看能否收到正常响应这是最终验证。2.2 怎么响应—— 分级处理策略检查到异常后脚本也不能蛮干我们设计一个简单的策略尝试重启服务首先尝试温和地重启服务进程。记录与告警无论重启成功与否都把时间、异常信息记录到日志文件里。如果重启失败或者同一时间段内异常发生太频繁就通过邮件、钉钉、企业微信等方式发送告警通知人工介入。避免重启风暴如果服务在短时间内频繁挂掉又重启可能是更深层次的问题比如模型文件损坏。脚本需要能判断这种情况避免陷入“重启-崩溃-再重启”的死循环。3. 手把手编写监控与重启Shell脚本下面我以一个典型的通过Python启动的Z-Image-Turbo_Sugar Lora服务为例展示脚本怎么写。假设你的服务启动命令是python app.py运行在GPU 0上服务端口是7860。我们创建一个脚本文件叫monitor_ai_service.sh。#!/bin/bash # # Z-Image-Turbo_Sugar Lora 服务监控与重启脚本 # 作者你的名字 # 功能检查进程、GPU显存、API健康异常时重启 # # ------------------ 配置区 ------------------ SERVICE_NAMEz_image_lora_service # 服务标识用于查找进程 SERVICE_CMDpython /path/to/your/app.py # 完整的服务启动命令 SERVICE_PORT7860 # 服务监听的端口 HEALTH_CHECK_URLhttp://localhost:${SERVICE_PORT}/ # 健康检查URL GPU_INDEX0 # 服务使用的GPU编号 GPU_MEMORY_THRESHOLD90 # GPU显存使用率告警阈值百分比 LOG_FILE/var/log/ai_service_monitor.log # 监控日志文件 MAX_RESTART_ATTEMPTS3 # 最大重启尝试次数防重启风暴 ATTEMPT_RESET_HOURS6 # 重置计数的时间窗口小时 # ------------------ 函数定义 ------------------ # 函数记录日志 log_message() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 $LOG_FILE } # 函数检查进程是否存在 check_process() { # 使用pgrep根据服务名查找进程更精确 if pgrep -f $SERVICE_NAME /dev/null; then echo running else echo stopped fi } # 函数检查GPU显存使用率 check_gpu_memory() { # 使用nvidia-smi获取指定GPU的显存信息 # 这里提取显存使用率。注意不同nvidia-smi版本输出格式可能略有不同。 local memory_info$(nvidia-smi --query-gpumemory.used,memory.total --formatcsv,noheader,nounits -i $GPU_INDEX) local used_mem$(echo $memory_info | cut -d, -f1) local total_mem$(echo $memory_info | cut -d, -f2) if [ -z $used_mem ] || [ -z $total_mem ]; then echo error return fi local usage_percent$(( used_mem * 100 / total_mem )) echo $usage_percent } # 函数检查API服务是否响应 check_api_health() { # 使用curl命令检查HTTP服务设置超时时间 if curl -s -f --max-time 10 $HEALTH_CHECK_URL /dev/null; then echo healthy else echo unhealthy fi } # 函数重启服务 restart_service() { log_message 尝试重启服务: $SERVICE_NAME # 1. 先尝试终止原有进程如果有 pkill -f $SERVICE_NAME sleep 5 # 等待进程完全终止 # 2. 启动服务 # 注意这里假设服务在前台运行。如果使用nohup或screen命令需调整。 # 例如nohup $SERVICE_CMD /dev/null 21 cd /path/to/your/project # 切换到项目目录 eval $SERVICE_CMD local new_pid$! sleep 15 # 等待服务启动完成 # 3. 检查新进程是否启动成功 if check_process | grep -q running; then log_message 服务重启成功新进程PID: $new_pid echo success else log_message 服务重启失败 echo failed fi } # 函数发送告警这里以日志记录代替实际可集成邮件、Webhook等 send_alert() { local alert_msg$1 log_message [告警] $alert_msg # 实际环境中你可以在这里调用发送邮件的命令或触发钉钉/企业微信机器人 # 例如curl -X POST 钉钉Webhook地址 -H Content-Type: application/json -d {\msgtype\:\text\,\text\:{\content\:\$alert_msg\}} } # ------------------ 主逻辑 ------------------ log_message 开始服务健康检查 # 初始化或读取重启计数 RESTART_COUNT_FILE/tmp/${SERVICE_NAME}_restart_count.txt if [ -f $RESTART_COUNT_FILE ]; then RESTART_COUNT$(cat $RESTART_COUNT_FILE) FILE_MTIME$(stat -c %Y $RESTART_COUNT_FILE) CURRENT_TIME$(date %s) HOURS_DIFF$(( (CURRENT_TIME - FILE_MTIME) / 3600 )) # 如果超过重置时间窗口则重置计数 if [ $HOURS_DIFF -ge $ATTEMPT_RESET_HOURS ]; then RESTART_COUNT0 echo $RESTART_COUNT $RESTART_COUNT_FILE fi else RESTART_COUNT0 echo $RESTART_COUNT $RESTART_COUNT_FILE fi # 检查1进程状态 PROCESS_STATUS$(check_process) if [ $PROCESS_STATUS stopped ]; then log_message 检查失败服务进程不存在。 PROBLEM_DETECTEDtrue else log_message 检查通过服务进程正在运行。 fi # 检查2GPU显存 GPU_MEMORY_USAGE$(check_gpu_memory) if [ $GPU_MEMORY_USAGE error ]; then log_message 检查失败无法获取GPU显存信息。 PROBLEM_DETECTEDtrue elif [ $GPU_MEMORY_USAGE -gt $GPU_MEMORY_THRESHOLD ]; then log_message 检查警告GPU显存使用率过高当前为 ${GPU_MEMORY_USAGE}%。 # 显存高不一定是致命错误但需要记录可作为预警 GPU_HIGHtrue else log_message 检查通过GPU显存使用率正常当前为 ${GPU_MEMORY_USAGE}%。 fi # 检查3API健康 API_STATUS$(check_api_health) if [ $API_STATUS unhealthy ]; then log_message 检查失败服务API无响应。 PROBLEM_DETECTEDtrue else log_message 检查通过服务API响应正常。 fi # ------------------ 决策与行动 ------------------ if [ $PROBLEM_DETECTED true ]; then log_message 检测到服务异常准备执行重启流程... # 检查重启次数是否超限 if [ $RESTART_COUNT -ge $MAX_RESTART_ATTEMPTS ]; then alert_msg服务 ${SERVICE_NAME} 在 ${ATTEMPT_RESET_HOURS} 小时内重启次数已达 ${MAX_RESTART_ATTEMPTS} 次可能存在严重问题请手动介入检查 send_alert $alert_msg log_message 重启次数超限已发送告警并停止自动重启。 exit 1 fi # 执行重启 RESTART_RESULT$(restart_service) if [ $RESTART_RESULT success ]; then # 重启成功计数加1 RESTART_COUNT$((RESTART_COUNT 1)) echo $RESTART_COUNT $RESTART_COUNT_FILE log_message 服务重启成功。当前重启计数$RESTART_COUNT # 如果是因为API无响应重启的可以再稍等片刻后做一次健康验证 sleep 30 if [ $(check_api_health) healthy ]; then log_message 重启后服务健康检查通过。 else log_message 警告重启后服务健康检查仍未通过。 fi else # 重启失败 alert_msg服务 ${SERVICE_NAME} 重启失败请立即手动处理 send_alert $alert_msg log_message 重启失败已发送告警。 exit 2 fi elif [ $GPU_HIGH true ]; then # 仅显存高但进程和API都正常可以只发预警不重启 alert_msg服务 ${SERVICE_NAME} GPU显存使用率偏高${GPU_MEMORY_USAGE}%请关注。 send_alert $alert_msg log_message GPU显存偏高预警已发送。 else log_message 所有检查通过服务状态健康。 fi log_message 服务健康检查结束 \n4. 让脚本自动跑起来Crontab定时任务脚本写好了总不能每次都手动执行吧我们需要让它定时自动运行比如每分钟检查一次。使用Linux系统的crontab来配置定时任务非常方便。首先给脚本加上可执行权限chmod x /path/to/your/monitor_ai_service.sh编辑当前用户的crontabcrontab -e在打开的编辑器中添加一行配置。下面的例子是每分钟执行一次* * * * * /bin/bash /path/to/your/monitor_ai_service.sh如果你想每5分钟检查一次可以写成*/5 * * * * ...如果想将脚本的输出包括日志也重定向可以* * * * * /bin/bash /path/to/your/monitor_ai_service.sh /var/log/cron_monitor.log 21这样监控脚本就会在后台默默工作定时检查你的AI服务状态了。5. 脚本的优化与扩展建议上面的脚本是一个基础版本在实际生产中你还可以根据需求进行增强更详细的日志除了记录时间还可以记录具体的异常信息、重启前后的GPU状态对比等。分级告警区分“警告”如显存偏高和“严重”如进程消失、重启失败并发送到不同的通知渠道。依赖检查在重启前检查必要的环境如Python环境、模型文件是否存在。与监控系统集成将检查结果如API响应时间、GPU使用率输出为Prometheus等监控系统可以抓取的格式方便在Grafana等看板上可视化。服务优雅终止在pkill之前可以先尝试向服务进程发送SIGTERM信号让它有机会完成当前任务再退出。6. 总结给Z-Image-Turbo_Sugar脸部Lora这类AI服务加上一个简单的Shell监控脚本就像是请了一个不知疲倦的运维助理。它成本极低几乎为零但带来的稳定性提升和人力解放效果是立竿见影的。核心逻辑就是“检查-决策-行动”把我们从重复的、被动的故障处理中解脱出来让我们能更专注于模型效果和业务逻辑本身。这套方法不仅适用于这个特定的Lora模型任何通过命令行启动的、需要长期运行的AI服务比如Stable Diffusion WebUI、各种AI API后端都可以借鉴。你可以根据自己服务的启动方式、健康检查接口调整脚本中的几个关键函数。一开始不用追求大而全的监控平台从这样一个切实可用的小脚本开始就能解决大问题。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Z-Image-Turbo_Sugar脸部Lora运维实践：使用Shell脚本监控GPU服务与自动化重启
Z-Image-Turbo_Sugar脸部Lora运维实践使用Shell脚本监控GPU服务与自动化重启做AI图像生成的朋友尤其是用Z-Image-Turbo_Sugar脸部Lora这类模型做长时间渲染或者批量处理的估计都遇到过这么个头疼事服务跑着跑着突然就卡住了或者直接没了。你这边正等着出图呢那边服务已经悄无声息地挂了不仅耽误事儿还得手动去服务器上查日志、重启特别麻烦。这种问题在GPU服务上还挺常见的。模型推理本身消耗资源就大长时间运行下来显存泄漏、进程假死、或者API响应超时都有可能发生。靠人工盯着既不现实效率也低。今天我就来聊聊我们是怎么用最朴素的Shell脚本给这类AI服务加上一个“自动保姆”实现服务状态的监控、异常告警和自动重启让运维工作轻松不少。1. 为什么需要给AI服务加监控你可能觉得服务部署好了能跑起来不就行了但对于生产环境尤其是提供在线服务的场景“能跑”和“稳定地跑”完全是两码事。想象一下你搭建了一个基于Z-Image-Turbo_Sugar脸部Lora的在线换脸或者风格化工具。用户上传照片等着生成结果。如果后台服务因为显存占满而卡死用户的请求就会一直转圈最终超时失败。这不仅影响用户体验还可能让你损失用户。手动运维的痛点很明显反应滞后通常都是用户反馈了你才知道服务挂了。排查费时需要登录服务器查进程、看日志、分析显存一套流程下来几分钟过去了。无法预防无法在服务出现性能下降的苗头时就进行干预。所以一个自动化的监控重启机制核心目标就三个提前发现问题、快速自动恢复、解放人力。接下来我们就看看怎么用Shell脚本实现这个目标。2. 监控脚本的核心设计思路我们的脚本不会搞得很复杂就聚焦几个最关键的检查点确保服务是真的在“健康工作”而不仅仅是进程还在。2.1 监控什么—— 三大健康指标进程是否存在这是最基础的检查。如果连进程都没了那肯定出问题了。GPU显存是否健康很多AI服务挂掉不是因为进程消失而是因为显存被占满后新请求无法分配资源导致服务“假死”。监控显存使用率能提前发现隐患。API服务是否可响应进程在显存也够但服务接口可能因为内部错误已经不响应了。所以直接调用一个简单的健康检查接口比如/health或/看能否收到正常响应这是最终验证。2.2 怎么响应—— 分级处理策略检查到异常后脚本也不能蛮干我们设计一个简单的策略尝试重启服务首先尝试温和地重启服务进程。记录与告警无论重启成功与否都把时间、异常信息记录到日志文件里。如果重启失败或者同一时间段内异常发生太频繁就通过邮件、钉钉、企业微信等方式发送告警通知人工介入。避免重启风暴如果服务在短时间内频繁挂掉又重启可能是更深层次的问题比如模型文件损坏。脚本需要能判断这种情况避免陷入“重启-崩溃-再重启”的死循环。3. 手把手编写监控与重启Shell脚本下面我以一个典型的通过Python启动的Z-Image-Turbo_Sugar Lora服务为例展示脚本怎么写。假设你的服务启动命令是python app.py运行在GPU 0上服务端口是7860。我们创建一个脚本文件叫monitor_ai_service.sh。#!/bin/bash # # Z-Image-Turbo_Sugar Lora 服务监控与重启脚本 # 作者你的名字 # 功能检查进程、GPU显存、API健康异常时重启 # # ------------------ 配置区 ------------------ SERVICE_NAMEz_image_lora_service # 服务标识用于查找进程 SERVICE_CMDpython /path/to/your/app.py # 完整的服务启动命令 SERVICE_PORT7860 # 服务监听的端口 HEALTH_CHECK_URLhttp://localhost:${SERVICE_PORT}/ # 健康检查URL GPU_INDEX0 # 服务使用的GPU编号 GPU_MEMORY_THRESHOLD90 # GPU显存使用率告警阈值百分比 LOG_FILE/var/log/ai_service_monitor.log # 监控日志文件 MAX_RESTART_ATTEMPTS3 # 最大重启尝试次数防重启风暴 ATTEMPT_RESET_HOURS6 # 重置计数的时间窗口小时 # ------------------ 函数定义 ------------------ # 函数记录日志 log_message() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 $LOG_FILE } # 函数检查进程是否存在 check_process() { # 使用pgrep根据服务名查找进程更精确 if pgrep -f $SERVICE_NAME /dev/null; then echo running else echo stopped fi } # 函数检查GPU显存使用率 check_gpu_memory() { # 使用nvidia-smi获取指定GPU的显存信息 # 这里提取显存使用率。注意不同nvidia-smi版本输出格式可能略有不同。 local memory_info$(nvidia-smi --query-gpumemory.used,memory.total --formatcsv,noheader,nounits -i $GPU_INDEX) local used_mem$(echo $memory_info | cut -d, -f1) local total_mem$(echo $memory_info | cut -d, -f2) if [ -z $used_mem ] || [ -z $total_mem ]; then echo error return fi local usage_percent$(( used_mem * 100 / total_mem )) echo $usage_percent } # 函数检查API服务是否响应 check_api_health() { # 使用curl命令检查HTTP服务设置超时时间 if curl -s -f --max-time 10 $HEALTH_CHECK_URL /dev/null; then echo healthy else echo unhealthy fi } # 函数重启服务 restart_service() { log_message 尝试重启服务: $SERVICE_NAME # 1. 先尝试终止原有进程如果有 pkill -f $SERVICE_NAME sleep 5 # 等待进程完全终止 # 2. 启动服务 # 注意这里假设服务在前台运行。如果使用nohup或screen命令需调整。 # 例如nohup $SERVICE_CMD /dev/null 21 cd /path/to/your/project # 切换到项目目录 eval $SERVICE_CMD local new_pid$! sleep 15 # 等待服务启动完成 # 3. 检查新进程是否启动成功 if check_process | grep -q running; then log_message 服务重启成功新进程PID: $new_pid echo success else log_message 服务重启失败 echo failed fi } # 函数发送告警这里以日志记录代替实际可集成邮件、Webhook等 send_alert() { local alert_msg$1 log_message [告警] $alert_msg # 实际环境中你可以在这里调用发送邮件的命令或触发钉钉/企业微信机器人 # 例如curl -X POST 钉钉Webhook地址 -H Content-Type: application/json -d {\msgtype\:\text\,\text\:{\content\:\$alert_msg\}} } # ------------------ 主逻辑 ------------------ log_message 开始服务健康检查 # 初始化或读取重启计数 RESTART_COUNT_FILE/tmp/${SERVICE_NAME}_restart_count.txt if [ -f $RESTART_COUNT_FILE ]; then RESTART_COUNT$(cat $RESTART_COUNT_FILE) FILE_MTIME$(stat -c %Y $RESTART_COUNT_FILE) CURRENT_TIME$(date %s) HOURS_DIFF$(( (CURRENT_TIME - FILE_MTIME) / 3600 )) # 如果超过重置时间窗口则重置计数 if [ $HOURS_DIFF -ge $ATTEMPT_RESET_HOURS ]; then RESTART_COUNT0 echo $RESTART_COUNT $RESTART_COUNT_FILE fi else RESTART_COUNT0 echo $RESTART_COUNT $RESTART_COUNT_FILE fi # 检查1进程状态 PROCESS_STATUS$(check_process) if [ $PROCESS_STATUS stopped ]; then log_message 检查失败服务进程不存在。 PROBLEM_DETECTEDtrue else log_message 检查通过服务进程正在运行。 fi # 检查2GPU显存 GPU_MEMORY_USAGE$(check_gpu_memory) if [ $GPU_MEMORY_USAGE error ]; then log_message 检查失败无法获取GPU显存信息。 PROBLEM_DETECTEDtrue elif [ $GPU_MEMORY_USAGE -gt $GPU_MEMORY_THRESHOLD ]; then log_message 检查警告GPU显存使用率过高当前为 ${GPU_MEMORY_USAGE}%。 # 显存高不一定是致命错误但需要记录可作为预警 GPU_HIGHtrue else log_message 检查通过GPU显存使用率正常当前为 ${GPU_MEMORY_USAGE}%。 fi # 检查3API健康 API_STATUS$(check_api_health) if [ $API_STATUS unhealthy ]; then log_message 检查失败服务API无响应。 PROBLEM_DETECTEDtrue else log_message 检查通过服务API响应正常。 fi # ------------------ 决策与行动 ------------------ if [ $PROBLEM_DETECTED true ]; then log_message 检测到服务异常准备执行重启流程... # 检查重启次数是否超限 if [ $RESTART_COUNT -ge $MAX_RESTART_ATTEMPTS ]; then alert_msg服务 ${SERVICE_NAME} 在 ${ATTEMPT_RESET_HOURS} 小时内重启次数已达 ${MAX_RESTART_ATTEMPTS} 次可能存在严重问题请手动介入检查 send_alert $alert_msg log_message 重启次数超限已发送告警并停止自动重启。 exit 1 fi # 执行重启 RESTART_RESULT$(restart_service) if [ $RESTART_RESULT success ]; then # 重启成功计数加1 RESTART_COUNT$((RESTART_COUNT 1)) echo $RESTART_COUNT $RESTART_COUNT_FILE log_message 服务重启成功。当前重启计数$RESTART_COUNT # 如果是因为API无响应重启的可以再稍等片刻后做一次健康验证 sleep 30 if [ $(check_api_health) healthy ]; then log_message 重启后服务健康检查通过。 else log_message 警告重启后服务健康检查仍未通过。 fi else # 重启失败 alert_msg服务 ${SERVICE_NAME} 重启失败请立即手动处理 send_alert $alert_msg log_message 重启失败已发送告警。 exit 2 fi elif [ $GPU_HIGH true ]; then # 仅显存高但进程和API都正常可以只发预警不重启 alert_msg服务 ${SERVICE_NAME} GPU显存使用率偏高${GPU_MEMORY_USAGE}%请关注。 send_alert $alert_msg log_message GPU显存偏高预警已发送。 else log_message 所有检查通过服务状态健康。 fi log_message 服务健康检查结束 \n4. 让脚本自动跑起来Crontab定时任务脚本写好了总不能每次都手动执行吧我们需要让它定时自动运行比如每分钟检查一次。使用Linux系统的crontab来配置定时任务非常方便。首先给脚本加上可执行权限chmod x /path/to/your/monitor_ai_service.sh编辑当前用户的crontabcrontab -e在打开的编辑器中添加一行配置。下面的例子是每分钟执行一次* * * * * /bin/bash /path/to/your/monitor_ai_service.sh如果你想每5分钟检查一次可以写成*/5 * * * * ...如果想将脚本的输出包括日志也重定向可以* * * * * /bin/bash /path/to/your/monitor_ai_service.sh /var/log/cron_monitor.log 21这样监控脚本就会在后台默默工作定时检查你的AI服务状态了。5. 脚本的优化与扩展建议上面的脚本是一个基础版本在实际生产中你还可以根据需求进行增强更详细的日志除了记录时间还可以记录具体的异常信息、重启前后的GPU状态对比等。分级告警区分“警告”如显存偏高和“严重”如进程消失、重启失败并发送到不同的通知渠道。依赖检查在重启前检查必要的环境如Python环境、模型文件是否存在。与监控系统集成将检查结果如API响应时间、GPU使用率输出为Prometheus等监控系统可以抓取的格式方便在Grafana等看板上可视化。服务优雅终止在pkill之前可以先尝试向服务进程发送SIGTERM信号让它有机会完成当前任务再退出。6. 总结给Z-Image-Turbo_Sugar脸部Lora这类AI服务加上一个简单的Shell监控脚本就像是请了一个不知疲倦的运维助理。它成本极低几乎为零但带来的稳定性提升和人力解放效果是立竿见影的。核心逻辑就是“检查-决策-行动”把我们从重复的、被动的故障处理中解脱出来让我们能更专注于模型效果和业务逻辑本身。这套方法不仅适用于这个特定的Lora模型任何通过命令行启动的、需要长期运行的AI服务比如Stable Diffusion WebUI、各种AI API后端都可以借鉴。你可以根据自己服务的启动方式、健康检查接口调整脚本中的几个关键函数。一开始不用追求大而全的监控平台从这样一个切实可用的小脚本开始就能解决大问题。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
