汎用コード大規模言語モデルは Verilog を書くとポートエラーを報告し、CUDA カーネルを調整するとハードウェアの上限を簡単に超えてしまう。
それは能力不足なのではなく、産業用コードの流儀を根本的に理解していないからだ。
北京航空航天大学（北航）が複数の機関と共同で発表したInCoder-32Bは、実機シミュレーション環境において 250 万件の実行検証済みの産業用コードデータを生成。チップ設計、GPU カーネル最適化、組込みシステム、コンパイラ最適化、3D モデリングという 5 大産業分野を網羅している。
現在、本論文は Hugging Face Daily Paper においてアップボート数が 300 に迫り、オープンソースコミュニティから熱い注目を集めている。モデルのフルバージョンおよび量子化バージョンの重みはすべて公開済みだ。
汎用コード大規模モデルではなぜ産業用コードを扱いきれないのか？
近年、コード大規模モデルは汎用プログラミングタスクにおいて顕著な進捗を遂げている。Claude などを代表とするモデルは SWE-bench などのベンチマークで記録を塗り替え続け、アルゴリズム問題の解決、Web 開発、GitHub イシューの自動修正などのシナリオにおいて実用的な価値を発揮している。
しかし、汎用プログラミングと産業用プログラミングの間には本質的な差異が存在する。チップ RTL 設計（Verilog/SystemVerilog）、GPU カーネル開発（CUDA/Triton）、組込みファームウェア作成（C/ARM）、コンパイラレベルのアセンブリ最適化（x86-64）、パラメトリック 3D モデリング（CadQuery）などを含む産業用コードは、特殊な言語構造やドメイン固有の API に関わるだけでなく、モデルに対してハードウェアのセマンティクス、リソース制約、物理的な振る舞いに関する正確な理解を要求する。
GPU カーネル最適化を例に取ると、論文では CUDA RMS Normalization の事例が示されている。
その根本的な理由は、産業用コードと汎用コードには本質的な違いがあるからだ。産業用コードでは、モデルがハードウェアのセマンティクスを理解し、特殊な言語構造を掌握し、リソース制約を厳密に遵守することが求められる。
InCoder-32B：産業用コード向けコード基盤モデル
Claude は CUDA グリッドを設定する際、spatial_size（262144）を直接 gridDim.y に代入した。しかし、CUDA ハードウェアの規定では gridDim.y の上限は 65535 であり、この代入は実行時に無効な引数エラーを引き起こす。これはアルゴリズム論理の誤りではなく、モデルが GPU ハードウェアの制約を認識できていないことに起因する。InCoder-32B のアプローチは、すべての空間次元を 1 次元に平坦化し、gridDim.x を介してスケジューリングを行うことで、ハードウェアの制限を回避するものだ。
論文の統計データはこの格差をさらに裏付けている。現在の最適モデルであっても、Triton 演算子生成タスクにおける関数呼び出しの成功率は 28.80% に留まり、Verilog コードの形式的等価性検証における正解率は 33.3% に過ぎない。これらのデータは、既存のコード大規模モデルが訓練データから評価体系まで汎用プログラミング言語を中心に構築されており、産業用コード分野のカバレッジが著しく不足していることを示している。
InCoder-32B は、産業用コードインテリジェンスに特化した初のコード基盤モデルであり、320 億パラメータの Decoder-only Transformer アーキテクチャを採用。単一のモデルで複数の産業用コード分野を統一的にサービスすることを目指している。
Verilog に特化した RTLC や CUDA に特化した Kevin など、これ以前の仕事が単一の産業用サブドメインに焦点を当てていたのとは対照的に、InCoder-32B はチップ設計、GPU カーネル最適化、組込みシステム、コンパイラ最適化、3D モデリングを統一された訓練フレームワークに取り込んでいる。モデルは産業用コード能力を網羅しつつ、汎用コードタスクにおける競争力も維持し、産業用と汎用の両立を実現している。
中核手法：実機シミュレーション環境における産業用コードデータの大規模生産
産業用コードの正当性検証は、汎用コードとは本質的に異なる。Python 関数はユニットテストで迅速に判定可能だが、Verilog モジュールは RTL シミュレーションと論理総合を経て、初めて実シリコン上での実行可能性が確認される。CUDA/Triton カーネルは実 GPU 上での実行により、数値の正当性と性能が基準を満たしているか検証する必要がある。組込みファームウェアは対象のマイクロコントローラまたはそのエミュレータ上でブート実行し、レジスタ設定や割り込み動作の正当性を確認しなければならない。CAD スクリプトもまた、生成された 3D 实体が幾何学的に設計仕様へ忠実かどうかを検証する必要がある。
したがって、論文の重要な洞察は「産業用コードの正当性は、実際のデプロイ環境での実行を通じてのみ検証可能である」という点だ。これは、高品質な産業用コード訓練データを生産的に規模拡大するには、本番グレードの実行・検証インフラ全体を構築することが前提条件となることを意味する。
このためチームは 4 大クラスの産業用シミュレーション環境を再構築した。その中核原則は、簡略化された代替案を構築するのではなく、産業エンジニアが実際に使用するツールチェーンと実行セマンティクスを忠実に再現することであった。
チップ設計環境：半導体業界のデジタル設計は、RTL 記述、動作シミュレーション、論理総合、物理実装という厳格なプロセスに従う。チームは公開 EDA ツールを用いて前半の 3 段階を再構築した。Icarus Verilog による Verilog 動作シミュレーション、Verilator による SystemVerilog RTL の最適化 C++ モデルへの変換と高速シミュレーション（CHIPS Alliance や lowRISC などのオープンソースチッププロジェクトで採用されているシミュレータと同一）、Yosys による RTL からゲートレベルネットリストへのマッピングと、合成可能性の検証および面積・タイミング推定の実行だ。これら 3 つは同一のコンテナイメージにパッケージ化されており、訓練データの品質判定基準は、設計が実シリコン上で成功するかどうかを決定する基準と完全に一致している。
GPU 最適化環境：NVIDIA A100 ノード上に直接デプロイ。CUDA パスは PyTorch のランタイムコンパイルインターフェースを介して nvcc を統合しており、FlashAttention や xFormers におけるカスタムカーネルのコンパイル・ロード方式と同一。Triton パスは公式コンパイルスタックを使用し、@triton.jit デコレータ付き Python 関数は初回呼び時に GPU コードへコンパイルされキャッシュされる。これは vLLM や SGLang などの推論フレームワークが使用するパスと同一だ。カーネルは本番ワークロードと同一の A100 ハードウェア上で起動され、メモリは標準 CUDA アロケータで管理され、計測には CUDA イベントが使用される。これにより、データ合成で得られた性能シグナルが実デプロイへ直接移行可能であることを保証している。
3D モデリング：業界で広く利用されているソリッドモデリングカーネルであり、ブーリアン演算、面取り、押し出し、回転、ロフトなどの操作をサポートする OpenCascade と、CadQuery を基に構築。生成されたスクリプトは FreeCAD や KiCad などの生産ツールと同一バージョンの OpenCascade 上で実行され、幾何学的忠実度は出力实体をメッシュ化して参照体積と比較評価することで検証される。検証基準は構文の正しさだけでなく、幾何学的に設計仕様へ忠実であることが求められる。
コード最適化：組込み方向は STM32F407（ARM Cortex-M4）を対象プラットフォームとし、arm-none-eabi-gcc クロスコンパイラを CMSIS デバイスヘッダファイルおよびチップメモリレイアウトリンクスクリプトと併用。検証は Renode エミュレータ上で実行される。Renode は GPIO、UART、SPI/I2C バス、タイマー、ADC+DMA、割り込みコントローラを含む STM32F407 の完全な仮想コピーを提供し、各周辺機器モデルはリファレンスマニュアルのレジスタレイアウトと割り込み動作を再現する。この忠実度は産業用コード検証に極めて重要だ。組込み分野の欠陥は往々にしてレジスタ設定ミスや割り込み優先度の競合に起因するため、実機または高精度シミュレーションハードウェアでのみ露呈するからだ。x86-64 アセンブリ方向は、固定 CPU 周波数・コアアフィニティ绑定の条件下で測定を繰り返す標準コンパイラボンチマークプロセスを再現した。
上記シミュレーション環境に基づき、チームは250 万件の実行検証済み SFT サンプルを構築。データ生産プロセスは以下の 4 段階から成る。
タスク構築：元の産業用コードタスクを構造化指示へ分解。自然言語による要求記述、インターフェース制約（ポートリスト、関数シグネチャ、API）、対象プラットフォーム・ツールチェーン設定、依存関係、検証スクリプトを含む。
候補生成：テンプレート摂動やクロス言語移行などの補完的戦略を通じて多様な候補解を生成し、異なる実装戦略やコーディングスタイルを網羅する。
実行検証：上記シミュレーション環境にて候補解のフルチェーン検証を実施。コンパイルチェック、シミュレーション実行、テスト実行、性能分析、形式的検証を含む。
フィードバック駆動型修復：これがデータ生産プロセスにおいて最も重要な工程だ。候補解の実行が失敗した際、パイプラインはコンパイルエラー情報、ランタイムログ、反例入力、波形差分、性能ボトルネックなど完全なフィードバックコンテキストを捕捉。その後、このフィードバックを失敗した解に付加して修復バージョンを生成する。この閉ループ修復軌跡（失敗解＋環境フィードバック＋修復解）も SFT 語料に組み込まれており、エンジニアがツール出力から問題を診断し反復修復するという実務ワークフローに対応している。
最終的に形成された訓練サンプルは 3 種類から成る。直接解答（要求から実装への直接パス）、欠陥修復（失敗 - フィードバック - 修復の閉ループ軌跡）、性能/構造最適化（機能は正しいが、さらに効率性やアーキテクチャ品質を最適化した解）だ。
3 段階トレーニング
InCoder-32B は 3 段階の漸進的トレーニングを採用。プレトレーニング段階では 4096 枚の GPU と 15 兆トークンを使用し、公開コードリポジトリ、技術文献、専門ドメインウェブサイトデータを融合。関数レベルからプロジェクトレベルへのカリキュラム学習を完了する。中期トレーニングでは 2 段階でコンテキスト長を 8K から 128K へ拡張し、推論 QA、エージェント軌跡、産業用成果物データを注入。後トレーニング段階では、前述の 250 万件の実行検証済み産業用コード SFT データを使用し、産業用能力の専門化を完了する。
モデル性能
InCoder-32B は 14 の汎用コードベンチマークと 9 の産業用コードベンチマークにて包括評価を実施。
汎用コード分野では、モデルは依然として強力な競争力を維持。HumanEval 94.5%、MBPP 91.8%、SWE-bench Verified 74.8%（同規模オープンソースモデルの中でトップレベル）を記録。エージェントタスクでも顕著な成果を収めており、Terminal-Bench 35.0、Mind2Web 55.8%、tau-2-bench Telecom 86.8% を達成した。
産業用コード分野では、InCoder-32B は複数のベンチマークで顕著なブレークスルーを達成した。
特筆すべきは、InCoder-32B が 32B パラメータのオープンソースモデルでありながら、CAD-Coder における IoU（53.5%）が Claude-Sonnet-4.6（32.4%）を大きく上回った点だ。また KernelBench の全 3 レベルにおいて、オープンソースモデルとして最高成績を収めた。これは産業用コードに特化したトレーニングアプローチが有効であることを示している。
エラー分析：産業用コードの難しさはどこにあるのか
チームは 9 つの産業用ベンチマークにおける 1882 件の失敗サンプルに対し、体系的な人手によるエラー分析を実施。5 つの核心的問題に分類した。
コンパイル・構文エラーが最も普遍的な失敗タイプであり、特にチップ設計分野で顕著だ。RealBench では 71% の失敗がフォーマット不正なリテラル、ポート宣言の不一致、ビット幅の不整合に起因。ArchXBench では 51% の失敗が名前付きポートの誤用や記号リテラルの不定ビット幅に由来する。モデルは広範なドメイン語彙を習得しているものの、産業用コードの厳格な構文規則までは完全に内在化できていない。
産業用 API 知識の不足が 2 番目の主要問題だ。EmbedCGen では 47% の失敗がリンクエラーであり、未定義または型誤りな HAL/CMSIS 関数呼び出しに起因。TritonBench では 33% が NameError、24% が TypeError で、いずれも Triton API の不適切な使用を示している。これらの産業専用 API は汎用コード訓練コーパスでの出現頻度が低く、モデルのカバレッジ不足を招いている。
機能的正しさの不足は、コードはコンパイル可能だがテストに合格しない現象を指す。VeriRepair では 79% の失敗がこれに該当。構文は正しいが、ステートマシン遷移条件の誤りや数値セマンティクスの偏差など潜在的な論理エラーが存在する。CAD-Coder では 93% の幾何学的失敗が、オイラー角の規約に関する体系的な誤解に起因している。この種の潜在的論理エラーが現在最も挑戦的な課題だ。
出力形式違反は VeriScope において 46% を占め、モデルが解析不能な出力を生成し、評価要件の構造化フォーマットに従わなかったケースだ。
性能最適化の不足は主に GPU およびコンパイラ分野で発生。KernelBench では 33% の失敗コードが機能は正しいが実行速度が基準未達。SuperCoder では 83% の失敗が入力アセンブリの単純コピーで最適化を全く行わなかったものだ。これはメモリ階層、命令パイプライン、並列スケジューリングなど下層ハードウェア動作に関する推論能力がまだ向上の余地があることを示している。
オープンソース情報
モデルおよびコードは現在 Hugging Face および GitHub にて Apache 2.0 ライセンスで公開中。
HuggingFace：https://huggingface.co/Multilingual-Multimodal-NLP/IndustrialCoder
GitHub：https://github.com/CSJianYang/Industrial-Coder
Arxiv：https://arxiv.org/abs/2603.16790
執筆者紹介：
本業務の中核貢献者には、北京航空航天大学の学部生 2 名も含まれている。計算機学院 4 年の呉佳峻氏と、高等理工学院 3 年の程浚航氏だ。
— 完 —