System One 模型将为 AI 软件带来一场革命：Laya 与 Jev

9 月 15 日，AI 和科技界发生了一场地震般的巨变，而普通大众几乎毫无察觉。和往常一样，走在这场进步最前面的是软件工程师，其他人则与它擦肩而过：这一天，TypeSafe AI 发布了首个商用 System One 模型“Jev”。

三周后，我已经为我们即将推出的一款产品训练出了自己的 System One 模型。本文就是这段经历的复盘。

如今关注 AI 的人都懂这种感觉。有人给您发来一条链接，介绍市面上又一款新的 AI 产品，您翻了个白眼。“System One 模型？”您问。谁在乎呢？我有 Claude Opus，还有一大堆活要干。我可没时间再折腾一个 Manus 或 Rabbit r1。

我第一次听说 Jev 时，脑子里想的正是这些。但有人来问我的看法，于是我决定研究一下。开门见山地说，TypeSafe AI 的网站在解释这个概念方面做得非常差。读完他们的发布博文，您要是以为它是来和 OpenAI、Anthropic 的顶级 AI 模型竞争的，也情有可原（何况他们的图表也是这么展示的）。他们满口“Reinforcement Learning for Calibrated Decisions”（RLCD，校准决策强化学习）之类的术语，这对普通消费者来说几乎毫无意义。

直到读了 LangChain 这篇好得多的文章，我才明白 Jev 到底是做什么的。如果您想了解完整的解析，请务必读一读那篇文章，绝对值得。下面是文章中的一张信息图，它让我大开眼界，把使用场景讲得比 TypeSafe 发布的任何内容都清楚。

一看到那个例子，无数可能性便在我眼前展开，我的脑海里涌现出它能为我眼下种种难题提供的解决方案。我意识到，它解决了我们两个即将推出的项目所面临的问题：Infinilang 和 kcalc.ai（截至本文发布时，后者的网站尚未完成）。

这两个项目的功能都依赖 LLM。我不是那种为了证明什么就把 AI 硬塞进任何东西里的人，我也不想经营那样的公司。过去 4 年 AI 工具不断发展，在此期间我各自独立地构思出了这两个项目，它们为人类多年来一直在努力解决的问题提供了真正有创新性的方案。

我先简单介绍一下这两个项目，让您了解背景，不过本文主要聚焦 Infinilang，如果您时间紧张，可以跳过 kcalc.ai 部分。

您尝试过减重或增重吗？我试过。我在健身房练了三年，才明白力量训练只占健身这件事的三分之一。另外两部分是睡眠和热量摄入。不幸的是，增重恰恰是我不擅长的，要吃得比维持体重所需的更多，对我来说太难了。

我试过应用商店里那种卡路里计算器。您知道是哪种：记录一整天吃的东西，努力达到一个目标。理念很好，但执行几乎总是很糟糕。花在记录食物、修正宏量营养素配比和热量上的时间，比真正吃饭的时间还多。它们通常还提供拍照功能，大约 20% 的时候能用，而且宏量营养素、份量和热量从来都算不对。对自制食物和非标准食物也几乎毫无用处。

kcalc.ai 的不同之处在于，它的目标是大幅减少记录时的麻烦。当您拍一张照片或做一次 LiDAR 扫描时，一条由 15 个阶段组成的复杂证据流水线会处理这些信息。它综合运用了 LLM、向量数据库、庞大的食物与食谱数据库、视觉模型、3D LiDAR 扫描重建、多步推理智能体等等。

说实话，这款应用的 AI 部分是一项浩大的工程。很少有人尝试做这件事并不奇怪，因为它需要大量的软件工程经验和高阶的系统思维，而具备这些的人很少。没有 AI 编程智能体的协助，这根本不可能做到，除非投入 1000 万美元，再加上 5 名工程师一年的时间。

kcalc.ai 要想在商业上可行，就必须解决一系列严重的问题。其中最大的两个是准确性评估和速度。

我们来看一个场景。

用户上传了一张“比利时薯条配蛋黄酱”的照片。

证据流水线处理这张图片，各个阶段加上多步 LLM 推理，最终得出结论：这确实是比利时薯条，很可能配了蛋黄酱。kcalc.ai 有意思的地方在于，它不一定会给用户返回一条预先配置好的记录，而是根据上下文和真实尺寸测量，结合体积计算动态生成记录。这些都没毛病。它能用，只是走完整条流水线大约需要 2 分钟。

这款应用有一个“World Atlas”（世界图鉴）功能，用户可以收集各国菜肴，也就是“经典菜”，逐步填满自己的世界地图。因此，在识别完食物之后，还需要对照一份菜肴清单进行检查。这该怎么做？按传统做法，我们可能会用某种正则表达式（Regex）或相似度算法去搜索清单，找出可能的匹配项。我最先试的就是这个办法，结果总是出错：系统会把名字相近的食物搞混，错发图鉴条目。于是下一个显而易见的选择，是先取出可能的匹配项，再让 LLM 挑出最合适的那个。问题在于这样太占算力，我没法为了一个次要的附加功能而拖住热量估算功能。

System One 模型配合向量数据库，就能解决这个问题。

有了 System One 模型，只需几毫秒就能得到准确的选择，而且与完整的 LLM 相比，资源成本低得惊人。在存在许多可能相似的选项的场景里，它简直是救星。

System One 模型接口真正的妙处在于，它极其容易集成。您可以在代码库里找到几百个可以插入它的地方，而且它又便宜又快，几乎不用多想。这只是一个例子，我相信 kcalc.ai 还会在许多地方受益于这项新技术。

我学了一辈子日语，时间极其有限，而且（说实话）缺乏语言天赋，但总算掌握了勉强过得去的水平。足够在日本到处走走，甚至能在酒吧里和人聊上几句有趣的天，但还没好到能躲过一句又一句客套的“nihongo jyouzu”（“你日语真好”）。

学习日语最棘手的部分之一是“kanji”（汉字），它是构成日语书写系统的第三套字符，也是数量最多的一套。下面是这三套字符的示例：

• 平假名：ありがとうございます（罗马音 arigatou gozaimasu，意为“非常感谢”）
• 片假名：コールドブリューアイスコーヒー（罗马音 korudo buru aisu kohi，意为“冷萃冰咖啡”）
• 汉字：人工知能（罗马音 jinkou chinou，意为“人工智能”）

日语汉字源自中国的汉字，部分字义相同，但读音通常完全不同。复杂之处在于，具备基本读写能力需要掌握 2136 个常用汉字，要接近母语水平则需要约 4000 个。更糟的是，汉字往往有多种读法，也就是说，同一个字用在不同地方，读音也不同。学起来简直是噩梦。

OpenAI 的 GPT-3 刚问世时，我是最早的一批使用者之一，很早就看到了这项技术近乎无限的可能性。对我来说最重要的一点，是量身定制的语言学习体验，一种比以往任何时候都更有效的语言学习方式。

当时我构思了 LLM 的三种全新应用，并反复琢磨了好几年。在此期间，我为这项技术开发了两代原型，证明它确实可行。

这个学术味十足的标题，是我围绕 Infinilang 的构想攻读硕士学位时所写论文的题目。我原本打算把这些工具作为开源研究贡献出来，但一边做全职工作，一边受限于资源，这条路实在走不通。所以我打算先把 Infinilang 作为闭源移动应用推向市场，之后再将它作为支持自带 AI（BYO AI）的开源桌面应用发布。

那么，Infinilang 能带来什么？对日语学习者来说，记住汉字只是学会高效阅读的一个方面。目前，记忆汉字是一个缓慢而枯燥的过程，要用到间隔重复系统（SRS）。著名的有 Anki 和 WaniKani，后者是我个人的最爱。SRS 会反复向用户展示闪卡，同时逐步拉长每两次之间的间隔。系统的设计是每次都在您快要忘记一个学过的字之前，再把它展示给您。您看到这张闪卡的次数越多，记住的时间就越长，而且看到它的频率越来越低时，记忆效果反而更好。SRS 经证实是记忆汉字的最佳方法，但它最大的弱点在于，它没法教您如何高效地阅读含有汉字的句子。

去读 NHK Easy 的文章或者儿童读物就行了。

传统的看法一直是：找些简单的读物，借助振假名 東(とう)京(きょう)（某些读物中标在汉字上方的小号平假名注音），尽力啃下不认识的汉字。问题显而易见：只要有一个汉字不认识，您就会被彻底绊住，整个句子往往也就读不懂了。

所以我的想法是这样的。SRS 应用能出色地记录您学过哪些汉字，以及您对每个字的掌握程度。如果能找到只由您学过的汉字组成的阅读材料，会怎么样？LLM 恰恰能做到这一点，而这正是 Infinilang 的用武之地。

Infinilang（第一阶段）的目标，是生成与用户水平精确匹配的阅读材料。我们直接从您的 SRS 应用中提取您学过的汉字，交给 LLM，然后在这个受约束的字符集内生成句子。这可不是把字符集丢给 LLM 就能产出优质阅读材料那么简单。要驯服 AI 把这项任务做好，比您想象的难得多。但它确实可行。

生成高质量阅读材料时遇到的挑战可以归为若干类别，本质上就是一系列必须提出的问题：要确保 LLM 没有犯错；如果犯了错，能否在不重新生成整条回答的情况下修复。

• 句子有多自然？
• 句子读起来是否像被过滤或受损过？
• 文段是否连贯？
• 文段是否切题？
• 文段是否适合未成年人？
• 是否包含真实的人物、品牌或地点？
• 能否从上下文推断出 N+1 插入词？
• 该文段将来是否值得复用？
• 句子是否合乎语法？

这份清单并不完整，但这些是针对生成内容必须提出的主要问题。

有件事很早就再明显不过了：使用第三方 LLM API 会让项目从一开始就夭折。API 额度实在太贵，会吃掉订阅收入的大部分。更糟的是，甚至会让我们入不敷出。

解决办法只有一个，那就是搭建我们自己的 AI 基础设施。对一个资金有限的创业者来说，这可不是件容易的事。好消息是，小型 LLM 每隔几个月就变得更强。它们当然达不到顶级模型的水平，能用上 Opus 级别的 LLM，我只能在梦里想想。但只要软件架构范围收得够窄、支撑得够好（也就是大量调教），这些小型 LLM 也能产出高质量的内容。

但这解决不了另一个事实：基础设施起步时规模很小，而每天有成千上万的用户在生成内容，推理资源会很紧张。我们还得以合理的速度生成内容。没有人愿意干坐 2 分钟，等一段日语出现在屏幕上，不管它写得多好。

所以，每次生成时 AI 需要执行的推理任务大概是这样的：

1. 在约束范围内生成一个句子、一个段落或一篇短篇故事。可能需要一些推理，内容越长，耗时越久。
2. 根据上面列出的几类问题，评估生成的材料。
3. 对于无法用程序直接修复的地方，让句子经过几轮有针对性的外科手术式修复。
4. 再重复一次第 2 步。
5. 在把内容发给用户之前，可能还要再重复一次第 3 步和第 2 步。

即使有企业级 GPU 和前缀缓存，这个过程也可能要花一两分钟，而且我们只有 8 个并行推理槽位，这意味着同时有超过 8 个人在生成时，任务就得排队。无论从哪方面看都不现实。

这时候，System One 模型就登场了。

与传统 LLM 相比，System One 模型有几个关键优势，让它们非常适合我这样的使用场景。

1. 它们的响应快得惊人。我在澳大利亚，Jev 运行在硅谷，可一次调用仍然大约 258ms 就能返回，这还包括了网络延迟。与传统 LLM 相比，这是巨大的优势。
2. 它们能并行回答许多问题。LLM 需要按顺序逐个处理问题，而 System One 模型可以一次接收一批问题，回答它们所花的时间与回答一个问题大致相同。也就是说，如果用 LLM 认真回答九个问题需要 60 秒，那么用 System One 模型回答同样的九个问题只需 258ms。您需要问的问题越多，从 Jev 这样的工具中获得的优势就越大。

3. 它们便宜得难以置信。在这个项目中，我每 1000 次调用只在 Jev 上花了 0.025 美元。我得到的一个心得是：Jev 运行起来极其经济。把它集成到任何地方我都毫无心理负担，它几乎是免费的。

另一个常被低估的优势是可靠性。有些 LLM 回答时会失控，给出无法用程序处理的非结构化回答。Jev 则是“类型安全”（typesafe）的，它总能给出一个可以解析的有效回答。

这就说到 Laya 了，它是这次实验的主角，很可能也是您读这篇文章的原因。Jev 公开发布后没几天，就冒出了一大批试图复刻这项技术的开源项目。

https://github.com/NandhaKishorM/laya

截至撰写本文时，Laya 在 GitHub 上已经斩获多达 35,000 颗星。它来势汹汹，短短几周内就有超过 1000 次提交，截至撰写本文时已接近 3000 次。这样的首秀相当惊艳，也说明软件工程社区对 System One 模型有多大的兴趣。

Laya 自带三个基础模型：laya (421M)、laya-multilingual (322M) 和 laya-typed-decisions (421M)。简单来说，laya 是全能型模型；laya-multilingual 更擅长英语以外的语言，但准确度较弱；laya-typed-decisions 准确度更高，代价是应对不同场景的灵活性较差，多语言能力也很弱。

Laya 最明显的优势是开源，基础设施由您自己掌控。不必担心 Laya 突然破产、关闭服务器，害您手忙脚乱地寻找合适的替代品，否则您的软件就要面临灾难性故障。对像我这样希望大规模扩张、又想把风险降到最低的公司来说，这是个很有吸引力的理由。

Laya 的另一个好处是模型体积小。默认情况下，它运行所需的显存非常少，而且根据那份由 AI 生成的超长 README.md，它甚至可以在 CPU 上运行。印象中，我实验时基础模型只占用 2GB 显存，轻松就能放进我的服务器基础设施。

如果一样东西好得不像真的，那它通常就不是真的。GitHub 页面上的统计数据和与 Jev 的对比，给出了这样的说法：

在我看来相当有说服力。那么问题出在哪里？看看 Laya 的模型是用哪些主题来测试的。

“垃圾邮件”“网络钓鱼”“RAG 段落相关性”和“客服分流”，这些主题都非常具体，也与上述劣势密切相关。您会注意到，“LLM 护栏”“内容审核”和“模型路由”被标为“留出”（held out），这是个重要的区别。

简单来说，Laya 不是那种拿来即用的通用模型。您没法随手拿起它，放进任何使用场景。出厂状态下，它只具备非常特定的能力，其他事情几乎都做不了。这正是 Jev 真正显示实力的第一个地方：“它直接就能用”。我第一次用 Infinilang 测试 laya-multilingual 模型时，结果一败涂地，所需的任务它没有一项能做到足够好。

初次失败之后，我没有马上放弃。由于 kcalc.ai 和 Infinilang 离上线还有一段时间，我手上有一套相当强悍的服务器基础设施几乎闲置着。这意味着 Qwen 3.8 27B 正闲在那里等活干，每当我需要一块强大的 GPU 来训练时，都可以把它关掉。是时候做些实验了。

实实在在地说，训练 AI 模型存在严重的法律障碍。作为一个法律实体，Hex Pro 必须严格遵守这些法律。所以我费了很大功夫，确保自己遵守所有许可要求。

第一个实验相对简单，目标是看看训练出来的模型能否达到预先设定的标准。

1. Qwen 3.8 按照 Infinilang 原型所需的方式，生成了 1,995 个日语示例。

2. Claude Opus 以 3 个为一组组成评审团，按六个类别评估每一条输出，这就是我们用来衡量的“金标”。

3. Qwen 3.8 作为教师，用它自己对同样六个类别的评估结果来标注训练数据。

最初实验中的六个类别是：

• S1：句子有多自然，5 分制打分（指标：Spearman）
• S2：句子读起来像是被过滤或受损过，是或否（指标：pAUROC）
• S3：英文是忠实的翻译，是或否（指标：pAUROC）
• P1：从三个修复候选中选出最佳者，或都不选，四选一（指标：金标一致率）
• P2：修复候选中有没有可接受的？是或否（指标：pAUROC）
• G1：句子合乎语法，是或否（指标：pAUROC）

结果令人失望。最扎眼的是 S1（自然度），它需要达到 Spearman 0.60 的标准，结果只有 0.452。我的第一反应是当场放弃 Laya 训练这个想法。到那时我已经在上面花了大约一天半，而这些结果实在不够好。

我就此叫停了实验，不值得再花时间。Jev 运行起来那么便宜，训练一个模型的花费，要比重度使用 Jev 5 年高出好几个数量级。那天晚些时候，我心血来潮，决定拿同一个实验测试一下 Jev，结果发现了非常有意思的东西。

我去！慢着。这些数字是怎么回事？教师模型在所有指标上都与 Jev 不相上下，在挑选句子修复候选方面甚至明显胜出。不过最让我信服的数字，是 S1 上的 0.446。Jev 也没达到 0.6 的标准。

这些结果让项目重新焕发了生机，我立刻着手在此基础上继续推进。只是粗略一试，我就在那些 Infinilang 任务上追平了 Jev。只有一个地方 Jev 自始至终无人能敌，那就是校准。虽然 Laya 的实际结果很扎实，但 Jev 提供的“置信度”分数在各方面都远远胜出。Jev 的评分是多维的，它知道自己什么时候有把握、什么时候没有。对于一个可以插进任何任务、拿来即用的模型来说，这一点非常重要。而对于一个专为一组非常特定的任务设计的模型，校准这个数字就没那么必要了。

到这一步，实验 1 已经结束，基准测试也已冻结。接下来要开始花钱了，事情变得严肃起来。现在的目标是在 Infinilang 的任务上大幅超越 Jev 的能力。在我看来，要提高实验 1 的分数有三条路：

1. 更多训练数据
2. 更好的 LLM 模型
3. 更多样的评分标准

此时我决定，要等收集完所有结果之后，才跑 Jev 的基准测试。一旦拆封了 Jev 的基准测试，我就得换一个新的数据集，以确保 Jev 始终处于隔离状态。

第一步是筛选替代的教师模型。我要找的模型，要么规模大得多，要么可能更适合 Infinilang 的日语约束条件。候选模型有：

• DeepSeek V4.1：规模庞大、能力出众的推理模型，调用价格相当便宜。日语得分很高。
• Gemma 4 31B：曾在 Infinilang 原型中测试过，在避免超纲汉字方面表现突出。体积也小到可以在我的服务器基础设施上运行，所以测试它基本不花钱。
• Qwen 3.8 Flash Next：基本上就是 Qwen 4 的预览版。它是混合专家（MOE）模型，因此比 Qwen 3.8 27B 规模大得多，知识也更丰富。
• Hy3 和 Inkling-Small：两个知名度较低的模型，我觉得它们的日语能力或许不错。

其他模型都被排除了，通常是因为它们的许可不允许用于训练。

最先被淘汰的是 Qwen 3.8 Flash Next。最大的问题是自我偏好风险，因为它与生成器（Qwen 3.8 27B）同属一个家族。值得一读的是 Extreme Self-Preference in Language Models（Steven A. Lehr、Mary Cipperman 和 Mahzarin R. Banaji，2026），这项研究表明，LLM 偏爱自己的输出，而对其他模型的输出往往更为挑剔。

“自我偏好是生物有机体的一项基本特征。由于大型语言模型（LLM）缺乏感知能力，人们或许会认为它们能够避免这类扭曲。然而，在 72 项实验、约 41,000 次查询中，我们在八个被广泛使用的 LLM 身上发现了强烈的自我偏好。”

自我偏好影响结果的风险太高，而且测试显示，它的结果本来就与 Qwen 3.8 27B 的高度一致。既然直接免费用 27B 版本就能得到相近的结果，再为一个带有这种风险的模型投入真金白银就说不过去了。

接着被淘汰的是 Hy3 和 Inkling-Small。这里没什么好说的：它们很贵，结果也没有比其他任何模型更好。

DeepSeek V4.1 全面领先，表现远远超出我的预期。我一直以为 DeepSeek 不过是个山寨的劣质中国模型，把 OpenAI 和 Anthropic 的东西偷了个遍。后者大概属实，但它已经不再劣质了。在允许用其数据进行训练的开放权重模型中，它显然是最好的。冲着他们的开放权重模型，上帝保佑中国人。

最后一个是 Gemma 4。在大多数类别上，DeepSeek 都占据压倒性优势。Gemma 4 在大多数方面达到了 DeepSeek 的水准，尤其在 S3（翻译忠实）上表现出色，在 P2（有可接受的修复）和 B2（切题）上也表现不错。既然测试它不花钱，我决定值得继续用它。

因此，之后的所有测试都将使用 Qwen 3.8 27B、Gemma 4 31B 和 DeepSeek V4.1。

最初的实验只有有限的几个类别，但这个模型在 Infinilang 里还有很多用武之地，我想确保它针对需要完成的每一项任务都受过训练。

新的评分标准共有 14 个类别。上面提到的 6 个（S1、S2、S3、P1、P2、G1）措辞经过了打磨和收紧，另外新增了以下类别：

• B1：文段连贯，是或否（指标：pAUROC）
• B2：文段切题，是或否（指标：pAUROC）
• B3：文段适合未成年人，是或否（指标：pAUROC）
• B4：不含真实品牌或地点，是或否（指标：pAUROC）
• B5：N+1（新汉字）词可以从上下文推断出来，是或否（指标：pAUROC）
• B6：文段值得复用，5 分制打分（指标：Harrell's C）
• B7：文段的日语自然，5 分制打分（指标：Harrell's C）
• PS2：文段的日语读起来像是受损过，是或否（指标：pAUROC）

这一次，训练数据不再只是一行日语（1 到 2 个句子），而是句子、段落和短篇故事的混合。评分标准也相应扩展，以满足这一需要。您还会注意到，我对另外几项功能也感兴趣，比如缓存内容供其他用户复用，以及为年龄限制识别适合未成年人的内容。

我的 GPU 嗡嗡运转了 10 个小时，用 Qwen 3.8 27B 生成新的话题和训练材料。这里我选择继续用 Qwen 生成训练数据，因为今后 Infinilang 生成内容用的反正就是这个模型。在这里换用更强的模型反而适得其反。

最终我得到了 215,000 行数据，每一行都有 Claude 金标评审团的评判。Jev 也会用上这套经过扩展和增强的评分标准，这让它在实验 1 基准上的结果显著提升。

请注意，以下结果采用了随增强版评分标准一起制定的新规则，因此明显优于实验 1。此外，对于部分类别，我还测试了把 DeepSeek 和 Gemma 的结果取平均，并按两者的一致程度加权。还有一点需要说明：在某些情况下，对某些模型而言，更多的思考反而会损害结果。所以这些结果，是我针对每个模型和每个类别，在开启或关闭思考、使用或不使用规则的不同组合之间调优后得到的最佳成绩。

*K8：在关闭思考的情况下采样八个简短回答，以平滑直方图的形式汇总

这些数字让我对手头能用的东西心里有了底。如前所述，我也用这些新标准测试了 Jev，发现它这次的表现好了很多。Jev 在较长文本上表现突出，在考虑 Laya 时应该注意这一点，因为 Laya 的上下文窗口没有那么长，处理长文本也更差。

既然每个类别的教师都已确定，是时候真正训练 System One 模型了。别忘了，实验 2 是为了确定哪个教师最适合哪个类别。这并不意味着学生模型就能表现得和教师一样好：把所有这些任务合并到一个模型里，难免要有所取舍。打算使用 Laya 的人应该考虑一下，您需要一个模型承担多少项任务。比如，如果我为每个类别单独训练一个模型，并把它优化到极致，然后把 14 个模型有策略地部署在程序各处，就能在各方面都拿到最好的结果。但问题是，那样就得同时运行 14 个独立的模型，占用的 GPU 资源要多得多。所以这是个规模问题。如果您是一家有数十亿资金可以砸在昂贵服务器上的巨头公司，这根本不用想。这样的模型单单一个就能以极少的资源服务海量用户。对其他人来说，这恐怕不是利用宝贵 GPU 算力的最佳方式。

到了这一步，该动真格的了。GPU 再次全速运转，这次花了 35 个小时生成和标注更多训练数据。然后 Claude 金标评审团又在新数据上跑了一遍，在 Ultra（原 Max 20x）套餐下消耗了超过 2 亿个 token。

最花钱的是 DeepSeek：它没法在本地运行，需要云端推理。它被选用于 9 个类别，花费 233.56 澳元，耗时 18 小时完成。用美元算，一切看起来都人畜无害，可银行流水里的澳元数字就难看多了。Gemma 4 的推理在我们自己的基础设施上运行，所以不花钱，为分配给它的几个类别做标注大约花了 60 个小时。

最终，我按不同的调优方式和思路训练了四个候选模型：prod-q38、prod-ds41、prod-mix1 和 prod-mix2。每个学生模型都分三个实验组训练，每组两个随机种子，以确保我们不会被离群值误导。进入决赛的模型又追加了三个种子。

• A 组：laya-multilingual（mmBERT），使用其预训练的分类头。
• B 组：modernbert-ja-310m，使用全新的分类头。
• E 组：将 sokudan-ja-310m 移植到 B 组的架构中。

另外还有一个 D 组，是 130M 参数的延迟测试，性能落后。

这是第一个、也是训练成本最低的一个，它完全使用 Qwen，并根据哪种得分最高采用不同配置（开启/关闭思考，使用/不使用规则）。我知道它不会像其他几个那样好，但它是实验 1 的延续，也为其他模型能提升多少提供了基线。

DeepSeek 在上一个实验中明显表现最好，但 Qwen 在少数几个类别上占优，或与 DeepSeek 相当接近。凡是 Qwen 追平或超过 DeepSeek 的地方，我都用 Qwen 来省点钱。

这个模型在每个类别中都选用最好的教师，试图打造一份终极拼盘。同时还测试了：在 prod-ds41 学生模型表现似乎不如预期的地方，把 Qwen 换成 DeepSeek。

思路与 prod-mix1 类似，但把 P1 和 B3 改回与 prod-ds41 一致，看看能否改善结果。

分不同实验组训练是个明智的决定，因为它揭示了一些非常重要的数据。所有基于 laya-multilingual 训练的实验组（A 组）都不如 B 组和 E 组。这是个重要发现，因为它表明多语言版本是垃圾，至少在我这种只需要日语的情况下是这样。

我强烈建议，任何想训练 System One 模型的人都扔掉 Laya 自带的模型，基于 ModernBERT 加一个全新的头来训练。或者至少像我们这样做一次多组对照测试，免得被一个劣质的检查点坑了。

下面是每个学生模型的最终成绩，以及 Jev 在新训练数据上使用增强版评分标准得出的最终成绩。

这些结果很有意思，因为它们并不总是符合直觉或预期。关键要认识到，针对每个类别的数值所做的训练，都会对其他所有类别产生虽小但会累积的影响。所以这些数字参差不齐。有些情况下学生模型得分比教师高，更多情况下则略低。

要决出真正的赢家也很困难，因为每个类别的价值并不相同。比如，S1（日语的自然度）是个重要类别，Jev 在这里明显优于其他模型。反过来，B7（整个文段日语的自然度）同样非常重要，而 Jev 在这一项上落后于其他所有模型。

同样，一个模型“赢下”很多类别，并不意味着它自然就更好。prod-ds41、prod-mix1 和 prod-mix2 在大多数情况下都非常接近。prod-mix1 的 S2 是 0.890，prod-ds41 的是 0.889，两者几乎没有差别。如果去掉干扰，只显示相对 Jev 的优势或劣势，并且只标出赢下该类别或并列第一的模型，这一点就更清楚了。

我的看法是，prod-ds41 是理想的全能型选手。prod-mix1 在少数几个类别上成绩亮眼（尤其是 P1、P2 和 B6），但在另一些类别上相对 Jev 落后很多，而 prod-ds41 在这些类别上落后得少一些（S3、S1、B1 和 B3）。和另外两个相比，prod-mix2 有一些明显的短板，尤其在好几个类别上较弱（S3、P1、P2 和 B5），在其余类别上也并不特别强。不过总体而言，这三个模型普遍比 Jev 占优，只有少数几个 Jev 真正擅长的类别例外（S1、S3 和 B3）。

所以在 prod-ds41 和 prod-mix1 之间二选一的话，prod-ds41 胜出，纯粹是因为它在所有类别上的表现都更稳定。

prod-ds41 最终夺冠，获得了 infini-jp-v1 的名号。数据非常清楚地表明，它有能力胜任大多数角色，令人失望的例外是 S1，也就是句子自然度，不过我已经为它找到了别的解决办法（后文详述）。

那么回到核心问题：Laya 比 Jev 好吗？也许吧？但多半不是。虽然在这个案例中，它在这组特定任务上确实胜过了 Jev，但我们先来算算开发它花了多少成本。

算下来，我在这个项目上总共花了 270 美元（389 澳元），其中 268.23 美元用于云端推理，0.21 美元用于 Jev。如果 Anthropic 和 OpenAI 正在背负数千亿债务的说法属实，那按 AI 训练的标准来看，这算便宜的。但对于一家资金有限、收入（暂时）微薄的初创公司来说，这并不便宜。不过这是一笔有价值的研发投入，因为它回答了一些重要问题：我将来是否应该在其他项目中使用这项技术。此外，我现在有了一个训练流水线项目，提交次数超过 1000 次，单元测试多达 14,522 个，这意味着将来再开发一个 System One 模型，只需要打磨评分标准、做几轮模型比拼就行了。

从亲自动手的时间来看，这也不便宜。谢天谢地谢 Dario，幸好有 Claude Code，大量杂活（盯着训练跑完、给下一步排队等等）都由它包办了。这意味着几乎没有停工时间，工作在夜里也照常进行。即便如此，这个项目从头到尾还是花了 24 天。要是没有 AI 协助，得花六个月，这一点我毫不怀疑。

尽管 AI 节省了大量时间，也让我能同时做其他事情，但按我以前的费率计算，我亲自投入的时间也值大约 5000 澳元的人工费。这是训练 System One 模型时必须考虑的成本。

我算是比较幸运，手头有一块又快又强的企业级 GPU。但这个项目需要独占 GPU 超过 40 个小时，我都不敢想电费账单有多少。我甚至根本不想知道。

另一项持续的成本是，它在我的服务器上占用大约 2GB 显存。

这是个重要但难以量化的问题。如果我在考虑做这件事，我会想先回答这些问题：

• Jev 能把这项任务做好吗？
• 您预计会有多少调用量？
• 您需要它完成的任务有多少、有多多样？
• 您需要多长时间才能收回投资？
• 确信 TypeSafe 消失后您的软件仍能运行，这份安心对您有多重要？
• 您有多在意准确的校准/置信度？

就我而言，能力上的提升或许能让 Infinilang 表现得更好。如果 Infinilang 因此表现更好，让我能积累更多用户，那它迟早能收回成本。这也是我能为选用 Laya 而不用 Jev 找到的唯一理由。

• 延迟：从澳大利亚出发，Jev 一次往返大约需要 258ms。Laya 平均约 19ms，至少比 Jev 快 13 倍，比 DeepSeek 快 2000 倍。
• 释放 GPU：它占用 2GB 显存。这不算少，但也不算多。真正的好处在于：infini-jp-v1 回答的这 14 类问题，就不必再由 Qwen 3.8 27B 来（蹩脚地）回答了，GPU 因此能腾出手来处理其他更重要、更合适的请求。
• 模仿更强的模型：不必运行 DeepSeek V4.1，也能得到与它相当接近的答案。在这些任务上，infini-jp-v1 的表现远超 Qwen 3.8 27B，而且不需要搬出需要 614GB 显存的 DeepSeek 模型。
• 业务安全：前面提过几次，用自己的模型，就不必担心 Jev 突然消失。不会有意外宕机，也不用手忙脚乱地找替代品。只要我的软件在线，我就知道我的 System One 模型也在线。
• 窄任务上的优势？：它在生产环境中是否表现更好，还有待观察。走着瞧吧。从分数上您也看到了，理论上它在 Infinilang 中要好 6%，但那是所有类别的综合，未必是真正关键的那几个类别。

给还不了解的读者科普一下：LoRA（Low-Rank Adaptation，低秩适配）有点像 LLM 的即插即用人设。您可能也听人把它叫作“微调”。System One 模型是一个独立的服务，而 LoRA 则在推理时直接作用于 LLM，调整它的权重，让它表现得不一样。

正因如此，在 Infinilang 后来的开发中，我训练了一个 LoRA，帮助 Qwen 3.8 27B 产出质量更高的内容，并遵守更严格的规则。这意味着 infini-jp-v1 要分类的将是质量更高的材料。它不必那么费劲，效果也应该更可靠，对已学汉字较少的用户尤其如此。

随着开发继续推进，我会努力让 Infinilang 变得更好。