TwIL-LM3-Pro：メールでのリクエストにより提供される3.66Bの形式論理モデル

TwIL-LM3-ProはwebAIによる36億6000万パラメータの推論モデルで、一般的な会話向けではなく形式論理のために特化して作られており、2026年9月3日からHugging Faceで公開されている。これは新リリースではなく、今週それを取り巻いて広がっている「webAIが『3.66Bモデルをリリースした』」という言い回しは、重みの公開から1か月遅れている。ここ数日で実際に変わったことは、より小さく、より有用だ。チェックポイントは9月30日に改訂され、10月1日にはwebAIがオンデバイスのAndroidおよびiOS推論向けに、このモデルのLiteRT-LMビルドを公開した。したがって、興味深い問いはTwIL-LM3-Proが何かではなく、それを入手できるかどうかであり、その答えは3つある配布チャネルのどれにあなたが立っているかによって変わる。なぜなら、そのうちの1つはフォームだからだ。

その区別は通常以上に重要だ。なぜなら、TwIL-LM3-Pro は単に呼び出せる製品ではないからだ。それは自分でダウンロードし、自分のハードウェア上で実行し、商用利用を禁じるライセンス条項に同意するチェックポイントである。自らのモデルカードが促す比較——パラメータ数が2倍を超える Qwen3-8B との比較——は本物だが、それはベンダーが実行したベンチマークをベンダーが構築したハーネス上で行った比較であり、モデルカード自身が、ほとんどのモデルカードよりも多くの箇所でそう述べている。本稿はそのカードを注意深く読み、webAI が測定したものと、他の誰かが持っているものとを切り分ける。

モデルが実際には何なのか

` block before answering and was evaluated with greedy decoding at a 2,048-token budget." No {{}} markers. Need output only translated text. Preserve URLs and brand/product names. Backticks code names should remain. Translate text. Ensure technical terms. Let's produce Japanese. Need be careful: "dense Granite decoder" => 密なGraniteデコーダ? "dense" in model architecture: デンス? "dense Granite decoder" maybe "密なGraniteデコーダー" or "denseなGraniteデコーダー". Better "高密度な" maybe not. In ML, dense = 密結合? For transformer decoder, "dense decoder" means non-MoE, so "密な" maybe "dense（密）". Japanese often "密なGraniteデコーダ". Could write "denseなGraniteデコーダ". Let's use "密なGraniteデコーダ". But "dense" as model type often "denseモデル" kept. Maybe "denseなGraniteデコーダ". Let's choose "密なGraniteデコーダ" maybe okay. "40 attention heads against 8 key-value heads" => 8個のキーバリューヘッドに対して40個のアテンションヘッド? That implies grouped query attention. Translate: "キーバリューヘッドが8つに対してアテンションヘッドは40". Better "8つのキー・バリューヘッドに対して40のアテンションヘッド". "hidden size 2,560" => 隠れ層サイズ2,560. "40 layers" => 40層. "derived from IBM's `granite-4.2-3b`" => IBMの`granite-4.2-3b`から派生. "The 3.66B parameter count is the real total, 3,659,737,600" => 3.66Bのパラメータ数は実際の合計で3,659,737,600です。 "3.66B" maybe "3.66Bパラメータ数". Keep numbers. "and the context window is the base model's 131,072 tokens carried through unchanged." => コンテキストウィンドウはベースモデルの131,072トークンがそのまま引き継がれています。 "It emits a `<think>…</think>` block before answering" => 回答前に`<think>…</think>`ブロックを出力し、... Note `<think>…</think>` includes backticks and tags. In Japanese, backticks maybe keep. "It emits" subject TwIL-LM3-Pro. "評価は2,048トークンの予算で貪欲法（greedy decoding）を用いて行われました" or "greedy decodingで". Preserve technical term maybe "greedy decoding". "at a 2,048-token budget" => 2,048トークンの予算で. "greedy decoding" maybe "貪欲法によるデコーディング". Let's include both? "greedy decoding（貪欲法）". But text says "was evaluated with greedy decoding at a 2,048-token budget." => "2,048トークンのバジェットでgreedy decodingにより評価されました". Good. Need output only translated text. No markers to worry. Ensure byte-for-byte markers if any? None. Do not add. Let's formulate polished Japanese. Potential translation: TwIL-LM3-Proは密なGraniteデコーダ — `GraniteForCausalLM`、40層、隠れサイズ2,560、8個のキーバリューヘッドに対して40個のアテンションヘッド — で、IBMの`granite-4.2-3b`から派生しています。3.66Bというパラメータ数は実際の合計で3,659,737,600であり、コンテキストウィンドウはベースモデルの131,072トークンが変更なしに引き継がれています。回答前に`<think>…</think>`ブロックを出力し、2,048トークンのバジェットでgreedy decodingを用いて評価されました。 This is good. "dense Granite decoder" as "密なGraniteデコーダ". "against 8 key-value heads" maybe "8個のキーバリューヘッドに対して40個のアテンションヘッド" okay. Need preserve `GraniteForCausalLM` etc. Good. Should we translate "greedy decoding" to "貪欲法によるデコーディング"? The instruction preserve brand/product names. Technical term can remain. Maybe Japanese target should translate, but technical terms often. Could write "greedy decoding（貪欲デコーディング）". However output only. Let's decide: "greedy decoding" is a method; professional localization often leaves it or translates. To be safe, "greedy decoding" maybe acceptable but "greedy decodingによる評価" okay. Could include parenthetical. But no need. "real total" => "実際の総数". "the real total, 3,659,737,600" => "実際の総数である3,659,737,600". Good. "carried through unchanged" => "そのまま引き継がれています". "emits ... before answering" => "回答する前に...を出力します". Use です/ます consistent. First sentence ends 派生しています, second です/ます, third 出力し、評価されました. Good. Potential issue "dense" maybe "密な" is odd; "dense（密）な". I can write "高密度な" not correct. In ML Japanese, "dense decoder" maybe "デンスなデコーダ" or "密なデコーダ". Let's write "denseなGraniteデコーダ" to avoid weird. Since "dense" is English term. But translation should be Japanese. Maybe "密な" okay. The phrase "dense Granite decoder" is likely from model card; Japanese translation "密なGraniteデコーダ" works. Keep. Need no markers. Output only. final. TwIL-LM3-Proは密なGraniteデコーダ — `GraniteForCausalLM`、40層、隠れサイズ2,560、8個のキーバリューヘッドに対して40個のアテンションヘッド — で、IBMの`granite-4.2-3b`から派生しています。3.66Bというパラメータ数は実際の合計で3,659,737,600であり、コンテキストウィンドウはベースモデルの131,072トークンが変更なしに引き継がれています。回答前に`<think>…</think>`ブロックを出力し、2,048トークンのバジェットでgreedy decodingを用いて評価されました。

ポストトレーニング・スタックは、webAIが実際に目を向けてほしい部分であり、この規模のモデルにしては異例なほど詳細に文書化されている。合成形式論理コーパスに対するrank-64 LoRAの教師ありファインチューニング、プロンプトごとに複数の推論トレースを生成するマルチパス蒸留、最終チェックポイントを採用するのではなくパラメータ空間でのチェックポイント融合、α = 0.15でのWiSE-FT補間をTIESとDARE-SLERPを用いて事前学習済みベースへ向けてマージし直し、最後に、プログラム検証器に対するエントロピー重み付きGRPO段階——webAIはこれをMGPOと呼ぶ——をステップ2580まで実行し、これが出荷されたチェックポイントである。

公開されている成果物はLoRAアダプタではなくマージ済みポリシーであり、これが実用的なポイントだ。スタンドアロンモデルとして、bf16で6.82 GiB、またはQ4_K_M GGUFで2.09 GiBなら、CPU上または4 GBのVRAMで実行できる。これが「ノートPCで動く」という主張であり、カード全体の中で自明に検証可能な唯一の主張であり、したがって信頼する価値がある。

Qwen3-8Bの比較、よくお読みください。

webAIがこのモデルに付けた見出しは、TwIL-LM3-Proが3.66Bパラメータで自身のTrack A要約行のトップに到達するというものだ。4つの要約行は、マクロゲートが0.5539、strict-7が0.2879、6レーン平均が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 対 Qwen3-8B 0.0000、報告された11行の中で最大のレーン間ギャップ。

• ルール帰納 — TwIL-LM3-Pro 0.4195 対 Qwen3-8B 0.3680。

• コーパス適合性 — 全アーム中で最低の `lm_corpus` パープレキシティが 2.3130 で、Qwen3-8B は 2.5478。

• パラメータ — 3.66B 対 およそ 8B、これが「パラメータ数が半分以下」という主張の根拠すべてである。

その表には2つの注意点が伴い、webAIはその両方を明言している。トラックAのTwIL-LM3-Proによる生成は平均1,902トークンで、その24.2%が長さ上限に達した。一方、自身の前身であるTwIL-LM3では564トークンだった。その結果生じた差についてカードが用いる表現は「正確というより示唆的」だ。また、表のスループット数値は、比較列（0.11.2）よりも新しいvLLM（0.19.1）を使った後続のセッションで測定された。そのため、トークン毎秒の行は互いに比較できるが、残りとはおおよそしか比較できない。

それが勝たない場所

ホールドアウトスイートでは、モデルカードは率直だ。「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.9013に対して0.9540）によるもので、その1行を取り除くと、モデルは残り13データセットで平均0.7263となり、VibeThinker-3Bの0.7350を下回る。

特化の中には、すべて開示済みの真に弱い箇所が3つある。FOL翻訳の完全一致が0.0100、`procedural` が厳密評価で0.1200、意味解析の完全一致が0.0000だ。ルール帰納は、その出力の56.5%しかパースしない。そして、このモデルは構造上冗長である——Track Bの回答1件あたり約792トークンで、前身は482トークン——これは能力ではなくコストである。

これはリリースに対する批判ではまったくない。よく書かれたモデルカードとはこういうものであり、だからこそここにある数字は引用できるのだ。

入手する3つの方法、そのうち1つはフォームです

流通状況こそが今週の本当のニュースであり、それを正確に述べる価値がある。

重みは Hugging Face 上にあり、ゲートなしで、webAI Non-Commercial License ver. 1.0 の下で公開されています。このライセンスは研究用途および個人利用を許可し、収益を生む展開には webAI との別個の契約を必要とします。このライセンスはリリース全体を拘束する制約であり、TwIL-LM3-Pro がほとんどのプロダクトチームにとって単純に採用できるモデルではない理由でもあります。

webAIは、このファミリーが1か月で50万ダウンロードを超えたと述べている。これは同社が自社の発表で公表した数字であり、独立した監査は受けていない。無料の非商用チェックポイントのダウンロード数は、本番利用の代理指標にはならず、webAIもそのようには提示していない。

一方、ベンダー自身のプラットフォームは公開エンドポイントではありません。webAI は自社を、AI をあなたのデータに届けるエンタープライズプラットフォームであり、ローカルファーストのモデルアプリケーションを備えていると説明しており、その商用ルートは、公開されたトークン単位の料金表ではなくエンタープライズ向けの契約形態です。TwIL-LM3-Pro は、オープンなチェックポイントを索引化している大手サードパーティ推論プラットフォームにも存在しません — 私たちが確認したところ、OrcaRouter のカタログにも入っていません — したがって「これを API からどこで呼べばいいのか」という問いに対する実用的な答えは、現時点ではほとんどどこからも呼べない、ということです。あなたはそれをダウンロードするのです。

第3のチャネルは新しいものです。`TwIL-LM3-Pro-LiteRT-LM` リポジトリは2026年10月1日に登場し、`.litertlm` アーティファクトを伴い、Android および iOS 向けにタグ付けされています — 同じ重みを webAI 自身の LiteRT-LM ランタイムでパッケージ化したものです。そのビルドが非商用ライセンスを継承するかどうかが、それを前提に計画を立てる前に答えるべき問いです。なぜなら親リポジトリは継承しているからです。

この規模で形式論理の専門家が注目に値する理由

このリリースが繰り返し話題になる理由は、ベンチマーク表ではない。webAI がパイプライン全体を公開し、同一のレシピを5つの異なるベースモデルで実行し、何が起きたかを報告したことにある。ファミリー比較表には、ベースに応じて 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の担うレイヤーです。プロバイダーの定価のまま、一切の上乗せなしで200以上のモデルを前に置く、OpenAI互換の単一エンドポイント。したがって、ベンダーの値下げは契約サイクルを待つのではなくその日のうちに反映されます。小規模な形式論理チェックポイントが本当に適する数少ない場面——オフラインのバッチラベリング、エアギャップ環境での含意判定パス、出力が散文ではなくラベルである前処理ステップ——において、正直な切り分けはこうです。ワークロードがテキストからラベルへの変換である箇所ではローカルモデルを動かし、その周辺の推論、プロンプト展開、QAは同じキーでホスト型モデルにルーティングするのです。

このセクションで特に繰り返す価値のある注意点が1つあります：自動フェイルオーバーがあれば、本番経路で信頼する前にモデルを指定することもできますし、再デプロイするのではなくルーティングルールを編集してロールバックできます。商用ステータスが未解決のとき、これがこのようなモデルに適したパターンです。

何を見るべきか

この話を変えるものは3つある。ライセンスの変更、あるいは明確にライセンスされたLiteRT-LM移植版があれば、TwIL-LM3-Proは研究用の成果物から展開可能なコンポーネントへと移行するだろう。主要なホステッド推論プラットフォームに登場すれば、本物のAPIが与えられる。そして、独立した評価――webAI以外の誰かがTrack Aハーネスを実行すること――は、Qwen3-8Bに対するstrict-7の優位が、ハーネスを構築していない人物によって測定されてもなお残るかどうかを教えてくれるだろう。この3つのうちどれもまだ実現しておらず、モデルカードは十分に正直なので、それらが意味を持つために何が成り立つ必要があるのかを正確に見て取れる。