InCoder-32B：面向工业场景的代码基础模型 InCoder-32B: Code Foundation Model for Industrial Scenarios

该方法分为三个主要阶段，每个阶段有明确的输入、输出和操作： 第一阶段：预训练与退火（Pre-training & Annealing）。输入是收集的工业代码数据，来源于公共仓库、技术文献和领域特定网页数据。数据收集采用三步召回策略增加工业代码覆盖率，并使用OCR从技术文献中提取高质量代码片段。数据清洗包括许可证过滤、PII移除、文件级验证，以及精确哈希匹配、token级近重复检测、仓库级fork合并和跨源去重的多级去重。数据精炼则进行表面格式规范化和结构化注解，所有样本通过AST比较和重新编译验证正确性。输出是工业领域基础能力的模型权重。 第二阶段：中期训练（Mid-training）。输入包括三类数据流：(1) 合成工业推理QA——通过工业场景规范（咨询实践工程师）→种子代码生成（反映真实硬件设计模式）→QA对合成与自动验证的三步流程生成；(2) 智能体轨迹——遵循Thought-Action-Observation循环，捕获来自硬件模拟器、综合工具、C/C++编译器和形式化验证引擎的工具反馈闭环推理；(3) 工业代码工件——包括硬件测试台（SystemVerilog/UVM）、时序约束（SDC）、综合脚本、GPU性能分析trace和内存消毒器日志。操作上分两个子阶段：先从8K扩展到32K（聚焦文件级任务如RTL模块完成），再扩展到128K（解锁长上下文能力如扩展调试会话）。输出是具备工业感知长上下文推理能力的模型。 第三阶段：后训练（Post-training）。输入是250万样本的SFT数据集。每个任务被分解为结构化指令（自然语言需求描述、接口约束、目标平台和工具链、依赖配置、验证脚本）。通过模板扰动和跨语言迁移等互补采样生成多样候选解，然后在真实执行环境中验证。对于执行失败的解，捕获完整反馈上下文（编译器错误、运行时日志、反例输入、波形差异、性能瓶颈），附加到失败解上生成修复解，形成闭环修复轨迹。最终通过可执行性、稳定性和信息密度过滤，将样本分为直接解、缺陷修复和性能/结构优化三类。输出是最终的InCoder-32B模型。

InCoder-32B的技术新颖性体现在多个维度。首先，这是第一个将多个工业编程领域统一在单一代码LLM中的工作——此前的VeriGen、RTL-Coder只覆盖Verilog，Kevin只覆盖CUDA，AscentKernelGen只覆盖NPU内核，每个模型只能处理一个子领域，而InCoder-32B同时覆盖芯片设计、GPU内核优化、嵌入式系统、编译器优化和3D建模五大领域。其次，本文构建了迄今最全面的工业代码评测体系，包含14个通用基准和9个工业基准，涵盖4个专业领域，这在工业代码领域是前所未有的评测广度。第三，本文的训练数据合成方法论具有原创性：不是简单地使用GPT-4等通用模型生成数据，而是在真实的工业仿真环境中（与生产环境完全一致的工具链）合成和验证数据，这确保了训练信号直接转移到实际部署。第四，本文通过消融实验揭示了三个重要的技术发现：仓库转换数据（repository transition data）优于静态快照用于规划能力训练、中期训练轨迹数据是分布偏移下鲁棒性的关键支架、基于执行反馈的多轮轨迹训练能解锁标准SFT中不存在的能力。第五，本文的闭环修复轨迹（包含失败解和成功解及执行反馈）模仿了有经验工程师的调试工作流，这是一种新颖的SFT数据构造范式。

基于论文的实验结果和错误分析，可以识别出InCoder-32B的几个关键弱点： 第一，编译和语法层面的错误占比过高，特别是Verilog生成中71%的失败涉及基本语法问题（位宽不匹配、端口声明错误、字面量格式错误）。这表明预训练阶段对工业语言的精确语法规则学习不足，可能需要在数据清洗阶段增加更严格的语法验证过滤器，或在中期训练中加入更多面向语法正确性的对比学习信号。 第二，模型在优化类任务上表现较弱——SuperCoder 83%的失败是直接复制输入汇编而非进行优化，KernelBench有33%的功能正确但不够快。这反映了模型在"做得更好"而非"做得对"方面的能力不足，可能需要在训练中引入更多性能对比信号（如更快vs更慢的实现对）或使用强化学习优化性能目标。 第三，CAD-Coder中的欧拉角约定系统性误解（93%的失败是几何性的）说明模型在空间推理和数学概念理解上存在深层缺陷，这类错误难以通过增加数据量简单解决，可能需要针对3D几何推理设计专门的训练任务。 第四，嵌入式领域EmbedCGen的47%链接错误（引用未定义或类型不正确的HAL/CMSIS函数）表明模型对嵌入式API的知识覆盖不完整，需要在数据收集中扩大STM32相关代码和文档的覆盖范围。 第五，论文未详细讨论模型的推理效率——32B Dense模型的推理延迟和吞吐量与更大MoE模型相比如何，在工业实时代码辅助场景中是否满足需求，这是一个实际部署中需要关注的重要维度。

论文作者在错误分析和消融研究的基础上提出了多个值得探索的未来方向。 首先，作者指出关闭剩余差距需要"针对稀有API和硬件语义的数据策展、训练中引入验证信号的循环、以及对低层性能的显式推理"。这意味着未来工作可以在数据层面进一步扩展工业代码覆盖范围，特别是当前稀缺的领域如FPGA HLS综合、RISC-V自定义扩展、专用加速器编程等。 其次，基于执行反馈的闭环修复轨迹被证明能解锁标准SFT中不存在的能力，这暗示可以将强化学习与执行验证信号更深度地结合——类似于CodeV-R1和VeriReason在芯片设计领域采用的方法，扩展到GPU优化、嵌入式和CAD等更多工业领域。 第三，本文的中期训练阶段展示了仓库转换数据优于静态快照的发现，未来可以进一步探索更丰富的代码上下文表示，如跨文件依赖图、构建系统配置、CI/CD流水线状态等，以增强模型对工业代码仓库全局结构的理解。 第四，论文目前每个工业领域使用统一的模型权重，未来可以探索领域自适应的混合专家架构，在保持统一模型的同时为不同工业领域激活专门的专家子网络。 第五，论文的评测体系（14个通用基准+9个工业基准）为进一步研究提供了完整的基线框架，但当前基准主要关注代码生成正确性，未来可以增加更多衡量代码质量、安全性、可维护性和部署就绪度的评估维度。

从复现角度来看，InCoder-32B具有较好的可复现性。模型权重已发布在HuggingFace（Multilingual-Multimodal-NLP/IndustrialCoder2026），源代码发布在GitHub（CSJianYang/Industrial-Coder），这为社区提供了直接使用和进一步研究的基础。论文描述了详细的训练配置：使用4096个GPU进行预训练，遵循与先前工作相同的模型配置，训练数据规模从83M到250M token的消融实验也提供了数据规模的参考。 然而，完全复现存在几个挑战：(1) 论文中的工业仿真环境构建需要配置多个专业工具链（Icarus Verilog、Verilator、Yosys、nvcc、Triton编译器、arm-none-eabi-gcc、Renode、CadQuery/OpenCascade），这些工具的版本兼容性和环境搭建有一定复杂度；(2) 250万SFT样本的构建涉及工业专家咨询（工业场景规范通过与实践工程师商议确定）、种子代码生成、执行验证和闭环修复轨迹生成，这一数据合成流水线的复现需要相当的领域专业知识和计算资源；(3) 论文未提供具体的GPU型号和训练时长信息，4096 GPU的训练规模对大多数研究机构来说门槛较高。 总体而言，模型权重和推理代码的开源使得使用该模型较为容易，但从零复现训练流程需要显著的工程和计算投入。