Echo LLM 路由池实测:Fable 同档水平 1/3 推理成本怎么做到的(本地接线 + 16 个 harness 接入)

一、起因

HN 49026810(2026-07-23 提交,169p / 82c,adam_rida)上线了一个叫 Echo 的服务,主打一句话:把一池开源权重模型(GLM-5.2、Kimi K2.7 等)对每个 prompt 动态决定"用几个、用哪几个、怎么合并",在自评 benchmark 上打到跟 Fable 同档的水*,推理成本只有它的约 1/3。这条立刻被几个常见反对声(就是 MoE / 就是 ensemble / 就是 OpenRouter)盖过去,但作者在评论区明确说"我们不公开 per-request 的路由决策,因为这条 policy 本身就是产品"。这就让"我具体做了什么"从一个文档阅读题变成一个实际接入题。我花了一个上午把 API 文档 + eval observatory 翻了一遍,把 16 个 harness 接入矩阵抄出来,顺便接了一个最简单的 OpenAI 兼容调用,看看这条"看不见路由决策"的端到端路径到底卡在哪里。

二、我做了什么

2.1 注册拿到 API key

https://echo.tracerml.ai/ 当前是 sign-up 才能拿到 ECHO_API_KEY,免费额度 + 不需要信用卡(这一点作者在 HN 评论里被 @ninjahawk1 质问后主动澄清,并承认隐私 wording 偏宽,正在改条款 + 改 signup 流程)。

2.2 最简 Chat Completions 接入

API 端点跟 OpenAI 完全兼容,base_url=https://echo.tracerml.ai/v1,model=echo,Authorization: Bearer $ECHO_API_KEY,max_tokens=128:

curl --fail-with-body --silent --show-error \
  https://echo.tracerml.ai/v1/chat/completions \
  -H "Authorization: Bearer $ECHO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "echo",
    "messages": [{"role":"user","content":"Explain recursion in one sentence."}],
    "max_tokens": 128
  }'

Python SDK 直接走官方 openai 包:

import os
from openai import OpenAI
client = OpenAI(
    api_key=os.environ["ECHO_API_KEY"],
    base_url="https://echo.tracerml.ai/v1",
    timeout=600.0,
    max_retries=0,
)
completion = client.chat.completions.create(
    model="echo",
    messages=[{"role":"user","content":"Explain recursion in one sentence."}],
    max_tokens=128,
)
print(completion.choices[0].message.content)

max_retries=0 是文档明确建议的——Echo 自己的路由层会处理失败重试,SDK 这边再 retry 会跟它打架。

2.3 16 个 harness 接入矩阵

对照 /docs/api 的"Echo agent harness integration catalog",官方给的接入清单按 priority 分四档(P0/P1/P2/Adapter)。我本地用 OpenCode + Echo 的 @ai-sdk/openai-compatible provider 跑通了三个回合的"写一个 Python 装饰器"任务,延迟 2-4 秒波动。速查表(base URL 都是 https://echo.tracerml.ai/v1,env key 都是 ECHO_API_KEY,wire model 是 echo):

  • P0(官方推荐):OpenCode(Chat+SSE)、Codex CLI(Responses)、Cline / Roo Code / Continue / Goose / swe-agent
  • P1:Aider / OpenHands / Open Interpreter / Hermes Agent(model.api_mode=codex_responses)
  • P2:smolagents / LangChain / CrewAI / AutoGen / PydanticAI
  • Adapter:Claude Code(需要 Anthropic-compatible 适配层,官方文档明说"requires an adapter",没给现成配置)

完整 16 项的 wire model + harness 端配置在原文 link #2(/docs/api)第 3 节。我只测了 OpenCode 一条,其余 15 项的 tool_use schema 兼容性跟 OpenAI 原版是不是 100% 一致,我目前没有数据(局限段会说)。

2.4 Eval observatory

https://echo.tracerml.ai/eval/ 是完全只读的页面,公开 907 stored rows / 8 benchmarks / 9 test sets,每张 card 能逐题展开看 prompt / Echo 答案 / Fable 参考答案 / 评分——比"我贴个总分"严肃很多。

三、效果 / 跟 Fable 的对照

https://echo.tracerml.ai/eval/ 是完全只读的页面,公开 907 stored rows / 8 benchmarks / 9 test sets,每张 card 能逐题展开看 prompt / Echo 答案 / Fable 参考答案 / 评分。我没系统重跑(官方明说"Read-only and does not rerun either model",自己跑也拿不到一样的内部路由),所以这节放官方公开数字 + 几条工程含义:

  • Echo 在 GPQA 100 题上接* Fable(官方"matches Fable on several evaluations"原话);1/3 推理成本(HN 标题数字) = Fable 的约 33%,口径未披露,我无法独立核算
  • Fable 领先:Belebele / Global-MMLU / MMLU-Pro;Echo 接* / 打*:GPQA 100 题子集(注:100 题是 build Echo 时用的,不是独立测试)/ MATH-500 / HLE 等
  • 41 题 GPQA 子集只有 Fable 答了 19 题,两边总分不能直接比——官方原文"Why are there three GPQA test sets?"专节说明
  • 还有 3 个 placeholder(SWE-bench Verified / ARC-AGI / BigCodeBench)写"No result yet",不是 claim

@gruez 评论区质疑:AA(Artificial Analysis)上的 Chinese lab 折扣率有限,如果 Echo 内部把便宜中文模型当主力,最终账单不一定真比纯 frontier 闭源模型便宜。官方页面没直接反驳。

四、差异化点

跟 OpenRouter / SakanaAI Fugu / pellmell.ai 等"多 LLM 编排"项目相比,Echo 三个差异化点:

  1. 决策不公开@adam_rida 评论区明说"per-request routing decision 因为 policy 是产品不公开"。可控性换调优空间,你没法 enforce"数学题必须用 X 模型"。
  2. OpenAI 兼容 + Responses 双协议。绝大多数路由层只做 Chat Completions,Echo 同时给 /v1/responses(适配 Codex CLI)。这是 16 个 harness 能直接接入的根本原因。
  3. Eval observatory 公开 question-by-question。比"我贴个总分"严肃很多,读者能逐题验证 Echo 在哪道题答错、Fable 在哪道题答对。这是一种 anti-benchmark-washing 的工程姿态

五、目前还没完全搞清楚的几个点(局限与待验证项)

下面这几条是我目前无法独立核实的,博客园读者如果要做选型最好自己也跑一遍:

  • 1/3 推理成本的具体口径(待验证):官方只说"约 1/3 of Fable",但没说计价基准——按 token / 按 task / 按 SLO 达成率?不同基准下数字可能差几个数量级。
  • 内部模型池的版本快照(待验证):Echo 说"will publish some of the eligible open-weight model pool",但 eval 页只给 907 行 row 数据,具体池子没披露。@bnjemian 评论区指出这就是经典 ensemble,新意有限——这点我部分同意,但 8 个 benchmark 横切的工程量比"调 sklearn VotingClassifier"高一个量级。
  • per-request 路由决策对 debugging 的影响(不足):不知道哪个模型答的哪段,出问题回溯极难。这是 trade-off,不是 bug,但工程读者应该提前知道。
  • @subygan 提的 cache 一致性问题(待验证):多模型切换会把 KV cache 打断,长 session 任务下 Echo 的延迟收益可能被 cache miss 吃掉。OpenCode session 太短没碰到。
  • Codex CLI 跟 /v1/responses 的实际接法(不足):官方给了配置但我本地没装 Codex CLI 跑实测,只能确认 URL 拼接正确,不知道 tool_use schema 跟 OpenAI 原版是不是 100% 兼容。

六、适用场景建议

  • 个人 dev 想试 frontier 任务:可以试 Echo free tier(1/3 成本 + 不绑卡 + Fable 同档对照)
  • 团队要把 Echo 接进生产 harness:等路由决策可观测化再上(不公开路由 = 排障极难,只能靠 X-Tracer-Request-ID 反查)
  • 中文 / 代码 / 工程类任务为主:等中文 benchmark 对照数据(目前公开对照里没有中文为主任务)
  • 长 session 多轮 agent 任务:小心 cache miss 成本(@subygan 提的隐患我没法本地复现但理论上合理)

七、参考链接

  • HN 原帖:HN 49026810(Show HN: Echo – Fable-level results at 1/3 the cost using open-weight models)
  • Eval observatory:https://echo.tracerml.ai/eval/(907 rows / 8 benchmarks / 9 test sets,只读可逐题展开)
  • API 文档:https://echo.tracerml.ai/docs/api(base URL、harness 接入矩阵、troubleshooting 表)
  • 作者对隐私 + sign-up 流程的回应:HN 49026810 评论区 @adam_rida 第 1 条长回复
  • 类似工程范式:https://github.com/SakanaAI/fugu(@vunderba 推荐,MoE-style multi-LLM 编排)
  • 评测基准成本对照:https://artificialanalysis.ai/agents/coding-agents(@gruez 引用,中国 lab 折扣率讨论)
posted @ 2026-07-24 07:10  Ninghg  阅读(16)  评论(0)    收藏  举报