Jais 3 對上 Fanar 2：兩家廠商對 Fanar 2 的得分看法不一

J​ais 3 與 Fanar 2是兩大波斯灣旗艦阿拉伯模型系列，而任何人能告訴你有關比較它們最有用的一件事，就是供應商自己針對Fanar-2-27B-Instruct的數字並不一致。QCRI 的模型卡報告其 27B instruct 模型的 ArabicMMLU 為 74.67%，Belebele 為 86.81%。J​ais-3-32B 的模型卡來自 Institute of Foundation Models 與 Inception42，它在自己的參考表上以同一個對手進行評測，並把Fanar-2-27B在 Arabic MMLU 上列為 66.3，在 Belebele 上列為 61.8。同一個模型，在一項基準上差了八分，在另一項上差了二十五分，而這兩個數字都不是捏造的——它們是不同測試框架、不同提示格式，以及就 IFM 而言是經稽核的樣本集所產生的輸出。這也是本頁最具啟發性的一點，因為這意味著，用已公布數字建構出來的 J​ais 3 與 Fanar 2 比較，不只是兩個模型的比較，也同樣是兩種量測實務的比較。

兩張卡片，簡單來說

• J​ais-3-32B — 來自 IFM 的 32B 稠密僅解碼器模型，上下文最高達 524,288 個 token，Apache 2.0，權重於 2026 年 9 月 29 日發布。隨附推理解析器（k2_horizon）、工具呼叫解析器，以及三種可選的工具呼叫格式。以張量平行度 2、bfloat16 精度提供服務。

• Fanar-2-27B-Instruct — 來自哈馬德·本·哈利法大學 QCRI 的 27B 稠密模型，上下文長度為 32,768 個 token，採用 Apache 2.0 授權，於 2026 年 3 月發布。以 google/gemma-3-27b-pt 為基礎持續預訓練，使用約 166B 個阿拉伯文與英文 token，涵蓋三種配方，之後進行合併，並接著經過五階段後訓練流程。

• 規模範圍 —— Jais 3 是一個模型系列，包含六個基礎檢查點，參數規模從 0.9B 到 375B，其中還有兩個混合專家模型。Fanar 2 的語言模型產品線基本上就只有一個 27B 的指令微調模型，其同系列成員分布於其他模態，而非更小的文字檢查點。

• 授權條款 —— 雙方皆採用 Apache 2.0，雙方皆不設閘門。兩個系列都不要求你簽署任何文件，這點值得特別說明，因為這在該地區並非慣例。

• 基礎架構 — Jais 3 由 IFM 以自訂架構訓練（k2_horizon，需要自訂遠端程式碼）。Fanar 2 則是對 Google 的 Gemma 3 27B 進行持續預訓練而成，這使其成為另一種產物：一次執行良好的調適，而非從零開始的訓練過程。

數字在哪裡出現分歧，以及為何這不是醜聞

逐一處理這些基準名稱，因為這個標籤實際發揮的作用比它表面上看起來的少。

• ArabicMMLU 與 Arabic MMLU* —— Fanar 的模型卡顯示，在其稱為 ArabicMMLU 的基準測試上為 74.67%。IFM 的表格則顯示，在其稱為 Arabic MMLU* 的欄位中為 66.3，星號代表 IFM 排除了提示語意不清、選項無效或黃金標籤站不住腳的題目。兩組不同的樣本集，其中一組經過清理，而兩家實驗室都沒有義務回報對方的結果。

• Belebele，86.81 對比 61.8——差距大得多，而測試框架的解釋在這裡更顯牽強。Fanar 的數據對應的是阿拉伯語方言；IFM 的欄位則寫著同一個基準名稱。25 分的差距不是四捨五入造成的差異，而誠實的結論是：這些執行結果中，至少有一個所測量的並不是另一個所測量的東西。

• IF-Eval：82.97 對 49.8 — Fanar 在其自家的改進表中回報 IF-Eval 成績為 82.97。IFM 的參考欄位則將 Fanar-2-27B 在阿拉伯語 IFEval 上列為 49.8。同樣的能力，不同的語言，以及不同的提示集。

• 雙方在趨勢上一致，儘管程度未必相同——Fanar 2 相較 Fanar 1 是一大躍進。QCRI 報告指出，與自家 9B 前代模型相比，ArabicMMLU 提升 +7.32、GSM8K 提升 +10.68，IF-Eval 提升 +8.27。這項說法內部自洽，且無人提出異議。

由此得出的規則不是「某個實驗室在作弊」，而是：就阿拉伯語基準測試而言，沒有附上評測框架的數字，就不算數字。IFM 至少會標明自己哪些數據經過稽核，並將被排除的樣本另行公開在獨立集合中，這比大多數實驗室做得更多——但這仍然是 IFM 在稽核 IFM 對競爭對手的評估。

情境與部署是比較起來最單純的地方

這些列不受線束論證影響，因為它們是架構性事實，而非量測值。

• 上下文 — Jais-3-32B 為 524,288 個符元，相較之下 Fanar-2-27B-Instruct 為 32,768 個。視窗大小是它的十六倍，而 Fanar 的說明文件記載了 54K 的長上下文指令，用於在訓練期間達到 16K，這使得訓練所得的長上下文行為遠落在名義上的 32K 之內。

• 服務佔用量 — J​ais-3-32B 在 TP=2、bfloat16 下，vLLM ≥ 0.30.0 或 SGLang ≥ 0.5.20。Fanar-2-27B 已使用 transformers 4.57.6 測試，且屬於標準的 G​emma 3 27B 架構，因此可直接套用於任何已執行 G​emma 的技術堆疊。

• 模型隨附的工具——Ja​is 3 包含推理解析器、工具呼叫解析器，以及可選用 json、xml 或 xml_typed 工具格式作為第一級服務旗標。Fanar 2 支援通用工具呼叫，外加十個內建的 Fanar 工具，但其整合介面是供應商自家的 API，而非一組框架旗標。

• 第三方評估——兩者皆無 Artificial Analysis 條目、皆無競技場評分，也皆無獨立複現。兩大家族提出的數字均為供應商自行通報，文章每次引用前皆已如此註明。

Fanar 2 有哪些 Jais 3 沒有的功能

三件事，而且它們都不小。

• 原生阿拉伯語推理軌跡。 Fanar 2 以約 250,000 個阿拉伯語推理範例訓練而成，並以阿拉伯語生成其思維鏈，而非從英語推理軌跡翻譯而來。J​ais 3 公開了推理解析器，並回報強勁的阿拉伯語代理數據，但其模型卡並未對思考所用語言作出相同的主張。

• 將幻覺緩解設計為一種刻意行為。Fanar 2 被訓練成會選擇不回答——訓練期間的知識探測、五步驟結構化驗證軌跡、經過校準的「我不知道」回應——而且它會把自發出現的古蘭經經文引用包在驗證標記中，讓下游系統可以檢查這些引用。最後這項功能很不尋常，在 Jais 3 模型卡中也沒有對應設計。

• 以該模型為核心的產品。QCRI 推出聊天介面、iOS 與 Android 應用程式，以及附有存取申請流程的文件化 API，另有供影像生成、影像理解與詩詞使用的同系列模型。J​ais 3 是伴隨框架食譜的權重發布；語音模型與之並列，其餘則是研究產物。

那些是能力上的差異，不是基準測試上的差異；公允地看，Fanar 2 作為產品完成度更高，而 Jais 3 作為模型則更有野心。

那些附有星號的 agentic 欄位，實際上到底說了些什麼

IFM 自家的表格是這兩個模型之間唯一已發表的正面對決，而它對 Fanar 並不光彩：Terminal Bench 2.1 為 63.7 對 1.1，GDPVal 為 75.5 對 0.0，MCPMark 為 66.1 對 12.1，SWE-Bench Verified 為 72.4 對 0.4，阿拉伯文檔案處理為 71.8 對 0.0。

就照它們的本來面目來讀。這些是 IFM 對某個競爭對手模型所做的量測，由 IFM 執行、跑在 IFM 自家的測試框架上，並發表在 IFM 的模型卡上。一個 27B 的 instruct 模型在 GDPVal 拿到零分、在 SWE-Bench Verified 拿到 0.4，是合理的——這些是 agentic 基準測試，會嚴厲懲罰那些沒有大規模工具呼叫訓練資料的模型，而 Fanar 2 的 agentic 工作是圍繞它自己那十個工具，而非一般軟體任務。但一個實驗室若回報自家模型在自己打造的表上每一列都勝出，那透露的是它的評估方式，而不是世界的實況。

比較站得住腳的陳述其實更狹隘：在 IFM 已發佈的評測框架上，Jais-3-32B 在每一項已報告的代理式基準測試中都優於 Fanar-2-27B-Instruct，而 Fanar 的模型卡完全沒有報告任何代理式基準測試，因此沒有任何證據與它矛盾，也沒有任何證據能佐證它。已發佈的證據之所以片面，是因為只有一方發佈了結果。

該選哪一個

長脈絡、代理式作業，或是需要選擇檢查點大小：Jais 3，而且在脈絡這點上，勝負毫無懸念。512K 視窗對上 32K，單憑這點就決定了文件處理、儲存庫規模的工作，以及漫長的代理軌跡。

無論是你打算閱讀的阿拉伯語推理、你可以信賴的拒答行為、古蘭經內容處理，還是擁有應用程式與支援途徑的供應商：Fanar 2。QCRI 的後訓練管線確實相當繁複——400 萬條 SFT 指令、28 萬組 DPO 配對、五個階段，以及一道刻意進行的能力再平衡程序，以防止長上下文調適削弱短篇任務的表現——而這會顯現在排行榜欄位無法捕捉的維度上。

如果這個決定之所以困難，是因為兩者對同一項工作負載都看似可行，那麼能讓它定案的，就是你自己的提示詞，分別在兩者上執行，並用你自己的標準來評分。那是沒有人為這兩個模型發表過的實驗，而它比上面引用的每一個數字都更有價值。

執行起來比以前省事多了。OrcaRouter 讓你不論 200 多個模型都只需一組金鑰，零加成，直接沿用供應商的定價，所以在兩個阿拉伯文檢查點之間做評比，只是改一下路由，而不是做兩次整合——而逐項評分正是這套路由 DSL 所為而生的情境，因為它讓你在一次組合呼叫中就把同一個提示送給兩個模型，而不必自己寫一套比較框架。目前我們的目錄裡這兩個系列都沒有；模型清單就是查看目前有哪些模型的地方。

「什麼能解決這件事？」

在共用的測試框架上，對這兩個模型進行一次獨立執行，並連同提示詞一起公開。這正是目前所欠缺的，而且不只這兩個模型，每個主流阿拉伯語模型都缺這個——整個領域都靠自我報告的數字在運作，這就是為什麼 Fanar 2 的 ArabicMMLU 出現八個百分點的分歧，可以在公開場合懸而未決七個月，卻始終無人解決。在有人做到之前，請把 Jais 3 的表格當作 IFM 的論點，把 Fanar 2 的表格當作 QCRI 的論點，並把架構事實——512K 對 32K、七個檢查點對一個、解析器旗標對代管 API——當作你真正能據以規劃的部分。

數字無法告訴你的是，這一切在實際運作中是否出了問題：針對此類模型有記錄的 AI 事件與代理故障，都收錄在the OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、可信度等級與爭議標記。