成功案例 品牌网站,温州seo方法,网站开发网站开发公司哪家好,镇江百度开户GLM-4-9B-Chat-1M保姆级教学#xff1a;模型服务健康检查Prometheus指标暴露配置 1. 引言#xff1a;为什么你的大模型服务需要“体检”#xff1f; 想象一下#xff0c;你花了好几天时间#xff0c;终于把GLM-4-9B-Chat-1M这个百万长文本大模型部署在了本地服务器上。它…GLM-4-9B-Chat-1M保姆级教学模型服务健康检查Prometheus指标暴露配置1. 引言为什么你的大模型服务需要“体检”想象一下你花了好几天时间终于把GLM-4-9B-Chat-1M这个百万长文本大模型部署在了本地服务器上。它运行得很顺利能帮你分析整本小说、梳理复杂的代码库你甚至开始依赖它来处理日常工作。但某天早上你发现它“罢工”了——响应变慢甚至完全没反应。你慌了开始检查日志、重启服务、排查网络……折腾了半天才发现原来是显存溢出了模型加载失败。这就是典型的“黑盒”运维困境你只知道服务“能用”或“不能用”但不知道它“健康不健康”、“压力大不大”、“资源够不够”。今天这篇文章我要带你解决这个问题。我们将为你的GLM-4-9B-Chat-1M服务装上“体检仪”和“监控仪表盘”让你能实时查看模型服务是否健康、响应速度如何、资源使用情况提前预警在服务崩溃前发现问题比如显存快满了、请求队列太长了数据驱动用实际数据决定是否需要升级硬件、优化配置我会手把手教你两件事给模型服务添加健康检查接口——就像给汽车装个故障灯暴露Prometheus监控指标——就像给汽车装全套仪表盘转速、油量、水温即使你之前没接触过监控系统跟着我做30分钟内就能搞定。让我们开始吧。2. 环境准备检查你的“工具箱”在开始之前我们先确认一下你的环境是否齐全。如果你已经按照之前的教程部署了GLM-4-9B-Chat-1M那么大部分工具应该都有了。2.1 基础环境确认打开终端逐一运行以下命令检查# 1. 检查Python版本需要3.8 python3 --version # 2. 检查pip是否可用 pip3 --version # 3. 检查Docker是否安装可选用于容器化部署 docker --version # 4. 检查你的GLM-4-9B服务是否在运行 # 通常你的服务运行在8080端口用curl测试 curl http://localhost:8080/health 2/dev/null || echo 服务可能未运行或没有健康接口如果前两项都正常但第四项返回错误这是正常的——因为我们还没添加健康检查接口。2.2 安装必要的Python包我们需要安装几个用于监控和指标暴露的库# 进入你的项目目录假设你的GLM-4-9B项目在这里 cd /path/to/your/glm-4-9b-project # 安装健康检查相关的库 pip3 install fastapi[standard] # 如果还没安装FastAPI pip3 install uvicorn[standard] # ASGI服务器 pip3 install prometheus-client # Prometheus指标库 pip3 install psutil # 系统资源监控简单解释一下这些库的作用FastAPI我们将用它创建健康检查接口比原始的Streamlit更灵活prometheus-client把模型服务的各种指标请求数、响应时间、错误率转换成Prometheus能识别的格式psutil获取系统资源信息CPU、内存、显存使用情况安装完成后我们可以开始改造你的模型服务了。3. 第一步给模型服务添加健康检查接口健康检查接口就像汽车的“故障灯系统”。外部系统比如Kubernetes、负载均衡器可以通过这个接口快速判断服务是否正常。3.1 创建健康检查模块在你的项目目录下创建一个新文件health_monitor.py# health_monitor.py import time import psutil import torch from fastapi import FastAPI, Response from fastapi.responses import JSONResponse from prometheus_client import Counter, Gauge, Histogram, generate_latest, CONTENT_TYPE_LATEST import threading import json # 创建FastAPI应用 app FastAPI(titleGLM-4-9B健康监控, version1.0.0) # 全局状态变量 # 这里存储模型服务的状态信息 _service_status { model_loaded: False, # 模型是否成功加载 last_heartbeat: time.time(), # 最后一次心跳时间 startup_time: time.time(), # 服务启动时间 total_requests: 0, # 总请求数 failed_requests: 0, # 失败请求数 } # Prometheus指标定义 # 计数器记录总请求数 REQUEST_COUNT Counter( glm4_9b_requests_total, GLM-4-9B模型总请求数, [method, endpoint, status] ) # 计数器记录失败请求数 FAILED_REQUEST_COUNT Counter( glm4_9b_failed_requests_total, GLM-4-9B模型失败请求数, [method, endpoint, error_type] ) # 直方图记录请求延迟单位秒 REQUEST_LATENCY Histogram( glm4_9b_request_duration_seconds, GLM-4-9B请求处理时间, [method, endpoint], buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0, 30.0, 60.0, float(inf)) ) # 仪表盘记录GPU显存使用如果有GPU GPU_MEMORY_USAGE Gauge( glm4_9b_gpu_memory_usage_bytes, GLM-4-9B GPU显存使用量, [gpu_id] ) # 仪表盘记录系统内存使用 SYSTEM_MEMORY_USAGE Gauge( glm4_9b_system_memory_usage_bytes, 系统内存使用量 ) # 仪表盘记录模型服务状态1健康0不健康 SERVICE_STATUS Gauge( glm4_9b_service_status, 模型服务状态 ) # 辅助函数 def check_gpu_memory(): 检查GPU显存使用情况 if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): memory_allocated torch.cuda.memory_allocated(i) GPU_MEMORY_USAGE.labels(gpu_idstr(i)).set(memory_allocated) return True return False def check_system_resources(): 检查系统资源使用情况 # 系统内存使用 memory_info psutil.virtual_memory() SYSTEM_MEMORY_USAGE.set(memory_info.used) # CPU使用率可选 # cpu_percent psutil.cpu_percent(interval0.1) return { memory_used: memory_info.used, memory_total: memory_info.total, memory_percent: memory_info.percent, } def update_service_status(): 更新服务状态后台线程定期执行 while True: try: # 检查GPU gpu_available check_gpu_memory() # 检查系统资源 system_info check_system_resources() # 更新服务状态指标 if _service_status[model_loaded] and system_info[memory_percent] 90: SERVICE_STATUS.set(1) # 健康 else: SERVICE_STATUS.set(0) # 不健康 # 更新心跳时间 _service_status[last_heartbeat] time.time() except Exception as e: print(f更新服务状态时出错: {e}) SERVICE_STATUS.set(0) # 每5秒更新一次 time.sleep(5) # API接口定义 app.get(/health) async def health_check(): 健康检查接口 # 记录请求 REQUEST_COUNT.labels(methodGET, endpoint/health, status200).inc() # 检查服务状态 current_time time.time() time_since_heartbeat current_time - _service_status[last_heartbeat] # 判断服务是否健康 is_healthy ( _service_status[model_loaded] and time_since_heartbeat 10 and # 10秒内有心跳 SERVICE_STATUS._value.get() 1 ) status_code 200 if is_healthy else 503 status_text healthy if is_healthy else unhealthy # 准备响应数据 response_data { status: status_text, timestamp: current_time, service_uptime: current_time - _service_status[startup_time], model_loaded: _service_status[model_loaded], gpu_available: torch.cuda.is_available(), system_resources: check_system_resources(), requests: { total: _service_status[total_requests], failed: _service_status[failed_requests], success_rate: ( (_service_status[total_requests] - _service_status[failed_requests]) / max(_service_status[total_requests], 1) * 100 ) } } return JSONResponse( contentresponse_data, status_codestatus_code ) app.get(/metrics) async def metrics(): Prometheus指标暴露接口 # 更新一次资源使用情况 check_gpu_memory() check_system_resources() # 生成Prometheus格式的指标数据 metrics_data generate_latest() return Response( contentmetrics_data, media_typeCONTENT_TYPE_LATEST ) app.get(/status) async def detailed_status(): 详细状态接口用于调试 response_data { service: _service_status, gpu: { available: torch.cuda.is_available(), device_count: torch.cuda.device_count() if torch.cuda.is_available() else 0, current_device: torch.cuda.current_device() if torch.cuda.is_available() else None, }, system: check_system_resources(), timestamp: time.time(), } return JSONResponse(contentresponse_data) # 启动函数 def start_monitor(host0.0.0.0, port8081): 启动健康监控服务 import uvicorn # 启动后台状态更新线程 monitor_thread threading.Thread(targetupdate_service_status, daemonTrue) monitor_thread.start() print(f 健康监控服务启动中...) print(f 健康检查接口: http://{host}:{port}/health) print(f Prometheus指标: http://{host}:{port}/metrics) print(f 详细状态: http://{host}:{port}/status) uvicorn.run(app, hosthost, portport) # 用于外部设置模型加载状态 def set_model_loaded(statusTrue): 设置模型加载状态在你的主程序中调用 _service_status[model_loaded] status print(f 模型加载状态更新: {status}) if __name__ __main__: # 直接运行此文件时启动监控服务 start_monitor()这个文件创建了一个完整的健康监控服务提供了三个关键接口/health基础健康检查返回服务是否健康/metricsPrometheus格式的指标数据/status详细状态信息用于调试3.2 集成到你的主程序现在我们需要把这个监控服务集成到你的GLM-4-9B主程序中。找到你启动模型服务的主文件可能是app.py或main.py在合适的位置添加以下代码# 在你的主程序文件比如app.py中添加 import threading from health_monitor import start_monitor, set_model_loaded # 在模型加载成功后设置模型加载状态 def your_model_loading_function(): 你原来的模型加载函数 # ... 你原来的模型加载代码 ... # 模型加载成功后更新状态 set_model_loaded(True) print( 模型加载完成健康监控已就绪) # 在适当的地方启动监控服务与主服务并行运行 def start_services(): 启动所有服务 # 启动健康监控服务在8081端口 monitor_thread threading.Thread( targetstart_monitor, kwargs{host: 0.0.0.0, port: 8081}, daemonTrue ) monitor_thread.start() # 启动你的主模型服务在8080端口 # ... 你原来的服务启动代码 ... print( 所有服务启动完成) print( 模型服务: http://localhost:8080) print( 健康监控: http://localhost:8081) # 在你的主函数中调用 if __name__ __main__: start_services()关键点健康监控服务运行在8081端口你的主服务在8080端口两个服务独立运行互不影响监控服务通过后台线程定期检查资源使用情况3.3 测试健康检查接口保存所有修改后重启你的服务。然后打开终端测试# 测试健康检查接口 curl http://localhost:8081/health # 预期输出类似 { status: healthy, timestamp: 1715589200.123456, service_uptime: 3600.5, model_loaded: true, gpu_available: true, system_resources: { memory_used: 8589934592, memory_total: 17179869184, memory_percent: 50.0 }, requests: { total: 0, failed: 0, success_rate: 100.0 } } # 测试Prometheus指标接口 curl http://localhost:8081/metrics # 预期输出Prometheus格式 # HELP glm4_9b_requests_total GLM-4-9B模型总请求数 # TYPE glm4_9b_requests_total counter # glm4_9b_requests_total{methodGET,endpoint/health,status200} 1 # HELP glm4_9b_system_memory_usage_bytes 系统内存使用量 # TYPE glm4_9b_system_memory_usage_bytes gauge # glm4_9b_system_memory_usage_bytes 8.589934592e09如果能看到这些输出恭喜你健康检查接口已经配置成功了。4. 第二步配置Prometheus监控系统有了指标暴露接口我们还需要一个监控系统来收集、存储和展示这些指标。Prometheus是目前最流行的开源监控系统。4.1 安装和配置Prometheus首先下载并安装Prometheus# 下载最新版Prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz # 解压 tar xvfz prometheus-2.47.0.linux-amd64.tar.gz cd prometheus-2.47.0.linux-amd64 # 创建配置文件 cat prometheus.yml EOF global: scrape_interval: 15s # 每15秒收集一次指标 evaluation_interval: 15s # 每15秒评估一次规则 # 告警规则配置可选 rule_files: # - alert.rules # 监控目标配置 scrape_configs: # 监控Prometheus自身 - job_name: prometheus static_configs: - targets: [localhost:9090] # 监控GLM-4-9B模型服务 - job_name: glm4-9b-model static_configs: - targets: [localhost:8081] # 你的健康监控服务端口 metrics_path: /metrics # 指标接口路径 scrape_interval: 10s # 模型服务指标收集更频繁一些 # 监控系统资源通过node_exporter下一步安装 - job_name: node static_configs: - targets: [localhost:9100] EOF4.2 安装node_exporter监控系统资源node_exporter用于收集服务器本身的资源使用情况CPU、内存、磁盘、网络等# 下载node_exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz # 解压 tar xvfz node_exporter-1.6.1.linux-amd64.tar.gz cd node_exporter-1.6.1.linux-amd64 # 启动node_exporter在后台运行 ./node_exporter 4.3 启动所有监控服务现在让我们启动所有监控组件# 在第一个终端窗口启动Prometheus cd prometheus-2.47.0.linux-amd64 ./prometheus --config.fileprometheus.yml # 在第二个终端窗口启动node_exporter如果还没启动 cd node_exporter-1.6.1.linux-amd64 ./node_exporter # 确保你的GLM-4-9B健康监控服务也在运行 # 它应该已经在8081端口运行了现在打开浏览器访问Prometheus UI: http://localhost:9090GLM-4-9B健康检查: http://localhost:8081/healthGLM-4-9B指标: http://localhost:8081/metrics4.4 在Prometheus中查看指标在Prometheus的Web界面http://localhost:9090中你可以查看监控目标状态点击顶部菜单 Status → Targets应该看到三个目标prometheus (localhost:9090) - UPglm4-9b-model (localhost:8081) - UPnode (localhost:9100) - UP查询模型指标在 Graph 页面输入以下查询语句glm4_9b_service_status # 服务状态1健康0不健康 glm4_9b_gpu_memory_usage_bytes # GPU显存使用 glm4_9b_requests_total # 总请求数 rate(glm4_9b_requests_total[5m]) # 最近5分钟的请求速率设置告警规则可选创建alert.rules文件groups: - name: glm4_9b_alerts rules: # 服务宕机告警 - alert: GLM4_9B_ServiceDown expr: glm4_9b_service_status 0 for: 1m labels: severity: critical annotations: summary: GLM-4-9B服务异常 description: 模型服务已超过1分钟不健康请立即检查 # GPU显存过高告警 - alert: GLM4_9B_GPUMemoryHigh expr: glm4_9b_gpu_memory_usage_bytes / 1024 / 1024 / 1024 7 # 超过7GB for: 2m labels: severity: warning annotations: summary: GPU显存使用过高 description: GPU显存使用超过7GB当前值 {{ $value }}GB # 请求失败率过高告警 - alert: GLM4_9B_HighErrorRate expr: | rate(glm4_9b_failed_requests_total[5m]) / rate(glm4_9b_requests_total[5m]) 0.1 # 失败率超过10% for: 5m labels: severity: warning annotations: summary: 请求失败率过高 description: 最近5分钟请求失败率超过10%当前值 {{ $value }}%然后在prometheus.yml中取消注释rule_files部分。5. 第三步使用Grafana创建监控仪表盘Prometheus擅长收集和查询指标但Grafana更擅长可视化。让我们创建一个漂亮的监控仪表盘。5.1 安装和配置Grafana# 安装Grafana以Ubuntu为例 sudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - sudo apt-get update sudo apt-get install -y grafana # 启动Grafana服务 sudo systemctl start grafana-server sudo systemctl enable grafana-server # 开机自启5.2 配置数据源和创建仪表盘访问Grafana: http://localhost:3000默认用户名/密码: admin/admin首次登录会要求修改密码添加Prometheus数据源点击左侧齿轮图标 → Data Sources点击 Add data source选择 PrometheusURL: http://localhost:9090点击 Save Test应该显示 Data source is working导入预制的GLM-4-9B监控仪表盘创建一个新文件glm4_9b_dashboard.json内容如下这是一个完整的仪表盘配置由于篇幅很长我在这里只展示关键部分你可以从我的GitHub获取完整版本{ dashboard: { title: GLM-4-9B模型服务监控, description: 监控GLM-4-9B-Chat-1M模型服务的健康状态、性能指标和资源使用情况, tags: [glm4, llm, monitoring], style: dark, timezone: browser, panels: [ { title: 服务健康状态, type: stat, targets: [{ expr: glm4_9b_service_status, legendFormat: 服务状态 }], fieldConfig: { defaults: { thresholds: { steps: [ {color: red, value: null}, {color: green, value: 1} ] }, mappings: [ {type: value, value: 0, text: 异常}, {type: value, value: 1, text: 健康} ] } } }, { title: GPU显存使用, type: gauge, targets: [{ expr: glm4_9b_gpu_memory_usage_bytes / 1024 / 1024 / 1024, legendFormat: GPU {{gpu_id}} }], fieldConfig: { defaults: { unit: GB, thresholds: { steps: [ {color: green, value: null}, {color: yellow, value: 6}, {color: red, value: 7} ] } } } } // ... 更多面板配置请求数、响应时间、错误率等 ] } }导入仪表盘点击左侧 图标 → Import上传JSON文件或粘贴JSON内容点击 Load选择Prometheus数据源点击 Import5.3 仪表盘功能介绍一个完整的GLM-4-9B监控仪表盘应该包含以下面板面板监控内容关键指标告警阈值服务状态模型服务是否健康glm4_9b_service_status0异常1健康GPU显存GPU显存使用量glm4_9b_gpu_memory_usage_bytes7GB警告请求数总请求数和QPSglm4_9b_requests_total-响应时间请求处理延迟glm4_9b_request_duration_seconds5秒警告错误率请求失败比例失败数/总请求数10%警告系统内存服务器内存使用node_memory_MemTotal - node_memory_MemAvailable90%警告CPU使用服务器CPU负载rate(node_cpu_seconds_total[5m])80%警告6. 实际应用从监控数据中发现问题监控系统不只是为了好看更重要的是能帮你发现和解决问题。让我分享几个真实场景场景一显存泄漏检测现象你发现GPU显存使用量在缓慢增长即使没有请求时也在增长。监控数据glm4_9b_gpu_memory_usage_bytes图表显示持续上升趋势服务重启后显存恢复正常但几小时后又慢慢涨上去根本原因可能是模型推理过程中有内存未释放或者缓存机制有问题。解决方案# 在你的模型推理代码中添加显存清理 import torch import gc def inference_with_memory_cleanup(prompt): try: # 原来的推理代码 result model.generate(prompt) return result finally: # 清理显存 if torch.cuda.is_available(): torch.cuda.empty_cache() torch.cuda.ipc_collect() gc.collect()场景二响应时间变慢现象用户反馈模型响应变慢但服务没有报错。监控数据glm4_9b_request_duration_seconds显示P95响应时间从1秒增加到5秒请求队列长度增加系统内存使用率超过85%根本原因可能是系统内存不足导致频繁的磁盘交换。解决方案增加服务器内存优化模型加载策略使用内存映射文件实现请求队列限制避免积压场景三间歇性服务失败现象服务偶尔返回503错误但很快自动恢复。监控数据glm4_9b_service_status偶尔跳变为0与glm4_9b_gpu_memory_usage_bytes峰值时间吻合系统日志显示 CUDA out of memory根本原因单个大请求耗尽了所有显存。解决方案# 添加请求大小检查和限制 def check_request_size(prompt): # 估算token数量简单方法按字数估算 estimated_tokens len(prompt) // 3 # 粗略估算 if estimated_tokens 100000: # 超过100K tokens return False, 请求过长请拆分后分批处理 # 检查当前显存是否足够 if torch.cuda.is_available(): free_memory torch.cuda.get_device_properties(0).total_memory - torch.cuda.memory_allocated() required_memory estimated_tokens * 100 # 粗略估算每个token约100字节 if required_memory free_memory * 0.8: # 需要超过80%的可用显存 return False, 显存不足请稍后重试或缩短请求 return True, # 在API接口中使用 app.post(/generate) async def generate_text(request: TextRequest): is_ok, message check_request_size(request.prompt) if not is_ok: # 记录失败指标 FAILED_REQUEST_COUNT.labels( methodPOST, endpoint/generate, error_typerequest_too_large ).inc() return JSONResponse( content{error: message}, status_code400 ) # ... 正常处理逻辑 ...7. 高级配置生产环境最佳实践如果你要在生产环境使用这套监控系统这里有一些建议7.1 使用Docker容器化创建docker-compose.yml文件一键启动所有服务version: 3.8 services: # GLM-4-9B模型服务 glm4-model: build: . ports: - 8080:8080 volumes: - ./models:/app/models deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] healthcheck: test: [CMD, curl, -f, http://localhost:8081/health] interval: 30s timeout: 10s retries: 3 # 健康监控服务 glm4-monitor: build: . command: python health_monitor.py ports: - 8081:8081 depends_on: - glm4-model # Prometheus prometheus: image: prom/prometheus:latest ports: - 9090:9090 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle # Grafana grafana: image: grafana/grafana:latest ports: - 3000:3000 volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 depends_on: - prometheus # node_exporter node-exporter: image: prom/node-exporter:latest ports: - 9100:9100 volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - --path.procfs/host/proc - --path.rootfs/rootfs - --path.sysfs/host/sys - --collector.filesystem.mount-points-exclude^/(sys|proc|dev|host|etc)($$|/) volumes: prometheus_data: grafana_data:7.2 配置告警通知在Grafana中配置告警通知渠道邮件、Slack、钉钉等配置告警渠道点击 Alerting → Contact points添加你的通知渠道邮件、Webhook等创建告警规则在仪表盘中点击面板标题 → Edit切换到 Alert 标签页配置告警条件和通知渠道7.3 性能优化建议指标采样优化# prometheus.yml scrape_configs: - job_name: glm4-9b-model scrape_interval: 30s # 生产环境可以适当降低频率 scrape_timeout: 10s metrics_path: /metrics数据保留策略# prometheus.yml 启动参数 --storage.tsdb.retention.time30d # 保留30天数据 --storage.tsdb.retention.size50GB # 最大50GB监控服务资源限制# docker-compose.yml glm4-monitor: deploy: resources: limits: memory: 512M cpus: 0.58. 总结通过今天的学习你已经为GLM-4-9B-Chat-1M模型服务搭建了一套完整的监控系统。让我们回顾一下关键收获8.1 核心成果健康检查接口(/health)让外部系统能快速判断服务状态Prometheus指标(/metrics)暴露详细的性能指标和资源使用数据监控仪表盘通过Grafana可视化所有关键指标告警系统在问题发生前及时通知你8.2 实际价值这套监控系统能帮你快速定位问题服务异常时1分钟内就能知道是GPU显存问题、内存问题还是代码问题容量规划通过历史数据预测何时需要升级硬件性能优化识别瓶颈针对性优化代码服务质量保障确保用户获得稳定可靠的服务体验8.3 下一步建议如果你想让监控系统更完善可以考虑添加业务指标监控模型输出质量、用户满意度等集成日志系统使用ELK或Loki收集和分析日志实现自动化修复某些问题可以自动恢复如显存清理、服务重启多实例监控如果你部署了多个模型实例需要集群级别的监控8.4 最后的话监控系统就像给模型服务装上了眼睛和耳朵。没有监控你就是在盲飞——不知道服务是否健康不知道用户是否满意不知道问题何时会发生。有了今天搭建的这套系统你就能睡得安稳告警系统会在问题发生时叫醒你决策有据用数据说话而不是凭感觉快速响应问题发生时你已经有了一半的答案现在你的GLM-4-9B-Chat-1M服务不再是一个黑盒而是一个透明、可控、可靠的生产系统。去享受这种掌控感吧获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。