AesCode-8B vs MathForm-8B: 둘 다 기계가 출력을 검증할 수 있는 8B 파인튜닝

AesCode-8B와 MathForm-8B는 서로 8주 안에 등장했고, 둘 다 보도자료가 아니라 저장소에서 나왔습니다. 그리고 그 우연은 언뜻 보이는 것보다 훨씬 흥미롭습니다. 둘 다 Qwen3 계열 체크포인트에서 출발합니다. 둘 다 전체 학습 예산을 좁은 출력 형태 하나에 쏟아붓습니다. 그리고 둘 다 검사기를 중심으로 만들어졌습니다. MathForm-8B는 Lean 4 컴파일러의 판정에 맞춰 학습되고, AesCode-8B는 각 후보 페이지를 샌드박스 브라우저에서 렌더링한 뒤 DOM과 계산된 스타일, 스크린샷을 읽어내는 방식으로 평가됩니다. 어느 쪽도 챗봇이 아니고, 챗봇이 되려 하지도 않습니다. 이 둘을 구분 짓는 것은 기계가 검증할 수 있는 것과 그렇지 않은 것입니다. 그리고 둘 중 더 최근 것의 경우에는, 점수의 절반이 아무도 이름을 밝히지 않은 심판에게서 나올 때 무슨 일이 벌어지는가입니다.

공개 기록은 대칭적이지 않습니다. MathForm-8B는 OpenBMB에서 나왔으며 모델 카드에는 출시일이 2026-08-14로 기재되어 있습니다. 이 모델은 Qwen3-8B를 기반으로 구축되었고, 약 367,000개의 검증된 Lean 4 예제로 구성된 코퍼스인 FormalVerse로 학습되었으며, 지도 미세 조정 후 Lean 컴파일과 의미 일관성 검사를 보상 신호로 사용하는 강화 학습이 이어졌습니다. AesCode-8B는 파일 어디에도 출시일이 없습니다. Microsoft는 2026-09-29에 Hugging Face 저장소를 만들었고, 2026-10-07 03:35 UTC에 "Release AesCode-8B"라는 메시지와 함께 가중치를 커밋했으며, 2026-10-08에 GitHub에 학습 코드를 공개했습니다. 두 사건 모두 어떤 발표도 동반되지 않았고, 모델 카드의 인용은 "Under review, 2027"이라고 적혀 있으며, 이 글을 쓰는 시점에 저장소는 다운로드 두 건을 보여주었습니다. 이 모델은 Qwen3-VL-8B-Instruct에서 미세 조정되었는데, 이는 MathForm-8B의 조상과 동일하지 않다는 점 때문에 정확히 주목할 가치가 있습니다.

혈통이 그 분열의 대부분을 설명한다

Qwen3-8B와 Qwen3-VL-8B-Instruct는 세대와 패밀리 이름을 공유하지만 하는 일은 다릅니다. Qwen3-8B는 텍스트 전용 범용 모델로, 총 파라미터가 약 82억 개이고 그중 약 70억 개가 비임베딩 파라미터이며, 그룹화된 쿼리 어텐션을 사용하고, 32K 토큰 네이티브 컨텍스트를 YaRN을 통해 131K까지 확장할 수 있으며, 119개 언어와 방언에 걸쳐 학습되었습니다. Qwen3-VL-8B-Instruct는 비전-언어 형제 모델이며, AesCode-8B가 출발점으로 삼는 체크포인트입니다. 공개된 AesCode 구성은 36개의 히든 레이어, 히든 크기 4,096, 8개의 키-값 헤드를 가진 32개의 어텐션 헤드, 그리고 151,936개 토큰 어휘를 갖춘, Qwen3-VL 레시피를 그대로 따른 것입니다.

그 분기는 두 전문가 중 어느 하나가 훈련되기 전에 두 전문가의 입력 측을 결정한다. MathForm-8B는 텍스트를 입력받아 형식 구문으로 텍스트를 출력한다. AesCode-8B는 텍스트와 선택적 참조 이미지를 입력으로 받아 문서를 출력한다.

• Base — MathForm-8B: Qwen3-8B, 텍스트 전용. AesCode-8B: Qwen3-VL-8B-Instruct, 이미지와 텍스트 입력.

• 파라미터 — MathForm-8B: 약 8.2B. AesCode-8B: bf16 기준 4개 샤드에 걸쳐 약 8.8B이며, Hugging Face에서는 이를 9B로 반올림합니다.

• 학습 데이터 — MathForm-8B: FormalVerse, 약 367K개의 검증된 Lean 4 예제. AesCode-8B: 3,000개의 콜드 스타트 시연 후, 7,408개 프롬프트에 대해 GDPO 강화 학습을 400스텝 수행.

• 출력을 검사하는 것은 무엇인가 — MathForm-8B: Lean 4 컴파일러, 그리고 원래 문제에 대한 의미적 일관성 검사. AesCode-8B: 6개의 결정론적 검증기와 1개의 모델 채점 루브릭을 갖춘 샌드박스형 Playwright 렌더.

• 라이선스 — 둘 다 Apache 2.0이고, 둘 다 게이팅 없이 공개되며, 둘 다 Qwen3 패밀리 백본을 계승합니다.

• 어디서나 호스팅됨 — 우리가 확인할 수 있는 한, 어느 쪽도 아닙니다.

"verifiable"의 두 가지 다른 의미

이것은 서두르지 않고 짚고 넘어갈 가치가 있는 구분이다. 왜냐하면 "기계 검증 가능"은 둘 모두에 쓰이지만 같은 뜻은 아니기 때문이다.

MathForm-8B의 검사기는 증명 보조기이다. Lean 4는 어떤 진술을 받아들이거나 받아들이지 않으며, 그 판정은 의견이나 평가 기준, 심사자의 취향의 문제가 아니다. 학습 루프는 그 신호를 겨냥한다: FormalVerse에서의 SFT 단계는 비형식 문제에서 imports 헤더와 명명된 정리를 갖춘 형식적 정리 진술로의 매핑을 가르치고, RL 단계는 컴파일과 함께 형식화가 원래 문제가 말한 내용을 여전히 말하고 있는지 묻는 일관성 검사를 사용해 이를 벼린다. 컴파일은 이진적이며 동일한 Lean 버전을 가진 누구나 재현할 수 있다. 일관성 검사는 덜 엄격한 절반이며, 보고된 수치가 약해지는 바로 그 절반이다 — 이것이 바로 발표된 결과가 보여주는 바이다.

AesCode-8B의 검사기는 렌더러다. 후보들은 외부 요청이 차단된 샌드박스형 Playwright 브라우저에서 렌더링되며, 하네스는 DOM, 계산된 스타일, 바운딩 박스, 콘솔 상태, 스크린샷을 다시 읽어 온다. 여섯 개의 결정적 채널이 파싱 가능한 것들 — 실행, 정확한 텍스트, 경계 동작, 표 및 차트 데이터, 의미론적 레이아웃, 공백 — 을 채점하고, 일곱 번째인 Visual Graph Rubric이 그래프에 묶인 예/아니오 질문을 통해 기하와 배치를 채점한다. 표는 실제 HTML 표여야 하고 차트는 ECharts 명세여야 하는데, 이는 실제로 역할을 하는 제약이다: 검증자가 파싱할 수 있는 형태로 출력을 강제한다. 결정적 절반은 진정으로 재현 가능하다. 시각적 절반은 문서에서 그 정체를 밝히지 않은 비전-언어 모델이 판정하는데, 이는 연구소 밖의 누구도 그것을 재현할 수 없다는 뜻이다.

따라서 솔직한 비교는 "하나는 검증되고 하나는 검증되지 않는다"가 아니다. 그것은 MathForm-8B의 주 신호는 컴파일러이고 보조 신호는 일관성 검사인 반면, AesCode-8B의 주 신호는 결정론적 DOM 단언들의 집합이고 보조 신호는 모델의 의견이며, 둘 모두 동일한 전체 점수 안에 담겨 있다는 점이다.

각각이 보고하는 내용, 그리고 그것이 지닌 가치

MathForm-8B는 6개 벤치마크에서 구문 검사 기준 평균 Pass@8 88.06%, 일관성 검사 기준 72.37%를 보고합니다. 벤치마크별 편차가 흥미로운 부분입니다. FormalIMATH에서는 일관성 95.06%, ProverBench에서는 94.83%인데, 이어서 FATE-H에서는 63%, FATE-X에서는 37%입니다. 마지막 두 가지는 어렵고 현실적인 문장들이며, 90%대 중반에서 30%대 중반으로 떨어지는 것이 이 능력의 솔직한 형태입니다. 이 수치들은 모두 공급업체가 보고한 것이고 재현되지 않았으며, 벤치마크 구성은 더 쉬운 세트 쪽으로 치우쳐 있습니다.

AesCode-8B는 Microsoft의 300개 샘플 인포그래픽 평가 기준에서 Overall 82.94를 보고합니다 — Text 94.06, Boundary 88.36, Chart 87.79, Rule 90.07, Content 86.41, Layout 87.80, Style 53.21, Visual 75.80 — 프롬프트당 세 번 생성하고 선택은 하지 않은 조건에서요. Microsoft는 또한 동일한 평가 기준에서 AesCode-8B가 참조 조건화된 GPT-5.5의 81.28과 Claude Opus 4.8의 80.39를 능가한다고, 심각한 캔버스 오버플로 실패가 300개 샘플 중 4.3%에서 반복 발생한다고, 그리고 22.4 Visual 점수가 32B 컴패니언과 자체 백본을 갈라놓는다고 보고합니다. 모든 수치는 벤더의 것이며, 벤더의 과제에서, 벤더가 설계한 채널을 기준으로 채점된 것입니다.

이 두 숫자 집합은 서로 전혀 비교할 수 없습니다. 공유된 과제도, 공유된 지표도, 공유된 평가자도 없습니다. 88.06%를 82.94 옆에 놓는 것은 Lean 형식화 통과율을 인포그래픽 종합 점수와 비교하는 셈이며, 어느 모델도 상대 모델이 하는 일에 대해 평가받은 적이 없습니다.

하나의 비대칭성은 언급할 가치가 있다. 그것이 더 새로운 모델에 불리하게 작용하기 때문이다. MathForm-8B의 대표 지표에는 외부 심판이 내장되어 있다: 누구든 Lean을 설치하고 같은 벤치마크를 불러와 명제들이 컴파일되는지 확인할 수 있다. AesCode-8B의 대표 지표에는 그런 것이 없다—결정론적 검증기들은 마음먹은 외부인이 다시 실행할 수 있겠지만, 점수의 시각적 절반은 논문이 밝히지 않은 심사자에게 달려 있다. 재현되지 않은 컴파일러 통과율은 벤치마크 표보다 약한 주장이고, 그 안에 익명의 채점자가 들어 있는 재현되지 않은 루브릭 점수보다는 여전히 강한 주장이다.

그것들을 실행하는 것은 두 점수 중 어느 것과도 별개의 문제다

둘 다 현재로서는 자체 호스팅 결정입니다. MathForm-8B가 훨씬 더 저렴합니다: 약 8.2B 텍스트 전용 체크포인트로, 생성 예산이 대략 16K 토큰의 Lean 출력이며, 이는 중급 단일 카드에 양자화할 수 있습니다. AesCode-8B는 8.8B 비전-언어 모델로, 서빙 경로가 텍스트뿐 아니라 이미지도 처리합니다; 해당 카드 자체의 명령은 vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576이며, 17.5 GB의 bf16 가중치에 24,576 토큰과 이미지 두 개를 위한 KV 캐시까지 더하면 24 GB 카드는 빠듯하고 40-48 GB가 현실적인 최소치입니다. 자체 출력을 평가하려면 렌더링 스택도 예산에 잡아야 합니다. 왜냐하면 모델에 관한 모든 품질 주장이 그렇게 이루어졌기 때문입니다.

더 큰 숨은 비용은 두 모델 모두 여러분이 영구적으로 도입하게 되는 전문가 모델이라는 점입니다. 정형화와 문서 생성이 필요한 팀은 이제 두 개의 8B 서빙 경로, 두 세트의 프롬프트 형식, 두 가지 장애 프로파일을 운영해야 하며, 어느 모델도 다른 쪽의 작업을 흡수할 수 없습니다. 바로 이런 경우를 위해 라우팅 계층이 존재합니다. 경제성과 데이터 처리 측면에서 GPU를 직접 소유하는 것이 정당화되는 곳에는 전문가 모델을 그대로 두고, 일반 트래픽은 동일한 엔드포인트 뒤에 호스팅된 무언가로 보내는 것입니다. 구체적으로, 이 두 기반 모델의 범용 형제 모델들은 호출할 수 있습니다 — 131,072 토큰 컨텍스트에서 입력 100만 토큰당 $0.18, 출력 100만 토큰당 $0.70인 Qwen3-VL-8B-Instruct를, Qwen 3.8 패밀리 및 기타 오픈 체크포인트와 함께 — 모두 200개 이상의 모델을 아우르는 OrcaRouter의 단일 API를 통해, 제공업체 정가를 0% 마크업으로 그대로 전달하고 제공업체 간 자동 장애 조치를 지원합니다. 어느 전문가 모델도 여기서도, 우리가 찾을 수 있는 다른 어디에서도 라우팅할 수 없습니다. 라우팅할 수 있는 것은 좁은 작업이 끝났을 때 폴백하는 범용 모델이며, 이것이 연구용 체크포인트를 시험해 보는 것과 그것을 핵심 의존성으로 만드는 것의 차이입니다.

그것들 중에서 선택하는 것, 정말로 해야만 한다면

아티팩트가 컴파일되어야 할 때는 MathForm-8B를 선택하세요. 문제 은행 변환, 증명기용 형식 코퍼스, Lean 기반 도구를 위한 명제 사전 포맷팅 — 이것이 전체 업무 설명이며, 둘 중 이 작업을 위해 훈련된 것은 이것뿐입니다. 범위를 정할 때 FATE 수치를 진지하게 받아들이세요: 가장 어려운 현실적인 명제들에서는 약 3분의 1이 일관된 결과로 나오며, 어쨌든 사람 검토 단계를 구축하게 될 것입니다.

산출물을 렌더링해야 할 때는 AesCode-8B를 선택하세요. 브리프를 입력하면 편집 가능한 HTML 문서가 나오고, 표는 표로, 차트는 차트 명세로 남으며, 전체가 Git에서 diff됩니다. 스타일 상한선 — 전달 전에 더 이상의 시각적 수정이 필요하지 않은 것으로 정의되는 차원인 53.21 — 을 남은 편집량에 대한 정직한 척도로 받아들이고, 24,576토큰 컨텍스트가 사람들이 실제로 원하는 여러 슬라이드 덱이 아니라 단일 인포그래픽 페이지에서만 검증되었다는 점을 받아들이세요.

하지만 대부분의 팀이 실제로 맞닥뜨릴 선택은 이 둘 중 어느 쪽도 아니다. 그것은 이 좁은 전문가 모델 중 하나가 배포할 가치가 있는지, 아니면 그 뒤에 있는 범용 모델을 API로 호출하는 것이 여러분이 가진 물량에 충분히 근접한지다. 그것은 GPU 구매가 아니라 프롬프트 테스트로 보내는 오후이며, 두 카드 자체의 수치가 이를 돌려볼 이유를 준다: MathForm-8B의 하드셋 일관성은 37%이고, AesCode-8B의 스타일 점수는 53%이므로, 둘 다 감독 없이 파이프라인에 넣을 모델은 아니다.

두 릴리스가 알려주는, 이제 모델이 출시되는 방식

8주 간격을 두고 서로 다른 두 연구소에서 나온 8B 파인튜닝 두 건은 발표도, 제품 페이지도, 독립적 평가도 없이 공개되었으며, 둘 다 검증 루프를 중심으로 만들어졌고, 둘 다 Apache 2.0이며, 어느 쪽도 아무도 서빙하지 않는다. 그 패턴이 두 모델 각각보다 더 큰 이야기다. 연구 방법은 보상 함수 — OpenBMB의 컴파일러 신호, Microsoft의 분리된 크로스모달 채널 — 로 이동했고, 공개되는 산출물은 학습 레시피와 가중치가 되었으며, 논문은 나중에, 설령 나온다 해도, 도착한다.

이런 비교를 읽는 사람에게 이것이 뜻하는 바는, 당분간은 벤더 자체 수치가 전부라는 것이다. 그리고 유용한 질문은 그 수치가 얼마나 높은가가 아니라 얼마나 검증 가능한가이다. AesCode-8B의 오버플로율과 Style 상한은 실패로 포장된 검증 가능한 주장이다. MathForm-8B의 FATE-X 일관성 수치도 마찬가지다. 바로 그 수치들을 읽어야 하고, 검사기들이 엔드 투 엔드로 재현 가능해지는 순간 직접 돌아가 다시 실행해 봐야 할 수치들이다.