问题定位：当 LLM 可观测性遇上 FinOps

在部署 DeepSeek-V4 推理服务时，我们常遇到两类矛盾： 1. 标签爆炸：为分析延迟分布，给每个 trace 打上模型版本、路由策略、租户ID等标签后，Prometheus 指标基数激增 2. 成本失真：token 账单与 tracing 数据对不上，突发流量下无法定位是恶意调用还是正常业务增长

关键维度设计

必选标签（控制基数）

• model_family=deepseek-v4：区分基础模型
• route_type=fallback|direct：识别降级调用
• status_code=429|500|200：成功/限流/错误
• cost_center=：对接财务分账

可选标签（动态采样）

• prompt_template_hash：仅错误请求全量记录
• user_agent：按 1% 比例采样
• input_length_bucket=：按 <512/512-2048/>2048 分桶

采样策略实战

错误请求全采样（含 4xx/5xx），成功请求按梯度采样： - QPS<100：全采样 - 100<QPS<1000：10% 采样 - QPS>1000：1% 采样 + 熔断告警

# Jaeger 采样配置示例
sampler = RemoteControlledSampler(
    group="deepseek-prod",
    strategy=PerOperationSampler(
        strategies={
            "complete": ProbabilisticSampler(rate=0.1),
            "stream": RateLimitingSampler(max_traces_per_second=100)
        }
    )
)

与 token 账单对账

1. 时间窗口对齐：
2. 账单按小时汇总
3. tracing 数据需做相同 time bucket 聚合
4. 关键校验点：
5. 差异率 >5% 时触发告警
6. 重点检查 streaming 请求的 token 计数

成本告警设计

静态阈值（适用于稳定业务）

• 单请求成本 > $0.05
• 同一 user_id 突发调用量 10 倍于基线

动态基线（推荐）

-- 基于 7 天滚动标准差计算异常值
SELECT 
    cost_center,
    PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY token_count) as p99,
    AVG(token_count) + 3*STDDEV(token_count) as upper_bound
FROM tracing_data
WHERE timestamp > NOW() - INTERVAL '7 days'
GROUP BY cost_center

数据保留权衡

数据类型	保留周期	存储策略
原始 trace	24h	对象存储冷备
聚合指标	30d	Prometheus TSDB
计费明细	1年	数据湖分区

实施检查清单

1. [ ] 定义标签基数预算（建议 <10,000 基数/服务）
2. [ ] 配置采样策略梯度
3. [ ] 部署对账作业（推荐 Airflow 每小时运行）
4. [ ] 设置熔断规则（如 5min 内成本超月度预算 1%）

边界说明

• 不适用于：非 DeepSeek 系模型、非计费场景
• 主要风险：采样率过低可能导致长尾问题漏检

深度扩展：可观测性管线的工程优化

1. 分布式追踪的代价控制

在 DeepSeek-V4 的高并发场景下，全量采集 trace 数据会导致： - 存储成本指数级增长 - 采集器成为性能瓶颈

解决方案： - 动态采样率调整：基于请求优先级自动调节 - 高优先级业务请求：100% 采样 - 低优先级测试请求：1% 采样 - 关键路径标记：对影响 P99 延迟的关键路径强制采样

2. 指标聚合的智能降维

当标签组合超过 10,000 种时： - Prometheus 内存占用暴增 - 查询性能急剧下降

优化策略： - 分级聚合： - 原始指标保留 24h - 按业务维度预聚合后保留 7d - 自动标签修剪：

# 自动识别低基数标签
def prune_labels(metrics):
    for label in metrics.labels:
        if len(metrics.unique(label)) < 5:
            metrics.drop(label)

3. 成本异常检测算法

传统阈值告警的不足： - 无法适应业务自然增长 - 误报率高

进阶方案： - 时间序列预测：

from prophet import Prophet

# 训练成本预测模型
model = Prophet(interval_width=0.99)
model.fit(historical_data)

# 检测异常点
forecast = model.make_future_dataframe(periods=24, freq='H')
anomalies = forecast[forecast['yhat_upper'] < actual_cost]

4. 存储架构选型对比

方案	写入吞吐	查询延迟	成本/GB/月	适用场景
Prometheus	高	低	$1.2	实时监控
Elasticsearch	中	中	$2.5	全文检索
ClickHouse	极高	极低	$0.8	分析型查询
S3 + Athena	低	高	$0.3	冷数据归档

实战案例：电商客服场景的优化

问题现象： - 促销期间 token 成本飙升 300% - 无法区分正常咨询与恶意爬取

解决步骤： 1. 在网关层注入请求特征标签： - is_robotic=true/false - marketing_campaign=双11 2. 建立成本热力图：

SELECT 
    hour,
    is_robotic,
    SUM(token_count) as total_tokens
FROM traces
WHERE date = '2026-11-11'
GROUP BY 1, 2

3. 发现 40% token 消耗来自 robotic 请求 4. 增加人机验证环节后成本回落

长期演进方向

1. 预测式伸缩：
2. 基于历史规律预分配 GPU 资源
3. 智能熔断：
4. 检测异常模式自动降级
5. 多租户隔离：
6. 确保单个租户不会挤占全局资源

关键取舍原则

1. 精度 vs 成本：
2. 核心业务指标保持高精度
3. 辅助指标允许适当降采样
4. 实时 vs 批处理：
5. 告警需要实时流处理
6. 报表适合批处理
7. 集中 vs 分散：
8. 关键组件集中监控
9. 边缘服务分散采集

最终建议

1. 上线前用 1% 流量验证采样策略
2. 建立基线时排除已知异常时段
3. 定期审查标签使用效率（推荐每月）