成本×延迟×质量 Pareto 面板 — 没有最优模型，只有前沿上的取舍

日期: 2026-07-31 阶段: Phase 2 - AI-native 参考架构 标签: #pareto-frontier #multi-objective #model-selection #observability

核心问题

P2 到现在已经把 AI gateway（Day 44-46）、语义缓存、多 provider 路由都摆上了台面。但有个产品层的决策一直没量化：AML Copilot 的每一步——typology 分类、SAR 起草、judge 评分——到底该用哪个模型？ 直觉答案是「用最强的」或「用最便宜的」。今天证明这两个直觉都错。

真正的问题是一个三目标优化：成本（$/1M token）、延迟（端到端响应）、质量（eval 分）三者互相打架——更强的模型更贵更慢，更快的模型质量掉档。不存在一个模型在三个维度上同时碾压其他所有模型。这就是为什么需要 Pareto 前沿（Pareto frontier）：它不给你「一个最优解」，而是给你一组无法被同时改进的取舍点，把「选哪个模型」从拍脑袋变成「在前沿上按业务约束挑一个点」。

今天回答两件事：(1) 怎么严格定义这个前沿（什么叫「一个模型支配另一个」）；(2) 怎么把仓库里三个互相独立的数据源（gateway 计量、eval 质量、trace 延迟）汇聚成一张可交互的面板。

关键内容

A. 帕累托前沿的形式化定义：什么叫「被支配」

多目标优化的核心概念是支配（dominance）。设候选集合 $S$（每个元素是一个「模型 + 配置」，如 claude-opus-4.6@temp0），每个配置 $x$ 有三个度量：质量 $Q(x)$（越高越好）、成本 $C(x)$（越低越好）、延迟 $L(x)$（越低越好）。

LLMRouterBench (arXiv 2601.07206, 2026-01) 给出二维（质量×成本）的支配定义，我把它扩到三维：

$$x \text{ 支配 } y \iff Q(x) \ge Q(y) \land C(x) \le C(y) \land L(x) \le L(y) \text{，且至少一个不等式严格成立}$$

Pareto 前沿 = $S$ 中不被任何其他配置支配的所有点的集合：

$$P = { x \in S : \nexists, y \in S,\ y \text{ 支配 } x }$$

前沿上的点彼此不可比——要质量更高，就得接受更贵或更慢；没有免费的提升。判定算法（朴素 $O(n^2)$，候选数 $n$ 才几十个，够用）：

function paretoFrontier(configs):           # configs[i] = {q, c, l}
  frontier = []
  for x in configs:
    dominated = false
    for y in configs:
      if y != x
         and y.q >= x.q and y.c <= x.c and y.l <= x.l   # y 各维不差于 x
         and (y.q > x.q or y.c < x.c or y.l < x.l):      # 且至少一维严格更好
        dominated = true; break
    if not dominated: frontier.push(x)
  return frontier

到前沿的距离也能量化——一个被支配的点离前沿多远，决定了它有多「亏」。LLMRouterBench 用 L1 范数：$\text{ParetoDist} = \frac{1}{|\Theta|}\sum_{\theta}\min_{y\in P}\lVert \tilde\theta - \tilde y \rVert_1$（各维先归一化到 [0,1] 再算曼哈顿距离）。这给了产品一个直接指标：当前选的模型离前沿差多少，是不是该换。

B. 三维不可比的真实数据：1000× 价差只换 8 分质量

抽象定义不如真实数字震撼。看 2026-Q2 OpenRouter 上 20 个前沿模型的实测（digitalapplied, 2026-Q2）：

反直觉洞察①（1000× 价差只买到 8 分质量）：输入单价从 $0.03/1M（LFM2 24B）到 $30/1M（GPT-5.4 Pro）是1000 倍的价差，但质量分（Artificial Analysis Index）从 ~49 到 ~57 只跨 8 分。价格的范围根本不匹配质量的范围。这意味着——「贵 = 好」是线性幻觉：质量随成本是严重次线性（边际收益急剧递减），多花 1000 倍钱换不到 1000 倍质量，连 1.2 倍都不到。对 AML Copilot 的直接含义：typology 分类这种结构化任务，强行上 Opus 是纯烧钱，前沿告诉你 $0.10 的 Nemotron 质量只差 6 分却便宜 100 倍。

更狠的是延迟维度。LLMRouterBench (2026-01) 实测：Qwen3-Thinking 和 GLM-4.6 性能和成本几乎一样，但延迟差了 8 倍——262.1s vs 32.4s。两个模型在「质量×成本」二维平面上几乎重叠，看似可互换；一旦把延迟拉进来，前者立刻被后者支配出局。只看二维会选错模型——这正是为什么面板必须是三维的。

反直觉洞察②（同质同价的两个模型，延迟可差 8 倍）：如果只用「质量 + 成本」选型（业界绝大多数 router 论文止步于此——LLMRouterBench 明说「to our knowledge, no methods explicitly target the joint performance-cost-latency tradeoffs」），你会把 262s 的模型和 32s 的模型当成等价选项随机抓一个。延迟是隐藏的第三轴，不画出来就踩。AML SAR 起草是人工复核工作流的一环，分析师盯着等 4 分钟和等 30 秒是天壤之别——延迟在这里直接是产品维度。

C. 三源数据汇聚：面板的数据流

面板的难点不在画图，在三个度量来自三个互相独立的子系统，且口径必须对齐到「同一个模型配置」这个 join key：

  [成本轴 C]              [质量轴 Q]              [延迟轴 L]
  AI gateway 计量         eval harness            trace store
  (Day 44-46)            (P1 评测底座)            (useTraceStore)
  每次调用记 input/        66 案 SAR 跑           startStep→endStep
  output token × 单价     evalChecks + judge      时间戳差
       │                      │                      │
       │  按 (model, task) 聚合  │  按 model 取 judge 均分 │  按 model 取 p50/p95
       └──────────┬───────────┴──────────┬───────────┘
                  ▼                       ▼
         join on configKey = `${model}@${task}`
                  │
                  ▼
        ┌────────────────────────────┐
        │  paretoFrontier(configs)    │ ← B 节算法
        │  标记每点 onFrontier: bool   │
        │  算 paretoDist（离前沿距离） │
        └─────────────┬──────────────┘
                      ▼
        散点图（X=成本 Y=质量，点大小/颜色=延迟）
        前沿点连线高亮，被支配点灰显

三个口径对齐的坑：

• 成本：gateway 记的是 token 数，单价是快照（CostMeter 已诚实标注「模型单价为快照/部分占位」）。前沿用混合单价（blended = input/output 加权），否则纯比 input 价会误导。
• 质量：必须是同一批 66 案 SAR跑出来的 judge 分（Day 17 已校准 κ≥0.6 的 judge），不同模型不能用不同样本，否则质量轴不可比。
• 延迟：取 p95 而非均值——AML 是合规工作流，尾延迟（最慢的 5%）才是分析师真实痛点；均值会被快请求拉低、掩盖长尾。

反直觉洞察③（前沿是动态的，每次新模型发布都要重算）：Pareto 前沿不是一次算完的静态结论。2026-Q2 有 20 个模型只 6 个在前沿；新模型（如某厂下个月发的更便宜模型）一发布，可能直接把现有前沿点挤成被支配。面板必须能重跑——这正是要走 dsdb-lab 交互装置模式（而非一张死图）的原因：用户调单价、换 eval 样本、切 p50/p95，前沿实时重算，看清「换个假设前沿就变」。

dsdb-lab 交互装置模式的复用

dsdb-lab 的 DemoShell（canvas + controls + 叙事条 + lens 切换）正是这张面板要的骨架：

• canvas：散点图（成本×质量），延迟编码为点的大小/颜色，前沿点连线。
• controls：滑杆调单价快照、下拉切 eval 样本子集、p50/p95 切换、按 task 过滤（typology / SAR / judge 分开看前沿——不同任务前沿不同）。
• lens：复用「tradfi / web3」镜头不合适，这里改成按任务的镜头（分类任务 vs 生成任务前沿形状不同）。
• 叙事条：实时显示「当前选中模型 vs 前沿最近点」的 paretoDist，一句话告诉用户「你现在亏了多少」。

设计要点/决策表

对本项目的落地

• 新建 src/agent/pareto/paretoFrontier.ts：导出 paretoFrontier(configs: Config[]) → { config, onFrontier, paretoDist }[]，实现 B 节 $O(n^2)$ 支配判定与 L1 归一化距离；纯函数无 React 依赖，可单测（构造「被支配/前沿」反例断言）。Config = { configKey, model, task, costPer1M, qualityScore, latencyP95Ms }。
• 新建 src/agent/pareto/aggregateSources.ts：三源汇聚适配器——从 useTraceStore（延迟：endedAt - startedAt 按 model 聚 p95）、P1 eval 产物（质量：judge 均分）、gateway 计量（成本：token×快照单价）三处各取所需子集，join 到 configKey。不 import 三个子系统的实现，只声明所需字段子集（沿用 attributeMap.ts 的「结构化解耦」模式，见其 StepTraceSubset）。
• 面板组件 src/agent/pareto/ParetoPanel.tsx：套 dsdb-lab/shell/DemoShell 模式（canvas=散点图、controls=单价滑杆/样本切换/p50-p95 切换），挂到 agent-lab 的新 tab。Day 48 用 gateway 实测数据填真实数字定稿。
• 诚实标注：paretoFrontier.ts 头注明确——质量分依赖 P1 judge 校准（κ≥0.6 才可信）、成本单价为快照、延迟 p95 来自浏览器内模拟 trace（W1-W2 用占位/小样本，真实数字待 Day 48 gateway 接通后回填）；前沿「重算」交互为 P2 装置目标，本日仅落算法 + 汇聚函数 + 面板骨架。

参考资料

1. arXiv 2601.07206 — LLMRouterBench: A Massive Benchmark and Unified Framework for LLM Routing：Pareto 支配定义 AvgAcc(x)≥AvgAcc(y) ∧ Cost(x)≤Cost(y) + 至少一严格；前沿=不被支配集；ParetoDist L1 范数；「no methods explicitly target joint performance-cost-latency tradeoffs」；Qwen3-Thinking vs GLM-4.6 延迟 262.1s vs 32.4s；延迟数据采于 OpenRouter 2026-01-05 (2026-01)
2. digitalapplied — AI Model Efficient Frontier Q2 2026: Performance vs Price：20 个模型仅 6 个在前沿；单价 $0.03–$30/1M（1000×）但质量仅 49–57（AA Index，8 分跨度）；前沿三轴=质量×成本×速度；6 个前沿模型清单（Qwen 3.6 Plus / Nemotron 3 Super / MiniMax M2.7 / MiMo V2 Pro / Sonnet 4.6 / Opus 4.6）(2026-Q2)
3. 本仓库 src/dsdb-lab/shell/DemoShell.tsx（canvas+controls+叙事条交互装置模式）、src/agent/trace/useTraceStore.ts（延迟数据源）、src/aml/observability/attributeMap.ts（结构化解耦/Subset 模式）、src/agent/ui/CostMeter.tsx（成本口径与快照标注）(2026-06)

SOTA 检查 (2026-06-11)

• 三目标 Pareto 选型在 2026-06 是 live 的前沿问题，尚无成熟工业方案：LLMRouterBench (2026-01) 明确指出「据我们所知，没有方法显式针对性能-成本-延迟联合权衡」——业界 router（RouteLLM 等）仍主要二维（质量×成本）。本面板把延迟拉成第三轴，方向与最新研究一致，是「补业界空白」而非复述成熟实践。
• 前沿模型清单半年即过时：digitalapplied 的 6 模型前沿是 2026-Q2 快照；Claude Opus/Sonnet 版本号、各厂混合单价每月在变。面板设计成「可重算装置」正是为对抗这种过时——Day 48 接 gateway 后用实测数据，且须在 UI 标注「数据快照日期」。
• 加权合成分 vs 保留前沿的争论仍在：部分工程团队图省事把三维压成一个加权分（如 0.5×质量−0.3×成本−0.2×延迟）排序选 top1。这丢掉了取舍可见性、且权重无原则。本笔记坚持保留前沿（不合成），与多目标优化学术共识一致；若 P3 要做自动选型，可在前沿上再叠业务约束（如「延迟<30s 内选质量最高」）做约束下的单点挑选，而非全局加权。
• 待跟踪：Day 48 gateway 实测后，验证「66 案 SAR + κ≥0.6 judge」的质量轴是否稳定（小样本方差大）；评估是否需要把成本轴从「快照单价」升级为「gateway 实际计费」闭环；关注是否有新 router 论文开始做真三维前沿，若有则对齐其算法。