PyTorch模型生产可观测性实战：Prometheus+Loki+Jaeger四层架构

1. 项目概述：当模型走出Jupyter，真正开始呼吸真实世界的空气

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在部署时被现实狠狠绊了一跤的工程师准备的。它不是讲怎么写model.fit()，而是讲模型第一次被放进API里、第一次接到线上用户请求、第一次因为内存泄漏把服务器拖垮、第一次在凌晨三点被告警电话叫醒时，你该抓哪根救命稻草。我带过十几支AI落地团队，最常听到的抱怨不是“模型不准”，而是“模型跑不起来”“数据对不上”“上线后性能断崖式下跌”。Part 4意味着这不是入门科普，而是直插生产环境腹地的实战切片：它聚焦的是模型服务化（Model Serving）之后的持续可观测性、弹性扩缩容、灰度发布控制与故障快速回滚这四个生死线。关键词里的“Real World”三个字，翻译过来就是：没有完美的数据管道、没有永远稳定的GPU显存、没有不改需求的产品经理、也没有能靠pip install解决的权限问题。这篇文章适合两类人：一类是刚从算法岗转战MLOps的工程师，手握PyTorch代码但面对Kubernetes YAML文件两眼发黑；另一类是技术负责人，需要在资源有限的前提下，用最小代价建立一套“模型出问题时，我能5分钟内定位到是特征工程bug还是GPU驱动崩溃”的防御体系。它不承诺“一键部署”，但能让你下次看到503 Service Unavailable时，第一反应不是重启服务，而是打开Grafana看一眼model_latency_p99和gpu_memory_used_percent的交叉趋势。

2. 内容整体设计与思路拆解：为什么放弃“全栈大包大揽”，选择分层解耦的观测架构

2.1 核心矛盾：Notebook的确定性 vs 生产环境的混沌性

在Jupyter里，df.head()永远返回同样的前5行，torch.cuda.memory_allocated()每次调用都精准反映当前显存占用，time.time()是绝对可靠的时钟。但一旦模型被封装成gRPC服务、部署到K8s集群、接入真实流量，这些“确定性”就消失了。我们曾在一个电商推荐模型上线后发现，P99延迟从200ms突然跳到1.8s，日志里只有一行CUDA out of memory，但nvidia-smi显示GPU显存使用率才65%。排查三天才发现，是上游数据平台在午间高峰时段将用户行为序列长度从平均128截断为512，而模型推理代码里有个未加保护的torch.cat()操作——它在CPU上拼接完512个向量后，才试图把结果搬上GPU，瞬间吃光显存。这个案例揭示了Part 4的核心设计哲学：不能把观测当成“锦上添花”的监控看板，而必须把它作为模型服务的“神经系统”，嵌入到数据流、计算流、控制流的每一个毛细血管中。因此，本方案彻底放弃了早期流行的“All-in-One”框架（比如把Prometheus指标、日志、链路追踪全塞进一个自研Agent），而是采用分层解耦架构：

• 数据采集层（Edge）：在模型服务进程内部埋点，不依赖外部代理。用opentelemetry-python直接注入tracing和metrics，确保即使网络抖动，关键指标（如单次推理耗时、输入张量shape、GPU显存峰值）也能通过本地缓冲区暂存。
• 传输层（Pipeline）：指标走Prometheus Pull模式（避免服务端主动Push带来的连接风暴），日志走Loki的Push模式（支持高吞吐文本），链路追踪走Jaeger的UDP上报（低延迟）。三者完全独立，互不阻塞。
• 存储与分析层（Core）：Prometheus存时序指标（精度15s，保留30天），Loki存结构化日志（按service_name+model_version索引），Jaeger存分布式追踪（保留7天热数据+冷数据归档至S3）。这种分离不是为了炫技，而是源于一个血泪教训：当Jaeger后端因磁盘满导致上报失败时，如果指标和日志也依赖同一套传输通道，整个可观测体系就彻底失明。

2.2 方案选型逻辑：为什么是Prometheus+Loki+Jaeger，而不是ELK或Datadog

很多团队第一反应是上ELK（Elasticsearch+Logstash+Kibana），但我们在金融风控场景实测发现，ELK在处理高频结构化日志（如每秒10万条{"model": "fraud_v3", "input_size_bytes": 2456, "latency_ms": 89}）时，Elasticsearch的JVM GC压力会导致日志延迟飙升至分钟级，根本无法支撑实时告警。而Loki的设计哲学是“日志即指标”，它不索引日志全文，只索引标签（labels），将日志体（log line）以压缩块形式存入对象存储。这意味着：

• 存储成本降低70%（对比ELK同等数据量）
• 查询速度提升3倍（{service="risk-model"} | json | latency_ms > 200毫秒级返回）
• 水平扩展无瓶颈（增加Loki querier节点即可）

同样，放弃Datadog这类SaaS方案，核心在于控制权与定制深度。Datadog的ML监控模板默认只抓http_request_duration_seconds，但我们需要的是model_inference_duration_seconds{device="cuda:0"}和feature_drift_score{feature="user_age_bucket"}。自建栈意味着我们可以把PyTorch Profiler的kineto事件直接导出为OpenTelemetry trace span，在Jaeger里看到aten::cudnn_convolution算子级耗时，这是任何商业产品都无法提供的颗粒度。当然，自建有运维成本，所以我们的折中方案是：用Helm Chart一键部署Loki/Prometheus/Jaeger（社区维护的loki-stack和kube-prometheus），将90%的YAML配置固化为CI/CD流水线中的helm upgrade命令，真正实现“运维即代码”。

2.3 架构图景：一张图看清四层协同关系

下表清晰展示了各组件在模型生命周期中的职责边界，避免常见误区（如用Prometheus查日志、用Jaeger做容量规划）：

这个表格不是教科书定义，而是我们踩坑后总结的“红线清单”。比如曾有团队试图用Loki的line_format功能计算延迟分布，结果因正则解析开销导致Loki querier CPU打满；也有团队把所有指标塞进Jaeger的tag里，导致trace存储膨胀10倍。分层解耦的本质，是承认每个工具都有其物理极限，强行越界只会让系统更脆弱。

3. 核心细节解析与实操要点：在PyTorch服务中埋点，比你想象的更“脏”也更有效

3.1 不是加装饰器那么简单：理解PyTorch的执行上下文陷阱

很多教程教你给predict()函数加@tracer.start_as_current_span("inference")，但这在真实场景中会失效。原因在于PyTorch的DataLoader多进程加载、torch.compile()的图优化、以及混合精度训练（AMP）的自动autocast上下文，都会导致OpenTelemetry的span context在进程/线程间丢失。我们的解决方案是双钩子注入法：

1. 进程级钩子（Pre-fork）：在main.py启动时，初始化全局TracerProvider，并设置contextvars作为上下文载体：

   from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor from opentelemetry.exporter.jaeger.thrift import JaegerExporter # 必须在multiprocessing之前初始化！ provider = TracerProvider() processor = BatchSpanProcessor(JaegerExporter(agent_host_name="jaeger", agent_port=6831)) provider.add_span_processor(processor) trace.set_tracer_provider(provider)

2. 推理级钩子（Inference-time）：在实际预测逻辑中，不依赖装饰器，而是手动管理span生命周期，并捕获PyTorch原生事件：

   import torch from opentelemetry import trace from opentelemetry.trace import Status, StatusCode def predict(input_tensor: torch.Tensor) -> dict: tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("model_inference") as span: # Step 1: 记录输入特征维度（防数据漂移） span.set_attribute("input_shape", str(list(input_tensor.shape))) span.set_attribute("input_dtype", str(input_tensor.dtype)) # Step 2: 启动PyTorch Profiler，捕获GPU算子级耗时 with torch.profiler.profile( record_shapes=True, with_stack=False, profile_memory=True, with_flops=True, ) as prof: with torch.no_grad(): output = model(input_tensor) # Step 3: 将Profiler结果转化为OpenTelemetry span for event in prof.key_averages(): if "cuda" in event.device_type: # 只关注GPU事件 child_span = tracer.start_span(f"torch_op_{event.key}") child_span.set_attribute("flops", event.flops) child_span.set_attribute("memory_usage_mb", event.self_cpu_memory_usage / 1024 / 1024) child_span.end() # Step 4: 记录最终输出与状态 span.set_attribute("output_shape", str(list(output.shape))) span.set_status(Status(StatusCode.OK)) return {"result": output.tolist(), "trace_id": span.context.trace_id}

这个写法看似繁琐，但它解决了三个致命问题：

• 跨进程追踪：DataLoader的worker进程会继承父进程的TracerProvider，contextvars确保span context不丢失；
• GPU算子可见：直接暴露torch.profiler的原始数据，比黑盒监控nvidia-smi更能定位是卷积层慢还是BN层慢；
• 内存泄漏预警：self_cpu_memory_usage能捕捉到torch.cat()等操作引发的CPU内存暴涨，提前于GPU OOM告警。

提示：torch.profiler在生产环境开启会有3%-5%的性能损耗，但我们通过动态开关控制——只在model_version包含-debug后缀的服务实例中启用，其他实例关闭。这需要在服务启动时读取环境变量ENABLE_PROFILER，并在span创建时检查。

3.2 指标命名不是小事：遵循OpenMetrics规范，避免“指标雪崩”

见过太多团队把指标命名为my_model_latency_seconds，结果在Prometheus里出现my_model_latency_seconds_count、my_model_latency_seconds_sum、my_model_latency_seconds_bucket三个时间序列，还纳闷为什么存储暴涨。正确的做法是严格遵循 OpenMetrics规范 ，使用_total后缀表示计数器（counter），_duration_seconds表示直方图（histogram）：

from prometheus_client import Counter, Histogram, Gauge # ✅ 正确：计数器用_total后缀 MODEL_ERRORS_TOTAL = Counter( "model_errors_total", "Total number of model inference errors", ["model_name", "error_type"] # 标签：按模型名和错误类型细分 ) # ✅ 正确：延迟用_duration_seconds_histogram MODEL_INFERENCE_DURATION_SECONDS = Histogram( "model_inference_duration_seconds", "Model inference duration in seconds", ["model_name", "device"], # 标签：区分CPU/GPU buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.0, 5.0, 10.0) # P99需覆盖到10s ) # ✅ 正确：GPU显存用_gauge（可增可减） GPU_MEMORY_USED_PERCENT = Gauge( "gpu_memory_used_percent", "GPU memory usage percent", ["device_uuid", "model_name"] )

关键细节在于buckets的设置。我们曾因buckets=(0.1,0.2,0.5)太窄，导致95%的请求落在+Inf桶里，P99计算完全失真。经过线上压测，最终确定电商推荐场景的合理bucket为(0.01,0.025,0.05,0.1,0.25,0.5,1.0,2.0,5.0,10.0)——这覆盖了从毫秒级（特征缓存命中）到秒级（冷启动加载）的全范围。计算P99的PromQL公式也因此固定为：
histogram_quantile(0.99, sum(rate(model_inference_duration_seconds_bucket[1h])) by (le, model_name))

3.3 日志结构化：用JSON而非文本，让Loki成为你的SQL引擎

把日志写成logger.info(f"Model {model_name} processed {batch_size} samples in {latency:.2f}s")是初级做法。Loki的强大在于它能把日志当数据库用，前提是日志是结构化的JSON。我们的标准日志格式如下：

{ "level": "INFO", "service": "recommend-api", "model_name": "rec_v4_prod", "model_version": "sha256:abc123...", "trace_id": "0123456789abcdef", "span_id": "fedcba9876543210", "input_batch_size": 32, "input_feature_dim": 128, "latency_ms": 142.3, "gpu_memory_used_mb": 12450.2, "cache_hit_rate": 0.92, "timestamp": "2024-05-20T14:23:45.123Z" }

生成这段JSON的关键是预计算+零拷贝：

• trace_id和span_id直接从OpenTelemetry context中提取，避免字符串拼接；
• gpu_memory_used_mb调用torch.cuda.memory_allocated()而非nvidia-smi，减少进程调用开销；
• cache_hit_rate在特征加载层就统计好，不等到推理结束再计算。

这样做的好处是，Loki查询变得极其高效：

• 查看某模型版本的错误TOP10：{service="recommend-api"} | json | model_version =~ "rec_v4.*" | level == "ERROR" | __error__ | count_over_time(| __error__ | [1h]) | __error__
• 定位慢请求的特征维度：{service="recommend-api"} | json | latency_ms > 500 | unpack | input_feature_dim

注意：unpack是Loki的高级功能，它能将JSON日志的key自动展开为标签，无需预先配置。但前提是日志必须是合法JSON且无嵌套过深（我们限制JSON深度≤3层），否则unpack会失败。

4. 实操过程与核心环节实现：从零搭建可观测流水线，重点攻克GPU指标采集与告警联动

4.1 GPU指标采集：绕过nvidia-smi，直取DCGM的C API

nvidia-smi是运维神器，但作为监控采集器它有硬伤：

• 调用开销大（每次执行需启动新进程，耗时~100ms）
• 数据粒度粗（默认1秒刷新，无法捕捉毫秒级抖动）
• 无法获取NVLink带宽、PCIe吞吐等关键指标

我们的方案是集成 NVIDIA Data Center GPU Manager (DCGM) 的Python绑定dcgm_bindings，直接调用C API获取亚毫秒级指标：

# 安装DCGM（需NVIDIA驱动≥450.80.02） wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/datacenter-gpu-manager_3.2.2-1_amd64.deb sudo dpkg -i datacenter-gpu-manager_3.2.2-1_amd64.deb sudo systemctl enable dcgmd sudo systemctl start dcgmd

import dcgm_structs, dcgm_agent, dcgm_fields from prometheus_client import Gauge # 初始化DCGM dcgm_structs._dcgmInit() handle = dcgm_agent.dcgmHostConnect(None) # 创建GPU指标Gauge GPU_UTILIZATION = Gauge('gpu_utilization_percent', 'GPU utilization percent', ['gpu_uuid']) GPU_MEMORY_USED_MB = Gauge('gpu_memory_used_mb', 'GPU memory used in MB', ['gpu_uuid']) GPU_PCIE_TX_BYTES = Gauge('gpu_pcie_tx_bytes_total', 'GPU PCIe TX bytes', ['gpu_uuid']) def collect_gpu_metrics(): # 获取所有GPU设备 device_list = dcgm_agent.dcgmGetAllDevices(handle) for gpu_id in device_list: # 获取GPU UUID（唯一标识，比索引更稳定） uuid = dcgm_agent.dcgmGetDeviceAttributes(handle, gpu_id).identifiers.uuid # 采集利用率（字段ID 1001） util = dcgm_agent.dcgmGetLatestValuesForFields(handle, [gpu_id], [1001])[0].value.iVal GPU_UTILIZATION.labels(gpu_uuid=uuid).set(util) # 采集显存使用（字段ID 1002） mem_used = dcgm_agent.dcgmGetLatestValuesForFields(handle, [gpu_id], [1002])[0].value.iVal GPU_MEMORY_USED_MB.labels(gpu_uuid=uuid).set(mem_used / 1024 / 1024) # 转MB # 采集PCIe TX（字段ID 1004） pcie_tx = dcgm_agent.dcgmGetLatestValuesForFields(handle, [gpu_id], [1004])[0].value.iVal GPU_PCIE_TX_BYTES.labels(gpu_uuid=uuid).set(pcie_tx) # 每5秒采集一次（比nvidia-smi快20倍） while True: collect_gpu_metrics() time.sleep(5)

这个脚本被部署为K8s DaemonSet，每个GPU节点运行一个Pod，通过hostNetwork: true直连DCGM服务。相比nvidia-smi，它带来三大收益：

• 延迟降低95%：采集耗时从100ms降至5ms；
• 指标丰富度提升3倍：新增NVLink带宽、温度、功耗、ECC错误计数等20+项；
• 稳定性增强：DCGM服务常驻内存，不受nvidia-smi进程竞争影响。

4.2 告警规则设计：从“阈值告警”升级到“模式识别告警”

传统告警如gpu_utilization_percent > 90会产生大量误报（比如模型预热时GPU利用率短暂冲高）。我们的升级策略是多维关联告警，用Prometheus的高级函数构建“异常模式”：

这些规则全部配置在prometheus.rules.yml中，并通过Argo CD同步到K8s集群。关键技巧是：所有告警都附带runbook_url标签，指向内部Confluence文档，里面详细说明排查步骤。例如GPU显存泄漏告警的runbook会指导：

1. 登录对应节点，执行dcgmi dmon -e 1002 -d 5（实时监控显存）
2. 在Jaeger中搜索trace_id匹配model_inference且gpu_memory_used_mb持续上升的Trace
3. 检查该Trace中torch.cat()操作的输入张量shape是否异常增大

4.3 灰度发布与自动回滚：用Argo Rollouts实现“模型级”金丝雀

模型上线最大的风险不是“模型不准”，而是“模型准但拖垮整个服务”。我们弃用K8s原生Deployment的滚动更新，改用 Argo Rollouts ，因为它支持基于指标的渐进式发布：

apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: recommend-model spec: strategy: canary: steps: - setWeight: 5 # 先切5%流量 - pause: {duration: 5m} # 观察5分钟 - setWeight: 20 # 再切20% - analysis: templates: - templateName: latency-check args: - name: service value: recommend-api - setWeight: 50 - pause: {duration: 10m} - setWeight: 100 analysisTemplates: - name: latency-check spec: args: - name: service metrics: - name: p99-latency interval: 30s successCondition: result[0].value < 200 # P99<200ms才继续 failureLimit: 3 # 连续3次失败则回滚 provider: prometheus: address: http://prometheus-server.monitoring.svc.cluster.local:9090 query: | histogram_quantile(0.99, sum(rate(model_inference_duration_seconds_bucket{service="{{args.service}}"}[5m])) by (le))

这个Rollout的精妙之处在于：

• 指标驱动决策：每一步权重提升前，都强制执行Prometheus查询，验证P99延迟达标；
• 失败自动回滚：若连续3次查询失败（如P99>200ms），Argo Rollouts会自动将流量切回旧版本，并发送Slack告警；
• 与可观测栈深度集成：analysisTemplates直接复用已有的Prometheus指标，无需额外开发。

我们实测过，当v4模型因特征工程bug导致P99延迟飙升时，系统在第2次latency-check失败后（约1分30秒内）完成回滚，全程无人工干预，业务影响控制在5%流量、90秒内。

5. 常见问题与排查技巧实录：那些只有亲手部署过才会懂的“幽灵Bug”

5.1 问题：Prometheus指标显示GPU利用率100%，但nvidia-smi显示只有65%

现象描述：
Grafana面板中gpu_utilization_percent曲线持续在100%，但登录节点执行nvidia-smi看到Volatile GPU-Util稳定在65%左右，且模型推理延迟正常。告警频繁触发，但实际业务无感知。

根因分析：
DCGM的gpu_utilization_percent（字段ID 1001）测量的是GPU核心（SM）的活跃周期占比，而nvidia-smi的Volatile GPU-Util测量的是GPU核心在最近采样窗口内的平均利用率。当模型存在大量短时爆发性计算（如小批量推理），DCGM可能在某个微秒级窗口内捕捉到SM 100%忙碌，而nvidia-smi的1秒采样窗口将其平滑为65%。这不是Bug，而是测量粒度差异。

排查步骤：

1. 在问题节点执行dcgmi dmon -e 1001 -d 0.1（100ms粒度监控），观察是否出现尖峰；
2. 对比dcgmi dmon -e 1001 -d 1（1秒粒度）与nvidia-smi输出是否一致；
3. 检查Prometheus的scrape_interval是否设为15s，若设为1s会导致DCGM高频调用，加剧尖峰放大效应。

解决方案：

• 调整Prometheus采集间隔：将scrape_interval从1s改为15s，与DCGM默认采样对齐；
• 修改告警逻辑：将gpu_utilization_percent > 90改为avg_over_time(gpu_utilization_percent[5m]) > 85，用5分钟均值过滤尖峰；
• 补充指标：增加gpu_sm__inst_executed（执行指令数）指标，与利用率联合判断是否真过载。

实操心得：不要迷信单一指标。GPU利用率100%不等于过载，要看gpu_memory_used_percent是否同步飙升、gpu_pcie_tx_bytes_total是否达到带宽上限。我们最终的“过载”判定公式是：(avg_over_time(gpu_utilization_percent[5m]) > 85) and (avg_over_time(gpu_memory_used_percent[5m]) > 90) and (rate(gpu_pcie_tx_bytes_total[5m]) > 10e9)（PCIe带宽>10GB/s）。

5.2 问题：Loki日志查询超时，但日志量并未激增

现象描述：
Loki查询{service="recommend-api"} | json | latency_ms > 500经常超时（>30s），但loki-distributor的CPU和内存使用率正常，S3存储桶的请求QPS也平稳。

根因分析：
Loki的查询性能高度依赖日志标签的选择性。当{service="recommend-api"}匹配到数百万条日志，而latency_ms > 500又是一个低选择性条件（假设10%请求超时），Loki需扫描海量日志块。更隐蔽的问题是：我们的日志中model_version标签值过多（如sha256:abc123...、sha256:def456...），导致Loki的索引碎片化，查询时需打开更多对象存储文件。

排查步骤：

1. 执行loki -query '{service="recommend-api"}' --limit 1，确认基础查询是否快；
2. 用loki -query '{service="recommend-api", model_version=~"rec_v4.*"}' --limit 1测试带model_version正则的查询耗时；
3. 检查Loki配置中的chunk_store_config.max_look_back_period是否过长（默认72h），导致查询需扫描过多历史块。

解决方案：

• 标签精简：将model_version从完整SHA256哈希，简化为rec_v4_prod、rec_v4_staging等语义化标签，减少标签基数；
• 查询优化：强制添加高选择性标签，如{service="recommend-api", env="prod"} | json | latency_ms > 500；
• 索引调优：在Loki配置中增加table_manager.retention_deletes_enabled: true，并设置retention_period: 168h（7天），避免索引无限膨胀。

5.3 问题：Jaeger中找不到完整的请求链路，Trace断在特征服务

现象描述：
前端请求/recommend，Jaeger中只看到recommend-api的span，下游feature-store-service的span缺失，trace_id在日志中存在但Jaeger不显示。

根因分析：
这是典型的跨服务上下文传播失败。recommend-api用OpenTelemetry Python SDK，而feature-store-service是Java写的，用的是Jaeger Java Client。两者默认的trace context传播格式不同：Python SDK默认用W3C TraceContext（traceparentheader），而老版Jaeger Java Client用Jaeger格式（uber-trace-idheader）。

排查步骤：

1. 在recommend-api的HTTP客户端中打印发出的headers，确认是否含traceparent；
2. 在feature-store-service的入口处打印收到的headers，确认是否含traceparent或uber-trace-id；
3. 检查feature-store-service的Jaeger配置，是否启用了propagation=jaeger,w3c。

解决方案：

• 统一传播协议：在recommend-api中强制使用Jaeger格式（兼容旧服务）：

  from opentelemetry.propagators.jaeger import JaegerPropagator from opentelemetry.trace import set_global_textmap set_global_textmap(JaegerPropagator())

• 升级Java Client：将feature-store-service的Jaeger依赖升级到1.8.0+，并配置propagation=jaeger,w3c；
• 兜底方案：在recommend-api调用feature-store-service前，手动将trace_id注入到URL参数或body中，下游服务解析后手动创建span。

实操心得：跨语言追踪是MLOps中最易被忽视的“暗礁”。我们的经验是：上线新服务前，必须用curl -v手动测试header传播。一个简单的测试用例：curl -H "traceparent: 00-12345678901234567890123456789012-1234567890123456-01" http://feature-store/health，看下游是否能在日志中打印出trace_id=12345678901234567890123456789012。这比任何文档都可靠。

5.4 问题：模型服务内存持续增长，但Python gc.get_stats()显示无异常

现象描述：
recommend-apiPod的内存使用率每小时增长2%，48小时后OOM被K8s Kill。gc.get_stats()显示代0/1/2的回收次数正常，objgraph.show_growth()未发现明显泄漏对象。

根因分析：
PyTorch的GPU内存管理与Python GC是两套独立系统。gc.get_stats()只监控Python对象，而真正的泄漏源是CUDA缓存。PyTorch为加速GPU内存分配，会缓存已释放的显存块（cudaMalloc/cudaFree），这些缓存不被Python GC感知，但会持续占用GPU显存，最终导致CUDA out of memory。

排查步骤：

1. 在服务中定期打印torch.cuda.memory_summary()，观察reserved（预留）与allocated（已分配）的差值；
2. 执行nvidia-smi，确认Memory-Usage是否与reserved值接近；
3. 检查代码中是否有torch.cuda.empty_cache()调用，但位置不当（如放在finally块中，但异常时未执行）。

解决方案：

• 主动清理缓存：在每次推理结束后，添加torch.cuda.empty_cache()，但需包裹在try/except中防止CUDA error中断流程；
• 限制缓存大小：在服务启动时设置os.environ['PYTORCH_CUDA_ALLOC_CONF'] = 'max_split_size_mb:128'，限制