開放復刻與 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 歷史， 程式碼量遠小於文件量。它們可能完全正當，只是還沒被證明過。 挑選時按「有沒有可跑的東西」篩，而不是按「有沒有出現在某個清單裡」。

一句話

模型層正在變成耗材，而介面、閾值與校準不是。 選型時把力氣花在後三樣上，前一樣隨時可以換。