---
arxiv_id: 2604.03144
title: "InCoder-32B-Thinking: 思考のための産業用コード世界モデル"
authors:
  - Jian Yang
  - Wei Zhang
  - Jiajun Wu
  - Junhang Cheng
  - Tuney Zheng
difficulty: 
tags:
  []
published_at: 2026-04-07
flecto_url: https://flecto.zer0ai.dev/ja/papers/2604.03144/
lang: ja
---

## Page Title

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

## Meta Description

InCoder-32B-Thinkingは、Error-driven Chain-of-Thought合成とIndustrial Code World Modelを使用することで、14の一般的なベンチマークと9つの産業用コードベンチマークにおいて、最高レベルのパフォーマンスを達成しています。

## Hero, Element=H1

### InCoder-32B-Thinking

## Hero, Element=Subtitle

### 思考のための産業コード世界モデル.

## Hero, Element=Authors

### Jian Yang、Wei Zhang、Jiajun Wuら — Beihang University、IQuest Research、Shanghai Jiao Tong University

## Hero, Element=Arxiv Btn

### arXivで読む↗

## Abstract, Element=P1

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

## Abstract, Element=P2

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

## Abstract, Metric Label

### LiveCodeBench V5

### CAD-Coder コンパイル成功

### KernelBench L2

### ICWM予測精度

## Introduction, Element=H2

### 1. 導入

## Introduction, Element=Problem H3

### 産業コードの格差.

## Introduction, Element=Problem P1

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

## Introduction, Element=Problem P2

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

## Introduction, Element=Solution H3

### 私たちの取り組み

## Introduction, Element=Solution P

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

## Introduction, Element=Contributions H3

### 主要な貢献

## Introduction, Feature Card=Ecot Title

### ECoT 合成

## Introduction, Feature Card=Ecot Desc

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

## Introduction, Feature Card=Icwm Title

### 産業コード世界モデル

## Introduction, Feature Card=Icwm Desc

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

## Introduction, Feature Card=Results Title

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

## Introduction, Feature Card=Results Desc

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

## Introduction, Element=Fig2 Caption

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

## Methodology, Element=H2

### 2. ECoT Synthesis & Industrial Code World Model

## Methodology, Element=Intro P

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

## Methodology, Element=Fig4 Caption

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

## Methodology, Element=Steps H3

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

## Methodology, Step1 Title

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

## Methodology, Step1 Desc

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

## Methodology, Step2 Title

### 実行に基づく軌道合成.

## Methodology, Step2 Desc

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

## Methodology, Step3 Title

### 多段階軌道形成.

## Methodology, Step3 Desc

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

## Methodology, Element=Icwm H3

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

## Methodology, Element=Icwm P1

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

## Methodology, Element=Icwm P2

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

## Methodology, Benefit1

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

## Methodology, Benefit2

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

## Methodology, Element=Pipeline Illust Caption

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

## Methodology, Element=Cuda H3

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

## Methodology, Element=Cuda Caption

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

## Evaluation, Element=H2

### 3. 評価

## Evaluation, Element=Intro P

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

## Evaluation, Element=General H3

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

## Evaluation, Element=Industrial H3

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

## Evaluation, Element=General Results H3

### 一般的なコードの結果

## Evaluation, Element=General Results P

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

## Evaluation, Element=Industrial Results H3

### 産業コードの結果

## Evaluation, Element=Industrial Results P

工業分野のベンチマークにおいて、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による学習が、あらゆる産業分野のコーディング領域において効果的に知識を伝達できることを裏付けています。

## Evaluation, Element=Chip Table H4

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

## Evaluation, Element=Gpu Table H4

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

## Evaluation, Element=Overview Fig Caption

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

## Analysis, Element=H2

### 4. 分析

## Analysis, Element=Fidelity H3

### 4.1 ICWMの信頼性分析

## Analysis, Element=Fidelity P

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

## Analysis, Element=Fidelity Fig Caption

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

## Analysis, Element=Fidelity Label

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

## Analysis, Element=Thinking H3

### 4.2 適応的思考の深さ

## Analysis, Element=Thinking P

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

## Analysis, Element=Thinking Fig Caption

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

## Analysis, Thinking Insight1

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

## Analysis, Thinking Insight2

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

## Analysis, Thinking Insight3

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

## Analysis, Element=Scaling H3

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

## Analysis, Element=Scaling P

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

## Analysis, Element=Scaling Fig Caption

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

## Conclusion, Element=H2

### 5. 結論

## Conclusion, Element=P

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

## Conclusion, List Item1

### ECoT synthesis は、多段階の実行エラーから学習することで、高品質な推論過程を生成します。これには、人間のアノテーションは必要ありません。

## Conclusion, List Item2

### ICWM は、96.7%という高い精度で結果を予測し、高価なリアルタイム処理を必要としない、スケーラブルな軌道生成を可能にします。

## Conclusion, List Item3

適応的思考の深さ (209倍の範囲) は、実際のタスクの複雑さを反映しています。GPUの最適化には、19,000文字の推論が必要ですが、エージェントによるコーディングでは91文字で済む場合があります。

## Conclusion, List Item4

最上位の成果 を、14の一般的なベンチマークと9つの産業用ベンチマークで達成し、一貫してClaude-Sonnet-4.6、Kimi-K2.5、およびQwen3.5-397B-A17Bを産業用タスクにおいて上回っています。

## Conclusion, Resource Link

### arXiv での論文を読む ↗

## Related Work, Element=Summary

### 関連研究

## Related Work, Element=Industrial H4

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

## Related Work, Element=Industrial P

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

## Related Work, Element=Thinking H4

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

## Related Work, Element=Thinking P

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

## References, Element=Summary

### 参照文献（一部）

## Footer, Element=P

### InCoder-32B-Thinking · Beihang University, IQuest Research · arXiv:2604.03144 · Flectoを通じて発表.
