TwIL-LM3-Pro：一个通过电子邮件申请即可交付的 3.66B 形式逻辑模型

TwIL-LM3-Pro 是 webAI 推出的一个拥有 36.6 亿参数的推理模型，专为形式逻辑而非日常对话而构建，自 2026 年 9 月 3 日起就已在 Hugging Face 上。它并非新发布，而本周围绕它流传的那套说法——即 webAI“发布了一个 3.66B 模型”——比权重迟了整整一个月。过去几天真正发生变化的事情更小、也更有用：检查点于 9 月 30 日修订，10 月 1 日 webAI 发布了该模型的 LiteRT-LM 构建版本，用于 Android 和 iOS 端侧推理。所以，有趣的问题不是 TwIL-LM3-Pro 是什么，而是你能否拿到它，而答案取决于你站在三个分发渠道中的哪一个——因为其中一个是一张表单。

这一区别比通常情况下更重要，因为 TwIL-LM3-Pro 不是那种你直接调用就能用的产品。它是一个检查点，你需要下载、在自己的硬件上运行，并接受禁止商业使用的许可证条款。它自己的模型卡所邀请进行的比较——与 Qwen3-8B 对比，后者的参数量是它的两倍多——是真实存在的，但这是基于供应商运行的基准测试、在供应商构建的测试框架上进行的比较，而且模型卡本身在比大多数模型卡更多的地方说明了这一点。这篇文章仔细解读了那张模型卡，并将 webAI 所测量的内容与其他人所拥有的内容区分开来。

模型实际上是什么

` block before answering and was evaluated with greedy decoding at a 2,048-token budget." I don't see any {{1}}...{{/1}} markers in this text. So maybe there are none. But the instruction says "The text contains numbered span markers like {{1}}...{{/1}}, {{2}}...{{/2}}." However, the provided input doesn't have them. Possibly the markers are implied? Or maybe the user expects us to handle them if present, but they aren't here. We need to output only the translated text with its markers. Since there are no markers, we just translate. But careful: The input might have hidden markers? The raw text doesn't show any. So we translate. We need to preserve URLs and brand/product names. Here we have: `GraniteForCausalLM`, `granite-4.2-3b`, IBM's, TwIL-LM3-Pro, `<think>…</think>`, etc. Also numbers: 40, 2,560, 8, 3.66B, 3,659,737,600, 131,072, 2,048. Also "greedy decoding" etc. We need to translate into Simplified Chinese. But keep code-like identifiers in English? The instruction: "Preserve URLs and brand/product names." `GraniteForCausalLM` is a class name, likely should stay as is. `granite-4.2-3b` is a model name, keep. IBM is brand, keep? Usually IBM stays IBM. TwIL-LM3-Pro is product name, keep. `<think>…</think>` is a tag, keep. The text between backticks? They are code identifiers. In localization, we often keep code identifiers untranslated. But the instructions say "Preserve URLs and brand/product names." It doesn't explicitly say to preserve code identifiers, but it's typical. Also, the markers: if there were markers, we'd move them. Since none, we just translate the natural language parts. We should also consider if there are any {{KEEP}} spans? Not present. So we translate: "TwIL-LM3-Pro is a dense Granite decoder — `GraniteForCausalLM`, 40 layers, hidden size 2,560, 40 attention heads against 8 key-value heads — derived from IBM's `granite-4.2-3b`." -> TwIL-LM3-Pro 是一个密集的 Granite 解码器——`GraniteForCausalLM`，40 层，隐藏大小 2,560，40 个注意力头与 8 个键值头——源自 IBM 的 `granite-4.2-3b`。 But careful: "dense" in model context is "稠密" (dense as opposed to sparse). So "密集的" is okay, but often "稠密" is used. We can use "稠密". "Granite decoder" -> "Granite 解码器". "hidden size" -> "隐藏层大小" or "隐藏维度". Typically "hidden size" is "隐藏大小" or "隐藏层维度". I'll use "隐藏大小". "attention heads" -> "注意力头". "key-value heads" -> "键值头". "derived from" -> "源自" or "衍生自". "IBM's" -> "IBM 的". "The 3.66B parameter count is the real total, 3,659,737,600, and the context window is the base model's 131,072 tokens carried through unchanged." -> 3.66B 的参数计数是真实总数，即 3,659,737,600，而上下文窗口是基础模型的 131,072 个标记，保持不变。 But "parameter count" -> "参数数量". "real total" -> "实际总数". "context window" -> "上下文窗口". "tokens" -> "标记" (or "令牌"? In Chinese, "token" is often translated as "标记" or "词元". But since it's technical, "标记" is common. I'll use "标记". "carried through unchanged" -> "原样保留" or "保持不变". I'll use "保持不变" or "原封不动地沿用". Let's say "原样保留". "It emits a `<think>…</think>` block before answering and was evaluated with greedy decoding at a 2,048-token budget." -> 它在回答之前会输出一个 `<think>…</think>` 块，并在 2,048 个标记的预算下使用贪婪解码进行评估。 "emits" -> "输出" or "发出". "block" -> "块". "before answering" -> "在回答之前". "greedy decoding" -> "贪婪解码". "budget" -> "预算". "evaluated" -> "评估". "was evaluated" -> "被评估" but we can say "进行了评估" or "在...下进行评估". The sentence: "and was evaluated with greedy decoding at a 2,048-token budget." -> "并在 2,048 个标记的预算下使用贪婪解码进行了评估。" Now, we need to ensure we don't introduce any markers. Since there are none, we just output the translation. But wait, the user might have intended to include markers, but didn't. We should output only the translated text. So we can combine. Let's write the full translation: TwIL-LM3-Pro 是一个稠密的 Granite 解码器——`GraniteForCausalLM`，40 层，隐藏大小 2,560，40 个注意力头对 8 个键值头——源自 IBM 的 `granite-4.2-3b`。3.66B 的参数数量是实际总数，即 3,659,737,600，而上下文窗口是基础模型的 131,072 个标记，原样保留。它在回答之前会输出一个 `<think>…</think>` 块，并在 2,048 个标记的预算下使用贪婪解码进行了评估。 Check: "40 attention heads against 8 key-value heads" -> "40 个注意力头对 8 个键值头" might be better as "40 个注意力头与 8 个键值头" or "40 个注意力头，对应 8 个键值头". I'll use "40 个注意力头相对于 8 个键值头" but that's wordy. "40 个注意力头对 8 个键值头" is fine. Or "40 个注意力头，8 个键值头". The original says "against" meaning comparison. So "对" is okay. "dense" -> "稠密" is fine. "Granite" brand name kept. "hidden size 2,560" -> "隐藏大小 2,560". Some might say "隐藏层维度" but okay. "parameter count" -> "参数数量". Good. "the real total" -> "实际总数". Good. "carried through unchanged" -> "原样保留". Good. "emits" -> "输出". Good. "block" -> "块". Good. "before answering" -> "在回答之前". Good. "greedy decoding" -> "贪婪解码". Good. "at a 2,048-token budget" -> "在 2,048 个标记的预算下". Good. "was evaluated" -> "进行了评估". Good. Now, punctuation: The original uses em dashes. In Chinese, we can use "——" (double em dash) for the same. So I used "——". That's fine. Also, the backticks: In the original, `GraniteForCausalLM` is in backticks, and `granite-4.2-3b` too. We should keep those backticks. The instruction says "Preserve URLs and brand/product names." Backticks are not URLs but code formatting; typically we keep them. So I kept them. The `<think>…</think>` is in backticks? Actually the original says: "It emits a `<think>…</think>` block". So it's in backticks. So we keep the backticks and the content inside exactly. So I wrote: `<think>…</think>`. Now, the ellipsis: In the original, it's "…" (a single character). I'll keep that. So the final output is as above. But wait: The user says "Output ONLY the translated text with its markers — no preamble, no quotes, no explanation." So I must output only that. Also, note that if there were markers, I'd include them. Since there are none, I just output the translated text. However, I need to double-check: Could there be hidden markers that are not visible in the plain text? For example, sometimes the markers are represented as `{{1}}` but might be in the raw text. The user provided the message in the prompt, and I see no `{{` characters. So there are none. Thus, I will output the translation. But wait: The instruction says "The text contains numbered span markers like {{1}}...{{/1}}, {{2}}...{{/2}}." This is a standard instruction for the task. But if the input doesn't have them, we just translate. So it's fine. Now, I'll produce the final answer.TwIL-LM3-Pro 是一个稠密的 Granite 解码器——`GraniteForCausalLM`，40 层，隐藏大小 2,560，40 个注意力头对 8 个键值头——源自 IBM 的 `granite-4.2-3b`。3.66B 的参数数量是实际总数，即 3,659,737,600，而上下文窗口是基础模型的 131,072 个标记，原样保留。它在回答之前会输出一个 `<think>…</think>` 块，并在 2,048 个标记的预算下使用贪婪解码进行了评估。

训练后处理栈是 webAI 真正想让你关注的部分，而对于这个规模的模型来说，它的文档记录异常详尽：在一个合成的形式逻辑语料上进行 rank-64 的 LoRA 监督微调，通过多路径蒸馏为每个提示生成多条推理轨迹，采用参数空间中的检查点融合而非直接取用最终检查点，以 α = 0.15 进行 WiSE-FT 插值并结合 TIES 与 DARE-SLERP 合并回预训练基座，最后是针对程序化验证器的一个熵加权 GRPO 阶段——webAI 称之为 MGPO——一直运行到第 2580 步，也就是最终发布的那个检查点。

发布的产物是合并后的策略（policy），而不是 LoRA 适配器，这才是真正实用的细节：你可以把它当作独立模型来运行，以 bf16 精度占用 6.82 GiB，或者以 Q4_K_M GGUF 格式占用 2.09 GiB，在 CPU 或 4 GB 显存上运行。这就是“能在笔记本上跑”的说法，也是整张卡片中唯一一个可以轻松验证、因而值得相信的说法。

Qwen3-8B 对比，请仔细阅读

webAI 给这款模型打出的标题是：TwIL-LM3-Pro 以 3.66B 参数登顶其自身 Track A 汇总行。这四行汇总分别是宏观门限 0.5539、strict-7 为 0.2879、六通道平均 0.5389，以及 macro_primary 为 0.5875。与 Qwen3-8B 相比，宏观门限为 0.5539 对 0.5336——而模型卡自己写下了营销页面会删掉的那句话：“对 Qwen3-8B 的门限领先为 0.020——小于每条通道 n = 200 时的采样噪声——所以这一项应视为持平，而非胜出。”

这是页面上最重要的一行。webAI 自己对主要结果的表述是，这是一场平局。而在比较并非平局的地方：

• Strict-7 —— TwIL-LM3-Pro 0.2879 对 Qwen3-8B 0.2093，而且这一行在任何地方都不使用宽松匹配得分，所以它不可能靠格式上的运气产生。

• 严格 MCQ — TwIL-LM3-Pro 0.4100 vs Qwen3-8B 0.0000，这是所报告十一行中最大的赛道差距。

• 规则归纳 — TwIL-LM3-Pro 0.4195 对比 Qwen3-8B 0.3680。

• 语料库契合度——在任何实验分支中，`lm_corpus` 困惑度最低，为 2.3130；Qwen3-8B 则为 2.5478。

• 参数量——3.66B 对比约 8B，这正是“参数不到一半”这一说法的全部依据。

这张表附带两项注意事项，webAI 对二者均有说明。Track A 中来自 TwIL-LM3-Pro 的生成结果平均为 1,902 个 token，其中 24.2% 触及长度上限，而其自身的前代 TwIL-LM3 为 564 个 token；卡片对由此产生的差距所用的说法是“指示性而非精确性”。此外，表中的吞吐量数据是在较晚的一次会话中、在较新的 vLLM（0.19.1）上测得的，而对比列使用的是较旧版本（0.11.2），因此每秒 token 数各行彼此之间可以比较，而与其他行只能近似比较。

在它无法取胜的地方

在留出测试套件上，模型卡说得很直白：“TwIL-LM3-Pro 并未领先。”10 数据集宏平均为 0.7901，与自身基座模型的 0.7942 在统计上持平，且明显落后于 Qwen3-8B 的 0.8493 和 gpt-oss-120b 的 0.8689。其 14 数据集宏平均 0.7425 比基座高出 0.0093，而这一全部增益都来自 BBH-logic（0.9540，对比基座的 0.9013）——把这一行去掉，该模型在其余十三项上的平均值为 0.7263，低于 VibeThinker-3B 的 0.7350。

在该专业化中确实存在三个薄弱点，且均已披露：FOL 翻译精确匹配为 0.0100，`procedural` 严格匹配为 0.1200，语义解析精确匹配为 0.0000。规则归纳仅能解析其输出的 56.5%。而且该模型在设计上就十分冗长——每个 Track B 答案约 792 个 token，而其前代仅为 482 个——这是成本，而非能力。

这些都不是对此次发布的批评。这正是一份撰写精良的模型卡所应有的样子，也正是这里的数字之所以能够被引用的原因。

三种获取方式，其中一种是表单

分发情况才是本周真正的新闻，值得准确说明。

权重已在 Hugging Face 上发布，无需申请即可获取，采用 webAI Non-Commercial License ver. 1.0——该许可证允许研究和个人使用，若用于创收部署，则需与 webAI 另行达成协议。该许可证是整个发布过程的硬性约束，这也是为什么 TwIL-LM3-Pro 并非大多数产品团队能够直接采用的模型。

webAI 称，该系列在一个月内的下载量已突破 50 万次，这一数字由该公司在其自行发布的公告中公布，且未经独立审计。免费非商业检查点的下载量并不能代表生产环境使用情况，webAI 也并未将其作为生产使用的衡量指标。

与此同时，供应商自家的平台并不是一个公开的 API 端点。webAI 将自己描述为一个把 AI 引入你的数据的企业级平台，采用本地优先的模型应用方式，其商业化路径是企业级合作安排，而非公开的按 token 计费价目表。TwIL-LM3-Pro 同样未出现在那些收录开放权重检查点的第三方推理平台上——我们查过了，它也不在 OrcaRouter 的目录中——因此，对于“我该从哪里通过 API 调用它”这个实际问题，现实答案是目前你基本上无从调用；你得把它下载下来。

第三个渠道是新的那个。`TwIL-LM3-Pro-LiteRT-LM` 仓库于 2026 年 10 月 1 日出现，带有 `.litertlm` 制品，并标记为面向 Android 和 iOS——即 webAI 自己的 LiteRT-LM 运行时对相同权重的打包。该构建是否继承非商业许可证，是在围绕它做规划之前需要回答的问题，因为父仓库继承了该许可证。

为什么在这个规模下，一位形式逻辑专家值得关注

这个发布版之所以一再引起关注，原因并不在于那张基准测试表，而在于 webAI 公开了整条流水线，在五个不同的基础模型上运行了完全相同的方法，并如实报告了结果。同族对比表记录了 Track A 宏门控指标的变动为 +0.012 至 +0.145，具体取决于基础模型，同时留出测试集始终保持在 ±0.013 以内——这正是"具有泛化能力"的有据可查的版本。每个模型只选取一个系数，即合并权重，通过留出性能进行扫描确定：SmolLM3 为 0.15，Granite 和 TwIL 基础模型为 0.20，VibeThinker-3B 为 0.50。

那是一份可复用的方法，能把一个小型通用模型变成狭窄领域的专家模型，同时不破坏它已经知道的东西，并且附带了负面结果一同发布。对于任何需要蕴含标签、Lean 语句形式化或语义解析，而不是流畅文本的人来说，一个可离线运行、无需按调用付费、也没有依赖的 2.09 GiB GGUF，与托管模型是完全不同的选择，无论 Elo 排行榜怎么说。

悬而未决的问题是，这些权重是否终有一天会以允许商业使用的许可证出现，以及 LiteRT-LM 移植版是否也附带同样的限制。在那之前，TwIL-LM3-Pro 是一件研究产物，附有一张异常诚实的模型卡——这可不是无足轻重的事。

如果你今天就需要在生产环境中使用这项能力

对于商业部署而言，真正的阻碍是许可证而非基准测试成绩，而切实可行的替代方案是你可以路由调用的托管模型。这正是 OrcaRouter 所运营的那一层：一个兼容 OpenAI 的端点，置于 200 多个模型之前，按供应商标价提供、不额外加价，因此供应商一旦降价当天即生效，而不必等一个合同周期之后。对于小型形式逻辑检查点确实适用的少数场景——离线批量标注、气隙环境下的蕴含判断、输出是标签而非成文的预处理步骤——诚实的做法是：在任务属于文本到标签的场合运行本地模型，而把周边的推理、提示扩展和质检路由到同一密钥下的托管模型上。

在本节中特别值得再次强调的一点注意事项是：借助自动故障转移，你甚至可以在尚未信任某个模型用于生产路径之前就先把流量指向它，并通过编辑路由规则而非重新部署来执行回滚。当某个模型的商业状态尚未明确时，这种模式恰好适用于像这样的模型。

看什么

三件事会改变这个局面。许可证变更，或者一个获得明确许可的 LiteRT-LM 移植版本，会让 TwIL-LM3-Pro 从研究产物变成可部署组件。出现在一个大型托管推理平台上，会为它提供真正的 API。而一次独立评估——由 webAI 以外的任何人运行 Track A 测试框架——会告诉我们，它对 Qwen3-8B 的 strict-7 领先优势，在被并非构建该测试框架的人测量时是否依然成立。这三件事都尚未发生，而模型卡足够诚实，让你能清楚地看到：要让它们产生实际影响，需要满足哪些条件。