开放复刻与 systemone 生态

这个栏目里其他页讲的是「怎么用」。这一页讲用哪一个 —— 以及为什么这个问题 比一年前更容易回答，也更容易答错。

一个接口变成了事实标准

POST /v1/systemone 这个形状已经不只是官方 SDK 的细节了。 它成了事实标准，原因是客户端的迁移成本接近于零： 换个后端只要改一个 base URL 环境变量，请求与响应的形状不变。

于是出现了几十个实现同一套接口的项目：有的是把任意开源大模型 「变成」决策模型（读 logits，不生成文本），有的是在开源基座上微调出专用权重， 有的是纯本地的推理运行时，还有 transpiler 一类把别的生态接进来的桥。

本地替代品的横向位置

公开的开权重复刻在参数量上跨了五个数量级 —— 从几十万参数到 27B：

几个具体到可以复算的数字：

• 一个 1B 的 CPU 实现（GGUF，619 MB）在短请求上 54 ms、长请求 220 ms， 而托管服务是 344 / 345 ms —— 但它的准确率是 0.815 vs 0.927， 而且只支持 yes/no 一种提问。
• 另一个开源权重在 308 条密封决策上是 33.1% vs 36.7%（约 13 ms）。
• 一个专用的表单填写模型（706,048 参数、2.8 MB）在它自己的任务上 拿到 99.7%，而通用模型是 83.6% —— 作者明确说明这是主场优势，不是普遍胜利。

这张表最该读出来的不是排名，而是量级。 「快 6 倍但准确率低 11 个点」 和「准确率接近但只支持一种提问」是完全不同的取舍， 而它们都能被描述成「一个本地的替代方案」。

合规率：一个不该被忽略的数字

生态热闹的时候，最需要问的是大家是不是真的遵守同一套接口。

有一份项目把 /v1/systemone 的语义固化成 48 条可检验的要求 （比如：Choice 各选项的概率按定义求和为 1；Score 的期望等于 概率加权和；选项个数在 2 到 255 之间；问题顺序变化时答案不变）， 并提供了一个测试套件去检测任意一个自称兼容的服务。

它的实测结果是：

八个 star 最高的开源端口里，只有两个完全合规。

这条结论对两件事都有用。对客户端来说，意味着「换个 base URL 就行」 需要用测试套件确认，而不是假定。对做替代品的人来说， 它给出了一个比准确率更容易达到、也更少人做的差异化方向。

这对选型意味着什么

把上面的东西拼起来，选型的重心已经不在「哪个模型的分数高」上了：

1. 接口是共同的，模型是可替换的。 那 48 条要求就是可替换性的定义 —— 先用套件确认，再谈别的。
2. 壁垒移到了模型之外。 当模型层被商品化，真正难被复制的是 接口契约 + 阈值策略 + 在你自己的数据上做的校准。这三样恰好是本栏目 其他几页都在讲的东西，而且它们都在你的仓库里，不在供应商那里。
3. 准确率的差距要放在正确的坐标里看。 「83.6% vs 99.7%」是专用模型在自己 主场上的成绩；「0.815 vs 0.927」是一个 CPU 上跑、只做 yes/no 的小模型。 这两句话要连着说，否则表就是误导。

生态的规模

目前公开的项目大约有 1,100 个（2026-09 的数）。

数量不是质量，也不是成熟度。 这个规模里包含大量单次提交、共享同一套脚手架 的项目：同一个作者在同一天放出一批仓库，共用一份 AGENTS.md、一个 commit 历史， 代码量远小于文档量。它们可能完全正当，只是还没被证明过。 挑选时按「有没有可跑的东西」筛，而不是按「有没有出现在某个清单里」。

一句话

模型层正在变成耗材，而接口、阈值与校准不是。 选型时把力气花在后三样上，前一样随时可以换。