AesCode-8B ra mắt âm thầm: mô hình 8B của Microsoft viết slide và dashboard dưới dạng HTML

Con số thú vị nhất trong bản phát hành mới của Microsoft là 1,00. Khi không cung cấp ảnh tham chiếu cho AesCode-8B — một mô hình 8 tỷ tham số có thể viết slide, poster và bảng điều khiển dưới dạng HTML và CSS có thể chỉnh sửa — điểm trực quan của nó giảm đi một điểm trên một trăm. Khi không cung cấp ảnh tham chiếu tương tự cho Qwen3-VL-8B-Instruct, mô hình trọng số mở mà AesCode-8B được tinh chỉnh từ đó, mức giảm là 19,55 điểm. Với GPT-5.5, con số đó là 10,04. Chính phép so sánh ấy mới là nơi chứa đựng kết quả nghiên cứu thực sự, và nó nằm bên dưới một tiêu đề mà Microsoft cũng đã công bố: trên thang điểm 300 mẫu của riêng mình, điểm tổng thể 82,94 của AesCode-8B nhỉnh hơn GPT-5.5 có điều kiện tham chiếu ở mức 81,28 và Claude Opus 4.8 ở mức 80,39, còn người anh em lớn hơn, AesCode-32B, đạt 85,89.

Không có gì về bản phát hành này được công bố. Microsoft đã commit trọng số lên Hugging Face vào ngày 2026-10-07 theo Apache 2.0 — AesCode-8B cùng một bản đồng hành 32B được xây dựng theo cùng cách từ Qwen3-VL-32B-Instruct — và đẩy mã huấn luyện và đánh giá lên GitHub vào ngày hôm sau. Không có bài đăng blog nào của Microsoft Research, không có ghi chú phát hành, không có trang sản phẩm và không có preprint: trích dẫn trong thẻ mô hình ghi là "Under review", năm 2027, một giá trị giữ chỗ thay vì một ngày tháng. Tính đến ngày 2026-10-11, kho lưu trữ 8B hiển thị hai lượt tải xuống và một lượt thích; kho lưu trữ GitHub hiển thị một sao. Mọi thứ bên dưới mang một con số đều hoặc là dấu thời gian bạn có thể tự xác minh, hoặc là một con số Microsoft đã báo cáo về bộ đánh giá của chính mình — và sự phân biệt đó ở đây quan trọng hơn mức thông thường, bởi vì không có phần nào của mô hình này được bất kỳ ai khác đo lường.

Những gì đã được giao, và những gì không có trong hộp

Ba ngày định hình bản phát hành này, và chúng là những ngày duy nhất trong đó. Kho lưu trữ Hugging Face cho microsoft/AesCode-8B được tạo vào 2026-09-29, các trọng số đã được commit với thông điệp "Release AesCode-8B" lúc 03:35 UTC ngày 2026-10-07, và microsoft/AesCode, kho lưu trữ mã, đã công khai vào ngày hôm sau, 2026-10-08 lúc 23:14 UTC. Các trọng số 32B đã được đưa vào cùng cửa sổ commit. Không có gì ở giữa được thông báo ở bất cứ đâu.

• Trọng số — bốn phân đoạn safetensors với tổng dung lượng 17.543.339.408 byte, tương đương khoảng 8,8 tỷ tham số bf16. Microsoft dán nhãn mô hình là 8B; trường kích thước của Hugging Face làm tròn thành 9B. Đó là làm tròn, không phải sai lệch.

• Kiến trúc — bản tinh chỉnh trực tiếp theo công thức Qwen3-VL: Qwen3VLForConditionalGeneration, 36 lớp ẩn, kích thước ẩn 4.096, 32 đầu attention với 8 đầu key-value, từ vựng 151.936 token và các vị trí mrope xen kẽ. Nó cần transformers 4.57 trở lên.

• Bối cảnh và đầu ra — các lần chạy được báo cáo đã sử dụng ngữ cảnh 24.576 token với tối đa 12.000 token đầu ra, được tạo ở temperature 0,8 và top-p 0,95 qua ba lượt rollout cho mỗi prompt mà không có chọn lọc. Lệnh phục vụ vLLM cho phép hai hình ảnh cho mỗi prompt: hình tham chiếu, và không gì khác, vì đầu ra là văn bản.

• Giấy phép — Apache 2.0, được mô tả là tuân theo backbone Qwen3-VL. Hoàn toàn cho phép tự do, không có gating, không có phụ lục về sử dụng được chấp nhận.

• Không có trong gói — dữ liệu huấn luyện và đánh giá. Kho mã cung cấp pipeline cùng tài liệu mô tả các đầu vào và đầu ra mong đợi, đồng thời có nhắc đến các tệp chia tách mà nó yêu cầu, nhưng không có bản phát hành tập dữ liệu nào được liệt kê trên thẻ mô hình lẫn kho mã. Bạn nhận được công thức, chứ không phải nguyên liệu.

• Cũng không có sẵn — bất kỳ endpoint được host nào. Chúng tôi không thể tìm thấy API nào phục vụ AesCode-8B ở bất cứ đâu và nó không có trong danh mục của chính chúng tôi. Cho đến khi có nhà cung cấp tiếp nhận nó, việc đánh giá nó đồng nghĩa với việc tải trọng số lên GPU của chính bạn.

Cách đặt vấn đề của Microsoft đáng được trích dẫn vì đó chính là toàn bộ bản đề bài thiết kế: các mô hình mã "không thể thấy cách bố cục, thứ bậc và màu sắc kết hợp với nhau trên canvas," trong khi các trình tạo hình ảnh "tạo nên những trang trực quan hấp dẫn nhưng thường hiển thị sai văn bản, số liệu và các mối quan hệ logic." AesCode là nỗ lực lấy cảm quan bố cục từ cái này và khả năng xác minh từ cái kia.

Giải thích kết quả 1,00 điểm

Sau đây là cơ chế đằng sau con số trong đoạn đầu tiên. Trong quá trình huấn luyện, mỗi prompt được ghép cặp với một ảnh tham chiếu được tạo ra từ chính prompt đó — các lần chạy của chính Microsoft đã dùng GPT-Image-2 cho hình ảnh và GPT-5.5 để mở rộng một ý tưởng ngắn thành prompt nội dung chi tiết. Ảnh tham chiếu không có thẩm quyền về nội dung; prompt văn bản vẫn là nguồn chân lý. Điều mà ảnh tham chiếu cung cấp là bố cục và phong cách, và hàm phần thưởng được xây dựng để giữ hai thứ đó tách biệt.

Hệ quả là tiên nghiệm thị giác nằm trong chính sách thay vì trong đầu vào. AesCode-8B mất 1,00 điểm Visual khi tham chiếu bị loại bỏ lúc suy luận. Backbone của chính nó, được đánh giá có điều kiện tham chiếu ở mức 44,72 Visual, mất 19,55 điểm khi không có tham chiếu. GPT-5.5 mất 10,04. Phiên bản chưng cất của điều đó: mô hình đã không còn cần đến hình ảnh nữa.

Nửa sau của kết quả là phần dễ bị bỏ sót. Microsoft báo cáo rằng phần thưởng dựa trên tham chiếu đã nâng Visual chỉ có prompt từ 25.17 lên 69.71 — mô hình vốn không bao giờ thấy tham chiếu tại thời điểm suy luận vẫn hưởng lợi từ việc đã được huấn luyện dựa trên chúng. Nếu bạn đang định bỏ qua bước tạo tham chiếu trong pipeline của riêng mình, thì đó chính là con số cho thấy bạn cũng đừng nên bỏ qua nó trong huấn luyện.

Lưu ý trung thực cho tất cả những điều đó: đây là thang điểm của Microsoft, trên 300 mẫu đồ họa thông tin của Microsoft, được chấm ba lần cho mỗi lời nhắc mà không hề chọn lọc. Một nửa số điểm đến từ các trình xác minh tất định, thứ mà bất kỳ ai cũng có thể tái tạo; nửa còn lại, các chiều trong danh sách kiểm tra, được đánh giá bởi một mô hình ngôn ngữ-thị giác mà tài liệu không nêu tên danh tính. Bạn không thể tái tạo nửa thứ hai nếu không biết trình đánh giá nào đã tạo ra nó.

Nơi khẩu vị thấm vào các trọng số

Phương pháp huấn luyện là phần chứa nhiều ý tưởng có thể chuyển giao nhất trong bản phát hành này, và nó mang tính cơ học nhiều hơn những gì mà kết quả đầu ra gợi lên.

• Mọi thứ trước hết đều là một đồ thị.Mỗi mục tiêu được biểu diễn dưới dạng một đồ thị thiết kế: các nút cho văn bản, biểu đồ, bảng, thẻ, vùng và khe hình ảnh, cùng các cạnh cho quan hệ chứa, căn chỉnh, thứ tự và kết nối. Ý nghĩa của đồ thị nằm ở việc quy kết — mọi thuộc tính trên canvas đều thuộc về một phần tử được đặt tên, nên mọi thuộc tính đều có thể được chấm điểm riêng.

• Bảy kênh thưởng.Sáu bộ kiểm chứng tất định sẽ kiểm tra những thứ có thể phân tích được — thực thi, văn bản chính xác, ranh giới, dữ liệu bảng và biểu đồ, bố cục ngữ nghĩa, khoảng trắng — và một Thang đánh giá Đồ thị Trực quan dành riêng cho từng mẫu, được xây dựng dưới dạng các câu hỏi có/không gắn với đồ thị về hình học và vị trí, sẽ cho điểm phần còn lại. Các kênh gồm thực thi, văn bản, ranh giới, tablechart, bố cục, khoảng trắng và thiết kế.

• Các kênh được chuẩn hóa trước khi chúng được kết hợp.GDPO chuẩn hóa từng kênh trong nhóm rollout của nó, nên một tín hiệu dày đặc dựa trên quy tắc không thể lấn át tín hiệu thị giác thưa thớt. Microsoft đo được mức 5,12 điểm Visual so với GRPO vô hướng thuần túy trong cùng một thiết lập — do nhà cung cấp báo cáo, nhưng là một phép ablation cụ thể chứ không phải một khẳng định suông.

• Việc chấm điểm diễn ra thông qua quá trình render. HTML của ứng viên được render trong một trình duyệt Playwright chạy trong môi trường sandbox với các yêu cầu bên ngoài bị chặn, và harness sẽ đọc lại DOM, các computed style, bounding box, trạng thái console cùng một ảnh chụp màn hình. Bảng phải là bảng HTML; biểu đồ phải là đặc tả ECharts. Ràng buộc đó thực sự có tác dụng — nó buộc đầu ra phải có dạng mà một trình kiểm tra có thể phân tích được.

• Bản thân công thức. Tinh chỉnh có giám sát khởi động nguội trên 3.000 mẫu minh họa với tốc độ học 1e-5, sau đó GDPO trên 7.408 prompt trong 400 bước trên engine lai FSDP-vLLM của verl, không dùng critic và không có mô hình phần thưởng được huấn luyện riêng. AdamW với hằng số 5e-6, không warmup, weight decay 0,01, 128 prompt mỗi bước với 8 rollout cho mỗi prompt, hệ số KL và entropy đều là 0,001, prompt và phản hồi mỗi thứ giới hạn ở 8.192 token. Các lần chạy được phát hành sử dụng một node duy nhất với tám NVIDIA B200. AesCode-32B dùng cùng công thức này trong 520 bước.

Đọc một cách tổng thể, đây là một bài báo về thiết kế phần thưởng khoác lốt một bản phát hành mô hình — và điều đó nhất quán với việc trích dẫn ghi "Under review" thay vì trỏ đến một bản tiền in.

Bảng điểm, và ai là người bảo đảm cho nó

Tất cả nội dung sau đây là đánh giá của chính Microsoft, được báo cáo trong thẻ mô hình, trên 300 mẫu infographic. Rule lấy trung bình các kiểm tra lập trình Text, Bound và Chart; Visual lấy trung bình các khía cạnh trong danh sách kiểm Content, Layout và Style; Overall là trung bình của hai mục. Điểm số là tỷ lệ phần trăm được lấy trung bình trên ba lần sinh cho mỗi prompt mà không chọn lọc. "Ref." đánh dấu việc mô hình có được cung cấp một tham chiếu được sinh ra cùng với prompt hay không.

• AesCode-8B kèm tham chiếu — Văn bản 94.06, Khung bao 88.36, Biểu đồ 87.79, Quy tắc 90.07; Nội dung 86.41, Bố cục 87.80, Phong cách 53.21, Hình ảnh 75.80; Tổng thể 82.94.

• So với mô hình nền tảng của nó — Qwen3-VL-8B-Instruct được điều kiện hóa theo tham chiếu đạt điểm Visual 44.72 và Overall 51.93. Đó là mức tăng 31.1 điểm ở Visual và 31.0 điểm ở Overall, và đây là phép so sánh ít gây bất ngờ nhất trong bảng, vì toàn bộ mục đích của quá trình huấn luyện nằm ở phần thị giác.

• So với GPT-5.5, có điều kiện tham chiếu — Tổng thể 81.28, Nội dung 82.44, Bố cục 89.93, và Phong cách 57.91.

• So với Claude Opus 4.8, được điều kiện hóa theo tham chiếu — Tổng thể 80.39, Nội dung 86.42, Bố cục 89.76.

• AesCode-32B, điều kiện hóa theo tham chiếu — Văn bản 95,34, Ràng buộc 97,27, Biểu đồ 90,37, Quy tắc 94,33, Bố cục 90,58, Visual 77,44, Tổng thể 85,89. Hai mươi hai phẩy bốn điểm Visual so với backbone 32B của chính nó.

• Mức trần Style — không có mô hình nào trong bảng vượt qua 60, và 57,91 của GPT-5.5 là cao nhất trong số đó. AesCode-8B đứng ở 53,21. Định nghĩa của chính Microsoft rất khắt khe: Style chỉ công nhận một thiết kế khi nó không cần chỉnh sửa trực quan nào nữa trước khi bàn giao. Vậy nên ở khía cạnh duy nhất đo lường liệu một con người có thực sự xuất bản trang đó mà không cần chỉnh sửa hay không, mô hình 8B không phải là dẫn đầu.

• Lỗi ranh giới — một lỗi tràn canvas nghiêm trọng tái diễn ở 4,3% trong số 300 mẫu, so với 34,7% ở GPT-5.5. Tràn là kiểu lỗi khiến HTML được tạo ra trở nên không dùng được, chứ không chỉ đơn thuần là xấu về mặt hình thức.

Giờ đến phần quan trọng không kém bảng số liệu. Mọi con số ở trên đều do nhà cung cấp tự báo cáo và chưa được tái lập. AesCode-8B không xuất hiện trên bất kỳ bảng xếp hạng độc lập nào mà chúng tôi tìm được, và việc so sánh với GPT-5.5 cùng Claude Opus 4.8 đang được thực hiện trên thang đánh giá của Microsoft, trên một tác vụ mà những mô hình đó không được tinh chỉnh cho nó, với định nghĩa về "Layout" thưởng cho việc tạo ra được một trang, bất kể ra sao. Điểm Text 94.06 không có nghĩa là mô hình này đánh bại GPT-5.5 về văn bản. Nó có nghĩa là mô hình đặt nhãn mà không mâu thuẫn với prompt trên các trang infographic, một tuyên bố nhỏ hơn nhiều. Kết quả Style là dấu hiệu cho thấy thang đánh giá không bị dàn xếp theo hướng có lợi cho AesCode — thắng lợi lớn nhất trên bảng điểm đi kèm với con số kém hay nhất nằm ngay cạnh nó.

Điều gì đã được xác nhận, và điều gì chưa được xác nhận?

Vì điều này đã được phát hành một cách âm thầm, nên đáng để tách biệt hai điều đó một cách rõ ràng.

• Đã xác nhận — các trọng số tồn tại và có thể tải xuống theo Apache 2.0; hai mốc thời gian phát hành nằm trong các kho lưu trữ; kiến trúc, số lượng tham số, độ dài ngữ cảnh và cấu hình lấy mẫu đều có trong tệp cấu hình và model card đã công bố; công thức huấn luyện và thiết kế phần thưởng được ghi lại đủ chi tiết để có thể tranh luận; mã nguồn, ngăn xếp trình xác minh và công cụ xây dựng rubric đều công khai; có một phiên bản đồng hành 32B.

• Chưa được xác nhận — bất kỳ con số benchmark nào, bởi bất kỳ ai khác ngoài nhà cung cấp. Bài báo, mà chính tài liệu mô tả là đang được xem xét. Danh tính của giám khảo thị giác-ngôn ngữ đứng sau nửa phần điểm số liên quan đến hình ảnh. Liệu có nhà cung cấp nào sẽ lưu trữ nó hay không. Liệu ngữ cảnh 24.576 token có trụ vững trên các bộ slide thực tế nhiều trang hay không, vì đánh giá được báo cáo chỉ trên các trang infographic đơn lẻ. Và bất cứ điều gì về hành vi ngoài tiếng Anh — thẻ ngôn ngữ của model card chỉ mỗi "en".

Nếu bạn muốn chạy nó, và chi phí để làm điều đó là bao nhiêu

Qwen3-VL-8B-Instruct — mô hình mà AesCode-8B được tinh chỉnh từ đó, và là phép so sánh đơn lẻ mạnh nhất hiện có cho đến khi ai đó công bố một kết quả AesCode độc lập — lại là một vấn đề khác:

Đường phục vụ cho chính AesCode-8B thì ngắn, và thẻ mô hình cung cấp trực tiếp: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, với transformers 4.57 trở lên cho tuyến không dùng vLLM, cùng một đoạn mã Python chấp nhận một ảnh tham chiếu tùy chọn trước lời nhắc văn bản.

Phép tính bạn phải tự làm là về bộ nhớ. 17,5 GB trọng số bf16 phải nằm cùng với một KV cache cho ngữ cảnh 24.576 token và tối đa hai hình ảnh, nên một card 24 GB về mặt kỹ thuật là đủ cho phần trọng số nhưng lại chật vật đến mức khó chịu cho mọi thứ còn lại; 40-48 GB, hoặc hai card 24 GB, mới là mức sàn thực tế. Mô hình đồng hành 32B là một bài toán ở đẳng cấp khác — tổng các shard của nó là 66,7 GB, nên nó cần tensor parallelism và một node đa GPU. Cũng phải tính đến một renderer: mô hình xuất ra một tài liệu HTML hoàn chỉnh, và mọi tuyên bố về chất lượng đối với nó đều được đưa ra bằng cách render tài liệu đó, nên việc chấm điểm đầu ra của chính bạn đồng nghĩa với việc phải dựng Playwright với các yêu cầu bên ngoài bị chặn.

Bạn không cần tạo ảnh tham chiếu ở thời điểm suy luận — đó chính xác là điều mà kết quả 1,00 điểm mang lại cho bạn — nhưng tài liệu nói rõ rằng chất lượng vẫn đạt mức cao nhất khi có sẵn một ảnh như vậy, nên cách thiết lập trung thực là tùy chọn tham chiếu chứ không phải hoàn toàn không cần tham chiếu.

AesCode-8B không phải là thứ mà OrcaRouter định tuyến, và chúng tôi cũng không tìm thấy nó được host ở bất kỳ đâu khác, nên việc đánh giá hiện tại đồng nghĩa với việc phải chạy trọng số trên phần cứng của chính bạn. Còn bộ khung xương của nó lại là câu chuyện khác. Qwen3-VL-8B-Instruct hiện có thể định tuyến qua OrcaRouter với giá $0.18 mỗi triệu token đầu vào và $0.70 mỗi triệu token đầu ra, cùng ngữ cảnh 131.072 token — điều này khiến nó trở thành cách rẻ để xem phiên bản chưa tinh chỉnh của kiến trúc này làm được gì trên các prompt infographic của riêng bạn trước khi bạn tốn cả một tuần GPU để tái tạo công thức của người khác. OrcaRouter chuyển nguyên giá niêm yết của nhà cung cấp với mức markup 0% và tự động chuyển đổi dự phòng giữa các nhà cung cấp, nên việc so sánh đó chỉ tốn một key và không cần hợp đồng thứ hai; nếu AesCode-8B có ngày nào đó xuất hiện trên một nhà cung cấp mà chúng tôi định tuyến, nó sẽ có mặt trong danh mục ngay trong ngày hôm đó. Và nếu bạn tự host nó, những model mà bạn sẽ dùng làm phương án dự phòng trong production chính là những model đã nằm sau một endpoint đó — đây là thế đứng hợp lý cho một model được phát hành âm thầm mà không có bất kỳ đánh giá độc lập nào.

Xem gì

Hai điều, và không điều nào là một bảng benchmark khác.

Đầu tiên là bài báo. “AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards” được trích dẫn là đang được xem xét cho năm 2027, điều này đọc như thể là một placeholder được gõ vào một mục BibTeX hơn là một lịch trình. Cho đến khi có bản preprint hoặc bản camera-ready xuất hiện, phần giải thích về kênh phần thưởng ở trên chỉ là tóm tắt của một abstract mà không ai ngoài phòng thí nghiệm có thể đọc — và những câu hỏi thú vị, chẳng hạn như cách Visual Graph Rubric xử lý một đồ thị thiết kế vốn đã sai, chỉ được trả lời trong toàn văn.

Thứ hai là hosting. Một mô hình 8.8B Apache-2.0 tạo ra HTML có cấu trúc, có thể xác minh chính xác là dạng mà một nền tảng sẽ chọn, bởi vì đầu ra có thể được kiểm tra theo cách mà một JPEG thì không. Ngay khi ai đó phục vụ nó, đây không còn là quyết định tự host nữa mà trở thành quyết định định tuyến — và so sánh chi phí không còn là về số giờ GPU.

Điều không nên kỳ vọng là một phán quyết dứt khoát. Style là mức trần đối với mọi hệ thống trong bảng đó, kể cả hệ thống này, và Style là chiều kích duy nhất hỏi liệu một con người có phát hành trang nguyên trạng hay không. Cách diễn giải có thể bảo vệ được về AesCode-8B thì hẹp nhưng có thật: nó rất giỏi ở những phần của thiết kế thị giác có thể được máy kiểm tra, nó ở mức trung bình ở phần không thể kiểm tra, và nó là mô hình trọng số mở đầu tiên trong ngách này mà ở đó khoảng cách giữa hai điều ấy chính là mục đích của bản phát hành chứ không phải là sự tình cờ của nó.