InCoder-32B-Thinking: 思考のための産業用コード世界モデル

概要

産業用ソフトウェア開発—チップ設計、GPUカーネル最適化、および組み込みシステムなど—は、長らく、エンジニアがハードウェアの制約やタイミングの意味をどのように考えているのかを示すような、専門的な推論の過程を明らかにするような情報が不足していました。具体的には、一般的なコーディングとは異なり、テストケースやリンターが迅速なフィードバックを提供するのに対し、産業用コードでは物理的な実行環境の理解が必要です。例えば、このTritonカーネルはGPUの共有メモリ制限を超えていませんか？このVerilogモジュールは、タイミング制約の下で正しく合成されますか？

InCoder-32B-Thinkingは、この課題を2つの相乗効果のある要素によって解決します。Error-driven Chain-of-Thought (ECoT) は、実行エラーから学習することで推論の過程を生成し、Industrial Code World Model (ICWM) は、実際の環境を使用せずにハードウェアの実行結果を予測します。これにより、高品質なトレーニングデータを大規模に生成することができます。その結果、320億パラメータのモデルが生まれ、一般的なコードと産業用コードの両方のベンチマークにおいて、トップレベルのオープンソース性能を達成しています。

81.3%LiveCodeBench V5

84.0%CAD-Coder コンパイル成功

38.0%KernelBench L2

96.7%ICWM予測精度

1. 導入

産業コードの格差.

大規模言語モデルは、ソフトウェア工学の分野において目覚ましい進歩を遂げており、関数作成、スクリプトのデバッグ、および競争プログラミングのベンチマークのクリアなど、様々なタスクをこなせるようになりました。しかし、実際の産業界で使用されるコードの領域においては、状況は大きく異なります。最先端のモデルであっても、Tritonカーネルの生成やVerilogの等価性チェックといったタスクにおいては、その汎用的な性能とは裏腹に、限定的な成果しか得られていません。

根本原因は、データ不足です。産業分野には、エンジニアがハードウェアの制約、タイミングの意味、および分野固有の実行フィードバックについてどのように考え、判断しているかを示す、専門的な推論の記録が不足しています。Verilogの修正は、単に構文の問題ではなく、RTLがゲートレベルのロジックとタイミングパスにどのように対応するかを理解する必要があります。Tritonカーネルの開発には、GPUのメモリ階層、warpスケジューリング、および数値精度について考慮する必要があります。

私たちの取り組み

InCoder-32B-Thinkingは、思考モデルの機能（慎重で、エラーを修正する、複数回の推論）と、産業用コードの世界モデルの知識（コードがハードウェアの動作に与える因果関係）を組み合わせたものです。このモデルは、ECoT合成フレームワークによって生成されたデータで学習され、ICWMによって検証されており、実行に基づいた推論の好循環を生み出しています。

主要な貢献

⚙️

ECoT 合成

Error-driven Chain-of-Thoughtは、実際の実行環境との複数回の対話を通じて、推論の過程を生成します。GPUコンパイラの誤り、RTLシミュレータ、およびCADエンジンのエラーが、学習信号となります。

🔬

産業コード世界モデル

ICWMは、コードからハードウェアへの動作に関する因果関係を、実行トレースから学習します。大規模なデータ生成時に、高価な実環境のバックエンドを置き換えることで、96.7%の予測精度を達成します。

🏆

最高レベルのパフォーマンス.

14種類の一般的なベンチマーク（81.3% LiveCodeBench V5）および9種類の産業用ベンチマーク（84.0% CAD-Coder, 38.0% KernelBench L2）において、最高レベルのオープンソースの結果を達成し、産業用タスクにおいてClaude-Sonnet-4.6およびKimi-K2.5を上回る性能を発揮。

Benchmark comparison bar chart — 図2：一般用途コードと産業用途コードの10種類のベンチマークにおける、InCoder-32B-Thinking の性能を、Claude-Sonnet-4.6、Kimi-K2.5、および Qwen3.5-397B-A17B と比較した結果。

2. ECoT Synthesis & Industrial Code World Model

このコアとなる手法は、2つの段階で構成されます。grounded collection：これは、実際の実行環境で検証された推論過程を生成する最先端のLLMを使用する段階です。ICWM-driven amplification：これは、訓練された世界モデルを使用して、高価なツールチェーンの実行を置き換えることで、データ生成を効率的に拡大する段階です。

ECoTとは？

従来のファインチューニングでは、モデルに正しい答えを教えます。ECoTは、推論プロセスを教えます。具体的には、間違いを犯したり、エラーフィードバックを読んだり、そして軌道修正を行うことを学習します。これは、熟練エンジニアが仕事をする方法を反映したものです。コードを書き、実行し、エラーを読み、なぜそうなるのかを理解し、修正し、繰り返します。

重要な点は、コンパイラやシミュレータからのエラーメッセージが、非常に豊富な学習信号であるということです。CUDAカーネルのメモリフォルトは、どのメモリアクセスパターンが間違っていたかを正確に教えてくれます。ECoTは、これらのドメイン固有のエラー信号を、教師データとして活用します。

ECoT data synthesis pipeline — 図4：ECoTデータ統合パイプライン。ドメインタスクは実行環境と共に開始され、推論過程は最先端のLLM（大規模言語モデル）によって抽出され、実際のバックエンド（GPUコンパイラ、RTLシミュレータ、CADエンジン）が各コードの修正を検証し、その結果得られる多段階の推論過程がICWM（Integrated Code-aware World Model）の学習に使用されます。

エラー駆動型連鎖思考（Error-driven Chain-of-Thought, ECoT）パイプライン

01

タスクの初期設定と環境のバンドリング

チップ設計、GPU最適化、3Dモデリング、および組み込みシステムに関するタスクが、それぞれ必要な実行環境と組み合わされています。具体的には、Verilogモジュールはテストベンチと合成制約と共に、CUDAカーネルはメモリプロファイルと共に、CadQueryスクリプトは幾何学的検証テストと共に提供されます。

02

実行に基づく軌道合成.

最先端のLLMは、推論過程と候補コードを生成します。このコードは、ドメイン固有の実際のバックエンドに送信されます。具体的には、GPUカーネルにはTriton/CUDA、マイクロコントローラーのファームウェアにはRenode、3D幾何形状にはCadQuery、RTLにはYosys/Icarusが使用されます。各バックエンドは、結果ラベル（PASS、COMPILATION_ERROR、MEMORY_FAULT）と診断ログを返します。エラーは次のターンでの観察となり、反復的な改善を促します。

03

多段階軌道形成.

成功と失敗の両方の試行を含む中間ステップが保持されており、これにより、トレーニングデータには、一般的な失敗パターンと、それらを解決するための推論ステップが共に含まれています。トラジェクトリ *T* = [( *S_init*, *r*⁽⁰⁾, *c*⁽⁰⁾) → (*r*⁽¹⁾, *c*⁽¹⁾) → ... → (*r*⁽ᵏ⁾, *c*⁽ᵏ⁾)] が、ECoT データセットの中核を構成します。

軌跡の式の理解

軌跡 T = [(S_init, r(0), c(0)) → (r(1), c(1)) → ... → (r(k), c(k))] は、会話のようなシーケンスを表しており、以下の要素で構成されます:S_init はタスクと環境、r(n) はターン n における推論の履歴、c(n) は候補コードです。各矢印は、1回の実行フィードバックラウンドを表します。コードが実行され、何らかの失敗が発生し、その失敗が次の入力となります。

重要な点として、失敗した中間ターンと成功した中間ターンは、どちらもトレーニングデータとして保持されます。これにより、モデルはエラーがプロセスの一部であること、つまり最小化すべきノイズではないことを学習します。

産業コード世界モデル (Industrial Code World Model, ICWM)

実際の実行バックエンドは、信頼性の高い監視を提供しますが、高価です。なぜなら、各インタラクションで、ドメイン固有のツールチェーンを呼び出す必要があるからです。データ生成をスケールアップするために、私たちはIndustrial Code World Model (ICWM)と呼ばれる言語モデルを訓練しました。これは、実行環境と候補コードが与えられた場合に、実際のバックエンドがどのような結果を返すかを予測するモデルです。

ICWM_e : (S_env, c^(k)) → ô^(k)

予測出力 ô⁽ᵏ⁾ には、結果ラベル（PASS、COMPILATION_ERROR など）、診断メッセージ、数値出力、または差分サマリーが含まれる場合があります。ICWM は、収集されたすべての実行トレースに基づいて学習されます。学習が完了すると、ICWM はフィードバックループ内の実際のバックエンドを置き換えます。各予測は、実際のコンパイルやシミュレーションではなく、単一の順伝播処理であるため、トレースの生成速度が 100 倍向上します。

⚡実際のバックエンド呼び出しよりも100倍高速—予測の各ステップで1回の順伝播処理のみを実行します。

✅すべてのICWMの軌跡は、実際の実行結果と照合して検証されています。最終的なデータセットDは、D_realとD_icwmの和集合です。

ICWMはなぜ存在するのか？

実際の産業用ツールチェーンを実行するには、費用がかかります。Verilog合成ツール（Yosys）を起動するだけでも数分かかります。GPUカーネルを実行し、メモリアクセスをプロファイリングするには、実際のハードウェアが必要です。数百万のトレーニング軌道が必要な場合、各ステップで実際のバックエンドを呼び出すことはできません。

ICWMは、実際のバックエンドがどのような結果を返すかを予測することでこの問題を解決します。これは、言語モデルとして、単にフォワードパスを実行するだけです。これは、AlphaZeroが、実際のボードで全ての局面をプレイするのではなく、ニューラルネットワークを使用してチェスの局面をシミュレートする方法に似ています。ICWMは、実際の実行結果を予測する際に、96.7%の精度を達成しています。

Pipeline concept illustration — 概念的な説明：ECoT合成パイプラインは、GPUチップ、RTL設計、組み込みシステムを、推論LLMを介して接続し、検証済みのトレーニングパスを生成します。

思考を動かす：CUDAカーネルの例

CUDAの例で何がうまくいかなかったのか？

タスク：予測値pの形状が(32768, 32768)（2次元行列）で、ターゲットtの形状が(32768,)（1次元ベクトル）である場合のHinge Lossを計算する。元のモデルでは、平坦な1次元インデックスpredictions[idx]を使用し、2次元行列をあたかも1次元であるかのように扱っていました。これにより、行の境界を越えて不正なメモリ読み込みが発生していました。

修正されたモデルの考え方：適切な2次元分解を持つグリッド・ストライドループを使用します。まず、batch_idx = i / input_sizeを計算して、どの行を処理するかを特定し、その後、targets[idx]ではなくtargets[batch_idx]をインデックスとして使用します。これにより、1次元のターゲットを2次元の予測行列のすべての列に正しくブロードキャストすることができます。

CUDA kernel comparison: InCoder-32B vs InCoder-32B-Thinking — 図3：CUDAヒンジ損失カーネルの実装。何も考えずに、InCoder-32Bは誤ったコードを生成します（形状の不一致：2次元の予測が1次元のインデックスで参照されている）。一方、ECoTによる学習を受けたInCoder-32B-Thinkingは、この不一致を体系的に特定し、ブロードキャストの意味を推測し、フラットなインデックスを行インデックスにマッピングし、正しいグリッド・ストライドのループコードを生成します。

3. 評価

私たちは、InCoder-32B-Thinkingを、汎用的なコーディングと、特定の産業分野の両方を網羅する包括的なテストスイートで評価し、Claude-Sonnet-4.6、Kimi-K2.5、Qwen3.5-397B-A17B、およびDeepSeek-V3といった、同時代のモデルと比較しました。

一般的なコードのベンチマーク

LiveCodeBench V5/V6
CruxEval (Input/Output COT)
Mercury (code efficiency)
Bird / Spider (Text2SQL)
Terminal-Bench v1/v2
SWE-bench Verified
Mind2Web, BFCL V3

産業分野のコード品質基準.

RealBench (Verilog module synthesis)
ArchXBench (RTL architecture)
CAD-Coder (chip CAD)
VeriScope / VeriRepair
EmbedICGen (embedded code)
SuperCoder Ace
TritonBench / KernelBench (GPU)

一般的なコードの結果

81.3%LiveCodeBench V5

83.5%LiveCodeBench V6

53.3CruxEval Input-COT

74.8%SWE-Verified

最も顕著な発見は、コード推論能力の向上です。InCoder-32B-Thinking は、LiveCodeBench V5 で 81.3 のスコアを獲得し、CruxEval Input-COT では 53.3 のスコアを獲得しました。これは、独自の最先端モデルと比較できる結果であり、思考拡張がコード実行のトレースにおける多段階推論を大幅に向上させることを示しています。

産業コードの結果

78.6%RealBench Syn@1

84.0%CAD-Coder

29.8%TritonBench G-call

38.0%KernelBench L2

工業分野のベンチマークにおいて、InCoder-32B-Thinkingは、競合モデルを常に上回る性能を発揮します。具体的には、CAD-Coder Compile Passでは84.0%（Claude-Sonnet-4.6では22.2%）、VeriScope Scoreでは82.0%、RealBench Module Syn@1では78.6%（Kimi-K2.5では50.1%）、そしてKernelBench L2では38.0%という結果を得ています。これらの結果は、ECoT + ICWMによる学習が、あらゆる産業分野のコーディング領域において効果的に知識を伝達できることを裏付けています。

チップ設計ベンチマーク結果

Model	Size	VeriScope Score	VeriRepair Fix%	Sys Syn@1	Sys Syn@5	Module Syn@1	Module Syn@5
Qwen3-Coder	3.6/21B	73.9	86.7	3.8	17.4	22.9	47.9
Qwen3.5	17/397B	62.5	86.7	11.2	38.1	35.2	59.5
Kimi-K2.5	32B/1T	82.4	76.7	6.2	26.2	50.1	70.1
Claude-Sonnet-4.6	—	83.2	90.0	2.5	11.2	22.2	43.4
InCoder-32B-Thinking	32B	82.0	53.5	35.2	91.0	82.0	—

GPU最適化ベンチマーク結果

TritonBench と KernelBench とは？

Triton は、OpenAI が開発した、高性能な GPU カーネルを作成するための Python ベースの GPU プログラミング言語です。TritonBench は、LLM（大規模言語モデル）が、(G-call) 実行可能なカーネルを生成できるか、および (G-exe) GPU ハードウェア上で正しく実行されるカーネルを生成できるかを測定します。

KernelBench は、モデルが PyTorch の演算子を、同等またはそれ以上の速度で動作するカスタム CUDA/Triton カーネルに置き換えることができるかを測定します（L1: 10% の高速化、L2: 50% の高速化、L3: PyTorch のベースラインと比較して 100% の高速化）。InCoder-32B-Thinking は、KernelBench L2 で 38.0% のスコアを獲得しており、これはそのカーネルが、PyTorch よりも 1.5 倍の高速化を 38% の場合に達成できることを意味します。

Model	Size	TritonBench G-call%	TritonBench G-exe%	KernelBench L1	KernelBench L2
Qwen3.5	17/397B	7.6	100.0	4.0	10.0
Kimi-K2.5	32B/1T	17.4	100.0	9.1	16.0
Claude-Sonnet-4.6	—	1.6	100.0	16.2	23.0
InCoder-32B-Thinking	32B	18.5	100.0	22.2	38.0

InCoder-32B-Thinking overview: Reflective Depth Reasoning and Domain Reasoning — 図1：InCoder-32B-Thinkingの機能概要。左：反射的深層推論 — マルチターンでのGPUカーネルデバッグを通じた反復的なエラー修正 (FAIL → think → PASS)。右：ドメイン推論 — 産業用コードタスクのためのハードウェアに配慮した推論連鎖。中央：このモデルは、汎用コードと産業用コードの両方の知性を結びつけます。

4. 分析

4.1 ICWMの信頼性分析

パイプラインの中核的な仮定は、ICWMが大規模な軌跡合成において、実際の実行バックエンドを忠実に再現できるという点です。この仮定を検証するために、各産業分野から2,000件の実行データを抽出し、ICWMの予測が実際のバックエンドの結果とどの程度一致するかを評価します。評価は、各実行の個別結果ラベルと、全体的な軌跡の判定の両方で行います。

ICWMの信頼性指標とは？

結果予測精度 (96.7%): テストデータセットにおける実行回において、ICWMは各ステップの結果ラベル（PASS / COMPILATION_ERROR / MEMORY_FAULT）を96.7%の精度で正しく予測します。これは、単一ステップの精度を測定しています。

軌跡の一致率 (94.4%): 複数のステップからなる実行全体の軌跡が、実際の実行結果と同一の最終的な判定で終わる割合。単一ステップの精度よりも常に低く、これはエラーが複数のステップにわたって累積する可能性があるためです。

ICWM fidelity across industrial domains — 図5：5つの産業分野におけるICWMの精度。紫色のバーは、各ステップでの結果予測の精度を示しています。オレンジ色のバーは、エンドツーエンドでの軌跡が実際の実行とどれだけ一致するかを示しています。すべての分野で、両方の指標において93%を超える精度を示しています。

GPU Kernels96.8% / 94.3%

Chip Design97.4% / 95.8%

3D Modeling95.9% / 93.1%

Code Optim.97.1% / 95.2%

Embedded Sys.96.2% / 93.7%

Mean96.7% / 94.4%

予測精度 / トラジェクトリの一致度. チップ設計は最も高い精度を達成 (97.4%/95.8%); 3Dモデリングは、CadQueryの幾何学的検証における浮動小数点数の許容範囲の複雑さにより、最も大きな誤差が生じる。

4.2 適応的思考の深さ

InCoder-32B-Thinking の重要な特徴の一つは、タスクの複雑さに応じて、推論に必要な計算リソースを調整することです。学習データセットの分析から、タスクカテゴリ間で推論トークンの長さが最大で 209 倍も異なることが明らかになりました。これは、固定されたプロンプトテンプレートではなく、実際の実行からのフィードバックによって引き起こされています。

Thinking depth distribution by task category — 図6：タスクカテゴリごとの思考の停滞期間の分布（中央値と四分位範囲 P25–P75）、思考の深さでソート。産業分野（強調表示）は、常に一般的なコーディングタスクよりも、より深い推論を必要とします。

19K chars GPU最適化 — 中央値の推論時間。修正ごとに、複数のハードウェア制約分析が必要となります。

209× タスクの種類ごとの思考の深さの範囲：エージェントによるコーディング（最も短い）から、GPU最適化（最も長い）まで。

91 chars エージェント的コーディング：最短の思考連鎖。これは、ツール使用タスクの明確なステートマシンの構造を反映しています。

なぜGPU最適化には19K文字の思考プロセスが必要なのか？

GPUカーネルの最適化には、複数の相互作用するハードウェアの制約を同時に考慮する必要があります。具体的には、L1キャッシュの制限（SMあたり32KB）、warpのスケジューリング（warp内の32スレッドが同時に実行される）、メモリアクセスのコヒーレンス（128バイトのキャッシュライン）、共有メモリバンクの競合、レジスタの使用量とスレッドブロックサイズのトレードオフなどです。それぞれの修正には、これらの制約をすべて再評価する必要があります。19K文字という数値は、冗長性ではなく、真に多段階のハードウェアに関する思考プロセスを反映しています。

これに対して、エージェント的なコーディングタスク（ツール利用、ファイル操作など）は、明確なステートマシンを持っています。観察、判断、実行という流れで、答えへの道筋は短く、明確に定義されています。

4.3 思考トレーニングデータの影響.

トレーニングデータの規模が性能にどのように影響するかを理解するために、私たちは180M、360M、および540Mトークンの思考データを使用してモデルのチェックポイントをトレーニングしました。 9つの産業用ベンチマークにおいて、データ規模が大きくなるにつれて一貫した性能向上が観察されました。特に、TritonBenchのGPU実行精度は、すべての段階で100%を維持しており、これは一部の機能が早期に現れ、安定していることを示しています。思考メカニズムは、常にベースとなるInCoder-32Bモデルを超える価値を提供します。

Performance vs thinking training data scale — 図7：思考のための学習データサイズが180Mトークンから540Mトークンに増加するにつれて、9つの産業ベンチマークにおけるパフォーマンスの変化を示しています。多くの指標は単調に向上しますが、TritonBenchのGPU実行における正確性は、すべての段階で100%に到達し、その後は変化しません。

5. 結論

InCoder-32B-Thinking は、実行に基づいた思考データを用いることで、一般的なコードインテリジェンスと産業用ソフトウェア開発の間のギャップを埋めることができることを示しています。 Error-driven Chain-of-Thought synthesis と Industrial Code World Model を組み合わせることで、このフレームワークは、産業用コードタスクに必要な実際の思考の深さを捉えたトレーニングデータを生成します。

ECoT synthesis は、多段階の実行エラーから学習することで、高品質な推論過程を生成します。これには、人間のアノテーションは必要ありません。
ICWM は、96.7%という高い精度で結果を予測し、高価なリアルタイム処理を必要としない、スケーラブルな軌道生成を可能にします。
適応的思考の深さ (209倍の範囲) は、実際のタスクの複雑さを反映しています。GPUの最適化には、19,000文字の推論が必要ですが、エージェントによるコーディングでは91文字で済む場合があります。
最上位の成果を、14の一般的なベンチマークと9つの産業用ベンチマークで達成し、一貫してClaude-Sonnet-4.6、Kimi-K2.5、およびQwen3.5-397B-A17Bを産業用タスクにおいて上回っています。

arXiv での論文を読む ↗ HuggingFace Model ↗ GitHub Repository ↗

産業コードインテリジェンス

これまでの研究では、個々の産業分野のサブドメインが個別に扱われてきました。具体的には、Verilogの生成と修正（RTLCoder, VeriGen）、GPUカーネルの最適化（KernelBench, TritonBench）、組み込みシステムのコーディング、および3Dモデリングコードなどが挙げられます。InCoder-32Bは、これらのサブドメイン間の統合に向けた一歩ですが、推論能力は備わっていません。InCoder-32B-Thinkingは、この基盤を拡張し、実行に基づいた推論データを取り込んでいます。

大規模言語モデルにおける思考.

OpenAIのo1は、強化学習（RL）によって学習された複雑な思考の連鎖が、複雑な推論を大幅に向上させることを示しました。DeepSeek-R1や関連研究は、構造化された思考が、GRPOベースの学習から生まれる可能性があることを示しました。コードに特化した推論においては、o1-CoderやrStar-Coderが、思考技法をプログラミングタスクに適用しました。InCoder-32B-Thinkingは、これらのアプローチを、実行環境が客観的なフィードバック信号を提供する、産業分野に特化して拡張したものです。

参照文献（一部）

Agarwal et al. GPT-OSS-120B model card. arXiv, 2026.
Ahmad et al. OpenCoderReasoning. 2025.
Anthropic. Introducing claude sonnet 4.6, 2026.
Chen et al. Codex. arXiv, 2021.
DeepSeek-AI. DeepSeek-V3.2. 2026.
Yang et al. InCoder-32B. 2025.
Zheng et al. CodeGeeX. 2023.
... (full reference list in arXiv paper)