通用代码大模型为什么还搞不定工业代码？

通用代码大模型写Verilog会报端口错误，调CUDA kernel能直接超出硬件上限

——不是能力不够，是根本不懂工业代码的规矩。

北航联合多家单位发布的InCoder-32B，在真实仿真环境中生成250万条经执行验证的工业代码数据，覆盖芯片设计、GPU内核优化、嵌入式系统、编译器优化、3D建模等五大工业领域。

目前，论文在Hugging Face Daily Paper的upvoted数已近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协议：