InCoder-32B-Thinking: Industrial Code World Model for Thinking
실행 오류에서 추론 사슬을 합성하는 ECoT와 툴체인 피드백을 대신 예측하는 산업용 코드 월드 모델의 설계를 설명하고, 일반·산업 벤치마크 결과를 자기 instruct 판본과 대조해 '모든 도메인 최고'라는 서술이 어디까지 성립하는지 검토합니다.
Paper: Jian Yang; Wei Zhang; Jiajun Wu; Junhang Cheng; Tuney Zheng; Fanglin Xu; Weicheng Gu; Lin Jing; Yaxin Du; Joseph Li; Yizhi Li; Yan Xing; Chuan Hao; Ran Tao; Ruihao Gong; Aishan Liu; Zhoujun Li; Mingjie Tang; Chenghua Lin; Siheng Chen; Wayne Xin Zhao; Xianglong Liu; Ming Zhou; Bryan Dai; Weifeng Lv (2026). "InCoder-32B-Thinking: Industrial Code World Model for Thinking". https://arxiv.org/abs/2604.03144v1 · arXiv:2604.03144v1. 이 글은 2026년 4월 3일 공개된 25쪽의 v1을 기준으로 한다. 분류는 cs.AR이다. PDF · GitHub · 모델 가중치.
Abstract: 칩 설계, GPU 커널 최적화, 펌웨어 같은 산업용 코드 영역에는 엔지니어가 하드웨어 제약과 타이밍 의미를 어떻게 따져 나가는지 보여주는 추론 기록이 웹 규모 말뭉치에 거의 없다. InCoder-32B-Thinking은 이 부재를 두 장치로 메운다. ECoT는 실제 툴체인에 코드를 실행해 얻은 오류 로그를 다음 턴에 되먹여 최대 네 번의 수정 라운드를 돌리고, 그 다중 턴 궤적에서 사고 내용을 합성한다. ICWM은 그렇게 모은 실행 턴으로 학습해 환경 번들과 후보 코드를 받아 백엔드가 돌려줄 결과를 예측하며, 대규모 합성 단계에서 실제 백엔드를 대신한다. 평가는 일반 14개와 산업 9개 벤치마크에 걸쳐 있고, 논문은 LiveCodeBench V5 81.3%, CAD-Coder 84.0%, KernelBench L2 38.0%를 앞세운다. 이 글은 두 장치의 정의와 경계를 정리한 뒤, 표에 실린 값을 같은 계보의 instruct 판본과 열 단위로 대조해 어떤 이득이 실제로 확인되고 어떤 서술이 표보다 넓은지 검토한다. 논문 §§2–4
Executive Summary
| 항목 | 설명 |
|---|---|
| 연구 질문 | 실행 피드백으로 만든 오류 수정 궤적을 사고 사슬로 합성하고, 그 피드백을 학습된 대리 환경으로 대체하면 산업용 코드 생성이 개선되는가? |
| ECoT | 생성기(DeepSeek-V3.2)가 코드를 내고 실제 백엔드가 채점하며, 최대 K=4 라운드의 수정 궤적을 남긴다. 성공·실패 중간 턴을 모두 보존한다. |
| ICWM | (s_{\mathrm{env}}, c^{(k)}) \mapsto \hat o^{(k)}. 환경 번들과 후보 코드로 결과 라벨·진단 메시지를 예측하는 언어 모델이며, 합성 루프에서 실제 백엔드를 대신한다. |
| 학습 말뭉치 | \mathcal D = \mathcal D_{\mathrm{real}} \cup \mathcal D_{\mathrm{icwm}}. 사고 데이터는 540M 토큰이며 InCoder-32B의 250M보다 크다. |
| 일반 결과 | LiveCodeBench V5 81.3(공개 가중치 중 최고), CruxEval Output-COT 95.5. 반면 Mercury·Text2SQL·Mind2Web은 instruct 판본보다 낮다. |
| 산업 결과 | RealBench 모듈 Syn@1·Func@1, CAD-Coder 컴파일 통과율, SuperCoder 정확도, KernelBench L2에서 공개 모델 최고. 같은 모듈 열의 Syn@5·Func@5는 자기 instruct 판본이 더 높고, VeriScope·VeriRepair·ArchXBench·EmbedCGen·TritonBench에서도 최고가 아니다. |
| ICWM 충실도 | 도메인당 2,000개 보류 실행 턴에서 결과 예측 정확도 평균 96.7%, 궤적 일치 평균 94.4%. |
| 핵심 한계 | ICWM과 ECoT의 기여를 각각 분리한 절제 실험이 없고, 학습 설정이 제시되지 않으며, 초록·서론·결론의 "모든 도메인 최고"는 자기 표가 지지하지 않는다. |
수치와 평가 범위는 논문 Tables 1–5 및 Figures 5–7에 따른다.
목차
- 산업용 코드에는 무엇이 없는가
- 오류에서 추론을 만든다
- 산업용 코드 월드 모델은 무엇을 대신하는가
- 평가 설계: 무엇을 누구와 비교했는가
- 일반 코드: 추론은 크게 오르고 간결함은 내린다
- 산업용 코드: "모든 도메인 최고"는 어디까지 성립하는가
- ICWM의 충실도는 어디서 측정되었는가
- 사고 길이와 데이터 규모
- 한계, 재현 조건과 결론
1. 산업용 코드에는 무엇이 없는가
일반 코드 모델이 잘하는 일과 산업용 코드가 요구하는 일은 다르다. Verilog 모듈은 합성 가능해야 하고 조합 경로 깊이와 클록 도메인 교차를 지켜야 한다. CUDA·Triton 커널은 워프 발산과 공유 메모리 예산 안에서 동작해야 한다. STM32 펌웨어는 주변장치 레지스터를 정해진 순서로 건드려야 한다. 논문은 이 영역들의 공통점을 "웹 규모 말뭉치에 없는 것"으로 정리한다. 결과 코드는 GitHub에 있지만, 엔지니어가 하드웨어 제약을 어떻게 따져 어떤 실패를 거쳐 그 코드에 도달했는지의 기록은 없다. 논문 §1
그래서 이 논문의 접근은 추론 기록을 사람에게서 수집하는 대신 실행에서 만들어 내는 쪽이다. 코드를 실제 툴체인에 넣고, 돌아온 오류를 다음 턴의 입력으로 삼고, 그 수정 과정을 사고 사슬로 다시 쓴다. 여기에 두 번째 장치가 붙는다. 실제 백엔드 호출은 비싸므로, 그 백엔드가 무엇을 돌려줄지 예측하는 모델을 따로 학습해 합성 단계에서 대신 쓴다.
원논문 Figure 2. 열 개 패널 각각에서 네 모델의 점수를 비교한다. 이 도판의 EmbedCGen Main 값은 51.0인데, 본문 Table 5의 같은 항목은 47.9다. 아래 6절에서 이 차이를 다시 다룬다. Yang et al. (2026), PDF p. 2. 원본 도판 영역 직접 추출.
그림을 누르면 원본 해상도로 볼 수 있다. 아래 도판도 같은 방식으로 확대할 수 있다.
논문이 내세우는 기여는 세 가지다. 오류 수정 과정을 명시적으로 모델링해 추론 사슬을 만드는 ECoT 합성, 산업용 실행 환경을 위한 월드 모델 ICWM, 그리고 둘을 결합해 학습한 InCoder-32B-Thinking이다. 읽을 때 유의할 점은 이 세 가지가 하나의 학습 파이프라인으로 묶여 있고, 논문 안에 각각을 떼어 낸 실험이 없다는 것이다. 따라서 "무엇이 얼마나 기여했는가"라는 질문에는 이 논문만으로 답할 수 없다.
2. 오류에서 추론을 만든다
2.1 과제 씨앗과 환경 번들
모든 과제는 실행 가능한 환경과 함께 묶인다. Verilog 모듈에는 테스트벤치와 Yosys 합성 스크립트가, STM32 펌웨어 조각에는 메모리 배치와 CMSIS 헤더와 링커 스크립트가 따라붙는다. 이렇게 만들어진 쌍 \langle s_{\mathrm{task}}, s_{\mathrm{env}} \rangle이 이후 모든 단계에서 재현 가능한 실행 문맥이 된다. 과제 씨앗 자체는 선행 연구인 InCoder-32B의 질의·단위 테스트·환경을 재사용한다. 논문 §2.1
2.2 최대 네 번의 수정 라운드
생성이 시작되기 전에 가벼운 프롬프트 라우터가 환경 번들을 보고 도메인별 지시를 고른다. GPU 커널 과제에는 워프 발산과 공유 메모리 예산을, RTL 과제에는 조합 경로 깊이와 클록 도메인 교차를, CAD 과제에는 벽 두께와 다양체 유효성을, 펌웨어 과제에는 주변장치 레지스터 순서를 따지라는 지시가 붙는다. 생성기 DeepSeek-V3.2가 첫 추론과 코드 (r^{(0)}, c^{(0)})를 내놓으면, 도메인에 맞는 실제 백엔드가 이를 실행한다. GPU 커널은 Triton/CUDA, 펌웨어는 Renode, CAD 기하는 CadQuery, RTL은 Yosys/Icarus다. 논문 §2.2
백엔드는 PASS, COMPILATION_ERROR, MEMORY_FAULT 같은 결과 라벨과 진단 로그를 함께 돌려준다. 오류가 나면 그 출력이 관측 o^{(k)}로 포장되어 생성기에 되먹여지고, 생성기는 원인을 진단해 수정본을 낸다. 최대 K=4 라운드를 허용해 다음 궤적을 얻는다.
\tau=\bigl(\langle s_{\mathrm{init}}, r^{(0)}, c^{(0)}\rangle \longrightarrow \langle r^{(1)}, c^{(1)}\rangle \cdots \longrightarrow \langle r^{(k)}, c^{(k)}\rangle\bigr)궤적은 코드가 모든 검사를 통과하거나 최대 턴에 도달하면 끝난다. 중요한 설계 결정은 성공한 턴과 실패한 턴을 모두 남긴다는 것이다. 학습 데이터가 실패 양상과 그것을 푸는 추론 단계를 함께 담게 된다. 완성된 다중 턴 궤적은 코드 모델을 학습시키고, 거기서 뽑아낸 단일 턴 쌍은 다음 절의 월드 모델을 학습시킨다.
원논문 Figure 3. 위는 2D predictions와 1D targets를 같은 평면 인덱스로 접근해 범위를 벗어나는 코드이고, 아래는 grid-stride 루프에서 batch_idx = i / input_size로 행 인덱스를 만들어 targets를 행 단위로 읽는 코드다. 도판 안의 초록색 주석 "Map flat index to raw index"는 원문 표기이며, 오른쪽 단계 사슬의 STEP 03 상자는 같은 단계를 "row index"로 적는다. Yang et al. (2026), PDF p. 2. 원본 도판 영역 직접 추출.
이 예시는 논문이 말하는 "하드웨어 인식 추론"이 구체적으로 무엇인지 보여준다. 다만 이는 선별된 사례이며, 두 판본의 차이를 통계적으로 정량화한 것은 아니다.
3. 산업용 코드 월드 모델은 무엇을 대신하는가
원논문 Figure 4. 왼쪽에서 과제 씨앗과 환경 번들이 만들어지고, 가운데 생성과 오른쪽 실행 사이를 피드백이 네 라운드 오가며, 오른쪽 아래에서 그 기록이 ICWM을 학습시킨다. 학습된 ICWM은 합성 단계에서 실제 백엔드 자리를 대신한다. 도판의 백엔드 표기는 Icarus/Verilator이고 본문 §2.2는 같은 역할을 Yosys/Icarus로 적는다. CUDA/Trition 표기도 원문 그대로다. Yang et al. (2026), PDF p. 4. 원본 도판 영역 직접 추출.
3.1 정의
논문은 산업용 코딩 과제에서의 "세계"를 코드 수정의 결과를 결정하는 실행 가능 환경으로 정의한다. 환경 번들 s_{\mathrm{env}}에는 테스트벤치, 시뮬레이터, 컴파일러 설정, 설정 파일, 메모리 배치, 도메인 제약이 들어간다. ICWM은 이 번들과 후보 프로그램을 받아 실제 툴체인이 돌려줄 관측을 예측하는 언어 모델이다.
\mathrm{ICWM}_{\theta}\colon (s_{\mathrm{env}}, c^{(k)}) \longmapsto \hat o^{(k)}예측 \hat o^{(k)}에는 결과 라벨, 진단 메시지, 그리고 해당하는 경우 수치 출력이나 차이 요약이 포함된다. 모델은 \mathcal D_{\mathrm{real}}의 모든 실제 실행 턴으로 학습하며, 도메인 차이는 입력에 도메인 태그를 붙이고 도메인별 출력 템플릿을 쓰는 방식으로 처리한다. 논문 §2.3, Eq. 2
이 문단의 두 진술은 뒤의 평가 절과 어긋난다. 첫째, §2.3은 모델이 \mathcal D_{\mathrm{real}}의 모든 실행 턴으로 학습한다고 적지만, §4.1은 충실도 측정을 위해 도메인당 2,000개 턴을 보류했다고 적는다. 둘 다 성립할 수는 없고, 어느 쪽이 맞는지가 96.7%를 보류 집합 점수로 읽을 수 있는지를 가른다. 둘째, §2.3은 모델 하나가 네 개 수직 영역을 담당한다고 쓰지만 §4.1과 Figure 5는 다섯 도메인을 평가한다. Figure 4의 도메인 상자도 넷이고 거기서 임베디드는 코드 최적화 쪽에 묶여 있다. 논문 §2.3, §4.1, Figure 5
3.2 합성 루프에서 화살표의 의미가 바뀐다
학습이 끝나면 ICWM이 피드백 루프에서 실제 백엔드 자리를 차지한다.
\tau=\bigl(\langle s_{\mathrm{init}}, r^{(0)}, c^{(0)}\rangle \xrightarrow{\ \mathrm{ICWM}_{\theta}\ } \langle r^{(1)}, c^{(1)}\rangle \cdots \xrightarrow{\ \mathrm{ICWM}_{\theta}\ } \langle r^{(k)}, c^{(k)}\rangle\bigr)앞 절의 궤적과 형태는 같지만 화살표 하나의 비용이 다르다. 실제 컴파일이나 시뮬레이션 대신 순전파 한 번이다. 최종 추론 말뭉치는 \mathcal D = \mathcal D_{\mathrm{real}} \cup \mathcal D_{\mathrm{icwm}}이다. 논문 §2.3, Eq. 3
논문은 이 합집합에 대해 "\mathcal D의 모든 궤적은 실제 실행으로 생성되었거나 그에 비추어 검증되었다"고 적는다. 문장은 두 갈래를 함께 담고 있다. \mathcal D_{\mathrm{real}}은 실제 실행의 산물이고, \mathcal D_{\mathrm{icwm}}은 §2.3이 설명하는 주기적 감사, 즉 실제 실행 표본 점검으로 보정된다. 초록의 "모든 합성 추론 기록은 도메인 툴체인을 통해 검증된다"는 문장을 합성 궤적 하나하나가 실제로 컴파일·시뮬레이션되었다는 뜻으로 읽어서는 안 된다. 감사 비율이나 주기는 제시되지 않는다.
한 가지 더 구분할 것이 있다. ICWM은 백엔드의 출력 텍스트를 예측하도록 학습된 언어 모델이지, 하드웨어 동작의 인과 구조를 별도로 표현하는 장치가 아니다. 논문이 "코드와 하드웨어 동작 사이의 인과 동역학을 학습한다"고 쓸 때, 실제로 학습되는 것은 환경 번들과 코드 텍스트에서 결과 라벨과 진단 문자열로 가는 사상이다. 7절에서 보듯 이 구분은 3D 모델링 실패 사례에서 그대로 드러난다.
4. 평가 설계: 무엇을 누구와 비교했는가
4.1 두 벤치마크 계열과 서로 다른 기준 모델
일반 코드와 산업 코드는 요구 능력이 다르므로 기준 모델 집합도 분리한다. 일반 쪽 비교 대상은 DeepSeek-Coder-V2-Lite부터 Qwen3-Coder-480B, Kimi-K2 계열, GLM-4.7까지이고, 산업 쪽은 Qwen3.5 계열, GLM-5, Kimi-K2.5, MiniMax-M2.5, GPT-OSS 계열과 함께 독점 참조 모델로 Claude-Sonnet-4.6을 둔다. 논문 §3.1
| 계열 | 개수 | 구성 |
|---|---|---|
| 일반 | 14 | HumanEval, MBPP(이상 EvalPlus), BigCodeBench, FullStackBench, CRUXEval, LiveCodeBench, Mercury, Spider, BIRD, Terminal-Bench, SWE-bench Verified, Mind2Web, BFCL V3, \tau^2-bench |
| 산업 | 9 | VeriScope, RealBench, ArchXBench, VeriRepair(칩 설계), KernelBench, TritonBench(GPU), EmbedCGen, SuperCoder(코드 최적화), CAD-Coder(3D) |
4.2 아홉 개 산업 벤치마크 중 셋은 이 논문이 만든 것이다
Appendix A를 보면 VeriScope("We propose VeriScope"), VeriRepair("As part of this work, we construct VeriRepair"), EmbedCGen("We also contribute EmbedCGen") 세 개가 이 연구에서 새로 도입된 벤치마크다. VeriScope는 568문제를 다섯 난이도로 나누고 컴파일 실패 0점, 컴파일 성공·기능 실패 50점, 전체 통과 100점의 3단계 채점을 쓴다. VeriRepair는 4개 대분류 20개 세부 오류 유형으로 버그를 주입해 만든 데이터로, 학습 표본 약 22,000개와 시험 표본 300개로 구성된다. EmbedCGen은 ARM GCC 교차 컴파일과 Renode 시뮬레이터로 검증하는 500문제다. 논문 Appendix A.2
자체 벤치마크를 함께 내는 것 자체가 문제는 아니지만 두 가지를 확인해야 한다. 첫째, 외부 검증을 거치지 않은 지표라는 점이다. 둘째, VeriRepair는 학습 분할이 존재하고 이 모델의 산업용 학습 데이터는 선행 InCoder-32B의 자산을 재사용하므로, 두 집합이 겹치는지 여부가 중요해진다. 논문은 이 관계를 다루지 않는다.
다만 결과를 먼저 보면 단순한 자기 벤치마크 편향으로 설명되지는 않는다. 6절에서 보듯 이 모델은 자신이 만든 세 벤치마크 중 어느 것에서도 공개 모델 1위가 아니다. 편향이 있었다면 나타났을 방향과 반대다.
5. 일반 코드: 추론은 크게 오르고 간결함은 내린다
논문의 일반 코드 결과에서 가장 뚜렷한 것은 코드 추론 항목의 도약이다. LiveCodeBench V5에서 81.3을 기록해 표에 실린 공개 가중치 모델 중 가장 높고, 한 자릿수 배 더 큰 모델들도 넘어선다. CruxEval Output-COT는 95.5다. 논문 §3.3, Table 2
이 값들을 같은 계보의 instruct 판본과 나란히 놓으면 성격이 분명해진다. 아래는 Tables 1–3의 지표 열 23개를 모두 옮긴 것이다.
| 지표 | InCoder-32B | InCoder-32B-Thinking | 차이 |
|---|---|---|---|
| LiveCodeBench V5 | 53.3 | 81.3 | +28.0 |
| LiveCodeBench V6 | 49.1 | 77.1 | +28.0 |
| CruxEval Input-COT | 62.4 | 88.9 | +26.5 |
| CruxEval Output-COT | 73.9 | 95.5 | +21.6 |
\tau^2-bench Telecom |
86.8 | 95.6 | +8.8 |
| Terminal-Bench v1.0 | 35.0 | 38.8 | +3.8 |
| FullStackBench | 57.1 | 60.8 | +3.7 |
| BFCL V3 | 61.0 | 63.9 | +2.9 |
\tau^2-bench Retail |
85.1 | 86.0 | +0.9 |
| HumanEval | 94.5 | 95.1 | +0.6 |
| MBPP | 91.8 | 92.1 | +0.3 |
| HumanEval+ | 89.6 | 89.6 | 0.0 |
| MBPP+ | 78.3 | 78.3 | 0.0 |
| Terminal-Bench v2.0 | 22.5 | 21.6 | −0.9 |
| BigCodeBench Hard | 31.1 | 29.1 | −2.0 |
| BigCodeBench Full | 49.8 | 47.4 | −2.4 |
| SWE-bench Verified | 74.8 | 70.4 | −4.4 |
| Mind2Web | 55.8 | 49.1 | −6.7 |
| BIRD | 55.4 | 47.9 | −7.5 |
\tau^2-bench Airline |
70.0 | 62.0 | −8.0 |
| Mercury Beyond@1 | 71.4 | 62.4 | −9.0 |
| Mercury Pass@1 | 85.6 | 73.4 | −12.2 |
| Spider | 79.7 | 66.7 | −13.0 |
일반 계열 23개 지표 열 전체로 보면 11개가 오르고 10개가 내리며 2개가 같다. 논문은 이 절충을 인정하되 범위를 좁게 잡는다. "간결한 응답을 선호하는 벤치마크에서 중간 정도의 절충이 나타나며(예: Mercury, Text2SQL) 이는 다른 사고 증강 시스템에도 공통된 양상"이라는 서술이다. Mercury와 Text2SQL은 실제로 그 설명에 들어맞지만, Mind2Web −6.7과 \tau^2-bench Airline −8.0, SWE-bench Verified −4.4는 간결성으로 설명되는 항목이 아니다.
SWE-bench Verified는 따로 볼 필요가 있다. §1은 "instruct 판본과 비교해 SWE-bench Verified에서 대등한 성능"이라고 적지만 74.8에서 70.4로 4.4점 내려간 값이고, instruct 판본은 같은 열에서 표에 실린 모든 공개 모델 중 가장 높다. 즉 이 열에서는 사고 학습이 자기 계보의 최고 기록을 깎았다.
같은 문장에 다른 문제도 있다. §1은 "LiveCodeBench에서 28.0% 향상"이라고 쓰는데, 53.3에서 81.3으로의 변화는 28.0점이고 상대 변화로는 약 52.5%다. 이어지는 "코드 데이터에 대한 계속 사전학습의 효과를 보여준다"는 설명도 이 논문의 기여인 사고 데이터 학습이 아니라 다른 단계를 가리킨다. 논문 §1
LiveCodeBench 자체도 판본에 따라 순위가 달라진다. V5에서는 81.3으로 표 안 최고지만, V6에서는 77.1로 GLM-4.7의 84.9, DeepSeek-V3.2의 83.3, Kimi-K2-Thinking의 83.1에 이어 네 번째다. 초록과 결론이 V5만 인용하는 이유를 표가 설명해 준다.
한 가지 주의할 점은 기준 모델 값 자체의 신뢰도다. Table 1에서 Qwen2.5-Coder-14B-Instruct의 HumanEval 62.8은 같은 계열 7B의 87.2보다 크게 낮고, Table 2에서 Qwen3-235B-A22B-Thinking-2507의 CruxEval Input-COT 15.2, KAT-Dev-72B-Exp의 LiveCodeBench V5 13.8도 모델 규모와 어긋난다. 논문은 이 값들을 그대로 싣고 따로 언급하지 않는다. "공개 가중치 모델 중 최고"라는 비교는 이런 항목들이 정상적으로 평가되었다는 전제 위에 있다.
6. 산업용 코드: "모든 도메인 최고"는 어디까지 성립하는가
6.1 결과 절의 서술과 초록의 서술이 다르다
결과 절 안에서도 문장의 성격이 갈린다. 개별 순위를 짚는 대목은 정확하다. "CAD-Coder와 SuperCoder에서는 독점 모델 Claude-Sonnet-4.6도 넘어서며, 그 밖에 VeriScope·VeriRepair·KernelBench에서 경쟁력을 유지한다"는 표와 맞는다. "RealBench 모듈 단위에서 공개 가중치 최고 점수를 큰 차이로 달성한다"도 자기 계보 밖의 모델과 견주면 맞다. 다만 모듈 네 열 가운데 Syn@5와 Func@5는 같은 공개 모델인 InCoder-32B가 더 높고, 앞서는 두 열의 차이도 +0.8과 +0.4다.
같은 절의 나머지 두 문장은 그보다 넓다. 절을 여는 "사고 학습의 이득이 산업 코딩 시나리오로 효과적으로 전이된다"와 절을 닫는 "개선이 칩 설계·GPU 프로그래밍·3D 모델링·임베디드 시스템에 걸쳐 나타난다"가 그렇다. 아래 6.3절에서 보듯 GPU와 3D는 오른 열과 내린 열이 섞여 있다. 초록의 "모든 도메인에서 최상위 공개 결과", §1의 "평가한 모든 도메인에서 가장 강한 공개 결과", 결론의 "칩 설계, GPU 최적화, 임베디드 시스템, 3D 모델링에서 가장 강한 공개 결과"는 그 두 문장을 더 밀고 나간 형태다. 논문 §3.3
| 산업 벤치마크 | 대표 지표 | InCoder-32B-Thinking | 더 높은 공개 모델 |
|---|---|---|---|
| RealBench (모듈) | Syn@1 | 75.6 | 없음 (단 Syn@5·Func@5는 InCoder-32B가 더 높다) |
| CAD-Coder | Comp. | 84.0 | 없음 |
| SuperCoder | Acc. | 93.0 | 없음 |
| KernelBench | L2 | 38.0 | 없음 |
| VeriScope | Score | 75.4 | GLM-5 83.2, Kimi-K2-Instruct 82.4, GPT-OSS-120B 82.2, GLM-4.7 81.2, Qwen3-Coder-480B 80.8, InCoder-32B 80.7, DeepSeek-V3.2 76.1 |
| VeriRepair | Fix | 83.3 | GLM-5 90.0, GPT-OSS-20B 86.7, Qwen3.5-397B 86.7 |
| ArchXBench | t |
46.7 | GPT-OSS-120B 54.8, DeepSeek-V3.2 53.9, Qwen3.5-397B 53.5, GPT-OSS-20B 53.5, GLM-5 53.2, GLM-4.7 51.4, InCoder-32B 51.0, Kimi-K2.5 49.7, Qwen3.5-27B 48.3 |
| EmbedCGen | Main | 47.9 | GLM-5 90.2, GLM-4.7 89.6, DeepSeek-V3.2 84.4, Kimi-K2.5 81.0, Kimi-K2-Instruct 69.6 |
| TritonBench | G-call | 15.2 | Qwen3-Coder-480B 20.1, DeepSeek-V3.2 19.6, InCoder-32B 18.5, Kimi-K2-Thinking 17.4, Kimi-K2-Instruct 15.8 |
임베디드 시스템 항목이 특히 분명하다. 이 도메인을 담당하는 벤치마크는 EmbedCGen이고, 표에서 이 모델은 47.9로 GLM-5의 90.2에 크게 못 미친다. 결론이 임베디드 시스템을 "가장 강한 공개 결과"에 포함시킨 근거는 표 어디에도 없다.
6.2 EmbedCGen 값이 세 곳에서 일치하지 않는다
이 항목에는 별도의 문제가 있다. Table 5는 47.9로 적지만 Figure 2의 막대 라벨은 51.0이다. Figure 7의 EmbedCGen 곡선을 축 눈금에 맞춰 읽으면 세 체크포인트가 43.6·47.9·51.0이므로, 도판 두 개는 최종값을 51.0으로 말하고 주 결과 표의 47.9는 한 단계 앞인 360M 지점의 값과 일치한다. 표에 중간 체크포인트 값이 실렸을 가능성을 시사하지만, 어느 쪽이든 최종 모델의 EmbedCGen 점수가 논문 안에서 하나로 정해져 있지 않다.
6.3 자기 instruct 판본과의 대조
산업 계열 22개 지표 열을 instruct 판본과 비교하면 11개가 오르고 10개가 내리며 1개가 같다. 일반 계열의 11승 10패 2무와 거의 같은 분포다. 아래는 Tables 4–5의 지표 열을 모두 옮긴 것이며, 배속만 점수 차이로 표현할 수 없어 마지막에 두었다.
| 지표 | InCoder-32B | InCoder-32B-Thinking | 차이 |
|---|---|---|---|
| EmbedCGen Main | 35.2 | 47.9 | +12.7 |
| TritonBench T-call | 19.3 | 22.9 | +3.6 |
| VeriRepair Fix | 80.0 | 83.3 | +3.3 |
| RealBench System Syn@1 | 10.0 | 12.3 | +2.3 |
| CAD-Coder Comp. | 82.0 | 84.0 | +2.0 |
| SuperCoder Acc. | 91.0 | 93.0 | +2.0 |
| KernelBench L2 | 36.0 | 38.0 | +2.0 |
| RealBench System Syn@5 | 23.7 | 24.53 | +0.83 |
| RealBench Module Syn@1 | 74.8 | 75.6 | +0.8 |
| RealBench Module Func@1 | 62.7 | 63.1 | +0.4 |
| TritonBench G-exe | 100.0 | 100.0 | 0.0 |
ArchXBench n |
3.4 | 3.12 | −0.28 |
| RealBench Module Func@5 | 70.5 | 69.8 | −0.7 |
| RealBench Module Syn@5 | 83.3 | 82.4 | −0.9 |
| KernelBench L1 | 22.2 | 20.2 | −2.0 |
| KernelBench L3 | 14.0 | 12.0 | −2.0 |
| TritonBench G-call | 18.5 | 15.2 | −3.3 |
| TritonBench T-exe | 93.8 | 89.5 | −4.3 |
ArchXBench t |
51.0 | 46.7 | −4.3 |
| CAD-Coder IoU | 53.5 | 48.6 | −4.9 |
| VeriScope Score | 80.7 | 75.4 | −5.3 |
| SuperCoder Spd. | 1.3× | 3.93× | 비율 지표 |
CAD-Coder를 예로 들면 컴파일 통과율은 82.0에서 84.0으로 오르지만 기하 충실도인 IoU는 53.5에서 48.6으로 내린다. 실행되는 스크립트는 늘고 만들어진 형상이 정답에 겹치는 정도는 줄었다는 뜻이다. KernelBench도 L2는 오르고 L1과 L3는 내린다. "사고 학습의 이득이 산업 시나리오로 효과적으로 전이된다"는 서술은 이런 혼재를 요약하기에는 넓다.
가장 큰 이득인 EmbedCGen +12.7이 이 논문이 직접 만든 벤치마크에서 나왔다는 점, 그리고 그 값 자체가 6.2절의 불일치 대상이라는 점도 함께 보아야 한다.
7. ICWM의 충실도는 어디서 측정되었는가
원논문 Figure 5. 보라색은 턴 단위 라벨 일치, 갈색은 다중 턴 궤적의 최종 판정 일치다. 세로축이 91%에서 시작하므로 막대 길이의 시각적 차이는 실제 점수 차이보다 크게 보인다. Yang et al. (2026), PDF p. 10. 원본 도판 영역 직접 추출.
| 도메인 | 결과 예측 정확도 | 궤적 일치도 | 차이 |
|---|---|---|---|
| GPU 커널 | 96.8 | 94.3 | 2.5 |
| 칩 설계 | 97.4 | 95.8 | 1.6 |
| 3D 모델링 | 95.9 | 93.1 | 2.8 |
| 코드 최적화 | 97.1 | 95.2 | 1.9 |
| 임베디드 시스템 | 96.2 | 93.7 | 2.5 |
| 평균 | 96.7 | 94.4 | — |
칩 설계가 가장 높은 이유를 논문은 Yosys와 Icarus의 진단이 구조적으로 정형화되어 있어 월드 모델이 안정적으로 학습한다는 점에서 찾는다. 3D 모델링이 가장 낮은 이유는 CadQuery 기하 검사가 부동소수점 허용오차와 암묵적 불리언 연산을 포함해 코드 텍스트만으로는 결과를 예측하기 어렵기 때문이다. 결과 정확도에서 궤적 일치도로 갈 때 생기는 1.6~2.8점의 하락은 한 턴의 오예측이 이후 수정 경로를 갈라 놓으며 누적되는 현상으로 설명된다.
논문이 직접 든 두 사례가 이 구분을 잘 보여준다. 융합 어텐션 Triton 커널이 tl.zeros([BLOCK_M, BLOCK_N]) 타일을 공유 메모리에 잡은 채 num_warps=8로 실행해 SM의 48 KB 예산을 넘겼을 때 ICWM은 실제 컴파일러와 같은 MEMORY_FAULT 라벨과 수치까지 맞는 진단을 냈고, 다음 턴에서 BLOCK_N을 128에서 64로 줄인 수정에 대해 PASS를 정확히 예측했다. 반대로 CadQuery 스크립트가 원통 축을 면에 정확히 접하게 두어 두께 0인 퇴화 간선을 만든 경우, 실제 백엔드는 GEOMETRY_ERROR를 냈지만 ICWM은 코드가 문법적으로 유효하고 치수가 그럴듯하다는 이유로 PASS로 분류했다. 논문 §4.1
측정 설계를 정확히 구분할 필요가 있다. 두 축 가운데 궤적 일치도는 턴 단위 정확도가 아니다. ICWM이 루프를 구동해 끝까지 굴린 뒤 최종 판정을 실제 실행 결과와 맞춰 보는 폐루프 측정이고, 결과 정확도와의 1.6~2.8점 격차를 논문은 오예측의 누적으로 설명한다. 즉 "합성 루프에서 경로가 갈라지는가"라는 질문 자체는 이 실험이 다룬다.
남는 질문은 범위다. 이 수치는 \mathcal D_{\mathrm{real}}에서 보류한 턴, 곧 실제 실행으로 이미 궤적을 만들어 본 과제 씨앗 위에서 측정된다. 대규모 합성이 그 씨앗 분포를 넘어서는 만큼 같은 충실도가 유지되는지는 별도 문제로 남고, \mathcal D_{\mathrm{icwm}}이 어떤 과제를 얼마나 덮었는지는 제시되지 않는다. 3D 모델링의 거짓 양성은 이 구간에서 특히 곤란한 유형이다. 잘못된 PASS는 생성기에게 "고칠 것이 없다"고 알려 궤적을 거기서 끝내므로, 틀린 코드에 성공 라벨이 붙은 학습 예제가 만들어진다.
더 중요한 공백은 따로 있다. ICWM의 가치는 결국 그것으로 증폭한 데이터가 최종 모델을 얼마나 개선했는지로 판정되어야 하는데, 논문에는 \mathcal D_{\mathrm{real}}만으로 학습한 모델과 \mathcal D_{\mathrm{real}} \cup \mathcal D_{\mathrm{icwm}}로 학습한 모델을 비교한 실험이 없다. 두 집합의 크기 비율도 제시되지 않는다. 월드 모델이 논문의 두 번째 기여인데, 그 기여의 크기는 대리 지표인 예측 충실도로만 제시된다.
8. 사고 길이와 데이터 규모
8.1 209배의 폭은 설계된 것이 아니다
원논문 Figure 6. T는 사고 길이 중앙값, A는 답변 길이 중앙값이고 음영은 사분위 범위다. 보라색이 산업 범주다. 표지 Figure 1은 같은 여섯 범주에 대해 THINK와 ANSWER 길이를 싣는데, 답변 길이는 여섯 범주 모두에서 다르고 어느 통계량인지는 밝히지 않는다. Yang et al. (2026), PDF p. 11. 원본 도판 영역 직접 추출.
사고 길이 중앙값은 에이전트 코딩의 91자에서 GPU 커널 최적화의 19,015자까지 209배 범위에 걸친다. 논문의 설명은 이 분포가 손으로 설계된 것이 아니라 오류 주도 합성에서 자연히 생긴다는 것이다. 복잡한 실행 피드백이 오가는 과제는 수정 라운드를 거치며 긴 추론을 쌓고, 오류가 자명한 과제는 짧게 끝난다. 논문 §4.2
범주별 양상도 백엔드 성격을 따라간다. GPU 커널은 매 수정마다 그리드·블록 구성과 공유 메모리 배치와 워프 스케줄링을 진단해야 해서 가장 깊고, 칩 설계는 반대 모양이다. Yosys/Icarus 피드백이 구조적으로 간결해 사고는 1.5K로 짧은 대신 RTL 답변이 6.9K로 길다. 에이전트 코딩은 추론이 수십 턴에 분산되고 각 단계가 다음 행동 하나만 정하므로 단계당 91자로 가장 짧다.
여기서 표지 도판과의 불일치를 기록해 둘 필요가 있다. Figure 1은 같은 여섯 범주에 대해 GPU 최적화 19,015/19,485, 경쟁 프로그래밍 11,075/9,672, 칩 설계 1,546/3,213, 3D 모델링 1,458/813, 도구 사용 1,170/548, 에이전트 코딩 105/130을 싣는다. Figure 6의 값은 각각 19.0K/11.5K, 8.1K/1.1K, 1.5K/6.9K, 1.5K/529, 897/270, 91/189이다. 사고 길이는 세 범주에서 반올림 범위 안에 들지만 답변 길이는 여섯 범주 모두 다르다. 본문 §4.2의 서술은 Figure 6을 따른다.
8.2 데이터를 세 배로 늘렸을 때
원논문 Figure 7. 각 패널은 180M·360M·540M 토큰 체크포인트의 지표를 잇는다. EmbedCGen 패널의 세 지점은 43.6·47.9·51.0으로, 540M은 Figure 2의 라벨 51.0과 같고 Table 5의 47.9는 한 단계 앞인 360M 지점의 값과 일치한다. 점이 세 개뿐이고 반복 실행이 없으므로 곡선의 기울기를 추세로 읽을 때는 주의가 필요하다. Yang et al. (2026), PDF p. 12. 원본 도판 영역 직접 추출.
논문은 사고 학습 데이터로 540M 토큰을 모았고 이는 InCoder-32B의 250M보다 크다. 세 체크포인트를 비교해 "대부분의 지표가 데이터가 늘수록 꾸준히 개선된다"고 정리하며, VeriScope가 61.8에서 75.4로, KernelBench L2가 16.0에서 38.0으로 오른 것을 예로 든다. 논문 §4.3
곡선의 모양은 그보다 갈린다. VeriScope와 KernelBench L1·L2는 180M에서 360M 사이에 거의 모든 이득을 내고 그다음 배증에서는 거의 움직이지 않는다. 반대로 VeriRepair와 SuperCoder 정확도는 두 번째 배증에서 더 크게 오른다. TritonBench의 G-call은 세 지점 내내 평평하고, KernelBench L3는 12.0에 머문다. "꾸준한 개선"이라는 하나의 서술로는 이 세 가지 모양을 함께 담기 어렵다.
TritonBench 해석은 따로 구분해야 한다. 논문은 "GPU 실행 정확도가 세 단계 내내 완벽한 100을 유지한다"는 것을 "사고 능력이 기본 실행 과제를 빠르게 익히게 한다"는 근거로 든다. 그러나 같은 표에서 G-call은 15.2%다. 출력이 정답과 맞으려면 먼저 실행이 되어야 하므로, G-exe가 전체 생성물에 대한 비율이라면 G-call을 넘을 수 없다. 100%와 15.2%가 함께 성립하려면 G-exe의 분모가 호출에 성공한 생성물이어야 한다. Appendix A.2.2가 실행 정확도를 "출력이 참조 구현과 더 나아가 일치하는지"로 적은 것도 같은 방향이다. 즉 100%는 15.2%라는 작은 분모 위의 값이고, 그 분모는 세 체크포인트 내내 개선되지 않았으며 instruct 판본의 18.5%보다도 낮다.
9. 한계, 재현 조건과 결론
9.1 논문이 밝힌 한계
- 간결한 응답을 선호하는 벤치마크(Mercury, Text2SQL)에서 절충이 나타나며, 이는 사고 증강 시스템에 공통된 양상이다. 논문 §3.3
- 3D 모델링은 부동소수점 허용오차와 암묵적 불리언 연산 때문에 코드 텍스트만으로 결과를 예측하기 어렵고, ICWM 충실도 격차가 가장 크다. 논문 §4.1
- 결과 정확도와 궤적 일치도 사이의 하락은 한 턴의 오예측이 이후 경로로 누적되기 때문이다.
- KernelBench L3가 12.0에 머무는 것은 가장 어려운 최적화 문제가 데이터 양이 아니라 별도 전략을 요구한다는 뜻이다. 논문 §4.3
9.2 해설자 관점
요약 문장이 순위 문장보다 넓다. 개별 순위를 짚는 대목은 표와 맞는다. 넓어지는 것은 그것을 일반화하는 문장들이다. §3.3의 "산업 코딩 시나리오로 효과적으로 전이된다"와 "개선이 네 도메인에 걸쳐 나타난다"에서 시작해, 초록의 "모든 도메인에서 최상위 공개 결과", §1의 "평가한 모든 도메인에서 가장 강한 공개 결과", 결론의 임베디드 시스템 포함으로 이어진다. 22개 산업 지표 열 중 공개 모델 1위는 다섯 개이고, EmbedCGen에서는 GLM-5와 42점 넘게 벌어진다.
사고 학습의 순효과는 도메인이 아니라 과제 유형으로 갈린다. instruct 판본과의 열 단위 대조에서 일반은 11승 10패 2무, 산업은 11승 10패 1무다. 큰 이득은 코드 추론(CruxEval, LiveCodeBench)에 몰려 있고 손실은 효율·SQL·웹 조작·SWE-bench에 퍼져 있다. "산업 시나리오로 효과적으로 전이된다"는 서술보다는 "추론 집약 과제에서 크게 얻고 나머지에서 조금씩 잃는다"가 표에 가깝다.
핵심 기여인 ICWM의 다운스트림 효과가 측정되지 않았다. \mathcal D_{\mathrm{real}} 단독 학습과 \mathcal D_{\mathrm{real}} \cup \mathcal D_{\mathrm{icwm}} 학습을 비교한 실험이 없고, 두 집합의 크기 비율도 없다. ECoT와 교사-학생 증류의 기여도 분리되지 않는다. 충실도 실험은 루프가 갈라지는 정도까지 측정하지만, 그 측정이 놓인 과제 씨앗은 이미 실제 실행을 거친 것들이다. 대규모 합성이 그 범위를 넘어설 때도 같은 수치가 유지되는지는 확인되지 않았다.
세 곳의 수치가 서로 다르다. EmbedCGen 최종 점수는 Table 5에서 47.9, Figure 2에서 51.0, Figure 7의 540M 지점에서 51.0이다. Figure 7의 RealBench Func@1(모듈) 540M 지점도 Table 4의 63.1보다 10점 가까이 낮은 위치에 찍힌다. 표지 Figure 1과 분석용 Figure 6은 같은 사고·답변 길이에 대해 여섯 범주 모두에서 다른 답변 길이를 싣는다.
단위와 귀속의 오기가 있다. §1의 "LiveCodeBench 28.0% 향상"은 28.0점이고 상대 변화로는 약 52.5%다. 같은 문장이 그 향상을 "계속 사전학습의 효과"로 돌리는데, 이 논문의 기여는 사고 데이터 학습이다. 참고문헌 [80]과 [81]은 같은 InCoder-32B 논문(arXiv:2603.16790)의 중복 항목이며 본문이 두 번호를 섞어 인용한다. 이런 중복은 고립된 사례가 아니라 적어도 여덟 쌍에 이른다. \tau^2-bench, DeepSeek-R1, CAD-Coder, TritonBench, VerilogEval, KernelBench, SuperCoder, InCoder-32B가 각각 두 번호를 갖는다.
기준 모델 값 일부가 규모와 어긋난다. Qwen2.5-Coder-14B의 HumanEval 62.8이 같은 계열 7B의 87.2보다 낮고, Qwen3-235B-Thinking의 CruxEval Input-COT 15.2, KAT-Dev-72B-Exp의 LiveCodeBench V5 13.8도 마찬가지다. "공개 가중치 중 최고"라는 비교는 이런 항목이 정상 평가되었다는 전제에 기대고 있는데, 논문은 이를 언급하지 않는다.
9.3 공개된 것과 확인하지 못한 것
2026년 9월 12일 조회 기준으로 GitHub 저장소 CSJianYang/Industrial-Coder는 공개되어 있으나 최상위에 README.md와 sft 디렉터리만 있고, 라이선스 파일이 없으며, 마지막 푸시가 2026년 3월 27일로 논문 공개일보다 앞선다. ECoT 합성 파이프라인, ICWM 학습·추론 코드, 두 데이터셋, 평가 하네스는 확인하지 못했다.
가중치 쪽은 두 저장소가 있다. 논문 첫 쪽이 적은 주소는 Multilingual-Multimodal-NLP/IndustrialCoder로 사고 기능이 없는 판본이고, 사고 판본은 IndustrialCoder-Thinking에 따로 있다. 둘 다 Apache-2.0이며, 두 저장소 모두 메타데이터에 이 논문이 아니라 선행 InCoder-32B 논문(arXiv:2603.16790)을 연결하고 있다.
재현에 필요한 정보 중 논문에 없는 것은 다음과 같다. 학습 하이퍼파라미터, 초기화 방식, 문맥 길이, 컴퓨트 예산, \mathcal D_{\mathrm{real}}과 \mathcal D_{\mathrm{icwm}}의 크기와 비율, ICWM의 크기와 기반 모델, 주기적 감사의 표본 비율과 주기, 그리고 디코딩 설정이다. 논문에는 학습 절이 따로 없고 부록도 벤치마크 설명만 담고 있다. 다만 두 항목은 제시되어 있다. 기반 모델은 §5.1이 InCoder-32B의 사고 변형이라고 밝히고, 시도 횟수는 RealBench가 과제당 20개 표본, ArchXBench가 과제당 5개 후보로 부록에 적혀 있다.
9.4 적용을 검토할 때 확인할 것
| 설계 질문 | 확인할 대상 |
|---|---|
| 어떤 과제에서 이득을 기대하는가? | 추론 집약 과제와 간결성·도구 조작 과제의 방향이 반대다 |
| 자기 계보의 비사고 판본과 비교했는가? | 22개 산업 지표 중 10개는 instruct 판본이 더 높다 |
| 대리 환경을 어디까지 믿을 것인가? | 보류 집합 96.7%는 분포 안의 값이며, 거짓 PASS는 틀린 코드에 성공 라벨을 붙인다 |
| 어떤 지표가 조건부인가? | TritonBench G-exe 100%는 G-call 15.2%를 분모로 한다 |
| 벤치마크의 출처는 어디인가? | 산업 9개 중 셋은 이 논문이 도입했고 VeriRepair에는 학습 분할이 있다 |
| 데이터를 더 넣으면 오르는가? | 벤치마크마다 곡선 모양이 다르고 평평한 지표가 있다 |
9.5 결론
이 논문의 값어치는 모델 점수보다 데이터 경로에 있다. 산업용 코드의 추론 기록이 없다는 진단은 정확하고, 그것을 사람에게서 수집하는 대신 실제 툴체인 실행의 실패와 수정에서 만들어 내는 발상은 구체적이며 재사용할 만하다. 실패 턴을 버리지 않고 남긴다는 결정, 도메인별 프롬프트 라우터, 그리고 사고 길이 분포가 프롬프트 템플릿이 아니라 백엔드 성격에서 나온다는 관찰은 이 경로가 실제로 작동했다는 증거다.
동시에 이 논문이 확인한 것과 주장한 것 사이에는 간격이 있다. 확인된 것은 사고 학습이 코드 추론 벤치마크를 크게 올리고, 다섯 개 산업 지표에서 공개 모델 최고를 만들며, 학습된 대리 환경이 자기 분포 안에서 96.7%의 라벨 일치를 보인다는 것이다. 확인되지 않은 것은 ICWM과 ECoT 각각의 기여, 씨앗 분포 밖에서의 대리 환경 신뢰도, 그리고 "모든 도메인 최고"라는 요약이다. 그 요약을 걷어내면 남는 것은 결과 절이 개별 벤치마크를 짚어 써 둔 문장들이고, 그 문장들은 표와 맞는다.
원논문 Figures 2–7을 도판 영역만 추출해 인용하고 한국어 해설을 덧붙였다. 원본 그래프·축·범례·수치는 유지했다. 이 글은 v1의 원문 검토이며, 모델을 새로 실행하거나 벤치마크를 재현한 것은 아니다.
References
Baronio, C., Marsella, P., Pan, B., Guo, S., & Alberti, S. (2025). Kevin: Multi-turn RL for generating CUDA kernels (arXiv:2507.11948). arXiv. arXiv 논문
Copet, J., Carbonneaux, Q., Cohen, G., Gehring, J., Kahn, J., Kossen, J., Kreuk, F., McMilin, E., Meyer, M., & Wei, Y. (2025). CWM: An open-weights LLM for research on code generation with world models (arXiv:2510.02387). arXiv. arXiv 논문
DeepSeek-AI. (2025). DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning (arXiv:2501.12948). arXiv. arXiv 논문
Gu, A., Rozière, B., Leather, H., Solar-Lezama, A., Synnaeve, G., & Wang, S. I. (2024). CRUXEval: A benchmark for code reasoning, understanding and execution (arXiv:2401.03065). arXiv. arXiv 논문
Jain, N., Han, K., Gu, A., Li, W.-D., Yan, F., Zhang, T., Wang, S., Solar-Lezama, A., Sen, K., & Stoica, I. (2024). LiveCodeBench: Holistic and contamination free evaluation of large language models for code (arXiv:2403.07974). arXiv. arXiv 논문
Ouyang, A., Guo, S., Arora, S., Zhang, A. L., Hu, W., Ré, C., & Mirhoseini, A. (2025). KernelBench: Can LLMs write efficient GPU kernels? (arXiv:2502.10517). arXiv. arXiv 논문
Yang, J., Zhang, W., Wu, J., Cheng, J., Guo, S., Wang, H., Gu, W., Du, Y., Li, J., Xu, F., Li, Y., Jing, L., Wang, Y., Gao, Y., Gong, R., Hao, C., Tao, R., Liu, A., Zheng, T., … Lv, W. (2026). InCoder-32B: Code foundation model for industrial scenarios (arXiv:2603.16790). arXiv. arXiv 논문
Yang, J., Zhang, W., Wu, J., Cheng, J., Zheng, T., Xu, F., Gu, W., Jing, L., Du, Y., Li, J., Li, Y., Xing, Y., Hao, C., Tao, R., Gong, R., Liu, A., Li, Z., Tang, M., Lin, C., … Lv, W. (2026). InCoder-32B-Thinking: Industrial code world model for thinking (arXiv:2604.03144v1). arXiv. arXiv 논문