PowerContext 的模型路由成本结构：多模型配置面实测与四个缺口

[AlexStocks]

承接说明（先声明与既有讨论的关系，避免重复）

仓库里已有两篇高度相关的讨论，本文不重复它们的结论：

• #1736（2026-09-25）已经定下「轻量决策模型」的接入范式：provider 中立的 DecisionModel 角色、opt-in + shadow、由确定性 runtime 直接调用而非做成 MCP tool 等主模型自行决定、审计需含 provider/model ID、不替换现有 model-free recall sufficiency gate、Laya 不进内核。本文不重新论证这些。
• #1971（2026-10-13，跟踪于 #1989 / RFC #1990）走的是另一条线：输入去重 + 输出去重的 token 削减。与本文不重叠。

本文补第三个维度：这些模型调用本身的钱花在哪里，以及当前的配置面能不能表达「用便宜模型省钱」这件事。

结论摘要

1. PowerContext 已经能同时配置多个 LLM，形态是 4 个固定工作负载槽位（generation / embedding / rerank / decision），每槽独立 endpoint / headers / model_settings / timeout / max_requests，且可跨厂商。这一点比文章举的例子更早落地。
2. 但**「同槽位内换成便宜模型」这层不存在**：无候选池、无能力分档、无运行时切换。
3. 代价最直接的一处：decision 槽位未显式配置时会直接复用 generation 的 provider/model 对象 —— Judge 与生产者同价，是成本上最坏的默认形态。文章量到 Judge 占总成本 21.2%（LangChain 自测），这个默认值只会让它更高。
4. 结构上更浪费的一处：打开 rerank 会旁路掉整个 model-free recall gate，零成本的扩展路径被静默关闭，而不是按信号分层。
5. 想照文章那套「用真实数据校准」去做，当前数据不够：pc_model_usage_daily 没有模型维度，全仓没有价格模型。#1736 §2 要求审计记录含 provider/model ID —— pc_decision_observations 有，但聚合用量表和生成链路没有。
6. 建议动作与优先级见 §三。全部建议先以 opt-in / shadow 落地，与 调研：Jev / Laya 与轻量决策模型在 Agent Memory 中的应用及 PowerContext 建议 #1736 的范式保持一致。

---

一、多模型配置面（实测）

实测方式：设置环境变量后构造 ServerSettings，直接检查落地的 InferenceConfig 字段（.venv/bin/python，当前 HEAD）。

槽位	环境变量	独立字段	默认值
generation	POWERCONTEXT_SERVER_INFERENCE_GENERATION_MODEL	base_url / headers / model_settings / timeout / max_requests	None
embedding	..._INFERENCE_EMBEDDING_MODEL + _PROFILE_ID + _DIMENSION + _NORMALIZATION	base_url / headers / model_settings / timeout / batch_size	None
rerank	..._INFERENCE_RERANK_MODEL	base_url / headers / model_settings / timeout / max_requests	None → 回落 generation
decision	..._INFERENCE_DECISION_MODEL	base_url / headers / model_settings / timeout / max_requests	None → 回落 generation

四个槽位同时配置实测通过，且 rerank_base_url 可指向与 generation 完全不同的厂商。机制来自 server/settings.py:190 的 SettingsConfigDict(env_prefix="POWERCONTEXT_SERVER_", env_nested_delimiter="_", env_nested_max_split=1)。

模型串为 适配器:模型名，由 pydantic-ai infer_model 解析；带 base_url/headers 时模型串必须含 :，否则抛 inference-endpoint-provider（composition.py:1674）。

配不到的边界

1. 每槽只能一个模型：无候选池、无分档、无运行时切换或降级。
2. generation 是 14 个 prompt key 共用一口锅（注册点 composition.py:1317-1333）：profile.generate、atomic_memory.extract、atomic_memory.reconcile、experience.incubate、experience.generate、skill.generate、handoff.generate（7 项）+ topic_memory 的 7 个 stage（probe / global / planner / evolve / temporary / reduce / reconcile）。想让 topic_memory.reduce 单独用便宜模型做不到。
3. embedding 是单例，Atomic Memory 与 Topic Memory 索引共用同一个。
4. rerank / decision 只有显式设 *_MODEL（或仅设 *_HEADERS）才算独立：separate_rerank_model = rerank_model is not None or bool(rerank_headers)（composition.py:1445），decision 同构（:1567）；否则直接复用 generation 的 provider/model 对象，timeout / max_requests 也走 or generation_* 回落（:1599）。
5. CLI 向导只认 2 个角色：cli/config_wizard_models.py:31-32 只有 GENERATION（"背景整理模型"）与 EMBEDDING（"语义检索模型"）；cli/config.py 的 _INFERENCE_REPLACEMENT_NAMES 同样不含 rerank / decision。这两个槽位目前只能手写 .env。
6. 配了 4 个模型也分不清钱花在哪（见缺口 4）。

---

二、四个缺口

缺口 1（P0）：Judge 默认与生产者同价

composition.py:1558-1567：decision_provider_model = generation_provider_model、decision_model = generation_model，只有 separate_decision_model 为真才另开连接。因此不显式配置 DECISION_MODEL 时，判断成本与生产生成成本同档。

这正好落在文章量到的那个陷阱上：LangChain 的 Escalation Router 公开测试中，93% 的执行调用由低成本模型完成，但费用结构是高性能模型 68.4% / Judge 21.2% / 低成本模型 10.4%。一个默认继承生成模型的 Judge，只会让这 21.2% 更高。

memory_write_gate.py:73-95 的 promotion_criteria 已经写了 "measured fallback, latency, cost, and friction"，config.py:154 的 memory_write_gate_threshold 也刻意留空等待校准（注释：stays unset until a calibration probe establishes it）。建议把「Judge 不得默认继承生产模型」也纳入同一条准入条件：要么要求 decision_model 显式配置，要么回落到最便宜可用档。

另外 memory_write_gate.py:81 已有 local_rules=("candidate_batch_budget", "evidence_projection_budget")。文章的「三层判断」（明确异常直接判 → 一般信号累计判 → 信号模糊才调 Judge）落到这里就是：把本地规则提升为前置门，本地能定案的请求不进 decision 模型。

缺口 2（P0）：rerank 旁路掉整个 gate

recall_sufficiency.py:503-504：

if policy.rerank_enabled and not policy.allow_expansion_with_rerank:
    return GateAssessment(sufficient=True, reason=REASON_RERANK_ENABLED, signals=signals)

这个 return 位于 candidate_count、family_count、top_score、top_gap、lexical_overlap 全部判断之前。后果是：打开 rerank 等于关掉整个 gate，零模型成本的 admission 扩展路径（ACTION_ADMISSION / ACTION_POLICY_FLOOR）被完全旁路，而 REASON_THIN_CANDIDATES / REASON_THIN_FAMILIES 这些信号明明可以在不调用任何模型的前提下处理。

这与 #1736 §6「不替换现有 model-free recall sufficiency gate」是两个不同方向的风险：#1736 防的是「用模型替换确定性 gate」；这里是「一个配置开关静默停用了 gate」。

模块 docstring 解释了为什么 rerank_enabled 读配置而非读实例存在（gate 必须在搜索之前决定是否允许扩展），但没有解释为什么开启 rerank 要取代扩展而不是分层。recall_gate_allow_with_rerank 目前是唯一的逃生阀，即全开或全关。

建议：按 reason 分层，而不是在入口短路 ——

reason	处置
no-content / budget-floor	直接判足够，不花钱
thin-candidates / thin-families	走现有 admission 扩展（0 模型调用）
weak-top-1 / weak-lexical	只有这一类才升级到 rerank
at-max-rounds	停止并回报

约束：SearchPlan 的 docstring（recall_sufficiency.py:149-157）明确承诺「never names a family, never sets limit, mode or a rerank candidate bound」，理由是 Atomic Memory 的 coarse_limit → candidate_limit = max(coarse_limit*4, 32) 会使 30→100 把后端池从 120 涨到 400，RFC 1560 已否决。新的分层策略必须延续这个 same-pool 不变量，不能靠改 limit 实现升级。

缺口 3（P1）：重试是同模型盲重试

builtin/inference/pydantic_ai.py:161：retries=self._limits.max_requests - 1，而 max_requests 默认 2（config.py:299）。结构与模型选择完全解耦 —— 第 1 次失败（尤其是 schema / 校验失败）后，第二次仍然打到同一个模型。

结构化解码 / 校验失败恰恰是「当前能力不足」最强的现成信号，对应文章里 NVIDIA Stage Router 的 spinning（反复相似操作、无进展）。建议把第 2 次尝试指向更高能力档，而不是重复同一请求。 实现成本极低（只换 model 参数）。

配套需要定义「升级后保持多久」：文章提示频繁切换会丢 Prompt Cache；对 PowerContext 而言抖动代价是候选池与 embedding 复用被打破，性质类似。NVIDIA 的 capable hold（升到强模型后跑满若干轮再考虑降级）或 LangChain 的单向升级（升上去就保持到本次 Session 结束）都是可选项，但必须显式选择其中一个，不能留给默认行为。

缺口 4（P1）：用量归因不到模型，也没有价格

文章里两条数据驱动机制都依赖「按模型归因 + 折价」：

• OpenRouter Auto Router 用近 7 天同类任务的实际支出占比排序候选；
• LangChain 先从 LangSmith 真实 Thread 统计调用轮数、单 Thread 成本和最终结果，再据此设计分类标准。

当前仓库做不到：MODEL_USAGE_DAILY_TABLE（persistence/tables.py:890）主键是 (scope_id, usage_date, purpose, operation)，operation 还有 CHECK 约束只允许 generation / embedding —— 归因到 purpose，归因不到 model；InferenceUsage（builtin/inference/models.py:27）只有 requests / input_tokens / output_tokens，全仓无价格字段。

值得注意的是术语已经存在：DECISION_OBSERVATIONS_TABLE（persistence/tables.py:1123）已有 provider_id / backend_model_id / model_policy_id / requests / input_tokens / output_tokens / latency_ms。也就是说决策链路已经满足 #1736 §2 的审计要求，缺的是把同一组字段扩展到生成链路与聚合用量表。

建议：给用量表加 model_policy_id（沿用已有术语，不造新名）与可选 cost_micros。注意两点：

• operation 的 CHECK 约束意味着加模型维度会动主键；
• 按 AGENTS.md，加列走启动钩子 ensure_*_schema（挂在 open_builtin_contexts），不是 Alembic。验证必须走真实启动路径（create_server_app + TestClient），只调 SQLiteProfile.open() 会得到假阳性。

这一点与 #1971 的评测要求也直接相关 —— 它已经写明 "Measure all actual provider usage, stages, retries, and later queries; missing usage is unknown"。两份工作面对的是同一个数据缺口：pc_model_usage_daily 当前既没有模型维度，也没有把 retry 单独记出来。

---

三、值得借用的一条算术：Router 自己的成本

文章里最有迁移价值的是这个判断方法，而非任何一个架构：

把 Judge 的单次调用成本 ÷ 高低档模型之间的单次价差，得到「需要把多少流量迁移到低成本模型才能抵消 Judge 本身的费用」。如果这个比例逼近或超过 100%，说明仅靠模型切换无法覆盖路由的额外成本，这套路由在经济上不成立。

这把「要不要引入决策模型/路由」从偏好问题变成一个可以先算后做的问题。对 PowerContext 的直接含义：在补上缺口 4（模型归因 + 价格）之前，这个算术根本算不出来。因此缺口 4 虽然排 P1，却是 P0 两项的前置条件。

同一个原则的本地形态是「简单情况用便宜方法判断」：recall_sufficiency.py 已经做到零模型成本判断，这一优势应当在缺口 2 修好后保留并扩大，而不是被 rerank 开关抵消。

---

四、评估口径

文章给出了可复用的 A/B 形态，以及一个明确的负例，两者都指向同一个要求：评估的单位是「完整任务」，不是「单次调用」。

• 入口路由（LangChain Open SWE，973 个真实 Thread）：单 Thread 成本中位数 $0.94 vs 全高性能模型 $2.61（约 -64%）；PR Merge Rate 29.2% vs 27.3%，差异未达统计显著。
• 动态升级（145 个多步骤 Agent Task）：全高性能 86.00% / $11.45，动态 Escalation 80.00% / $3.00，全低成本 77.70% / $0.72。相对全高性能模型省约 74% 成本但准确率掉 6 个百分点；相对全低成本模型只提升 2.3 个百分点，却贵约 4.2 倍。

对 PowerContext 而言，recall gate / rerank / write gate 这三个开关的评估应输出三列：完整任务成功率、总成本、执行时间，且必须包含「全便宜档」作为基线 —— 上述负例正是缺基线的后果。

需要如实标注的现状：仓库内的 token_reduction 是「召回已选对前提下的压缩率」，不是端到端收益；仓库内也没有「任务成功率提升」的对照证据。这一点与 #1971 的评测设计和 #1736 §3 的对照实验要求方向一致，可以合并考虑。

---

五、不建议照搬的部分

文章中的做法	为什么不适用于 PowerContext
语义路由（Embedding 相似度选档）	PowerContext 的工作负载划分是编译期确定的（谁调用谁已知），不是运行时猜用户意图。引入分类器只会多一次 embedding 成本与一次误判面
~30 类任务分类器	ModelUsagePurpose 的 9 个枚举值已是更可靠的人工任务分类，不需要再训 / 调一个分类器去逼近它
多轮会话粘滞（sticky model）	只对开放式多轮对话 Agent 有意义；PowerContext 的调用点是确定性 pipeline 阶段，不存在「候选排名微抖动」这个问题

---

六、顺带发现两项

1. 环境变量名写错会被静默忽略。 ServerSettings 使用 SettingsConfigDict(extra="ignore")（server/settings.py:190）。实测 POWERCONTEXT_SERVER_INFERENCE_TYPO_MODEL 无任何提示地被丢弃，rerank_model 于是静静回落到 generation。对于一个以「换便宜模型省钱」为目的的配置面，这类静默失败代价不小 —— 拼错 RERANK_MODEL 不会报错，只是悄悄按 generation 的价格跑。建议至少对 POWERCONTEXT_SERVER_INFERENCE_* 前缀做未识别名称告警。

2. #1736 §3 建议「继续 feat(memory): add an optional Jev reranker with comparative evaluation #1643」，但 feat(memory): add an optional Jev reranker with comparative evaluation #1643 目前不存在：GraphQL issueOrPullRequest(number: 1643) 返回 null，REST 亦为 404。该后续动作当前没有落点，建议重新开一个跟踪项承接 §3 里那组对照实验要求（同一候选池 / 查询集 / 下游模型 / 上下文预算下比较「无重排 / 当前 LLM reranker / Jev / 专用 reranker」）。

---

七、优先级

优先级	动作	理由
P0-1	Judge 独立分档；禁止默认继承生产模型；本地规则前置	唯一「改配置就可能省钱且不影响正确性」的一项；当前默认在成本上最坏
P0-2	去掉 recall_sufficiency.py:503 的入口短路，改按 reason 分层	rerank 从「全量开启」变为「弱信号才调用」；零成本路径不再被静默旁路
P1-1	max_requests 的重试改为升级重试，并显式定义升级保持策略	实现成本极低；能把已有的 spinning 类信号接上
P1-2	用量表加 model_policy_id + 价格（走 ensure_*_schema）	P0 两项的前置条件：没有它就算不出 §三 的 break-even
P2	评估口径改为「成功率 + 总成本 + 延迟」三列，含全便宜档基线	避免重现 4.2 倍成本换 2.3 个百分点的负例

以上均为设计与证据层面的建议，未对内核行为做任何约定；是否采纳、以何种顺序推进，请维护者判断。欢迎指出事实性错误 —— 所有行号基于当前 HEAD，若已变动以代码为准。

---

参考资料

仓库内相关讨论与跟踪项

• #1736 调研：Jev / Laya 与轻量决策模型在 Agent Memory 中的应用及 PowerContext 建议
• #1971 Discussion: reducing tokens across memory generation and context delivery
• #1989 tracking issue / RFC PR #1990

代码证据（当前 HEAD）

• src/powercontext/builtin/runtime/config.py — InferenceConfig（:289）、4 个槽位字段、memory_write_gate_threshold（:154）
• src/powercontext/builtin/runtime/composition.py — 生成档 14 个 prompt key（:1317-1333）、rerank 独立判定（:1445）、decision 继承（:1558-1567）、or generation_* 回落（:1599）、模型串校验（:1674）
• src/powercontext/builtin/runtime/recall_sufficiency.py — rerank_enabled 入口短路（:503-504）、SearchPlan same-pool 不变量（:149-157）
• src/powercontext/builtin/runtime/memory_write_gate.py — local_rules（:81）、promotion_criteria（:90-94）
• src/powercontext/builtin/inference/models.py — InferenceUsage（:27）
• src/powercontext/builtin/inference/pydantic_ai.py — retries = max_requests - 1（:161）
• src/powercontext/builtin/persistence/tables.py — MODEL_USAGE_DAILY_TABLE（:890）、DECISION_OBSERVATIONS_TABLE（:1123）
• src/powercontext/server/settings.py — SettingsConfigDict（:190）
• src/powercontext/cli/config_wizard_models.py — 仅 GENERATION / EMBEDDING 两个角色（:31-32）

文章引用的外部来源（均为各方自测，未经独立复现）

• LangChain — Open SWE 入口路由与 Escalation Router 的公开测试
• NVIDIA — Stage Router / Escalation Router 的设计描述
• AWS — Intelligent Prompt Routing、Semantic Routing 架构说明
• OpenRouter — Auto Router 的任务分类与支出占比排序机制
• Portkey — Task-Based Routing 规则映射

[hidb4ai]

Uploading PowerContext Gateway：运行时上下文与模型成本的统一网关.pdf…

[AlexStocks]

主打三个方面：省 token、强隐私、高性能。

[IlyaKhalafi]

Two points would change the proposed routing baseline.

The second attempt is on the same model, but a schema failure is not an identical request. The adapter uses Pydantic AI's validation retry mechanism. With PromptedOutput, validation feedback is added to the conversation so the model can repair its output.

I checked this with Pydantic AI 2.27.1, the dependency lower bound, using a local FunctionModel and the adapter's output/retry settings. Both invalid JSON and a wrong field type produced a second request containing retry feedback. With retries disabled, the invalid response failed after one request. This checks the library behavior, not model quality or the full PowerContext runtime.

That makes the useful comparison same-model repair versus escalation, with the same request and time budgets, rather than blind repetition versus escalation. A schema error alone does not establish that the model lacks the required capability.

Also, the external benchmark's 21.2% judge share cannot be carried over to this workload just because decision and generation share a model. Call frequency, input/output lengths and caching affect that share. The proposed per-model usage accounting is needed to measure it before choosing a cheaper default.