单位产出成本取代榜单：结构化模型路由指南

把选型口径从"哪个模型最强"换成"哪条路由的单位产出成本最低"。这一期的主角是两类不走"更大"路线的新模型：一类是为快速、结构化、可被软件直接使用的决策而构建的 System One Model，Jev 是其中一个代表；另一类是在实验室数据上做 midtraining 与 RL 打磨出来的领域模型 Periodic Neon。把这两类和通用前沿模型摆进同一张成本表之后，能直接指导接入决策的指标只剩一个，就是单位产出成本。这套路由与核算框架我挂在 4sapi（https://4sapi.com）的网关层上跑，这一期把口径、代码、门禁和避坑清单一次讲完。

一、第 200 期：选型口径该从排名换成单位成本

两百期写下来，接入侧最贵的一课不是"选错模型"，而是"用错口径选模型"。过去很长一段时间，接入决策基本靠一张能力榜：谁分高就接谁，谁排在前面就给谁加权重。这套办法在通用对话场景里还能凑合，一旦任务被拆成大量结构化、可被软件直接消费的决策，榜单就不好使了，因为它只回答"能不能做对"，不回答"做对一次要花多少钱、要等多久、下游还要不要兜底"。

这一期要处理的问题很具体：当 Jev 这类 System One Model 与 Periodic Neon 这类领域后训练模型摆在同一张表里，单位产出成本怎么算、任务怎么按类型路由、灰度与质量门禁怎么设，以及哪些任务永远不该路由到快模型上。这三个问题答清楚，接入决策就从"追榜"变成了工程问题。

二、两类新模型摆在一起看

Jev 属于一类新的 System One Model。这类模型是为"做出快速、结构化、可被软件直接使用的决策"而构建的前沿模型，定位与通用大模型不同：在 System One 类任务上，Jev 达到与现有大模型相近的智能水平，同时快两个数量级、效率高两个数量级；它针对结构化输出做了专门的优化，并且不会产生幻觉；目前开放早期访问。

Periodic Neon 走的是另一条路。在一项用于科学分析的高难度评测上，它以更低的成本超过 GPT-6 Astra 与 Claude Fable 5.1；它已经被部署到实验室里分析实验，目标方向是更好的超导体与磁体；拿到这个结果的方式是在实验室数据上做 midtraining 与强化学习，也就是用领域数据把成本-性能的帕累托最优前沿整体推出去；在 FrontierXRD 上，它以更低的单次分析成本超过前沿模型。

两件事放在一起看，共同点比差异更重要：都没有靠"参数更大"取胜，而是靠在特定任务分布上把单位成本压下去。Jev 压的是每次结构化决策的耗时与开销，Periodic Neon 压的是每次科学分析的成本。这两个方向恰好对应接入侧最常见的两类账本。

维度	Jev（System One 类）	Periodic Neon（领域后训练）
构建目标	快速、结构化、可被软件直接使用的决策	高难度科学分析、实验数据分析
相对水平	System One 类任务上与现有大模型智能水平相近	高难度评测上以更低成本超过 GPT-6 Astra 与 Claude Fable 5.1
速度与效率	快两个数量级、效率高两个数量级	单次分析成本更低，FrontierXRD 上同样更低
幻觉处理	不会产生幻觉	结论建立在实验室数据与真实实验流程上
领域打磨	面向结构化输出专门优化	在实验室数据上做 midtraining 与 RL
当前状态	开放早期访问	已部署到实验室分析实验

三、绝对能力榜为什么指导不了接入决策

能力榜衡量的是上限，接入要的是账本，两者之间隔着四道落差。

第一道是均分落差。榜单把分类、抽取、长链推理、开放写作混在一个总分里，而生产环境的任务分布是高度偏斜的：一个电商中台可能九成调用是字段抽取和意图判定，只有一成需要长推理。用均分选型，等于用一个几乎不出现的场景给全部流量定价。

第二道是下游落差。自由文本输出不能直接进数据库，中间要加解析器、字段补全、失败重试、格式兜底，有时还要一次校验调用。这些开销不出现在榜单里，却实实在在地压在账单上，而结构化输出优化过的模型可以把这一层整段省掉。

第三道是时延落差。排名接近的模型，时延可能差出一个数量级；对同步链路来说，时延直接决定并发容量，也就决定单位成本。把快两个数量级的模型放到短决策任务上，省下的是排队和超时重试。

第四道是区分度落差。在窄域任务上，通用前沿模型与领域模型的能力差距往往很小，但成本差距很大。此时榜单排的是差距很小的那一维，而决策真正依赖的是差距很大的那一维。

四、单位产出成本：把成本除以任务产出

单位产出成本的定义很朴素：一段周期内的全部推理开销，除以这段周期内真正产生价值的产出数量。

分子由五块构成：输入 token 开销、输出 token 开销、重试与超时重试开销、解析与校验开销、人工复核开销。分母的口径必须按任务类型定义，否则不同任务之间没法比：

结构化决策类，分母是每千次通过 schema 校验并成功落库的决策；
抽取类，分母是每条通过字段级校验的记录；
分析类，分母是每次被确认有效的分析结论。

分母的口径定了，账才算得准。解析失败和 schema 校验失败必须计入分子的重试开销，而不是从分母里悄悄扣掉。

这套口径也是比较 Jev 与 Periodic Neon 的唯一公平方式。Jev 的规格里有两个"数量级"：在 System One 类任务上快两个数量级、效率高两个数量级，而智能水平与现有大模型相近。落到账本上就是：同样一单位有效产出，成本量级可以低两个数量级，同时时延量级也低两个数量级。Periodic Neon 的规格给的是成本-性能的帕累托最优前沿——在同样的分析质量下成本更低，在同样的成本下质量更高。

帕累托前沿这个概念值得停在脑子里：它说的不是一个点，而是一条边界。落在边界上的模型，任何"再便宜一点"的尝试都会掉质量，任何"再准一点"的尝试都会涨成本。选型的工作就是找出自家任务落在边界上的哪个位置，而不是找一个放之四海皆准的最优点。

五、结构化输出加不可幻觉，才是能被软件直接消费的模型

Jev 的两个规格连在一起看，价值远大于相加：针对结构化输出做了优化，并且不会产生幻觉。

结构化输出优化的直接收益是省掉解析层。下游拿到的是符合 schema 的对象，字段类型、枚举取值、必填项都能直接映射到数据库列或消息队列，不需要宽容解析器去猜、不需要正则去补、不需要为了格式错误重试。解析层的代码量、维护成本和失败率一起消失。

不会产生幻觉的直接收益是省掉二次校验。在可验证的决策空间里，字段值要么来自输入原文、要么来自受约束的枚举，模型没有编造空间，于是"再调一次模型复核"这条预算也可以砍掉。这两项叠加，单位产出成本里的分母不变，分子直接掉两块。

但边界必须同时说清楚，否则这套结论会被用坏。结构化输出加不可幻觉成立的前提是任务本身可验证：输入里有答案、答案空间是离散或受约束的、schema 能把任务描述完整。一旦任务需要模型在开放空间里构造前提、做多步假设、再自我否定，这两个规格就不再保证任何东西。

六、可验证决策空间：快模型的适用边界

把任务按"答案是否存在于输入与规则之中"分类，边界立刻清晰。

适合路由到快模型的，是那些答案确定、schema 可写全、判定成本低的任务：

字段抽取与实体归一化；
意图分类与工单分派；
路由判定与风控标签；
参数生成，例如把自然语言需求翻译成受约束的配置项；
合规规则命中判定；
质检判定与格式核对。

不适合路由到快模型的，是那些答案需要被构造出来的任务：

开放式长推理与多步规划；
需要权衡取舍的方案设计；
长文档综述与观点生成；
对话陪伴与开放问答；
需要跨领域联想的新问题拆解。

这条线不是能力的线，是任务结构的线。同一个业务里，字段抽取可以走快模型，同一批数据上的策略建议就得走前沿模型；两者的调用量可能差几十倍，成本结构却完全相反。

七、领域后训练换成本优势，这条结论可以迁移到自家业务

Periodic Neon 的路径最值得抄：在实验室数据上做 midtraining 与强化学习，从而建立起成本-性能的帕累托最优前沿。这里没有魔法，只有三件事——领域数据足够贴近真实任务分布、任务结果可以被判定对错、训练与推理口径一致。做完这三件事，一个更小的领域模型就能在窄域任务上以更低的单次成本超过通用前沿模型。

迁移到自家业务，动作是一样的四步：先把任务分布固化下来，明确哪些输入形态占多少流量；再把判定信号做出来，把人工复核结果、下游反馈、线上指标转成可用的奖励信号；然后在自家数据上做 midtraining 与 RL；最后把新模型放回成本表里，与通用前沿模型比单位产出成本而不是比总分。

前提也要说清楚：任务分布必须稳定，否则领域后训练出来的优势会随着分布漂移快速衰减；正确性必须可判定，否则 RL 阶段拿不到可用信号。这两条不满足时，走领域后训练不如先把路由做好。

八、请求流：按任务类型路由的网关

接入侧要落地这套结论，需要在模型前面加一层按任务类型分流的网关。请求流大致是这样：

业务调用进入网关
        |
   任务类型识别（显式标签 / 结构判别 / 规则匹配）
        |
   +----+-----------------------------+
   |                                  |
可验证结构化决策                  开放式长推理
   |                                  |
schema 校验前置                    预算与会话判定
   |                                  |
   +--> 路由到 System One 类快模型     +--> 路由到前沿通用模型
   |        |                          |        |
   |    结构化结果直连下游              |    文本结果进入后处理
   |        |                          |        |
   |    校验失败 --> 升级路由 ----------+--------+
   |        |                                   |
   +--------+-----------------------------------+
                    |
            计费、用量、单位产出成本回传
                    |
            灰度开关 / 质量门禁 / 一键回退

三条设计原则来自前面的结论。第一，分流判定必须在调用之前完成，发生在前置阶段，否则无法控制成本。第二，schema 校验是快模型支路的前置条件，而不是事后补丁；校验不通过就升级路由，不重试同一个快模型。第三，两条支路共用同一套请求标识与计费口径，对账时才能把每一笔开销归到具体任务类型。

九、路由表：谁走快模型，谁走前沿模型

路由表是这套网关的核心配置，应该是一个可评审、可版本化的数据文件，而不是散落在代码里的条件分支。

任务类型	输出形态	有效产出口径	首选路由	升级条件
字段抽取	受约束 schema	每千条通过校验的记录	System One 类快模型	校验连续失败或字段缺失
意图与标签判定	枚举	每千次落库决策	System One 类快模型	低置信度或新意图
参数生成	受约束配置	每千次可执行配置	System One 类快模型	参数越界或组合非法
规则命中判定	布尔与依据字段	每千次判定	System One 类快模型	依据字段无法回指输入
高难度领域分析	结构化分析结论	每次有效分析	领域后训练模型	超出已验证的分布范围
开放式方案设计	自由文本	每次被采纳的方案	前沿通用模型	不适用

这张表有两个容易写错的地方。一是把"有效产出"写成调用次数，调用失败和校验失败都会虚增分母，账面单位成本因此被低估。二是升级条件写成"效果不好就升级"，这种条件无法自动执行；升级条件必须是可判定的信号，例如校验失败、置信度低于阈值、字段无法回指输入。

十、教程：4sapi 网关上的路由与成本核算

下面这段代码是我在 4sapi 网关层实际使用的骨架，接口地址统一走 OpenAI 兼容的 base_url：一份可评审的路由表、一个按许可证读取密钥的客户端工厂、一个把重试与校验开销都算进去的单位产出成本函数。密钥一律从部署环境注入，代码里不留任何明文。

import os
from dataclasses import dataclass

BASE_URL = "https://4sapi.com/v1"


def make_client():
    api_key = os.getenv("FOURSAPI_API_KEY")
    if not api_key:
        raise RuntimeError("缺少 FOURSAPI_API_KEY，请在部署环境注入，不要写进代码或配置仓库")
    from openai import OpenAI
    return OpenAI(api_key=os.environ["FOURSAPI_API_KEY"], base_url=BASE_URL)


@dataclass(frozen=True)
class Route:
    lane: str          # system_one / domain_tuned / frontier
    need_schema: bool
    upgrade_to: str


ROUTES = {
    "field_extraction": Route("system_one", True, "frontier"),
    "intent_label":     Route("system_one", True, "frontier"),
    "param_build":      Route("system_one", True, "frontier"),
    "rule_check":       Route("system_one", True, "frontier"),
    "domain_analysis":  Route("domain_tuned", False, "frontier"),
    "open_planning":    Route("frontier", False, ""),
}


def pick_route(task_type: str, schema_ok: bool) -> str:
    route = ROUTES.get(task_type)
    if route is None:
        raise KeyError(f"未登记的任务类型：{task_type}")
    if route.need_schema and not schema_ok:
        return "frontier"          # 前置校验失败，直接升级，不用快模型试错
    return route.lane


@dataclass(frozen=True)
class Price:
    in_per_1k: float       # 输入单价，填自家合同价
    out_per_1k: float      # 输出单价，填自家合同价
    retry_factor: float    # 平均重试系数，含超时与校验失败重发
    check_per_call: float  # 解析与校验的单次开销
    review_per_call: float # 人工复核摊薄到单次调用的开销


def unit_output_cost(tokens_in, tokens_out, price, output_units, pass_rate):
    """单位产出成本 = 全部开销 / 有效产出。"""
    if not 0 < pass_rate <= 1:
        raise ValueError("pass_rate 必须落在 (0, 1]")
    raw = (tokens_in / 1000 * price.in_per_1k
           + tokens_out / 1000 * price.out_per_1k)
    per_call = raw * price.retry_factor + price.check_per_call + price.review_per_call
    effective_units = output_units * pass_rate
    return {"total": per_call * output_units, "per_unit": per_call / pass_rate}


def compare_lanes(task_type, stats, prices):
    """同一任务上，快模型与前沿模型的单位产出成本对照。"""
    rows = []
    for lane, s in stats.items():
        c = unit_output_cost(s["tokens_in"], s["tokens_out"], prices[lane],
                             s["output_units"], s["pass_rate"])
        rows.append({"lane": lane, "per_unit": round(c["per_unit"], 6)})
    return sorted(rows, key=lambda r: r["per_unit"])

三个实现细节值得单独强调。其一，schema 校验放在路由判定之前，校验不过就直接升级，不让快模型在处理不了的任务上反复试错，这条规则砍掉的往往是最贵的那部分开销。其二，retry_factor 与 check_per_call 必须进分子，否则结构化模型省下解析层的收益会从账面上消失。其三，prices 是一份按合同价维护的配置，成本函数本身不写死任何单价，换供应商时只改配置。

十一、灰度与质量门禁

新路由上线走灰度和门禁两条线，缺一条都不要全量。

灰度按流量分批，每一批都要跑满一个完整业务周期，覆盖工作日与高峰时段的分布差异。建议的节奏是：内部影子流量只看不生效，确认结构化结果可以直连下游；然后放一小批真实流量，观察单位产出成本与升级率；最后按 10%、30%、60% 逐级放量，每一级都保留一键回退到原来路由的能力。

质量门禁要设成可自动判定的阈值，而不是需要人看的主观评价。至少包含四项：schema 校验通过率、升级到前沿模型的比例、下游落库失败率、单位产出成本与基线之比。四项里任何一项越界，自动回退并保留当批请求的完整样本，用于事后定位。

门禁的判据要用配对口径：同一批输入、同一套 schema、同一套下游写入逻辑，只切换路由。随机性大的任务要固定采样参数并跑多轮，报告区间而不是单点，避免用一次波动决定路由去留。

十二、避坑清单：哪些任务不该走向快模型

以下六类任务，无论成本压力多大都不要路由到快模型：

答案不在输入里的构造型任务，例如开放式方案设计与长链规划；
schema 写不全的任务，字段无法枚举、判定标准只能靠人解释；
需要跨文档、跨领域联想的分析任务，输入本身不构成完整证据链；
一次错误代价极高的动作，例如直接触发资金、权限或生产变更的决策；
分布漂移快的任务，新意图、新品类频繁出现，领域优势维持不住；
只有"看起来对"这一种验收方式的任务，缺少可自动判定的正确性信号。

还有三类实现层面的坑：把快模型当成通用模型的降级备份，在超时后无差别兜底，会把结构化任务变成事实上的自由文本任务；把"不会产生幻觉"当成对所有任务都成立的承诺，忽略它依赖可验证的决策空间；把成本函数写成只统计 token 单价，漏掉重试、校验与人工复核，最后账面对不上。

十三、上线验收清单

按任务类型切换路由之前，逐条确认：

该任务的有效产出口径已定义，并且能被下游系统自动统计；
schema 已冻结并有版本号，校验失败有明确错误码；
升级路由的条件可在网关内自动判定，无需人工介入；
同一批输入在旧路由与新路由上各跑一遍，单位产出成本与通过率都已记录；
灰度开关与一键回退已演练过，回退后计费口径保持一致；
密钥全部来自环境变量注入，代码与镜像中不存在明文凭证；
审计记录包含任务类型、路由分支、校验结果、是否升级与最终落库状态；
单位产出成本已接入常驻面板，异常时能按任务类型下钻。

十四、成本与风险提示

快模型的成本优势建立在任务可验证的前提上，前提不成立时，省下的解析层开销会被升级与返工吃掉；
领域后训练模型的优势依赖稳定的任务分布，分布漂移是这类模型最大的隐性成本；
灰度期必须保留完整样本，否则回退之后无法定位是路由问题还是数据问题；
计费口径要与上游账单对齐，重试、校验、复核三项开销都要有归属，避免成本核算和真实账单两张皮；
敏感数据不要进入共享的校验样本池，灰度留样同样要做脱敏与访问控制；
全部走正规接入与计费渠道，不做绕过官方限制的配置。

十五、总结

这一期把选型口径从榜单排名换成了单位产出成本：分子是输入、输出、重试、校验与人工复核五块开销，分母按任务类型定义成每千次有效结构化决策或每次有效分析。Jev 这类 System One Model 在 System One 类任务上智能水平与现有大模型相近，快两个数量级、效率高两个数量级，针对结构化输出优化且不会产生幻觉，适合被软件直接消费，但要限定在 schema 清晰、结果可验证的决策空间内；Periodic Neon 在高难度科学分析评测上以更低成本超过 GPT-6 Astra 与 Claude Fable 5.1，在 FrontierXRD 上以更低单次分析成本超过前沿模型，路径是在实验室数据上做 midtraining 与 RL，把成本-性能的帕累托最优前沿整体推出去，这条路子同样能搬到自家窄域任务上。落到工程，就是一个按任务类型分流的网关、一份可评审的路由表、一个把重试与校验都算进去的成本函数、一套灰度加质量门禁，以及一份不该走向快模型的清单。这套路由与核算框架我挂在 4sapi（https://4sapi.com）的网关层，字段抽取、意图判定这类任务已经全部切到快模型支路。自家业务里哪些任务该走快模型、哪些必须留给前沿模型，欢迎在评论区聊聊。