InCoder 團隊 投稿 量子位 | 微信公眾號 QbitAI
通用程式碼大模型在撰寫 Verilog 時常報端口錯誤，調試 CUDA kernel 更是直接超出硬體上限。
這並非模型能力不足，而是根本不懂工業程式碼的規矩。
北京航空航天大學（北航）聯合多家單位發布的InCoder-32B，在真實模擬環境中生成了 250 萬筆經執行驗證的工業程式碼數據，涵蓋晶片設計、GPU 內核優化、嵌入式系統、編譯器優化、3D 建模等五大工業領域。
目前，該論文在 Hugging Face Daily Paper 的按讚數已近 300，引發開源社群熱烈關注。模型的全量與量化版本權重均已開源！
通用程式碼大模型為何搞不定工業程式碼？
近年來，程式碼大模型在通用編程任務上進展顯著。以 Claude 等為代表的模型在 SWE-bench 等基準測試中屢創佳績，在演算法題求解、Web 開發、自動化修復 GitHub issue 等場景展現出極高的實用價值。
然而，通用編程與工業編程本質迥異。工業程式碼——包含晶片 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 的做法是將所有空間維度展平為一維，透過 gridDim.x 進行調度，從而規避了硬體限制。
論文的統計數據進一步印證了這一差距：當前最優模型在 Triton 算子生成任務上的函數調用成功率僅為 28.80%，在 Verilog 代碼的形式等價性驗證中準確率僅為 33.3%。這些數據表明，現有程式碼大模型從訓練數據到評測體系均圍繞通用編程語言構建，對工業程式碼領域的覆蓋嚴重不足。
InCoder-32B 是首個面向工業程式碼智慧的基座模型，採用 320 億參數的 Decoder-only Transformer 架構，旨在以單一模型統一服務多個工業程式碼領域。
與此前專注於單一工業子領域的工作（如 RTLCoder 聚焦 Verilog、Kevin 聚焦 CUDA）不同，InCoder-32B 將晶片設計、GPU 內核優化、嵌入式系統、編譯器優化和 3D 建模納入統一訓練框架。模型在覆蓋工業程式碼能力之餘，亦保持了通用程式碼任務上的競爭力，實現了工業與通用的兼顧。
核心方法：在真實模擬環境中大規模生產工業程式碼數據
工業程式碼的正確性驗證與通用程式碼本質不同。一段 Python 函數可透過單元測試快速判定，但 Verilog 模組需經過 RTL 模擬與邏輯綜合才能確認其在真實矽片上的可行性；CUDA/Triton kernel 需在真實 GPU 上運行，驗證數值正確性與性能是否達標；嵌入式韌體需在目標微控制器或其模擬器上引導運行，確認寄存器配置與中斷行為的正確性；CAD 腳本則需驗證生成的 3D 實體在幾何上是否忠實於設計規格。
因此，論文的關鍵洞察是：工業程式碼的正確性只能透過在真實部署環境中執行來驗證。這意味著，大規模生產高品質工業程式碼訓練數據的前提，是構建一整套生產級的執行與驗證基礎設施。
為此，團隊重建了四大類工業模擬環境，核心原則是復刻工業工程師實際使用的工具鏈與執行語義，而非構造簡化的替代方案。
晶片設計環境：半導體行業的數位設計遵循嚴格流程：RTL 編寫、行為模擬、邏輯綜合和物理實現。團隊使用公開 EDA 工具重建了前三個階段：Icarus Verilog 執行 Verilog 行為模擬；Verilator 將 SystemVerilog RTL 翻譯為優化的 C++ 模型進行高速模擬，與 CHIPS Alliance、lowRISC 等開源晶片專案所採用的模擬器一致；Yosys 將 RTL 映射到門級網表，驗證可綜合理性並提取面積與時序估計。三者封裝在同一容器化鏡像中，訓練數據的品質判定標準與決定設計能否在真實矽片上成功的標準完全一致。
GPU 優化環境：直接部署在 NVIDIA A100 節點上。CUDA 路徑透過 PyTorch 的運行時編譯接口集成 nvcc，與 FlashAttention、xFormers 中自定義 kernel 的編譯加載方式一致；Triton 路徑使用官方編譯棧，@triton.jit 裝飾的 Python 函數首次調用時編譯為 GPU 代碼並緩存，與 vLLM、SGLang 等推理框架使用的路徑相同。內核在與生產負載相同的 A100 硬體上啟動，記憶體透過標準 CUDA 分配器管理，計時使用 CUDA events 測量，確保數據合成中獲得的性能信號可直接遷移到真實部署。
3D 建模：基於 OpenCascade（業界廣泛使用的實體建模內核，支持布林運算、倒角、拉伸、旋轉、放樣等操作）和 CadQuery 構建。生成的腳本在與 FreeCAD、KiCad 等生產工具相同版本的 OpenCascade 上運行，幾何保真度透過對輸出實體進行網格化並與參考體進行體積比較來評估，驗證標準不僅要求語法正確，更要求幾何上忠實於設計規格。
代碼優化：嵌入式方向以 STM32F407（ARM Cortex-M4）為目標平台，使用 arm-none-eabi-gcc 交叉編譯器配合 CMSIS 設備頭文件和晶片記憶體佈局鏈接腳本。驗證在 Renode 模擬器上執行，Renode 提供了 STM32F407 的完整虛擬副本，包含 GPIO、UART、SPI/I2C 總線、定時器、ADC+DMA、中斷控制器，每個外設模型均復現參考手冊中的寄存器佈局和中斷行為。這一保真度對於工業代碼驗證至關重要，因為嵌入式領域的缺陷往往源於寄存器配置錯誤或中斷優先級衝突，只有在真實或高保真模擬硬體上才能暴露。x86-64 組合語言方向復刻標準編譯器基準測試流程，在固定 CPU 頻率、綁定核心親和性的條件下重複測量。
基於上述模擬環境，團隊構建了250 萬筆經執行驗證的 SFT 樣本。整個數據生產流程分為四步：
任務構造：將原始工業代碼任務分解為結構化指令，包含自然語言需求描述、接口約束（端口列表、函數簽名、API）、目標平台與工具鏈配置、依賴關係以及驗證腳本。
候補生成：透過模板擾動、跨語言遷移等互補策略生成多樣化候補解，確保覆蓋不同的實現策略與編碼風格。
執行驗證：在上述模擬環境中對候補解進行全鏈路驗證——編譯檢查、模擬運行、測試執行、性能分析、形式化驗證。
反饋驅動修復：這是數據生產流程中最關鍵的環節。當候補解執行失敗時，流水線捕獲完整的反饋上下文——編譯錯誤信息、運行時日誌、反例輸入、波形差異、性能瓶頸——然後將反饋附加到失敗解上生成修復版本。這一閉環修復軌跡（失敗解 + 環境反饋 + 修復解）也被納入 SFT 語料，對應的是工程師從工具輸出中診斷問題並迭代修復的真實工作流。
最終形成的訓練樣本包含三種類型：直接解答（需求到實現的直接路徑）、缺陷修復（失敗 - 反饋 - 修復的閉環軌跡）、性能/結構優化（功能正確的解經進一步優化效率或架構品質）。
三階段訓練
InCoder-32B 採用三階段漸進式訓練：預訓練階段使用 4096 塊 GPU、15 兆 token，融合公開代碼倉庫、技術文獻和領域專業網站數據，完成從函數級到專案級的課程學習；中期訓練分兩步將上下文從 8K 擴展至 128K，同時注入推理 QA、Agent 軌跡和工業製品數據；後訓練階段使用上述 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 全部三個級別上均取得了開源模型中的最佳成績。這說明面向工業代碼的專業化訓練路線確實有效。
錯誤分析：工業代碼難在哪
團隊對 9 個工業基準中的 1882 個失敗樣本進行了系統的人工錯誤分析，歸納出五類核心問題：
編譯與語法錯誤是最普遍的失敗類型，在晶片設計領域尤為突出。RealBench 中 71% 的失敗源於格式錯誤的字面量、端口聲明不匹配和位寬不一致；ArchXBench 中 51% 的失敗來自命名端口誤用和符號字面量的不確定位寬。模型雖已習得廣泛的領域詞彙，但對工業代碼嚴格的語法規則尚未完全內化。
工業 API 知識不足是第二類主要問題。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
作者簡介：
本工作的核心貢獻者中還包括兩位來自北京航空航天大學的本科同學：計算機學院大四本科生吳佳峻，以及高等理工學院大三本科生程浚航。
— 完 —