2026 年最佳開源 LLM 評估框架（其中一個其實不算開源）

Arize Phoenix 儲存庫裡 LICENSE 檔案的第 1 行寫著「Elastic License 2.0 (ELv2)」。不是 Apache，也不是 MIT。有一款被大量推薦的開源 LLM 評估框架，依照 OSI 的定義根本不算開源，而幾乎每一篇在這個查詢字詞上排名的文章都照樣重複這個說法——我們自己的文章也是,直到今天為止。2026-08-04 這天，我們親手檢查了八款框架，外加另外三款至今仍被排名靠前的文章推薦的框架的授權檔案與預設分支提交紀錄，然後安裝了其中六款，用同樣的 10 筆案例逐一測試。我們不賣評估框架，所以下面的結論不是在替任何產品護航。

重點摘要

• Arize Phoenix 採用 Elastic License 2.0，OSI 不承認這是開源授權。
• UpTrain 對 main 分支的最後一次提交是 2024-07-29，別在上面啟動新專案。
• pip install promptfoo 裝到的是第三方封裝版本，真正的專案發布在 npm 上。
• Ragas 自 2026-02-24 起沒有任何提交，而且已經把 GitHub 組織遷到 vibrantlabsai。

2026 年該裝哪一款開源 LLM 評估框架？

按限制條件挑，不是按排名挑。若要在現有的測試套件裡放進 pytest 形式的斷言，就裝 DeepEval。若想要一份 YAML 設定檔搭配適用任何語言堆疊的 CLI，就裝 promptfoo。若想要我們實測中好答案與壞答案分得最乾淨的表現，就裝 Opik。這三款全部採用 Apache-2.0 或 MIT 授權。

以下是完整稽核結果。範圍內有八款框架，外加另外三款目前這個查詢字詞排名靠前的頁面仍在推薦的框架。

日期為截至 2026-08-04 各專案預設分支的最後一次提交。GitHub 的儲存庫頁面顯示的是任何分支的最後推送時間，其中兩個專案的數字會比較晚：UpTrain 為 2024-08-18，Deepchecks 為 2025-12-28。兩個儲存庫都沒有被封存。

遷移成本這一欄最常被跳過，之後也最容易後悔。分數本質上只是數字，所以在 DeepEval、Ragas、Opik 與 phoenix-evals 之間搬遷，大多只是重寫一個迴圈。離開 promptfoo 或 Inspect AI，就得重寫一份沒有替代品的設定或任務格式；離開 Evidently，則要重新檢查每一個你寫過的閾值，因為它的尺度方向是相反的。目前排名靠前的頁面仍在推薦的框架裡，有兩款自 2024 年起就沒發過新版本。

想看分級、託管平台加上直接排序的內容嗎？那是另一份不同的工作，我們已經在涵蓋付費平台的 LLM 評估工具排名比較裡做過了。

八款 LLM 評估框架，依安裝方式分組

安裝方式是你實際要長期共處的東西，所以我們依此分組。

匯入測試中的 Python 函式庫

DeepEval（pip install deepeval，Apache-2.0）把 LLM 指標包裝成 pytest 形式的斷言：建立一個 LLMTestCase，交給 assert_test，只要低於你設的閾值測試就會失敗。最擅長把品質關卡放進團隊本來就在跑的單元測試旁邊。若你的評估本該和其他一切共用同一個 CI 工作，就選它。

一個聲明，只說一次：DeepEval 由 Confident AI 開發，這是本站另外兩篇文章的付費合作夥伴，包括本文連結到的那份排名比較。這裡沒有給它任何特殊待遇，本頁每一個 DeepEval 連結都指向GitHub 儲存庫。

Ragas（pip install ragas，Apache-2.0）是 RAG 專用選項：evaluate() 接收 question、context、answer 資料列，非同步回傳每個指標的分數。最擅長在 Python 流程裡衡量檢索品質。它的儲存庫已從 explodinggradients 遷至 vibrantlabsai，最新版本是 2026-01-13 發布的 v0.4.3，自 2026-02-24 起沒有任何提交。如果 RAG 指標就是你唯一要做的事，且能接受一個沉靜的儲存庫，就選它，也可以看看更廣泛的RAG 工具堆疊。

Opik（pip install opik，Apache-2.0，來自 Comet）提供可以獨立呼叫的指標。設定 OPIK_TRACK_DISABLE=true，AnswerRelevance().score() 就能在沒有帳號、沒有本地伺服器、沒有設定檔的情況下執行，這一點產品文案並沒有特別強調。最擅長用最少程式碼拿到真實分數。若你現在就想要指標、平台之後再說，就選它。

Evidently（pip install evidently，Apache-2.0）把評估當成資料集上的 descriptor，副作用是寫出一份 HTML 報告。最擅長大量資料列的批次報告，而不是二元把關。它的 LLM 分數是反過來的：1.0 代表不忠實。若你欠某人的是一份可分享的報告，而不是一個紅燈建置，就選它。

Giskard（pip install giskard，Apache-2.0）掃描模型的漏洞，而不是替你寫的資料集打分數。PyPI 套件解析到的是 v2 系列，而該專案自己的README寫著 v2「已不再積極維護」。最擅長自動化的紅隊式掃描。若你想要的是自動找出漏洞，而不是自己定義LLM 作為裁判的指標，就選它。

對著 YAML 檔案執行的 CLI 與設定工具

promptfoo（npm install promptfoo，MIT）是一個讀取 YAML 檔案的 CLI：宣告 provider、測試案例與斷言，執行 npx promptfoo eval，就能拿到每個案例的通過╱不通過結果，加上一個本地結果 UI。最擅長在你的應用不是用 Python 寫的情況下評估提示詞。若你的品質關卡應該是一份非 Python 隊友也能編輯的設定檔，就選它。

Harness 等級與平台捆綁型

Inspect AI（pip install inspect-ai，MIT）來自英國 AI 安全研究院，用你以 Python 定義的任務評估模型，具備正式的 solver 與 scorer 抽象概念，還有一個執行檢視器。最擅長具備可重現任務定義的模型層級基準測試。若受測對象是模型本身而不是你的應用，就選它。

Arize Phoenix（pip install arize-phoenix-evals）提供像 FaithfulnessEvaluator 和 CorrectnessEvaluator 這類預建評估器，回傳一個二元標籤加一個分數。最擅長給出不需要自己挑閾值的確定性標籤。它的授權正是這篇文章標題裡出現括號說明的原因，下一節就專門談這件事。

Arize Phoenix 是開源的嗎？

不是，至少依開放原始碼促進會（Open Source Initiative）維護的定義來看不是。Arize Phoenix 採用 Elastic License 2.0（ELv2）。儲存庫LICENSE 檔案的第 1 行就這麼寫，PyPI 也在 v19.15.0 上獨立標示 license: Elastic-2.0。原始碼是可讀、可分叉、可自架的。受限制的只有一種用法。

真正重要的限制在這裡：ELv2 禁止把這套軟體以託管或代管服務的形式提供給第三方。仔細讀這句話，因為它綁住的人比聽起來要少得多。如果你安裝 arize-phoenix-evals 來為自己的應用打分數，ELv2 完全不會碰到你。如果你是顧問公司或平台團隊，打算把 Phoenix 包裝成賣給外部客戶的評估服務，那就受限了。差別就是這麼多，而 ELv2 沒能通過的正是開放原始碼定義裡關於使用領域限制的條款。

目前每一篇在這個查詢字詞上排名的頁面都把 Phoenix 歸類為「開源」，我們自己也是。我們自己的LLM 評估工具排名比較把 Phoenix 描述為完全開源，這是錯的，目前正在修正。Phoenix 是原始碼可取得（source-available），不是開源，這個區別只有在你打算把它當服務賣時才會咬人。 如果你真正需要的是追蹤而不是打分數，那屬於AI 可觀測性平台的範疇，不是本文的重點。

這些框架裡有哪些還在積極維護？

大多數都是。我們檢查的十一個儲存庫裡，有六個在 2026-08-03 或 2026-08-04 對 main 有過提交：DeepEval、promptfoo、Opik、Arize Phoenix、Inspect AI 與 Giskard。有兩個自 2024 年起就沒發過新版本。有一個在換了 GitHub 組織後，2026 年整年都很安靜。

我們不會用來啟動 2026 年新專案的框架

UpTrain 已經死了。它對 main 的最後一次提交落在 2024-07-29，最新版本 v0.7.1 是 2024-05-14 發布的，不管用哪個指標算，都已經冷了整整兩年。儲存庫依然在，也依然是 Apache-2.0，所以沒有什麼能阻止你，但在一個已被放棄的評估函式庫上啟動新工作，是一個之後得跟人解釋的決定。

Deepchecks 值得把版本號寫清楚。它自 2024-12-15 的 0.19.1 之後就沒發過新版本，不過儲存庫還是持續有人提交程式碼，最近一次落在 main 上的日期是 2025-11-24。People are still working on it；只是超過十八個月沒有人剪過一個新版本。UpTrain 和 Deepchecks 都沒有在 GitHub 上被封存，也都沒有停止接受貢獻。

Ragas 只給日期，不多說別的。最新版本 v0.4.3 是 2026-01-13，自 2026-02-24 起沒有任何提交，儲存庫已經從 explodinggradients 遷至 vibrantlabsai。我們找不到可查證的組織遷移原因說明，所以不會憑空編一個。一個安靜的儲存庫不等於一個壞掉的儲存庫：今天算出忠實度分數的 Apache-2.0 程式碼，明年一樣算得出來。真正的風險在未修補的依賴套件，這正是我們下面實測時踩到的坑。

在這個查詢字詞排名第一頁的其他文章，至今仍在推薦 UpTrain 和 Deepchecks，卻沒有附上任何日期。一個自 2024 年 12 月起就沒發過新版本的框架，是一個依賴套件層級的決定，不是一個功能層級的決定。

你需要的是評估框架，還是評估 harness？

應用層的評估框架，是拿你自己的資料替你應用自己的輸出打分數。DeepEval、Ragas、promptfoo、Opik、phoenix-evals 和 Evidently 都做這件事。模型層的評估 harness，則是拿標準化的公開任務替模型做基準測試。lm-evaluation-harness 和 Inspect AI 做這件事。選錯類別是這篇文章裡代價最高的錯誤。

失敗的模式很具體。有人把 lm-evaluation-harness 接上去測他們的 RAG 聊天機器人，拿回一組 MMLU 分數，卻對他們的檢索器有沒有回傳正確段落這件事一無所獲。分數是真的，量到的卻是基礎模型，而那本來就不是任何人擔心的東西。

Inspect AI 的形狀來自它的出身：它由英國 AI 安全研究院以 MIT 授權打造，用來評估前沿模型，所以 solver、scorer 與任務都是一等公民，而「你的應用」根本不是它有的概念。用它做它該做的事，是一個好理由。如果你的問題是代理而不是單輪對話，生產環境中評估 AI 代理是完全不同的一門學問，而工具呼叫伺服器則在我們的MCP 伺服器與工具評估指南裡有專門的討論。

我們安裝了其中六款、跑完同樣 10 筆案例之後發生了什麼事

2026-08-04 這天，我們在全新的 Python 3.11.14 虛擬環境（promptfoo 額外用 npm）裡安裝了其中六款，用同一位裁判 openai/gpt-4o-mini（透過 OpenRouter，溫度設為 0）替同一組 10 筆 RAG 測試集打分數。七筆答案是正確的。三筆以三種不同方式壞掉：一筆與自己的上下文矛盾，一筆憑空捏造細節，一筆是流暢的散文卻完全沒回答問題。每款框架都連續跑了兩次。

六款裡有五款的紮根性指標抓到了全部三個瑕疵。下面這三個發現，就是這一節存在的理由。

相關性指標不是品質指標，其中兩款把一個信心滿滿的謊言評得比正確答案還高。 Ragas 的 ResponseRelevancy 把「宣稱 HTTP 404 是 5xx 伺服器錯誤」這一項評為 0.777，高過七個正確答案裡的兩個；把捏造了流量限制的那一項評為 0.813，高過其中四個。promptfoo 的 answer-relevance 也一樣：404 那一項拿到 0.800，乾淨通過 0.7 的閾值，同時卻讓正確的 q01 以 0.679 沒過門檻。這不是 bug。一個信心滿滿的錯誤答案，可以把問題回答得非常「切題」。但如果相關性就是你儀表板上的那個數字，一句流暢的幻覺看起來就會像你最好的輸出。

只看忠實度的關卡，會漏掉那個離題的答案。DeepEval 把那個完全沒回答問題的答案評為 1.000 忠實度，乾淨通過——這其實說得通：一個對上下文什麼都沒斷言的答案，自然也不會與上下文矛盾。只有相關性指標抓到了它，評分是 0.000。這是上表裡唯一一個紮根性漏抓案例。單獨看任何一個指標都有漏洞，兩個一起用才能互補。

在溫度 0 的設定下，二元評估器很穩定，分級評估器卻不是。Phoenix 和 DeepEval 在兩次完全相同的執行之間，十筆項目一筆都沒漂移。Opik 漂移了四筆，全部在 AnswerRelevance 上，落在一個 0.05 的刻度格；Evidently 也漂移了四筆。這裡沒有任何一次漂移翻轉了結論，但 promptfoo 那個正確的 q01 先落在 0.679，再落到 0.642，卡在 0.700 的閾值兩側，這正是一個會鬧脾氣的 CI 關卡的樣子。

還有兩個比較小的觀察：六款裡有三款（DeepEval、Opik、Phoenix）第一次就乾淨安裝、乾淨執行，而 Ragas 直到我們鎖定 langchain-community<0.4 才能匯入成功。只有 promptfoo 回報了裁判的 token 用量，第一次執行用了 16,011 個斷言 token，第二次是 16,010 個。

把這次實測的侷限說清楚。 n = 10 是一次抽樣試跑，不是一份基準測試：它告訴你的是易用性與盲點，不是指標準確度。只用了一個裁判模型評分，換一個更大的裁判模型，每個數字都會變，很可能連 DeepEval 和 Ragas 在同一個正確項目上都做出的那兩個偽陽性也會變。兩次執行足以證明漂移存在，卻不足以描述它的特性。答案是預先寫好的，所以這裡完全沒有測到生成、追蹤或資料集管理，這也讓 promptfoo 那 337.9 秒的安裝時間看起來比實際情況更糟。「最佳」永遠是相對某個限制條件而言：CI 關卡、RAG 指標，或是一個 UI，各自會導出不同的答案，線上與離線評估之間的取捨也是一樣的道理。

同一個檢查，寫成三種寫法

挑介面形式最快的方法，是把同一個斷言讀三遍。這裡是同一筆項目在 DeepEval、Ragas 與 promptfoo 裡的紮根性檢查，從我們實際跑過的腳本裡精簡出來。指標名稱不同；我們連到LLM 作為裁判的指標實際運作原理，而不在這裡重新定義它們。

# DeepEval 4.1.5: pytest 形式，低於閾值就讓測試失敗
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3：注意匯入路徑。`from ragas.metrics import Faithfulness`
# 在這個版本裡會丟出 ImportError；具體的指標已經搬家了。
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20：npm install promptfoo，然後 npx promptfoo eval
providers:
  - id: echo          # 我們評分的是預先寫好的答案，而不是即時生成
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

安裝那幾行藏的坑，比程式碼本身還多，下面每一句註解，都是 2026-08-04 那天實際害我們浪費時間的事：

# 真正的 promptfoo 發布在 npm 上。同名的 PyPI 套件是第三方封裝版：
# https://pypi.org/project/promptfoo/ 對比
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard 解析到的是 v2 系列，而該專案自己的 README
# 標示 v2 已不再積極維護。
pip install giskard

# lm-evaluation-harness 是以套件名稱 lm-eval 安裝的。
pip install lm-eval

# Evidently 不會自動拉入 openai，而裁判是在呼叫當下才崩潰，
# 不是在匯入時就崩潰——而那時你早就已經把資料集建好了。
pip install evidently openai

# Ragas 0.4.3 沒辦法在 langchain-community 0.4.x 上匯入成功。
pip install ragas "langchain-community<0.4"

可以用一個評估分數卡掉建置嗎？

可以。這裡的每一款框架都會回傳數值或二元分數，只要有一個閾值斷言失敗，就會以非零狀態碼結束，這正是 GitHub Actions 判斷紅燈所需要的一切。接上結束碼是簡單的部分。挑一個裁判模型不會不小心跨過去的閾值，才是要花一整週的部分。

以下是我們實際在跑的工作流程形狀，版本鎖定在我們 2026-08-04 那次測試用的版本：

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Score the golden set
        env:
          # 鎖定裁判模型。季中換模型會讓每個分數都變動。
          JUDGE_MODEL: openai/gpt-4o-mini
          # 閾值集中放在一個地方，由指標建構子讀取。
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

有兩個坑會在閾值之前先咬人。第一，裁判呼叫是網路呼叫：我們那次 10 筆項目的 DeepEval 執行花了 126.8 秒，因為 .measure() 是循序執行的，換成 200 筆項目的黃金測試集，走這條程式路徑，每個 pull request 都會變成一次喝咖啡的等待。這次測試裡其他每一款框架預設都會平行化，這是影響 CI 等待時間最大的單一因素。

第二，不穩定性。在溫度 0 的設定下，Opik 和 Evidently 各自在連續兩次執行之間漂移了十筆裡的四筆，promptfoo 那個正確答案先落在 0.679、再落到 0.642，卡在 0.700 的關卡兩側。緩解方式其實很無聊，但確實有用：跑一份只依 pull request 而變動的固定黃金資料集、鎖定裁判模型、能用二元評估器就優先用二元評估器，而且以差值而不是絕對下限來把關。最後這一點在線上與離線評估裡特別重要，因為一場對話會產生很多個各自都可能晃動的分數。

以規模來看：LangChain 的《Agent 工程現況》調查（1,340 份回覆，調查期間為 2025 年 11 月 18 日至 12 月 2 日，發布於 2026 年 6 月 12 日）發現，89% 的組織已經替他們的代理部署了某種形式的可觀測性，卻只有 52.4% 會對測試集執行離線評估。看著發生什麼事很常見，真正把關的卻不多。

這週我們會裝什麼

四件事帶走。Arize Phoenix 在 Elastic License 2.0 之下屬於原始碼可取得，不是 OSI 核准的開源，對大多數讀者而言這什麼都不改變，但如果你想轉售評估工具，就會改變一切。UpTrain 已經死了，卻仍有沒標日期的頁面在推薦它。Deepchecks 自 2024 年 12 月起也沒剪過新版本，不過它的儲存庫依然持續有人提交程式碼。紮根性指標和相關性指標各有一個對方能補上的漏洞，所以兩個都要用來把關。而分級分數在溫度 0 下依然會漂移，所以要鎖定裁判模型，並且給閾值留一點餘裕。

如果是我這週要啟動一套新的評估套件，我會為了 CI 關卡裝 DeepEval，因為斷言本來就該和測試放在一起（上面已聲明合作關係），再加上 Opik 的獨立指標，取我們實測裡最乾淨的分離效果。如果我們的技術堆疊不是 Python，我會毫不猶豫改裝 promptfoo。如果你寧願讓別人替你把黃金測試集和工作流程接好，歡迎跟我們聊聊。

常見問題

最佳的開源 LLM 評估框架是哪一款？

沒有單一贏家，只有各種限制條件下最合適的選擇。若要在 Python 測試套件裡做通過╱不通過的關卡，選 DeepEval。若要一套跨語言的 YAML 加 CLI 設定，選 promptfoo。若要 RAG 檢索指標，選 Ragas，前提是你能接受一個自 2026-02-24 起沒有任何提交的儲存庫。若要我們 2026-08-04 那次測試裡好答案與壞答案分得最乾淨的表現，選 Opik。

Arize Phoenix 是開源的嗎？

依照開放原始碼促進會（Open Source Initiative）的定義，不是。Arize Phoenix 採用 Elastic License 2.0，PyPI 在 v19.15.0 上標示為 license: Elastic-2.0，儲存庫 LICENSE 檔案的第 1 行也直接這麼寫。它是原始碼可取得的：你可以閱讀、分叉、修改並自架它。唯一的限制是不能把這套軟體以託管或代管服務的形式提供給第三方。

Ragas 還有在維護嗎？

截至 2026-08-04 可查證的事實是：最新版本是 2026-01-13 發布的 v0.4.3，自 2026-02-24 起沒有任何提交，儲存庫已從 explodinggradients 組織遷至 vibrantlabsai。儲存庫沒有被封存。我們找不到可靠的公開說明解釋組織為何變更，也不會憑空猜測。Apache-2.0 的程式碼依然能跑；真正的風險在未修補的依賴套件。

我需要的是評估框架，還是可觀測性平台？

長期來看兩者都需要，但它們回答的是不同的問題。評估框架告訴你，在你控制的資料集上，一次改動讓你的輸出變好還是變壞——而且是在你出貨之前。可觀測性平台告訴你，出貨之後在生產環境裡實際發生了什麼事。如果你有 CI 流程，就從評估框架開始；生產環境那一側可以參考AI 可觀測性平台。

我可以在 CI/CD 裡跑 LLM 評估嗎？

可以。這裡涵蓋的每一款框架，只要閾值斷言失敗，就會以非零狀態碼結束，這正是 GitHub Actions 工作所需要的一切。實務上的限制在於等待時間（裁判呼叫是網路呼叫，我們循序執行的 DeepEval 跑 10 筆項目花了 126.8 秒）以及裁判的不確定性。工作流程的形狀與緩解方式都在上面的 CI 章節裡。

DeepEval 和 Ragas 有什麼差別？

差在介面形式與涵蓋範圍，不是品質。DeepEval 是 pytest 形式、用途通用的：你寫測試案例、對指標閾值做斷言，它能涵蓋很多種應用輸出。Ragas 是 RAG 專用的函式庫，它的 evaluate() 對一組 question、context、answer 資料列做非同步執行。DeepEval 更自然地適合 CI 關卡；Ragas 在檢索面向鑽得更深。

為什麼 pip install promptfoo 裝到的東西不對？

因為 promptfoo 是一個 Node 專案。真正的專案發布在 npm 上，採用 MIT 授權，用 npm install promptfoo 安裝。同名的 PyPI 套件是第三方封裝版，不是上游專案，裝到它是一個很常見的踩坑方式，最後你會發現自己在除錯一個文件裡描述的完全不是這個 CLI。

lm-evaluation-harness 算是 LLM 評估框架嗎？

它是模型評估 harness，是一份相關但不同的工作。lm-evaluation-harness（以 pip install lm-eval 安裝）用像 MMLU 這類標準化公開任務替模型做基準測試。它不會告訴你檢索流程有沒有回傳正確段落，因為「你的應用」根本不是它有的概念。框架與 harness 的分野可以參考上面的章節。

這些框架都免費使用嗎？

就授權而言，是的。DeepEval、Ragas、Opik、Evidently 和 Giskard 是 Apache-2.0；promptfoo、Inspect AI 和 lm-evaluation-harness 是 MIT。兩種授權都允許商業使用、修改與再散布。Arize Phoenix 是例外：Elastic License 2.0 允許自架，但不允許把這套軟體以代管服務的形式提供給第三方。裁判模型的 API 用量由你的服務商另外計費。