Jais 3 vs Fanar 2：两家厂商对 Fanar 2 得分多少意见不一

J​ais 3 和 Fanar 2 是海湾地区的两个旗舰阿拉伯语模型系列，而关于比较它们，任何人能告诉你的最有用的信息是，供应商自己为 Fanar-2-27B-Instruct 提供的数字对不上。QCRI 的模型卡报告其 27B 指令模型的 ArabicMMLU 为 74.67%，Belebele 为 86.81%。J​ais-3-32B 模型卡来自基础模型研究所和 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）、工具调用解析器，以及三种可选的工具调用格式。可在 bfloat16 精度下以张量并行度 2 提供服务。

• Fanar-2-27B-Instruct——来自哈马德·本·哈利法大学 QCRI 的 27B 稠密模型，上下文长度 32,768 tokens，采用 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 那一列读的是同一个基准名称。二十五分的差距不是四舍五入能解释的，诚实的结论是：这两次运行中至少有一次测的并不是另一次所测的东西。

• 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 之内。

• 服务资源占用 — Jais-3-32B 在 TP=2、bfloat16 下，需 vLLM ≥ 0.30.0 或 SGLang ≥ 0.5.20。Fanar-2-27B 已使用 transformers 4.57.6 进行测试，且为标准 Gemma 3 27B 形态，因此可无缝接入任何已在运行 Gemma 的技术栈。

• 随模型发布的工具 — Jais 3 包含推理解析器、工具调用解析器，并支持选择 json、xml或xml_typed 工具格式作为一等服务标志。Fanar 2 支持通用工具调用以及十个内置 Fanar 工具，但其集成接口是供应商自己的 API，而不是一组框架标志。

• 第三方评估 —— 两者都没有 Artificial Analysis 收录条目，都没有竞技场评分，也都没有独立复现。两个系列的数字均为厂商自行报告，文章每次引用这些数字前都会明确说明这一点。

Fanar 2 拥有的而 Jais 3 没有的

三件事，而且都不是小事。

• 原生阿拉伯语推理轨迹。Fanar 2 在约 250,000 条阿拉伯语推理样本上完成训练，其思维链以阿拉伯语生成，而非从英文思维链翻译而来。Jais 3 公开了一个推理解析器，并报告了强劲的阿拉伯语智能体表现数据，但其模型卡并未就"思考过程所使用的语言"作出同样的表述。

• 将幻觉缓解作为一项设计行为。Fanar 2 经过训练会主动弃答——训练期间进行知识探查、五步结构化验证轨迹、经过校准的"我不知道"回应——并且它会把自发引用的古兰经经文包裹在验证标记中，以便下游系统可以核查。最后这项功能很不寻常，在 J​ais 3 卡片中没有对应项。

• 围绕该模型打造的产品。QCRI 提供聊天界面、iOS 和 Android 应用，以及一套带有访问申请流程的文档化 API，此外还有用于图像生成、图像理解和诗歌创作的同系列模型。J​ais 3 是附有框架配方的权重发布；语音模型与之并列，其余部分则是研究成果。

那些是能力上的差异，而不是基准测试上的差异；公允地解读，Fanar 2 作为产品更完善，而 J​ais 3 作为模型更有雄心。

那些智能体专栏到底在说什么，还附带着星号注解

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 分，这是合理的——这些是智能体基准，会惩罚那些没有大规模工具调用训练数据的模型，而 Fanar 2 的智能体工作是围绕它自己的十个工具展开的，而不是通用软件任务。但一个实验室报告它自己的模型在它自己构建的表格中每一行都胜出，这告诉你的其实是它的评估，而不是现实世界的情况。

站得住脚的说法要更窄：在 IFM 公布的评测框架上，Jais-3-32B 在每一个已报告的智能体基准上都优于 Fanar-2-27B-Instruct，而 Fanar 的模型卡根本没有报告智能体基准，因此既没有任何东西反驳它，也没有任何东西佐证它。已公布的证据是单方面的，因为只有一方公布了证据。

该选哪一个

长上下文、智能体工作，或者需要选择检查点规模时：选 Jais 3，而在上下文这一项上，这根本算不上难以取舍。512K 窗口对 32K，仅此一点就足以决定文档处理、代码库级工作和长智能体轨迹的成败。

你想要阅读的阿拉伯语推理、你可以信赖的拒答行为、《古兰经》内容处理，或者一个拥有应用和支持途径的供应商：Fanar 2。QCRI 的后训练流水线确实极为精细——400 万条 SFT 指令、28 万对 DPO 数据、五个阶段，以及一次刻意进行的能力再平衡处理，以防止长上下文适配削弱短格式任务——而这会体现在排行榜任何一列都无法捕捉的维度上。

如果这个决定很难，是因为两者对同一工作负载都同样合理，那么能一锤定音的就是你自己的提示词：让两者都跑一遍，再按你自己的标准打分。这正是没有人针对这两个模型发表过的实验，而它的价值高于上面引用的每一个数字。

现在跑起来比过去省事多了。OrcaRouter 让你用一个密钥就能访问 200 多个模型，0% 加价，提供商标价原样透传，所以两个阿拉伯语检查点之间的对比只需改一下路由，而不是做两次集成——而逐项打分恰恰就是路由 DSL 天生擅长的场景，因为它让你在一次组合调用中把同一个提示发给两个模型，而不用自己写一套对比测试框架。这两个系列目前都不在我们的目录里；模型列表就是查看当前有哪些模型的地方。

怎样才能解决这件事

在共享测试框架上对两个模型各做一次独立运行，并连同提示词一并公布。这正是所缺失的，而且不只是这两个，每一个主流阿拉伯语模型都缺失这一点——整个领域都在依赖自我报告的数字，这就是为什么关于 Fanar 2 的 ArabicMMLU 的八分分歧能在公开场合搁置七个月而无人解决。在有人做到之前，把 J​ais 3 的表格视为 IFM 的主张，把 Fanar 2 的表格视为 QCRI 的主张，而把架构层面的事实——512K 对 32K、七个检查点对一个、解析器标志对托管 API——视为你真正可以据以规划的部分。

数字无法告诉你的是，这一切在实际应用中是否已经出了问题：围绕这一类模型的有据可查的人工智能事故和智能体故障，都收录在OrcaRouter AI 事故档案中，其中每一条记录都附有各自的来源、严重程度、置信度等级和争议标记。