上周深夜收到告警，线上推荐服务的响应延迟突然从50ms飙到800ms。登录服务器一看，CPU使用率正常，内存也没溢出，模型推理的batch size配置也没变。最后在监控面板的角落里发现：输入特征的长度分布最近一周悄悄从平均256维涨到了1024维——某个上游特征工程服务改了参数没同步通知。这个坑让我再次确认：模型上线只是开始，真正的挑战在于让它稳定地跑下去。

一、监控：给模型装上仪表盘

模型监控不是简单的服务存活检查。你得知道模型在“想”什么、怎么“工作”。

基础监控项必须覆盖：

# 监控埋点示例
class ModelMonitor:
    def __init__(self):
        self.request_counter = Counter()  # 请求量
        self.latency_histogram = Histogram()  # 延迟分布
        self.error_gauge = Gauge()  # 错误率
        
    def inference(self, input_data):
        start = time.time()
        
        # 关键：记录输入特征统计
        self.record_feature_stats(input_data)  # 均值、方差、缺失率
        
        try:
            output = model.predict(input_data)
            
            # 记录输出分布（防止输出崩坏）
            self.record_output_stats(output)  # 输出值分布、异常值
            
            # 业务指标（如推荐系统的CTR）
            if business_context:
                self.record_business_metric(output)
                
        except Exception as e:
            # 别只记录“有异常”，要记录异常时的输入特征
            self.log_error_with_context(e, input_data)
            raise
            
        finally:
            latency = time.time() - start
            self.latency_histogram.observe(latency)

特征漂移监控最容易忽视。我习惯用PSI（群体稳定性指数）来量化：

# 计算PSI——特征分布变化检测
def calculate_psi(base_dist, current_dist, bins=10):
    # base_dist: 训练集特征分布
    # current_dist: 线上当前特征分布
    # 返回值>0.1就要告警，>0.25必须人工干预
    
    # 这里踩过坑：连续特征要分箱，类别特征要检查新类别
    # 别直接用训练时的分箱边界，线上数据可能超出范围

线上模型最怕“静默失败”——模型照样输出结果，但质量已经下降。我的做法是部署一个影子模型：用最新数据训练的小模型并行运行，对比两个模型的输出差异，差异突然增大就是预警信号。

二、日志：让问题可追溯

模型服务的日志不能像Web服务那样只记请求和响应。关键是要能复现推理过程。

# 糟糕的日志写法
logger.info(f"Model inference finished. Latency: {latency}ms")
# 出问题时你只知道慢了，不知道为啥慢

# 有用的日志写法
class DebugLogger:
    def log_inference(self, input_data, output, context):
        # 1. 记录请求ID（便于链路追踪）
        # 2. 记录特征哈希（避免日志过大）
        feature_hash = hashlib.md5(str(input_data).encode()).hexdigest()
        
        # 3. 记录关键中间结果
        if self.debug_mode:
            # 记录第一层激活值分布
            # 记录注意力权重（NLP模型）
            # 记录重要特征的贡献度
            
        # 4. 结构化存储，方便ELK分析
        log_entry = {
            "request_id": context.request_id,
            "feature_hash": feature_hash,
            "model_version": "v2.3.1",
            "latency_ms": context.latency,
            "output_stats": {
                "mean": output.mean(),
                "std": output.std(),
                "anomaly_score": self.detect_anomaly(output)
            }
        }
        
        # 重要：采样记录，别全量打日志
        if random.random() < 0.01:  # 1%采样率
            logger.info(json.dumps(log_entry))

日志采样策略需要权衡：采样率太高影响性能，太低可能错过关键线索。我的经验是：

• 正常请求：0.1%-1%采样
• 错误请求：100%记录（包括错误输入）
• 延迟超过阈值的请求：100%记录

特别提醒：别在日志里记录完整特征向量，既占空间又可能泄露用户数据。用特征哈希加数据库存储原始数据，需要调试时再按哈希查询。

三、性能评估：不只是准确率

线上模型的评估维度要复杂得多。我常用这个评估矩阵：

延迟监控的坑：平均值会骗人。P99延迟（最慢的1%请求）才是用户体验的关键。

# 延迟统计的正确姿势
from prometheus_client import Histogram

# 错误做法：只记录平均值
avg_latency = total_time / request_count

# 正确做法：使用直方图分桶
latency_histogram = Histogram(
    'model_inference_latency_seconds',
    'Model inference latency',
    buckets=[0.01, 0.05, 0.1, 0.5, 1.0, 2.0]  # 根据业务调整
)

# 这样能统计出P50、P90、P99

资源监控有个细节：GPU利用率高不一定是好事。如果CUDA核心利用率100%但显存利用率只有30%，可能是batch size太小，没有充分利用并行能力。用nvidia-smi的dmon工具持续监控。

四、模型衰减检测与迭代

所有模型都会衰减。检测信号包括：

1. 线上AUC每周下降超过0.5%
2. 输入特征PSI连续三天>0.1
3. 用户负反馈率上升（比如推荐系统的“不感兴趣”点击增加）

我设计了一个简单的衰减检测流水线：

class ModelDecayDetector:
    def __init__(self):
        self.performance_window = deque(maxlen=30)  # 30天性能窗口
        
    def daily_check(self):
        # 收集当天指标
        daily_metrics = self.collect_metrics()
        
        # 滑动窗口计算趋势
        if len(self.performance_window) >= 7:
            trend = self.calculate_trend()
            
            # 连续3天下降就触发预警
            if trend < -0.005 and self.consecutive_days >= 3:
                self.trigger_retraining_alert()

模型版本管理容易被忽视。每次上线新模型时，保留旧模型一周，并设置流量切换开关。这样发现问题时能快速回滚。版本元数据要记录：训练数据时间范围、特征工程版本、超参数、离线评估结果。

个人经验与建议

1. 监控先行：在模型开发阶段就设计监控方案，而不是上线后补。把监控代码当作模型代码的一部分。

2. 建立基线：上线第一天记录各项指标的基线值，后续变化用相对值而不是绝对值判断。

3. 告警分级：

   • P0：服务不可用（立即电话通知）
   • P1：性能下降30%以上（30分钟内处理）
   • P2：特征漂移PSI>0.25（当天处理）
   • P3：模型衰减趋势（本周内处理）

4. 保留调试能力：线上服务永远保留一个“调试模式”开关，可以临时开启详细日志、记录完整中间结果。这个开关在排查诡异问题时能救命。

5. 性能与效果的权衡：有时候降低模型复杂度，牺牲1%的准确率，换来50%的延迟下降，在业务上是划算的。要做这个决策，必须有完善的监控数据支撑。

最后说个真事：我们有个模型跑了半年一直很稳定，突然某天凌晨效果暴跌。查遍所有监控项都正常，最后发现是某个特征的数据源服务器时钟漂移，导致时间特征全部错乱。模型监控的终极目标，是让你在喝咖啡时收到告警，而不是在凌晨三点被电话吵醒。

模型上线不是终点，而是运维的开始。好的监控能让你睡个好觉，好的日志能让你快速定位问题，好的评估体系能让你知道该往哪个方向优化。这套体系搭建起来需要时间，但绝对值得——毕竟，没人愿意在半夜两点对着生产服务器猜谜。