Phi-3-Mini-128K企业级部署架构设计高可用与弹性伸缩指南如果你正在考虑把像Phi-3-Mini-128K这样的AI模型引入到公司的生产环境里那你肯定不止关心“能不能跑起来”更关心的是“能不能稳定、高效、安全地跑起来”。毕竟一个动不动就崩溃或者响应慢如蜗牛的AI服务不仅没法创造价值反而会成为业务系统的负担。今天我们就来聊聊怎么给Phi-3-Mini-128K设计一个“企业级”的部署架构。这不仅仅是把模型扔到一台服务器上那么简单而是要构建一个具备高可用性、能弹性伸缩、并且易于管理的服务系统。我们会从最核心的架构设计开始一步步讲到在星图GPU平台上如何落地包括负载均衡、API网关、监控告警和自动扩缩容这些关键环节。目标很明确让你能规划出一个既可靠又经济的生产环境方案。1. 企业级部署的核心目标与挑战在动手画架构图之前我们得先想清楚一个好的企业级AI服务部署到底要解决哪些问题。首先高可用性是底线。这意味着服务不能有单点故障任何一台服务器、一个网络设备甚至一个软件进程挂了都不能导致整个服务对外不可用。用户可不管后台有多少台机器他们只关心API能不能调通、响应快不快。其次弹性伸缩是应对业务波动的关键。AI推理尤其是大模型推理是典型的计算密集型任务对GPU资源非常敏感。你的业务流量可能有高峰有低谷比如白天咨询多晚上少或者做营销活动时流量暴增。架构必须能根据压力自动调整资源高峰时扩容保证性能低谷时缩容节省成本。再者可观测性与运维便捷性决定了后期的运维成本。服务运行状态是否透明出了故障能不能快速定位版本更新能不能平滑进行这些都是在设计之初就需要考虑的。最后安全与成本控制是商业项目的现实约束。API接口需要鉴权防止滥用多实例间的网络通信可能需要加密同时在保证服务质量的前提下要尽可能优化资源使用率控制云服务成本。面对Phi-3-Mini-128K我们还需要考虑其模型特点它虽然参数规模相对较小但对内存和计算仍有要求并且支持128K的超长上下文。这意味着在部署时我们需要为每个实例分配足够的GPU显存并且在设计网关和负载均衡策略时要考虑长文本输入输出的处理效率。2. 高可用架构设计告别单点故障一个高可用的架构核心思想就是“冗余”和“解耦”。没有任何一个组件是不可替代的。下面是一个典型的Phi-3-Mini-128K高可用部署架构示意图。[ 客户端 ] - [ 负载均衡器 (SLB) ] - [ API网关集群 ] | v [ Phi-3推理实例组 1 ] [ Phi-3推理实例组 2 ] [ Phi-3推理实例组 ... ] | v [ 共享存储 / 模型仓库 ] [ 监控告警中心 ] [ 配置管理中心 ]我们来拆解一下图中的关键组件2.1 负载均衡器流量入口这是服务对外的第一道大门。你可以使用云平台提供的负载均衡服务如SLB或者自行部署Nginx、HAProxy等软件。它的作用是将来自四面八方客户端的请求按照一定策略如轮询、最少连接数、基于来源IP等分发到后端的多个API网关节点上。即使某个网关节点故障负载均衡器也能自动将其从健康检查列表中剔除将流量导向其他健康节点从而保证入口层面的高可用。2.2 API网关集群业务逻辑与安全层API网关是整个架构的“大脑”和“守门人”。它不应该只是简单的请求转发而应该承担更多职责统一鉴权与限流在这里验证API密钥、令牌防止未授权访问。同时针对不同用户或应用实施请求频率限制QPS、并发数保护后端模型实例不被突发流量打垮。请求/响应预处理可以对输入文本进行基础的清洗、格式化或者对模型的输出进行后处理如敏感词过滤、格式标准化。路由与熔断将请求路由到后端不同的模型实例组。如果某个实例响应超时或连续出错网关可以快速熔断该实例避免请求堆积导致雪崩。日志聚合统一收集所有访问日志便于后续分析和审计。部署多个网关实例组成集群并通过负载均衡器暴露就实现了网关层的高可用。2.3 Phi-3推理实例组计算核心层这是真正执行模型推理的地方。我们会在多台GPU服务器上部署Phi-3-Mini-128K的推理服务例如使用vLLM、TGI或模型自带的FastAPI服务。每一台服务器上的服务都是一个独立的实例。关键点在于“无状态”设计。每个推理实例本身不保存任何会话状态如果模型支持会话状态也应外置到缓存中。这样任何一个实例都是可以被随时创建或销毁的请求无论被分发到哪个实例都能得到一致的处理。这是实现弹性伸缩的基础。多个这样的实例构成一个“实例组”或“集群”由上游的API网关来调用。2.4 支撑服务共享、配置与监控共享存储/模型仓库所有推理实例应该从同一个地方如S3对象存储、NAS文件存储或Hugging Face模型库加载相同的模型文件。这保证了服务版本的一致性也便于模型热更新。配置管理中心将API网关、模型服务的配置如超时时间、模型参数集中管理修改后能动态推送到各个实例无需重启服务。监控告警中心收集所有组件的指标CPU、GPU、内存、显存使用率请求延迟、QPS、错误率等并设置告警规则。这是运维的眼睛。3. 在星图GPU平台上的部署实践理论架构清楚了我们来看看如何在星图GPU平台上具体实施。星图平台提供了强大的GPU算力容器服务非常适合部署这类AI应用。3.1 利用多实例实现负载均衡在星图平台上我们不会去手动创建一大堆虚拟机然后部署那样太累了。更高效的方式是使用其容器服务Kubernetes。制作推理服务镜像首先你需要创建一个Docker镜像里面包含Phi-3-Mini-128K的推理环境和服务代码。例如基于一个Python镜像安装好PyTorch、transformers、vLLM等库并编写一个启动脚本启动一个HTTP推理服务。# 示例 Dockerfile 片段 FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 假设你的启动命令是启动一个FastAPI服务 CMD [python, app.py]创建Kubernetes Deployment这是核心。通过一个Deployment配置文件告诉Kubernetes如何运行你的推理服务。# phi3-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: phi3-mini-inference spec: replicas: 3 # 初始启动3个实例副本 selector: matchLabels: app: phi3-mini template: metadata: labels: app: phi3-mini spec: containers: - name: inference image: your-registry/phi3-mini-inference:latest ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 # 申请1块GPU memory: 16Gi requests: nvidia.com/gpu: 1 memory: 16Gi env: - name: MODEL_NAME value: microsoft/Phi-3-mini-128k-instruct执行kubectl apply -f phi3-deployment.yamlKubernetes就会自动在集群中创建3个Pod即3个推理实例并确保它们始终处于运行状态。如果某个Pod挂了它会自动创建一个新的。创建Kubernetes ServiceDeployment管理了Pod的生命周期但Pod的IP是会变化的。Service提供了一个稳定的网络端点ClusterIP来访问这组Pod并自带负载均衡功能。# phi3-service.yaml apiVersion: v1 kind: Service metadata: name: phi3-mini-service spec: selector: app: phi3-mini # 选择上面Deployment管理的Pod ports: - port: 80 targetPort: 8000 # 转发到Pod的8000端口现在在集群内部其他服务如API网关就可以通过phi3-mini-service这个域名来访问推理服务流量会被自动负载均衡到后端的3个Pod。3.2 部署API网关API网关也可以容器化部署在同一个Kubernetes集群中。例如使用开源的Kong或Apache APISIX。部署网关同样通过Deployment部署网关实例并通过Service暴露。配置路由与插件在网关上配置路由规则将特定路径如/v1/chat/completions的请求代理到后端的phi3-mini-service。同时启用鉴权插件如Key Authentication、限流插件和日志插件。对外暴露最后为网关的Service创建一个LoadBalancer类型的Kubernetes Service或者配置Ingress规则。星图平台会为此分配一个公网IP或域名这就是你最终对外提供的AI服务地址。至此一个具备基本高可用能力的Phi-3服务就部署完成了。客户端访问公网IP经过负载均衡到网关网关鉴权限流后将请求负载均衡到后端的多个模型实例。4. 配置监控告警让运维心中有数部署完了不是终点让服务稳定运行才是开始。监控是运维的“眼睛”。需要监控什么基础设施层GPU使用率、显存占用、CPU、内存、磁盘I/O、网络流量。星图平台的控制台通常提供基础的资源监控。服务层黄金指标流量QPS、延迟P95/P99响应时间、错误率HTTP 5xx比例。业务指标每个请求的输入/输出token数与成本相关、模型缓存命中率等。日志收集所有服务的访问日志和错误日志。如何实施埋点与暴露指标在你的推理服务和API网关中集成Prometheus客户端库如prometheus_clientfor Python暴露/metrics端点输出自定义的业务指标。收集与存储在集群中部署Prometheus让它定期抓取所有Pod的指标。可视化使用Grafana连接Prometheus数据源绘制丰富的监控仪表盘。你可以分别创建“全局概览”、“网关层”、“模型实例层”等不同视角的看板。告警在Prometheus或Grafana中配置告警规则。例如当某个模型实例的GPU使用率持续5分钟高于90%时发出警告。当API网关的P99延迟超过2秒时发出警告。当服务整体错误率超过1%时发出严重告警。 告警可以通过Webhook发送到钉钉、企业微信、Slack等协作工具或者集成PagerDuty等值班系统。有了完善的监控你就能实时掌握服务健康度在用户投诉之前发现问题。5. 实现弹性伸缩应对流量洪峰这是企业级架构的“高级技能”能让你在成本和性能间取得最佳平衡。Kubernetes提供了两种主要的伸缩机制5.1 水平伸缩HPA增减实例数量这是最常用的伸缩方式根据CPU、内存或自定义指标来增加或减少Pod的副本数。安装Metrics ServerHPA需要获取Pod的资源使用指标首先确保集群中已部署Metrics Server。创建HPA策略针对我们的Phi-3推理服务Deployment创建HPA。# phi3-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: phi3-mini-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: phi3-mini-inference minReplicas: 2 # 最少保持2个实例 maxReplicas: 10 # 最多可扩展到10个实例 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 目标CPU平均使用率70% - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # 目标内存平均使用率80%这个策略会根据所有Pod的CPU和内存平均使用率来调整副本数。但注意对于GPU密集型应用CPU和内存可能不是最佳指标。基于自定义指标伸缩更推荐我们可以基于更贴近业务的指标比如“每个Pod的平均请求并发数”或“GPU利用率”来伸缩。首先需要部署Prometheus Adapter将Prometheus中的业务指标如http_requests_in_flight转换为Kubernetes能识别的自定义指标。然后创建基于该自定义指标的HPA策略。metrics: - type: Pods pods: metric: name: requests_per_second_per_pod # 假设的自定义指标名 target: type: AverageValue averageValue: 10 # 目标是每个Pod每秒处理10个请求这样当每个Pod的平均负载超过10 RPS时HPA就会自动增加副本数来分摊压力。5.2 集群节点伸缩CA应对资源不足当HPA想要创建新的Pod但集群中的GPU节点资源已经耗尽时就需要集群自动伸缩Cluster Autoscaler登场了。CA会监测到有Pod因为资源不足而无法调度Pending状态然后自动向云平台申请创建新的GPU节点并加入集群。当节点上的Pod被删除且资源空闲一段时间后CA又会自动回收节点以节省成本。在星图平台上你需要确认其容器服务是否支持并已配置好集群自动伸缩功能。通常这需要在创建集群时或后期在控制台进行配置。伸缩流程闭环业务流量增长。每个模型实例的负载请求数、GPU利用率上升。HPA检测到指标超过阈值。HPA增加Deployment的Pod副本数。调度器尝试在新节点上调度新Pod。如果资源不足CA触发创建新的GPU节点。新节点加入集群新Pod成功启动。流量被负载均衡到更多实例单个实例负载下降指标恢复正常。流量低谷时反向操作缩容并回收节点。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Phi-3-Mini-128K企业级部署架构设计：高可用与弹性伸缩指南
发布时间：2026/5/16 23:49:49
Phi-3-Mini-128K企业级部署架构设计高可用与弹性伸缩指南如果你正在考虑把像Phi-3-Mini-128K这样的AI模型引入到公司的生产环境里那你肯定不止关心“能不能跑起来”更关心的是“能不能稳定、高效、安全地跑起来”。毕竟一个动不动就崩溃或者响应慢如蜗牛的AI服务不仅没法创造价值反而会成为业务系统的负担。今天我们就来聊聊怎么给Phi-3-Mini-128K设计一个“企业级”的部署架构。这不仅仅是把模型扔到一台服务器上那么简单而是要构建一个具备高可用性、能弹性伸缩、并且易于管理的服务系统。我们会从最核心的架构设计开始一步步讲到在星图GPU平台上如何落地包括负载均衡、API网关、监控告警和自动扩缩容这些关键环节。目标很明确让你能规划出一个既可靠又经济的生产环境方案。1. 企业级部署的核心目标与挑战在动手画架构图之前我们得先想清楚一个好的企业级AI服务部署到底要解决哪些问题。首先高可用性是底线。这意味着服务不能有单点故障任何一台服务器、一个网络设备甚至一个软件进程挂了都不能导致整个服务对外不可用。用户可不管后台有多少台机器他们只关心API能不能调通、响应快不快。其次弹性伸缩是应对业务波动的关键。AI推理尤其是大模型推理是典型的计算密集型任务对GPU资源非常敏感。你的业务流量可能有高峰有低谷比如白天咨询多晚上少或者做营销活动时流量暴增。架构必须能根据压力自动调整资源高峰时扩容保证性能低谷时缩容节省成本。再者可观测性与运维便捷性决定了后期的运维成本。服务运行状态是否透明出了故障能不能快速定位版本更新能不能平滑进行这些都是在设计之初就需要考虑的。最后安全与成本控制是商业项目的现实约束。API接口需要鉴权防止滥用多实例间的网络通信可能需要加密同时在保证服务质量的前提下要尽可能优化资源使用率控制云服务成本。面对Phi-3-Mini-128K我们还需要考虑其模型特点它虽然参数规模相对较小但对内存和计算仍有要求并且支持128K的超长上下文。这意味着在部署时我们需要为每个实例分配足够的GPU显存并且在设计网关和负载均衡策略时要考虑长文本输入输出的处理效率。2. 高可用架构设计告别单点故障一个高可用的架构核心思想就是“冗余”和“解耦”。没有任何一个组件是不可替代的。下面是一个典型的Phi-3-Mini-128K高可用部署架构示意图。[ 客户端 ] - [ 负载均衡器 (SLB) ] - [ API网关集群 ] | v [ Phi-3推理实例组 1 ] [ Phi-3推理实例组 2 ] [ Phi-3推理实例组 ... ] | v [ 共享存储 / 模型仓库 ] [ 监控告警中心 ] [ 配置管理中心 ]我们来拆解一下图中的关键组件2.1 负载均衡器流量入口这是服务对外的第一道大门。你可以使用云平台提供的负载均衡服务如SLB或者自行部署Nginx、HAProxy等软件。它的作用是将来自四面八方客户端的请求按照一定策略如轮询、最少连接数、基于来源IP等分发到后端的多个API网关节点上。即使某个网关节点故障负载均衡器也能自动将其从健康检查列表中剔除将流量导向其他健康节点从而保证入口层面的高可用。2.2 API网关集群业务逻辑与安全层API网关是整个架构的“大脑”和“守门人”。它不应该只是简单的请求转发而应该承担更多职责统一鉴权与限流在这里验证API密钥、令牌防止未授权访问。同时针对不同用户或应用实施请求频率限制QPS、并发数保护后端模型实例不被突发流量打垮。请求/响应预处理可以对输入文本进行基础的清洗、格式化或者对模型的输出进行后处理如敏感词过滤、格式标准化。路由与熔断将请求路由到后端不同的模型实例组。如果某个实例响应超时或连续出错网关可以快速熔断该实例避免请求堆积导致雪崩。日志聚合统一收集所有访问日志便于后续分析和审计。部署多个网关实例组成集群并通过负载均衡器暴露就实现了网关层的高可用。2.3 Phi-3推理实例组计算核心层这是真正执行模型推理的地方。我们会在多台GPU服务器上部署Phi-3-Mini-128K的推理服务例如使用vLLM、TGI或模型自带的FastAPI服务。每一台服务器上的服务都是一个独立的实例。关键点在于“无状态”设计。每个推理实例本身不保存任何会话状态如果模型支持会话状态也应外置到缓存中。这样任何一个实例都是可以被随时创建或销毁的请求无论被分发到哪个实例都能得到一致的处理。这是实现弹性伸缩的基础。多个这样的实例构成一个“实例组”或“集群”由上游的API网关来调用。2.4 支撑服务共享、配置与监控共享存储/模型仓库所有推理实例应该从同一个地方如S3对象存储、NAS文件存储或Hugging Face模型库加载相同的模型文件。这保证了服务版本的一致性也便于模型热更新。配置管理中心将API网关、模型服务的配置如超时时间、模型参数集中管理修改后能动态推送到各个实例无需重启服务。监控告警中心收集所有组件的指标CPU、GPU、内存、显存使用率请求延迟、QPS、错误率等并设置告警规则。这是运维的眼睛。3. 在星图GPU平台上的部署实践理论架构清楚了我们来看看如何在星图GPU平台上具体实施。星图平台提供了强大的GPU算力容器服务非常适合部署这类AI应用。3.1 利用多实例实现负载均衡在星图平台上我们不会去手动创建一大堆虚拟机然后部署那样太累了。更高效的方式是使用其容器服务Kubernetes。制作推理服务镜像首先你需要创建一个Docker镜像里面包含Phi-3-Mini-128K的推理环境和服务代码。例如基于一个Python镜像安装好PyTorch、transformers、vLLM等库并编写一个启动脚本启动一个HTTP推理服务。# 示例 Dockerfile 片段 FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 假设你的启动命令是启动一个FastAPI服务 CMD [python, app.py]创建Kubernetes Deployment这是核心。通过一个Deployment配置文件告诉Kubernetes如何运行你的推理服务。# phi3-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: phi3-mini-inference spec: replicas: 3 # 初始启动3个实例副本 selector: matchLabels: app: phi3-mini template: metadata: labels: app: phi3-mini spec: containers: - name: inference image: your-registry/phi3-mini-inference:latest ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 # 申请1块GPU memory: 16Gi requests: nvidia.com/gpu: 1 memory: 16Gi env: - name: MODEL_NAME value: microsoft/Phi-3-mini-128k-instruct执行kubectl apply -f phi3-deployment.yamlKubernetes就会自动在集群中创建3个Pod即3个推理实例并确保它们始终处于运行状态。如果某个Pod挂了它会自动创建一个新的。创建Kubernetes ServiceDeployment管理了Pod的生命周期但Pod的IP是会变化的。Service提供了一个稳定的网络端点ClusterIP来访问这组Pod并自带负载均衡功能。# phi3-service.yaml apiVersion: v1 kind: Service metadata: name: phi3-mini-service spec: selector: app: phi3-mini # 选择上面Deployment管理的Pod ports: - port: 80 targetPort: 8000 # 转发到Pod的8000端口现在在集群内部其他服务如API网关就可以通过phi3-mini-service这个域名来访问推理服务流量会被自动负载均衡到后端的3个Pod。3.2 部署API网关API网关也可以容器化部署在同一个Kubernetes集群中。例如使用开源的Kong或Apache APISIX。部署网关同样通过Deployment部署网关实例并通过Service暴露。配置路由与插件在网关上配置路由规则将特定路径如/v1/chat/completions的请求代理到后端的phi3-mini-service。同时启用鉴权插件如Key Authentication、限流插件和日志插件。对外暴露最后为网关的Service创建一个LoadBalancer类型的Kubernetes Service或者配置Ingress规则。星图平台会为此分配一个公网IP或域名这就是你最终对外提供的AI服务地址。至此一个具备基本高可用能力的Phi-3服务就部署完成了。客户端访问公网IP经过负载均衡到网关网关鉴权限流后将请求负载均衡到后端的多个模型实例。4. 配置监控告警让运维心中有数部署完了不是终点让服务稳定运行才是开始。监控是运维的“眼睛”。需要监控什么基础设施层GPU使用率、显存占用、CPU、内存、磁盘I/O、网络流量。星图平台的控制台通常提供基础的资源监控。服务层黄金指标流量QPS、延迟P95/P99响应时间、错误率HTTP 5xx比例。业务指标每个请求的输入/输出token数与成本相关、模型缓存命中率等。日志收集所有服务的访问日志和错误日志。如何实施埋点与暴露指标在你的推理服务和API网关中集成Prometheus客户端库如prometheus_clientfor Python暴露/metrics端点输出自定义的业务指标。收集与存储在集群中部署Prometheus让它定期抓取所有Pod的指标。可视化使用Grafana连接Prometheus数据源绘制丰富的监控仪表盘。你可以分别创建“全局概览”、“网关层”、“模型实例层”等不同视角的看板。告警在Prometheus或Grafana中配置告警规则。例如当某个模型实例的GPU使用率持续5分钟高于90%时发出警告。当API网关的P99延迟超过2秒时发出警告。当服务整体错误率超过1%时发出严重告警。 告警可以通过Webhook发送到钉钉、企业微信、Slack等协作工具或者集成PagerDuty等值班系统。有了完善的监控你就能实时掌握服务健康度在用户投诉之前发现问题。5. 实现弹性伸缩应对流量洪峰这是企业级架构的“高级技能”能让你在成本和性能间取得最佳平衡。Kubernetes提供了两种主要的伸缩机制5.1 水平伸缩HPA增减实例数量这是最常用的伸缩方式根据CPU、内存或自定义指标来增加或减少Pod的副本数。安装Metrics ServerHPA需要获取Pod的资源使用指标首先确保集群中已部署Metrics Server。创建HPA策略针对我们的Phi-3推理服务Deployment创建HPA。# phi3-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: phi3-mini-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: phi3-mini-inference minReplicas: 2 # 最少保持2个实例 maxReplicas: 10 # 最多可扩展到10个实例 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 目标CPU平均使用率70% - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # 目标内存平均使用率80%这个策略会根据所有Pod的CPU和内存平均使用率来调整副本数。但注意对于GPU密集型应用CPU和内存可能不是最佳指标。基于自定义指标伸缩更推荐我们可以基于更贴近业务的指标比如“每个Pod的平均请求并发数”或“GPU利用率”来伸缩。首先需要部署Prometheus Adapter将Prometheus中的业务指标如http_requests_in_flight转换为Kubernetes能识别的自定义指标。然后创建基于该自定义指标的HPA策略。metrics: - type: Pods pods: metric: name: requests_per_second_per_pod # 假设的自定义指标名 target: type: AverageValue averageValue: 10 # 目标是每个Pod每秒处理10个请求这样当每个Pod的平均负载超过10 RPS时HPA就会自动增加副本数来分摊压力。5.2 集群节点伸缩CA应对资源不足当HPA想要创建新的Pod但集群中的GPU节点资源已经耗尽时就需要集群自动伸缩Cluster Autoscaler登场了。CA会监测到有Pod因为资源不足而无法调度Pending状态然后自动向云平台申请创建新的GPU节点并加入集群。当节点上的Pod被删除且资源空闲一段时间后CA又会自动回收节点以节省成本。在星图平台上你需要确认其容器服务是否支持并已配置好集群自动伸缩功能。通常这需要在创建集群时或后期在控制台进行配置。伸缩流程闭环业务流量增长。每个模型实例的负载请求数、GPU利用率上升。HPA检测到指标超过阈值。HPA增加Deployment的Pod副本数。调度器尝试在新节点上调度新Pod。如果资源不足CA触发创建新的GPU节点。新节点加入集群新Pod成功启动。流量被负载均衡到更多实例单个实例负载下降指标恢复正常。流量低谷时反向操作缩容并回收节点。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
