InCoder-32B: Code Foundation Model for Industrial Scenarios 出自北航联合多家机构的研究团队，权重已经以 IndustrialCoder 的名字发布在 Hugging Face。它瞄准的问题一句话就能说清：通用代码大模型在真实工业代码上会明显退化——芯片设计、GPU kernel、嵌入式这些领域不只是「另一种编程语言」，而是带着硬件语义和硬资源约束的深水区。
问题：工业代码为什么是深水区
过去三年代码大模型的进步集中在通用软件工程：Python、TypeScript、Java，评测也围绕这一侧建立。但工业场景的代码有三个通用场景没有的特性。
第一，硬件语义。一段 CUDA kernel 写得好不好，取决于内存层级、线程束调度和数据局部性；一段 RTL 代码的正确性，取决于时序约束和综合工具如何理解它。这些语义在自然语言注释里很少完整出现，模型必须从代码结构本身推断。
第二，专门语言构造。SystemVerilog 的断言、嵌入式的寄存器映射、编译器 pass 之间的 IR 变换，这些构造在主流训练语料里占比极小。低频分布正是大模型系统性出错的地方。
第三，严格资源约束。通用代码的「能用」标准是跑通测试；工业代码的「能用」标准还包括芯片面积、功耗、时钟频率、内存占用这些硬指标。差一个数量级的优化建议在工业上等于错误。
论文的实验观察是：通用代码模型在这些场景的性能显著退化。InCoder-32B 的回应是不回避：从零开始训练一个把工业代码当一等公民的基座模型。
五大工业领域
InCoder-32B 统一覆盖五个领域，每个领域都对应真实且长期缺工具的工程环节：
| 领域 | 典型语言与框架 | 工程痛点 |
|---|---|---|
| 芯片设计 | Verilog、SystemVerilog、RTL | 设计与验证人力瓶颈最大 |
| GPU kernel 优化 | CUDA、Triton | 性能调优高度依赖专家直觉 |
| 嵌入式系统 | C、汇编、寄存器级代码 | 资源约束下的代码生成 |
| 编译器优化 | IR、pass 编写 | 新语言后端开发成本高 |
| 3D 建模 | 几何脚本、建模 DSL | 艺术资产管线的重复劳动 |
选择这五个领域并非随机。它们共同的特征是：语料稀缺但价值高、验证信号明确（综合结果、执行时间、渲染输出）、而且社区长期缺乏针对性模型。这也是「基座模型」定位的合理性所在——单独每个领域的市场规模不足以支撑专模型，统一建模才划算。
四阶段训练流水线
论文最有工程参考价值的部分是训练流水线的设计，四个阶段各解决一个明确问题。
第一阶段是通用代码预训练，从零训练 32B 参数的基座。先保证通用编程能力不缺课，这是后续一切的地基。评测也确认了这一点：InCoder-32B 在 14 个主流通用代码基准上保持竞争力，没有为了工业性能牺牲基础能力。
第二阶段是工业代码退火（annealing）：在训练后期提高精选工业语料的采样权重。这个安排很关键——如果一开始就重仓工业代码，模型连基本的代码先验都学不稳；放到后期退火，工业知识是在通用能力之上做特化。
第三阶段是中程训练（mid-training），把上下文窗口从 8K 逐步扩展到 128K，并掺入合成的工业推理数据。128K 的上下文对工业场景不是奢侈：一个完整的 RTL 模块、一份 kernel 加上依赖头文件、一个编译器 pass 链路，都很容易超过 32K。合成工业推理数据则是为了让长上下文不只是「装得下」，还要「推得动」。
第四阶段是执行验证后训练（execution-grounded post-training）：用真实的执行结果作为反馈信号。工业代码的优势恰好在这里——验证信号天然存在：RTL 可以综合，kernel 可以跑分，嵌入式可以上板。执行验证比人工偏好更硬，也是工业代码比开放式写作更适合后训练的原因。
评测：14 个通用基准加 9 个工业基准
评测覆盖 14 个主流通用代码基准和 9 个工业基准，工业部分横跨 4 个专业领域。结果的双面性值得一提：通用任务上「高度竞争」，工业领域上建立了「强开源基线」。
「基线」这个词在这里是谦虚但准确的定位。工业领域的评测还很不成熟——每个领域的评测集都只覆盖真实工作的一小部分，综合结果的正确性不等价于流片成功。InCoder-32B 的价值在于给这个方向立了第一个可比较的公开参照物，后续工作有了起跑线。
工程意义：三个直接受益场景
对开发者，这篇论文的意义可以落到三个具体场景。
第一，EDA 与 AI 的融合有了可用的模型层。芯片设计的人力瓶颈是行业共识，验证工程师的缺口最大。一个懂 SystemVerilog 的开源 32B 模型意味着：内部工具链可以低成本接入代码生成做验证激励生成、断言草稿和代码审查辅助，而不用等商业 EDA 厂商的 AI 排期。
第二，IP 敏感代码的本地部署。工业代码不能出门是常态——芯片设计代码、嵌入式固件都涉及核心 IP。开源 32B 模型可以完全离线部署，这条约束直接排除了所有闭源 API 方案。
第三，执行验证方法论的可迁移性。「用真实工具链做后训练信号」这个思路不局限于代码：任何有确定性验证器的领域（CAD、金融建模、科学计算）都可以复用这套流水线。这可能是论文比模型本身更长尾的贡献。
局限与冷静面
三个局限需要说在前面。第一，32B 的规模决定了它的上限：复杂架构级的 RTL 设计、需要全局权衡的编译器 pass 重写，仍然超出能力圈，这类任务在可预见的时间里还是人的领地。第二，「工业基准表现好」到「工程师愿意用」之间有很长的工具链距离——IDE 集成、综合工具的反馈闭环、领域模板，这些配套一个都没有的话，模型只是个聊天窗口。第三，工业代码的时效性敏感：新的硬件架构、新的指令集出现后，模型知识需要持续更新，开源模型的维护节奏是个未知数。
另外要提醒：执行验证后训练在提升正确率的同时也可能强化「迎合验证器」的倾向——生成的代码恰好通过评测却不符合工程习惯。落地时保留人工 review 和代码规范检查是必须的。
结论
InCoder-32B 做的事朴素但重要：承认通用代码模型在工业场景的退化，然后用一条四阶段流水线——通用预训练、工业退火、128K 长上下文中程训练、执行验证后训练——把五个长期缺工具的领域拉进开源模型的能力圈。
对芯片、嵌入式、编译器方向的团队，这是第一个值得认真评估的本地代码模型基线：先用验证激励生成和样板代码这类低风险任务试点，把执行验证闭环接进自己的工具链，再看它能吃掉多少重复劳动。工业代码的 AI 深水区，总算有了第一艘像样的开源潜水艇。