AesCode-32B: 편집 가능한 HTML로 슬라이드 덱을 작성하는 마이크로소프트의 조용한 33B 모델

AesCode-32B의 타임스탬프는 서로 어긋나며, 그 어긋남 자체가 보고할 거리의 대부분이다. Hugging Face 저장소 microsoft/AesCode-32B는 2026년 9월 29일에 생성되었지만, 그 안에 들어 있는 모든 것은 2026년 10월 7일자 단일 커밋으로 들어왔고 그 메시지는 그저 "Release AesCode-32B"였다 — 그리고 결과를 재현 가능하게 만드는 학습 스택은 github.com/microsoft/AesCode에 10월 8일 푸시되었다. 마이크로소프트는 아무것도 발표하지 않았다: 블로그 글도, arXiv 프리프린트도, 리더보드 제출도, 자사 사이트의 모델 페이지도 없다. 존재하는 것은 프롬프트를 받아 완전하고 자족적인 HTML 문서 — 슬라이드, 포스터, 대시보드 — 를 출력하는 330억 파라미터 비전-언어 모델과, 더 작은 동반 모델인 microsoft/AesCode-8B이다. 둘 다 Qwen3-VL 비전 모델 — Qwen3-VL-32B-Instruct 및 Qwen3-VL-8B-Instruct — 에서 파인튜닝되었고, 둘 다 Apache 2.0이며, 둘 다 오늘 다운로드할 수 있다.

저장소 ID는 microsoft/AesCode-32B이고, 모델 카드는 다음과 같은 묘책으로 시작한다: AesCode는 프롬프트를 같은 프롬프트에서 생성된 이미지와 짝지어 주고, 그 이미지를 미적 참조로 사용하며, 실제 내용은 텍스트를 따른다. 이미지 생성기는 보기 좋은 페이지를 구성하지만 그 안의 숫자는 잘못 렌더링한다; 코드 모델은 숫자를 제대로 맞히지만 페이지가 어떻게 보이는지는 볼 수 없다. AesCode는 둘 다 가지려는 시도이며, 2026년 10월 11일 기준으로 그것에 대한 솔직한 요약은 가중치는 실제이고 검증 가능하며, 벤치마크 수치는 연구소가 직접 작성한 하네스에서 나온 연구소 자체 수치이고, Microsoft 외부의 누구도 아직 그것에 대한 수치를 발표하지 않았다는 것이다. 이 글은 그 세 범주를 끝까지 구분해 둔다.

저장소에 실제로 무엇이 들어 있는지, 바이트 하나하나까지

모델 카드의 한 마디도 믿지 않고 검증할 수 있는 것부터 시작하세요. 32B 저장소에는 총 66,714,912,704바이트에 달하는 14개의 safetensors 샤드가 들어 있으며, BF16에서 이는 약 334억 개의 파라미터입니다 — 카드의 "33B params" 및 가중치만으로도 약 65GB의 가속기 메모리가 필요하다는 경고와 일치합니다. config는 Qwen3VLForConditionalGeneration을 아키텍처로, 그리고 qwen3_vl을 모델 유형으로 선언하므로, 이는 새로운 아키텍처가 아니며 그럴 필요도 없습니다: 이는 transformers>=4.57로 로드되며, 카드에는 네 개의 텐서 병렬 랭크에 걸쳐 이를 서비스하고 프롬프트당 두 개의 이미지를 허용하며 24,576토큰 상한을 두는 vLLM 명령이 함께 제공됩니다.

참여 지표는 이번 공개에서 가장 조용한 부분이다. 이 글을 쓰는 시점에 32B 저장소의 다운로드 수는 두 건, 좋아요는 한 건이다. Hugging Face의 추론 제공자 매핑에도 항목이 없는데, 이는 저장소 페이지 뒤에 호스팅된 엔드포인트가 연결되어 있지 않다는 뜻이며, GGUF나 MLX, llama.cpp 빌드도 어디에도 광고되어 있지 않다. Microsoft의 이름을 달고 벤더 자체 표에서 GPT-5.5를 앞서는 결과를 낸 모델로서는 놀랄 만큼 작은 흔적이며, 이는 이 모델이 아무런 출시도 없이 올라왔다는 가장 강력한 증거다.

컴패니언 코드 저장소는 타임라인의 나머지 절반을 채워 주는데, 바로 여기서 릴리스 날짜 문제가 진짜로 모호해진다. microsoft/AesCode는 2026년 7월 23일, 즉 가중치보다 10주 앞서 만들어졌으며, 커밋이 열네 개 있는데 그중 하나도 빠짐없이 동일한 기여자가 작성했고, 모두 2026년 10월 8일 23:14:04에서 23:14:24 UTC 사이에 서로 20초 이내로 타임스탬프가 찍혀 있다. 여기에는 프롬프트와 검증 가능한 요구사항을 생성하기 위한 명세, 설계 그래프와 루브릭 질문을 만드는 데이터 파이프라인, 콜드 스타트 SFT 단계, GDPO 강화학습 루프, Playwright 기반 렌더링 검증기, 테스트, 그리고 이 모든 것을 문서화한 README가 포함된다. 릴리스도 태그도 없고, 저장소 설명은 비어 있으며, 스타는 하나뿐이다.

그래서 출시일은 언제인가? 저장소 기록은 9월 29일이라고 한다. 모델을 담고 있는 커밋은 10월 7일이라고 한다. 모델이 어떻게 만들어졌는지 설명하는 코드는 10월 8일이라고 한다. 한 2주 기간 안에 들어 있는 세 개의 타임스탬프이며, 그중 어느 것도 마이크로소프트가 "우리는 이것을 출시합니다"라고 말한 문장과 함께 있지 않다. 대부분 사람들이 실제로 다운로드하게 될 아티팩트에 대해서는 10월 7–8일을 적용 날짜로, 저장소가 예약된 날짜로는 9월 29일을 취급하라. AesCode-32B가 특정 날짜에 "출시되었다"고 말하는 사람은 누구든 당신을 대신해 그 타임스탬프 중 하나를 고르는 것이다.

메커니즘: 미적 가이드로서의 이미지, 보상으로서의 그래프

카드의 기술적 주장은 좁고 구체적이며, 이는 장점입니다. 모델은 3,000개의 데모에 대해 학습률 1e-5로 콜드 스타트 지도 미세 조정으로 훈련된 다음, 그룹 상대 정책 최적화 변형인 GDPO로 7,408개의 프롬프트에 대해 520스텝 동안 훈련됩니다. 8B 모델은 동일한 레시피를 사용했고 400스텝에서 중단했습니다. RL 실행은 비평가도, 별도로 훈련된 보상 모델도 없이 verl의 FSDP-vLLM 하이브리드 엔진을 사용했으며, 워밍업 없이 상수 5e-6의 AdamW, 스텝당 128개 프롬프트와 각각 8회의 롤아웃, 그리고 프롬프트와 응답은 각각 8,192토큰으로 제한했습니다.

이 보상이 특별한 점은 단일 스칼라가 아니라는 데 있다. 각 학습 대상은 전체 캔버스를 아우르는 디자인 그래프로 기술되므로, 개별 속성을 따로 귀속시킬 수 있다. 그 그래프로부터 실행, 텍스트, 경계, 표차트, 레이아웃, 여백, 디자인이라는 일곱 개의 채널이 나오며, 각각은 롤아웃 그룹 내에서 정규화되어 하나의 신호가 다른 신호들을 압도하지 못하게 한다. 결정론적 검증기는 코드와 그 렌더링에서 파싱할 수 있는 것을 채점하고, 비전-언어 판정자는 그래프 자체의 요소와 관계에 묶인 루브릭을 사용해 파싱할 수 없는 것을 채점한다. 후보 HTML은 외부 요청을 차단한 샌드박스된 Playwright 브라우저에서 렌더링하여 채점되며, 이 브라우저는 DOM, 계산된 스타일, 바운딩 박스, 콘솔 상태 및 스크린샷을 내보낸다.

엔지니어링적 결과는 언급할 가치가 있습니다. 왜냐하면 그것은 여러분이 받는 출력에 나타나기 때문입니다: 모델은 표를 실제 HTML 표 구조로, 차트를 ECharts 사양으로 내보내도록 학습되었으므로, 둘 다 픽셀에 박히는 대신 직접 검사할 수 있습니다. 그것이 디자이너에게 건넬 수 있는 덱과 린터에게 건넬 수 있는 덱의 차이입니다. 재현 요구 사항은 그에 상응하게 무겁습니다 — README는 Python 3.10, CUDA 12.6, 그리고 8개의 B200 GPU로 구성된 노드를 요구하고, 특정 verl 커밋을 고정하며, 기본 verl에는 Qwen3-VL 지원이 없기 때문에 해당 커밋에 대한 패치가 필요하다고 분명히 밝히고, Playwright 시스템 라이브러리가 없으면 브라우저가 실행 시 실패하고 페이지가 0점을 받는다고 경고하며, 고정된 OCR 스택이 없으면 해당 보상 채널이 보류하는 대신 0을 반환하고 신호를 조용히 훼손한다고 경고합니다.

벤치마크 표, 그리고 그것을 느슨하게 붙잡아야 할 네 가지 이유

AesCode-32B의 대표 수치는 300개의 인포그래픽 샘플, 프롬프트당 3회 생성(온도 0.8, top-p 0.95), 각각 최대 12,000개의 출력 토큰을 사용했으며, 생성 결과 중 선택은 없었다. 점수는 백분율이다. 참조 조건에서 32B 모델은 Text 95.34, Boundary 97.27, Table/Chart 90.37, Rule 평균 94.33을 보고했고, 시각적 측면에서는 Content 85.76, Layout 90.58, Style 55.99로 Visual 평균 77.44, Overall 85.89를 기록했다. 같은 표에서 참조가 있는 GPT-5.5는 Overall 81.28점, 참조가 있는 Claude Opus 4.8은 Overall 80.39점을 받는 반면, 이 모델이 훈련된 기반인 Qwen3-VL-32B-Instruct는 61.10점을 받는다.

네 가지 유의점은 그 수치들과 같은 맥락에서 언급되어야 하며, 그중 어느 것도 이 작업을 폄하하는 것은 아니다. 첫째, GPT-5.5와 Claude Opus 4.8 행을 포함한 모든 행은 Microsoft가 Microsoft의 하네스에서 Microsoft의 평가 기준으로 실행한 것이다. 이는 다른 연구소들의 수치가 아니라 Microsoft가 경쟁사 모델을 측정한 결과이며, 카드 자체도 해당 평가 기준을 각 설계 그래프에 "샘플별로 특화된(sample-specific)" 것이라고 부른다. 둘째, 이 평가 기준은 학습 데이터를 생성한 것과 동일한 파이프라인에서 만들어졌는데, 이는 바로 벤치마크가 특정 모델의 강점 쪽으로 흐를 수 있는 구조다. 카드는 그 평가 기준의 한계를 솔직히 밝히고 있다. 즉, 디자인이 납품 전에 추가적인 시각적 수정이 필요 없어야 함을 요구하는 Style은 "모든 시스템의 공통 상한선"이라고 불리며, 표에 있는 어떤 모델도 60을 넘지 못한다. 셋째, 이 모델에 대한 독립적인 측정은 어디에도 없다. 제3자 리더보드 항목도, 재현도 없으며, 다운로드 수가 두 건인 점을 고려하면 연구소 외부에서 아직 이 모델을 실행하는 사람은 거의 확실히 없다. 넷째, 이 비교는 주목할 만한 방식으로 미묘하게 비대칭적이다. AesCode-32B의 행은 모두 참조 조건(reference-conditioned)으로, 모델이 학습된 구성에서 측정되고 있다. 카드도 참조가 제공될 때 품질이 여전히 가장 높다는 점을 보여주며 이를 인정한다.

표에서 헤드라인보다 더 잘 견디는 단 하나의 결과는 품질 주장이 아니라 견고성 주장이다. 추론 시 참조 이미지를 제공하지 않으면 AesCode-8B는 Visual 포인트를 1.00만 잃는 반면, 백본인 Qwen3-VL-8B-Instruct는 19.55, GPT-5.5는 10.04를 잃는다. 이 카드의 주장은 참조 조건부 학습이 모델이 보는 것을 베끼도록 가르치는 대신 시각적 계획을 정책에 내재화한다는 것이다. 이는 벤더가 보고한 것이며 재현된 바 없고, 단 한 번의 독립 실행으로 결판날 수 있는 종류의 주장이기도 하다. 그리고 프로덕션에서 가장 중요한 종류의 주장이기도 한데, 프로덕션에서는 항상 참조 이미지를 손에 쥐고 있지는 않기 때문이다.

실행하는 데 드는 비용, 그리고 그것이 비교에 의미하는 바

이 모델을 셀프 호스팅하는 데 값싼 부분은 하나도 없습니다. 출력 토큰 10,000~12,000개가 단일 아티팩트의 작업 크기이고, ECharts 스펙이 포함된 완전한 HTML 문서는 그 범위의 하단보다 상단에 더 가깝기 때문에 모든 생성은 긴 디코딩입니다. 이 카드 자체의 서빙 레시피는 약 65GB의 BF16 파라미터를 담기 위해 텐서 병렬 처리로 GPU 4개를 요구하고, 학습 레시피는 B200 8개를 요구합니다. 이는 취미용 배포가 아니라 실제 머신이며, 비교의 조건을 규정합니다. AesCode-32B가 비교 대상으로 삼는 모델들은 토큰당 임대되고, 모델 자체는 GPU 시간당 임대됩니다. 하드웨어를 소유하고 있든 아니든 마찬가지입니다.

그 비교의 실질적인 형태야말로 라우팅 계층이 존재하는 이유이며, 우리가 무엇을 호스팅하고 무엇을 호스팅하지 않는지에 관해 정확히 짚고 넘어갈 필요가 있습니다. AesCode-32B는 OrcaRouter의 카탈로그에 없고 우리도 이를 제공하지 않습니다 — 제가 확인할 수 있는 한, 마이크로소프트를 포함해 어디에도 이 모델을 위한 호스팅 엔드포인트는 존재하지 않습니다. 카탈로그에 있는 것은 테이블 반대편입니다: 자체 호스팅 아티팩트 생성기를 벤치마크할 때 비교 대상이 되는 호스팅 모델들, 즉 GPT-5.5와 더 작은 Qwen3-VL 비전 모델들, 제공자 정가에 0% 마크업으로 하나의 API 키를 통해 접근할 수 있는, 즉 공급업체 가격 변경이 같은 날 우리 쪽에 반영된다는 뜻입니다. 임대한 엔드포인트를 직접 실행하는 모델과 비교하는 데 두 번째 계약이나 두 번째 SDK는 필요하지 않으며, 라우팅 DSL을 쓰면 자체 호스팅 호출을 단일 엔드포인트 뒤에서 호스팅 호출 옆에 나란히 둘 수 있습니다. AesCode-32B가 그 모델 카드가 주장하는 단 한 가지 일을 잘 해낸다면, 그것을 알아보는 비용은 GPU 청구서이고, 비교 대상인 대안들의 비용은 여러분이 이미 가지고 있을 법한 키 하나입니다.

오늘날 그것으로 할 수 있는 것, 그리고 존재하지 않는 것

• 다운로드해서 실행하세요 — 가중치는 Apache 2.0이고, Qwen3-VL 백본을 따르며, 14개의 BF16 샤드와 4.57 버전 이상에서 작동하는 transformers 경로, 그리고 카드에 수록된 vLLM 레시피를 제공합니다.

• 학습을 재현합니다 — 코드는 MIT 라이선스이며 의미 있을 만큼 충분히 완전합니다: 보상 검증기, 루브릭 빌더, SFT 및 GDPO 단계, 고정된 verl 커밋과 Qwen3-VL 지원을 추가하는 패치, 그리고 실패 모드를 숨기지 않고 나열하는 README.

• 레퍼런스 없이 평가하세요 — 이 모델은 레퍼런스 이미지가 있든 없든 프롬프트를 받아들이며, 이 카드에서 가장 검증하기 쉬운 주장이 바로 그 구성에 담겨 있습니다.

• 이걸 위한 API를 구하라고? — 불가능하다. 호스팅된 엔드포인트도 없고, 저장소에 추론 제공자 매핑도 없으며, GGUF나 MLX 빌드도 없다. 이걸 실행한다는 것은 곧 하드웨어를 실행한다는 뜻이다.

• 논문을 읽어 보세요 — 아직은 읽을 수 없습니다. 이 카드는 다음과 같은 제목의 논문을 링크합니다: AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, 그리고 자체 BibTeX 항목에는 발표처가 "Under review", 연도가 2027로 나와 있습니다. arXiv를 검색해도 그 제목의 논문은 나오지 않습니다. 이름이 거의 같은, 더 이른 시기의 다른 Microsoft 논문이 있습니다 — Code Aesthetics with Agentic Reward Feedback (2025년 10월)이며, AesCoder-4B 모델과 AesCode-358K 데이터셋을 공개했습니다 — 그리고 AesCode-32B 카드에는 이 논문을 인용하거나 이와의 관계를 밝힌 내용이 전혀 없습니다. 배경 자료를 찾다가 대신 그 논문에 도착한다면, 당신은 저자가 겹치는 다른 모델에 대해 읽고 있는 것입니다.

• 공개 리더보드에서 비교하기 — 아직은 아니다. 제3자 지수가 이를 평가한 적은 없는 것으로 보이며, 다운로드 수가 두 건에 불과한 저장소로서는 놀라운 일이 아니다.

누가 신경 써야 하고, 누가 기다려야 할까

이 글의 대상 독자는 헤드라인 표가 시사하는 것보다 좁고, "모델로 무언가를 만드는 사람 누구나"보다 더 구체적이다. 당신의 제품이 프롬프트를 나중에 누군가가 편집해야 하는 슬라이드, 포스터, 보고서 또는 대시보드로 바꾸는 제품이라면, 당신은 이미 이 모델이 겨냥하는 선택지를 발견한 것이다. 이미지 생성은 바꿀 수 없는 아름다운 직사각형을 주고, 코드 생성은 컴파일러가 조립한 것처럼 보이는 편집 가능한 무언가를 준다. 실제 표와 ECharts 명세가 들어간 완전한 HTML 문서를 출력하고, 참조로 줄 것이 없을 때에도 참조 조건 기반 품질에서 약 1점 이내에 머물며, Apache 2.0 아래에서 자체 하우스 스타일에 맞춰 미세 조정할 수 있는 33B 오픈 웨이트 모델이 존재한다는 것은 진심으로 유용한 일이다. 이 크기에서 이런 조건으로 바로 그 일을 하는 다른 모델은 없다.

그에 대한 반론으로는: 품질에 대해 당신이 아는 모든 것은 벤더가 만든 표에서 나오고, 그 표의 근거가 된 평가 기준은 훈련 데이터를 만든 것과 동일한 파이프라인에서 산출됐으며, 그 카드가 인정하는 유일한 한계 — 테스트된 모든 시스템에서 Style이 60 미만이라는 점 — 는 디자인에 민감한 제품이 가장 중요하게 여길 바로 그 차원이다. 생성 작업을 사내에서 유지해야 할 규정 준수상의 이유가 있고 여분의 8-GPU 노드를 가진 팀이라면 오늘 당장 시작할 수 있을 만큼 충분하다. 다음 주에 프로덕션용 모델을 선택하려는 팀은 선택의 근거로 삼을 독립적인 수치가 없으며, 85.89 대 81.28을 확정된 결과로 받아들여서는 안 된다.

무엇이 이것을 이야기로 만들어 줄까

네 가지이며, 그중 어느 것도 아직 존재하지 않는다. 하나, 발표 — Microsoft는 아무 말도 하지 않았고, 카드가 참조하는 논문은 명시적으로 심사 중이므로, 카드의 요약을 넘어서는 학습 세부 정보를 담은 기술 보고서가 어느 시점에든 나올 수 있다. 둘, 독립 실행 — 참조 없는 견고성 주장과 Boundary 점수는, 카드에 따르면 샘플의 4.3%에서 심각한 실패로 떨어지며 GPT-5.5의 34.7%와 대비되는데, 둘 다 테스트하기 저렴하고 둘 다 테스트할 가치가 있다. 셋, 공급업체의 레시피 밖에서의 서빙 지원 — GGUF 빌드나 주류 런타임 항목은 어떤 벤치마크보다도 하드웨어 이야기를 더 바꿔 놓을 것이다. 그리고 넷, 크기 문제에 대한 두 번째 데이터 포인트: 8B 모델이 같은 표에서 32B의 85.89와 비교해 Overall 82.94를 기록한다는 것은 매개변수 4분의 1로 2점 차이인데, 이는 재현되거나 아니면 조용히 언급되지 않게 되는 종류의 일이다.

그중 하나가 실현되기 전까지 AesCode-32B에 대한 정확한 설명은 이렇다: 허용적 라이선스 아래 공개된 실제 가중치, 설비를 잘 갖춘 연구소라면 재현할 수 있을 만큼 상세한 학습 스택, 한 회사가 자사 모델과 두 경쟁사 모델을 측정한 벤치마크 표, 그리고 어떤 단 하루도 출시일이라고 부를 수 없게 하는 저장소 이력. 그것은 다운로드 두 건이라는 카운터가 시사하는 것보다 더 흥미로운 산출물이고, 85.89가 암시하는 것보다 덜 입증된 산출물이다. 그 문장의 양쪽 절반 모두 2026년 10월 11일 기준의 정직한 해석이다.