99% 可用性意味着一年宕机时间 53 分钟。推理服务要做到这个指标需要解决NPU 故障、OOM、网络中断、版本回滚失败。这篇讲在昇腾NPU上的具体做法。可用性计算99.9% 8.76 小时/年 99.99% 52.6 分钟/年 99.999% 5.26 分钟/年99% 是多数在线服务的目标。99.999%金融级需要多机房容灾。故障域隔离隔离级别 1进程级# 每个推理请求在独立进程处理frommultiprocessingimportProcess,Queuedefworker(queue_in,queue_out,device_id):modelLLM(model_id,devicefnpu:{device_id})whileTrue:reqqueue_in.get()resultmodel.generate(req.prompt)queue_out.put(result)# 主进程负责调度worker 崩溃不影响其他 worker某个请求导致 NPU 崩溃如 OOM只影响当前 worker主进程重启它即可。隔离级别 2容器级# 每个 NPU 一个容器 FROM cann:8.5 # 只暴露推理端口 EXPOSE 8000 # 健康检查 HEALTHCHECK --interval10s --timeout5s \ CMD curl -f http://localhost:8000/health || exit 1Kubernetes 的 Pod 健康检查失败 → 自动重启容器 → 30 秒内恢复。隔离级别 3机器级Load Balancer (SLB) ├── 机器 A8 卡→ 容器 1-8 ├── 机器 B8 卡→ 容器 9-16 └── 机器 C8 卡→ 容器 17-24某台机器宕机LB 把流量切到另外两台。需要 3 台机器才能达到 99.99%1 台宕机不影响服务。健康检查检查项 1NPU 是否正常fromfastapiimportFastAPI,HTTPException appFastAPI()app.get(/health)defhealth_check():try:# 检查 NPU 是否可访问torch.randn(1,devicenpu:0)return{status:ok}exceptExceptionase:raiseHTTPException(status_code503,detailstr(e))检查项 2模型是否加载完成modelNoneapp.on_event(startup)defload_model():globalmodel modelLLM(model_id,devicenpu:0)app.get(/health)defhealth_check():ifmodelisNone:raiseHTTPException(status_code503,detailModel not loaded)# ... 检查 NPUreturn{status:ok}检查项 3推理是否正常app.get(/health)defhealth_check():# ... 前面的检查try:# 用简短 prompt 测试推理resultmodel.generate(Hi,max_new_tokens5)iflen(result)0:raiseException(Empty output)exceptExceptionase:raiseHTTPException(status_code503,detailstr(e))return{status:ok}优雅降级NPU 故障时降级到 CPU 推理慢但可用classFallbackLLM:def__init__(self,model_id):try:self.model_npuLLM(model_id,devicenpu:0)self.npu_availableTrueexcept:self.npu_availableFalsedefgenerate(self,prompt,**kwargs):ifself.npu_available:try:returnself.model_npu.generate(prompt,**kwargs)except:self.npu_availableFalse# 降级到 CPUifnothasattr(self,model_cpu):self.model_cpuLLM(model_id,devicecpu)returnself.model_cpu.generate(prompt,**kwargs)CPU 推理速度是 NPU 的 1/50但总比返回 503 好。滚动更新新版本上线时先启动新版本容器健康检查通过后再下线旧版本# Kubernetes DeploymentapiVersion:apps/v1kind:Deploymentspec:replicas:8strategy:type:RollingUpdaterollingUpdate:maxSurge:2# 最多多 2 个 PodmaxUnavailable:0# 更新期间不允许不可用template:spec:containers:-name:inferenceimage:inference:v2.0readinessProbe:# 健康检查通过后才接收流量httpGet:path:/healthport:8000initialDelaySeconds:60# 模型加载需要时间periodSeconds:10更新期间始终有 8 个可用 Pod零宕机。监控和告警关键指标和告警阈值# Prometheus 告警规则groups:-name:inference_alertsrules:-alert:InferenceHighLatencyexpr:histogram_quantile(0.99,inference_latency_seconds)1for:5mannotations:summary:推理 P99 延迟 1s-alert:InferenceHighErrorRateexpr:rate(inference_requests_total{statuserror}[5m]) / rate(inference_requests_total[5m])0.01for:2mannotations:summary:推理错误率 1%-alert:NPUUnavailableexpr:up{jobnpu_health} 0for:1mannotations:summary:NPU 不可用实测可用性配置3 台机器 × 8 卡K8s 滚动更新NPU 健康检查。场景恢复时间对可用性影响单个 NPU 故障30s容器重启可忽略单台机器宕机0LB 切流量0版本回滚2 分钟滚动0机房断电5 分钟切换到备用机房5 分钟全年宕机时间约 30 分钟 → 可用性 99.994%达到目标。推理服务高可用的关键是故障域隔离进程/容器/机器、健康检查NPU/模型/推理、优雅降级NPU → CPU、滚动更新零宕机。三台机器 K8s 可以做到 99.99%。仓库在这里https://atomgit.com/cann/ATB
CANN-昇腾NPU-推理服务高可用-怎么做到99.99%可用性
发布时间：2026/5/23 21:30:07
99% 可用性意味着一年宕机时间 53 分钟。推理服务要做到这个指标需要解决NPU 故障、OOM、网络中断、版本回滚失败。这篇讲在昇腾NPU上的具体做法。可用性计算99.9% 8.76 小时/年 99.99% 52.6 分钟/年 99.999% 5.26 分钟/年99% 是多数在线服务的目标。99.999%金融级需要多机房容灾。故障域隔离隔离级别 1进程级# 每个推理请求在独立进程处理frommultiprocessingimportProcess,Queuedefworker(queue_in,queue_out,device_id):modelLLM(model_id,devicefnpu:{device_id})whileTrue:reqqueue_in.get()resultmodel.generate(req.prompt)queue_out.put(result)# 主进程负责调度worker 崩溃不影响其他 worker某个请求导致 NPU 崩溃如 OOM只影响当前 worker主进程重启它即可。隔离级别 2容器级# 每个 NPU 一个容器 FROM cann:8.5 # 只暴露推理端口 EXPOSE 8000 # 健康检查 HEALTHCHECK --interval10s --timeout5s \ CMD curl -f http://localhost:8000/health || exit 1Kubernetes 的 Pod 健康检查失败 → 自动重启容器 → 30 秒内恢复。隔离级别 3机器级Load Balancer (SLB) ├── 机器 A8 卡→ 容器 1-8 ├── 机器 B8 卡→ 容器 9-16 └── 机器 C8 卡→ 容器 17-24某台机器宕机LB 把流量切到另外两台。需要 3 台机器才能达到 99.99%1 台宕机不影响服务。健康检查检查项 1NPU 是否正常fromfastapiimportFastAPI,HTTPException appFastAPI()app.get(/health)defhealth_check():try:# 检查 NPU 是否可访问torch.randn(1,devicenpu:0)return{status:ok}exceptExceptionase:raiseHTTPException(status_code503,detailstr(e))检查项 2模型是否加载完成modelNoneapp.on_event(startup)defload_model():globalmodel modelLLM(model_id,devicenpu:0)app.get(/health)defhealth_check():ifmodelisNone:raiseHTTPException(status_code503,detailModel not loaded)# ... 检查 NPUreturn{status:ok}检查项 3推理是否正常app.get(/health)defhealth_check():# ... 前面的检查try:# 用简短 prompt 测试推理resultmodel.generate(Hi,max_new_tokens5)iflen(result)0:raiseException(Empty output)exceptExceptionase:raiseHTTPException(status_code503,detailstr(e))return{status:ok}优雅降级NPU 故障时降级到 CPU 推理慢但可用classFallbackLLM:def__init__(self,model_id):try:self.model_npuLLM(model_id,devicenpu:0)self.npu_availableTrueexcept:self.npu_availableFalsedefgenerate(self,prompt,**kwargs):ifself.npu_available:try:returnself.model_npu.generate(prompt,**kwargs)except:self.npu_availableFalse# 降级到 CPUifnothasattr(self,model_cpu):self.model_cpuLLM(model_id,devicecpu)returnself.model_cpu.generate(prompt,**kwargs)CPU 推理速度是 NPU 的 1/50但总比返回 503 好。滚动更新新版本上线时先启动新版本容器健康检查通过后再下线旧版本# Kubernetes DeploymentapiVersion:apps/v1kind:Deploymentspec:replicas:8strategy:type:RollingUpdaterollingUpdate:maxSurge:2# 最多多 2 个 PodmaxUnavailable:0# 更新期间不允许不可用template:spec:containers:-name:inferenceimage:inference:v2.0readinessProbe:# 健康检查通过后才接收流量httpGet:path:/healthport:8000initialDelaySeconds:60# 模型加载需要时间periodSeconds:10更新期间始终有 8 个可用 Pod零宕机。监控和告警关键指标和告警阈值# Prometheus 告警规则groups:-name:inference_alertsrules:-alert:InferenceHighLatencyexpr:histogram_quantile(0.99,inference_latency_seconds)1for:5mannotations:summary:推理 P99 延迟 1s-alert:InferenceHighErrorRateexpr:rate(inference_requests_total{statuserror}[5m]) / rate(inference_requests_total[5m])0.01for:2mannotations:summary:推理错误率 1%-alert:NPUUnavailableexpr:up{jobnpu_health} 0for:1mannotations:summary:NPU 不可用实测可用性配置3 台机器 × 8 卡K8s 滚动更新NPU 健康检查。场景恢复时间对可用性影响单个 NPU 故障30s容器重启可忽略单台机器宕机0LB 切流量0版本回滚2 分钟滚动0机房断电5 分钟切换到备用机房5 分钟全年宕机时间约 30 分钟 → 可用性 99.994%达到目标。推理服务高可用的关键是故障域隔离进程/容器/机器、健康检查NPU/模型/推理、优雅降级NPU → CPU、滚动更新零宕机。三台机器 K8s 可以做到 99.99%。仓库在这里https://atomgit.com/cann/ATB
