InCoder-32B开源：320亿参数工业代码基座，保住通用代码能力，工业代码全线领先

魔搭ModelScope社区

23人浏览 · 2026-03-31 10:26:23

魔搭ModelScope社区 · 2026-03-31 10:26:23 发布

Verilog 端口声明写错、CUDA 配置出错、嵌入式 HAL 调用类型不匹配……这些不是模型"不够聪明"，而是通用代码大模型压根没学过工业代码。

近日，北航团队联合多家机构正式发布 InCoder-32B，一个在真实仿真环境中用 250 万条执行验证数据训练出来的工业代码基座模型，统一覆盖芯片设计、GPU 内核优化、嵌入式系统、编译器优化与 3D 建模等工业方向。模型全量权重与量化版本均已开源。

开源地址：

ModelScope: IndustrialCoder
GitHub: https://github.com/CSJianYang/Industrial-Coder
Arxiv: InCoder-32B: Code Foundation Model for Industrial Scenarios

模型定位：为什么需要一个工业代码专用模型？

当前主流代码大模型的训练语料以 Python、JavaScript、TypeScript 等通用语言为主，对 Verilog/SystemVerilog、CUDA/Triton、ARM 汇编、CadQuery 等工业语言的覆盖极为有限。论文统计显示，即使是最先进的模型，在 Triton 算子生成上的函数调用成功率仅 28.80%，在 Verilog 形式等价性验证中准确率仅 33.3%。

InCoder-32B 的设计思路是：与其在通用模型上做补丁式适配，不如从预训练阶段就将工业代码纳入核心训练框架，同时保持通用编程能力不退化。

技术路线：三阶段 Code-Flow 训练

InCoder-32B 的训练采用三阶段渐进式 Code-Flow 流水线，从通用代码能力逐步过渡到工业代码专精。

Stage 1：预训练与退火。 使用 4096 块 GPU 进行大规模预训练，处理 15 万亿 token。数据来源包括公开代码仓库、技术文献中经 OCR 提取的代码片段，以及领域专业网站。数据质量通过许可证过滤、PII 移除、多级去重以及 AST 级验证和重编译校验来保障。训练目标为自回归语言建模与 Fill-in-the-Middle 补全，并通过课程学习从函数级逐步过渡到项目级。

Stage 2：中期训练。 这一阶段承担两项核心任务。一是通过两个子阶段将上下文窗口从 8K 扩展至 128K，先从 8K 扩展到 32K 以处理文件级任务，再从 32K 扩展到 128K 以支持扩展调试会话等长上下文场景。二是在数据配比中注入三类合成数据：合成工业代码 QA，通过与硬件和系统工程师协作确定工业场景规格，生成种子代码，再合成经自动验证的 QA 对；Agent 轨迹，遵循思考-行动-观察循环的多步调试与修复轨迹，包含来自硬件仿真器、综合工具、编译器和形式化验证引擎的工具反馈；工业代码制品，包括硬件测试台、时序约束、综合脚本、GPU profiling 日志和内存 sanitizer 日志等。

Stage 3：后训练。 使用前述 250 万条经执行验证的工业代码 SFT 数据进行指令微调。这一阶段是 InCoder-32B 在工业代码领域实现能力突破的直接驱动。论文同时提供了 Instruct 和 Thinking 两种微调变体，分别对应标准指令遵循和带分析推理链的生成模式。

数据扩展：工业级仿真环境驱动的数据生产

通用 SFT 数据集对工业编码任务几乎没有帮助，尤其当代码的正确性必须依赖执行来判定时。InCoder-32B 的核心创新正在于此：直接从真实工业编码任务出发，在生产级执行环境中构建 250 万条有执行验证背书的训练样本。

通用代码可以靠单元测试快速判定对错，工业代码则不然。一个 Verilog 模块在语法上毫无问题，却可能在综合阶段因为时序违约而无法流片。一段 CUDA 内核编译通过且数值正确，但如果吞吐量不达标就毫无意义。嵌入式固件在桌面模拟器上运行正常，到了真实微控制器上却因为中断优先级冲突而死锁。CAD 脚本成功生成了 3D 实体，但体积偏差超标意味着零件不可制造。

换言之，工业代码的"正确"需要在其目标部署环境中被证实。这就要求数据生产的基础设施必须还原真实的执行条件，而不能依赖启发式规则或静态分析来代替。

四套生产级执行环境

团队从零搭建了四套仿真基础设施，每一套都对齐了对应领域工程师在日常工作中使用的完整工具链：

芯片设计。 容器内集成了三款开源 EDA 工具：Icarus Verilog 负责行为级仿真，Verilator 将 RTL 编译为 C++ 进行周期精确仿真，Yosys 完成门级综合并输出面积与时序报告。从仿真到综合的完整前端流程都在同一镜像中闭环运行，任何一条训练数据能否通过，取决于它在这三个阶段的全部表现，而非仅仅"编译不报错"。

GPU 内核开发。 在 NVIDIA A100 集群上直接部署了 CUDA 和 Triton 两条编译执行路径。CUDA 侧通过 PyTorch 运行时编译接口调用 nvcc；Triton 侧走官方 JIT 编译栈。所有内核在真实 GPU 硬件上启动和测量，性能数据通过 CUDA events 采集，与 FlashAttention、vLLM 等项目的开发环境完全一致。这保证了训练数据中的性能信号在真实推理部署中同样成立。

3D 参数化建模。 以 OpenCascade 内核配合 CadQuery Python 接口为基础。验证不仅检查脚本能否执行，还将生成的实体与参考体分别网格化后做体积重合度比较。也就是说，即使脚本无报错地跑完了，只要最终三维形状与设计规格的偏差超过阈值，这条数据一样会被标记为失败。

嵌入式与汇编优化。 嵌入式方向瞄准 STM32F407 微控制器，使用 ARM 交叉编译器生成固件，然后在 Renode 全系统仿真器上运行。Renode 为 STM32F407 提供了寄存器级精确的外设模型，能暴露实际硬件上才会出现的中断与总线时序问题。x86-64 汇编方向则在固定 CPU 频率、绑定核心亲和性的受控条件下做原生执行测量，复刻编译器回归测试的标准方法论。

闭环修复：让"失败"也变成训练信号

有了执行环境之后，数据生产按四步推进。首先将工业编码任务拆解为结构化指令，明确需求描述、接口签名、目标平台和验证脚本。然后通过模板扰动和跨语言迁移等手段为每个任务生成一批多样化的候选解。接下来将候选解送入对应的仿真环境做全链路验证。

关键在第四步：对于未通过验证的候选，流水线不是一弃了之，而是完整捕获失败的上下文信息，比如编译器报错、运行时异常、仿真波形差异、性能热点等，然后将这些诊断信息附加到原始失败代码上，驱动模型生成修复版本。最终产出的"失败代码 → 诊断反馈 → 修复代码"完整轨迹本身也作为高质量训练样本保留。这种设计直接模拟了资深工程师的核心工作模式：阅读工具输出、定位问题根因、迭代修复直到通过验证。

经过质量过滤后，250 万条样本最终分为三类：需求直接到实现的解答型样本、包含修复轨迹的缺陷修复型样本、以及在功能正确基础上进一步提升效率或结构的优化型样本。

评测结果

InCoder-32B 在 14 个通用基准和 9 个工业基准上进行了全方位测试。

通用代码能力未受损。 模型在 HumanEval 上达到 94.5%，MBPP 达到 91.8%，SWE-bench Verified 达到 74.8%，Terminal-Bench v1.0 得分 35.0，在同规模开源模型中处于领先水平。这说明面向工业场景的专项训练并没有以牺牲通用代码能力为代价。

工业代码全线领先。 芯片设计方向，VeriScope 得分 80.7，VeriRepair 修复率达到 80.0%，RealBench 的 Syn@1 和 Func@5 分别达到 74.8% 和 70.5%，远超 Kimi-K2-Instruct 的 50.1% 和 28.3%。GPU 优化方向，KernelBench 三个难度级别 L1、L2、L3 的通过率分别为 22.2%、36.0%、14.0%，均为开源最佳。3D 建模方向，CAD-Coder 编译成功率 82.0%，IoU 达到 53.5%，显著超过闭源的 Claude-Sonnet-4.6 的 32.4%。代码优化方向，SuperCoder 准确率 91.0%。

数据规模效应：扩展工业 SFT 数据是否有效？

另外，团队在 83M、167M、250M 三个 token 规模节点上进行了系统的消融实验，验证工业代码 SFT 数据的扩展效果。

实验结果表明，大多数工业代码基准随数据规模增长而持续提升，证实了规模化工业 SFT 数据对模型能力的正向驱动作用。仅有 RealBench 和 TritonBench 的个别子指标在 250M 阶段出现轻微波动，但整体仍高于或接近 83M 基线，表明与验证相关的能力可能在较小规模的高质量数据上就已趋于饱和。

模型推理

使用transformers推理

环境安装

pip install -U "transformers>=4.57.1" accelerate safetensors

推理脚本

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Multilingual-Multimodal-NLP/IndustrialCoder"

tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto",
    trust_remote_code=True,
)

messages = [{"role": "user", "content": "Optimize this CUDA kernel for better memory coalescing."}]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer([text], return_tensors="pt").to(model.device)

with torch.no_grad():
    out = model.generate(**inputs, max_new_tokens=2048, temperature=0.6, top_p=0.85, top_k=20)

print(tokenizer.decode(out[0][inputs["input_ids"].shape[-1]:], skip_special_tokens=True))

使用vLLM推理

pip install vllm

# BF16
vllm serve Multilingual-Multimodal-NLP/IndustrialCoder \
    --tensor-parallel-size 4 --max-model-len 32768

# FP8
vllm serve Multilingual-Multimodal-NLP/IndustrialCoder-32B-FP8 \
    --tensor-parallel-size 2 --max-model-len 32768

推荐的采样参数：