AesCode-8B so với MathForm-8B: Cả hai đều là những bản tinh chỉnh 8B mà đầu ra của chúng có thể được kiểm tra bằng máy

AesCode-8B và MathForm-8B ra mắt cách nhau trong vòng tám tuần, cả hai đều từ các kho lưu trữ chứ không phải thông cáo báo chí, và sự trùng hợp này thú vị hơn vẻ ngoài ban đầu. Cả hai đều bắt đầu từ một checkpoint thuộc họ Qwen3. Cả hai đều dành toàn bộ ngân sách huấn luyện cho một dạng đầu ra hẹp. Và cả hai đều được xây dựng xung quanh một trình kiểm tra: MathForm-8B được huấn luyện dựa trên phán quyết của trình biên dịch Lean 4, còn AesCode-8B được chấm điểm bằng cách kết xuất từng trang ứng viên trong một trình duyệt sandbox và đọc lại DOM, các kiểu tính toán và ảnh chụp màn hình. Cả hai đều không phải là chatbot và cũng không cố gắng trở thành một chatbot. Điều phân biệt chúng là những gì máy có thể xác minh và những gì nó không thể — và, trong trường hợp cái mới hơn trong hai cái, điều gì xảy ra khi một nửa điểm số đến từ một giám khảo mà không ai đặt tên.

Các hồ sơ công bố không hề đối xứng. MathForm-8B đến từ OpenBMB và thẻ mô hình của nó ghi ngày phát hành là 2026-08-14; nó được xây dựng trên Qwen3-8B và được huấn luyện trên FormalVerse, một kho ngữ liệu gồm khoảng 367.000 ví dụ Lean 4 đã được kiểm chứng, với quá trình tinh chỉnh có giám sát theo sau là học tăng cường sử dụng việc biên dịch Lean và kiểm tra tính nhất quán ngữ nghĩa làm tín hiệu phần thưởng. AesCode-8B không ghi ngày phát hành ở bất kỳ đâu trong các tệp của nó. Microsoft đã tạo kho lưu trữ Hugging Face vào ngày 2026-09-29, commit các trọng số vào lúc 03:35 UTC ngày 2026-10-07 với thông điệp "Release AesCode-8B", và công bố mã huấn luyện trên GitHub vào ngày 2026-10-08. Không có thông báo nào đi kèm với cả hai sự kiện, phần trích dẫn của thẻ mô hình ghi "Under review, 2027", và kho lưu trữ cho thấy hai lượt tải xuống tính đến thời điểm viết bài này. Nó được tinh chỉnh từ Qwen3-VL-8B-Instruct, điều này đáng lưu ý chính vì nó không cùng tổ tiên với MathForm-8B.

Nguồn gốc tổ tiên giải thích phần lớn sự chia tách.

Qwen3-8B và Qwen3-VL-8B-Instruct cùng chung một thế hệ và một tên họ nhưng không cùng một công việc. Qwen3-8B là mô hình đa dụng chỉ dành cho văn bản: tổng cộng khoảng 8,2 tỷ tham số, trong đó khoảng 7 tỷ tham số không thuộc phần embedding, attention truy vấn theo nhóm, ngữ cảnh gốc 32K token có thể mở rộng lên 131K nhờ YaRN, và được huấn luyện trên 119 ngôn ngữ và phương ngữ. Qwen3-VL-8B-Instruct là mô hình anh em xử lý thị giác-ngôn ngữ, và nó là checkpoint mà AesCode-8B khởi tạo từ đó — cấu hình AesCode đã công bố là một công thức Qwen3-VL thuần với 36 lớp ẩn, kích thước ẩn 4.096, 32 đầu attention với 8 đầu key-value và từ vựng 151.936 token.

Sự phân nhánh đó quyết định phía đầu vào của cả hai chuyên gia trước khi bất kỳ chuyên gia nào được huấn luyện. MathForm-8B nhận văn bản và xuất ra văn bản theo cú pháp hình thức. AesCode-8B nhận văn bản cùng với một hình ảnh tham chiếu tùy chọn và xuất ra một tài liệu.

• Cơ sở — MathForm-8B: Qwen3-8B, chỉ văn bản. AesCode-8B: Qwen3-VL-8B-Instruct, đầu vào hình ảnh và văn bản.

• Tham số — MathForm-8B: khoảng 8,2B. AesCode-8B: khoảng 8,8B ở định dạng bf16 trải trên bốn shard, mà Hugging Face làm tròn thành 9B.

• Dữ liệu huấn luyện — MathForm-8B: FormalVerse, khoảng 367K ví dụ Lean 4 đã được kiểm chứng. AesCode-8B: 3.000 bản trình diễn khởi động nguội, sau đó GDPO học tăng cường trên 7.408 prompt trong 400 bước.

• Điều gì kiểm tra đầu ra — MathForm-8B: một trình biên dịch Lean 4, cùng với kiểm tra tính nhất quán ngữ nghĩa so với bài toán gốc. AesCode-8B: một bản kết xuất Playwright trong môi trường sandbox với sáu trình xác minh tất định và một thang đánh giá do mô hình chấm điểm.

• Giấy phép — cả hai đều dùng Apache 2.0, cả hai đều không bị giới hạn truy cập, cả hai đều kế thừa từ bộ khung của dòng Qwen3.

• Được lưu trữ ở bất cứ đâu — không phải vậy, theo như chúng tôi có thể tìm thấy.

Hai ý nghĩa khác nhau của “verifiable”

Đây là sự phân biệt đáng để chậm rãi suy xét, bởi vì "có thể kiểm tra bằng máy" được dùng cho cả hai và nó không mang cùng một ý nghĩa.

Trình kiểm tra của MathForm-8B là một trợ lý chứng minh. Lean 4 hoặc chấp nhận một phát biểu, hoặc không, và phán quyết không phải là vấn đề ý kiến, một tiêu chí chấm điểm hay gu thẩm mỹ của giám khảo. Vòng lặp huấn luyện hướng vào tín hiệu đó: giai đoạn SFT trên FormalVerse dạy ánh xạ từ một bài toán không chính thức sang một phát biểu định lý chính thức với phần đầu imports và một định lý có tên, còn giai đoạn RL mài giũa nó bằng cách dùng biên dịch cùng một kiểm tra tính nhất quán, thứ hỏi liệu bản hình thức hóa có còn nói điều mà bài toán gốc đã nói hay không. Biên dịch mang tính nhị phân và có thể tái lập bởi bất kỳ ai có cùng phiên bản Lean. Kiểm tra tính nhất quán là nửa mềm hơn, và đó chính là nửa mà các con số được báo cáo trở nên yếu — đúng như những gì kết quả đã công bố cho thấy.

Trình kiểm tra của AesCode-8B là một renderer. Các ứng viên được render trong một trình duyệt Playwright chạy trong sandbox với các yêu cầu bên ngoài bị chặn, và harness đọc lại DOM, các kiểu đã tính, hộp giới hạn, trạng thái console và một ảnh chụp màn hình. Sáu kênh tất định chấm điểm những thứ có thể phân tích cú pháp — thực thi, văn bản chính xác, hành vi biên, dữ liệu bảng và biểu đồ, bố cục ngữ nghĩa, khoảng trắng — và kênh thứ bảy, Visual Graph Rubric, chấm điểm hình học và vị trí thông qua các câu hỏi có/không gắn với đồ thị. Bảng phải là bảng HTML thật và biểu đồ phải là đặc tả ECharts, đây là một ràng buộc thực sự có tác dụng: nó ép đầu ra thành một dạng mà trình xác minh có thể phân tích cú pháp. Phần tất định thực sự có thể tái lập. Phần thị giác đượ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, nghĩa là không ai ngoài phòng thí nghiệm có thể tái lập nó.

Vậy nên so sánh trung thực không phải là “một cái đã được xác minh còn một cái thì chưa”. Mà là tín hiệu chính của MathForm-8B là một trình biên dịch và tín hiệu phụ của nó là một phép kiểm tra tính nhất quán, trong khi tín hiệu chính của AesCode-8B là một tập các khẳng định DOM mang tính tất định và tín hiệu phụ của nó là ý kiến của một mô hình, được đóng gói bên trong cùng một điểm tổng thể.

Mỗi mục báo cáo những gì, và điều đó đáng giá bao nhiêu

MathForm-8B báo cáo Pass@8 trung bình đạt 88,06% theo kiểm tra cú pháp và 72,37% theo kiểm tra tính nhất quán trên sáu benchmark. Điểm đáng chú ý là sự phân tán theo từng benchmark: 95,06% tính nhất quán trên FormalIMATH và 94,83% trên ProverBench, sau đó là 63% trên FATE-H và 37% trên FATE-X. Hai benchmark cuối là những tuyên bố khó, thực tế, và sự sụt giảm từ khoảng 90% xuống khoảng 30% phản ánh đúng hình dạng thực tế của năng lực. Tất cả những số liệu này đều do nhà cung cấp báo cáo và chưa được tái lập, và hỗn hợp benchmark nghiêng về các tập dễ hơn.

AesCode-8B báo cáo 82.94 Tổng thể trên thang đánh giá infographic 300 mẫu của Microsoft — Text 94.06, Boundary 88.36, Chart 87.79, Rule 90.07, Content 86.41, Layout 87.80, Style 53.21, Visual 75.80 — với ba lần sinh cho mỗi prompt và không chọn lọc. Microsoft cũng báo cáo rằng nó đánh bại GPT-5.5 được điều kiện bằng tham chiếu ở 81.28 và Claude Opus 4.8 ở 80.39 trên cùng thang đánh giá, rằng lỗi tràn khung vẽ nghiêm trọng tái diễn trên 4.3% của 300 mẫu, và rằng 22.4 điểm Visual tách biệt mô hình đồng hành 32B khỏi chính xương sống của nó. Mọi con số đều là của nhà cung cấp, trên tác vụ của nhà cung cấp, được chấm điểm dựa trên các kênh do nhà cung cấp thiết kế.

Hai bộ số này hoàn toàn không thể so sánh với nhau. Không có tác vụ chung, không có thước đo chung và không có giám khảo chung. Đặt 88,06% bên cạnh 82,94% chẳng khác nào so sánh tỷ lệ đạt hình thức hóa bằng Lean với điểm tổng thể của một infographic, và cả hai mô hình đều chưa từng được đánh giá trên việc mà mô hình kia làm.

Có một sự bất đối xứng đáng được gọi tên vì nó đi ngược lại mô hình mới hơn. Chỉ số nổi bật của MathForm-8B có sẵn một trọng tài bên ngoài được tích hợp ngay trong đó: bất kỳ ai cũng có thể cài Lean, nạp cùng các benchmark đó và kiểm tra xem các phát biểu có biên dịch được hay không. Chỉ số nổi bật của AesCode-8B thì không — các bộ xác minh tất định có thể được chạy lại bởi một người ngoài đủ quyết tâm, nhưng nửa điểm số về hình ảnh phụ thuộc vào một giám khảo mà bài báo chưa xác định danh tính. Một tỷ lệ biên dịch thành công chưa được tái lập là một tuyên bố yếu hơn một bảng benchmark, nhưng vẫn mạnh hơn một điểm rubric chưa được tái lập với một người chấm ẩn danh nằm bên trong.

Việc chạy chúng là một vấn đề khác với cả hai điểm số

Cả hai ngày nay đều là những quyết định tự vận hành. MathForm-8B là lựa chọn rẻ hơn với khoảng cách rất lớn: một checkpoint chỉ-văn-bản khoảng 8,2B với ngân sách sinh khoảng 16K token đầu ra Lean, có thể lượng tử hoá vừa trên một card tầm trung. AesCode-8B là mô hình thị giác-ngôn ngữ 8,8B mà đường phục vụ của nó mang theo cả hình ảnh lẫn văn bản; lệnh của chính card là vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, còn 17,5 GB trọng số bf16 cộng với KV cache cho 24.576 token và hai ảnh nghĩa là card 24 GB sẽ chật vật, và 40-48 GB mới là mức sàn thực tế. Hãy dự trù cả một stack render nếu bạn muốn tự chấm điểm đầu ra của mình, bởi vì đó chính là cách mọi tuyên bố về chất lượng của mô hình được đưa ra.

Chi phí ẩn lớn hơn nằm ở chỗ cả hai mô hình đều là những chuyên gia mà bạn sẽ đưa vào vận hành lâu dài. Một nhóm cần chuẩn hóa và tạo tài liệu giờ đây phải chạy hai luồng phục vụ 8B, hai bộ định dạng prompt, hai kiểu lỗi, và không mô hình nào có thể đảm nhận công việc của mô hình kia. Đó chính là trường hợp mà một lớp định tuyến tồn tại để xử lý: giữ các chuyên gia ở nơi mà yếu tố kinh tế và việc xử lý dữ liệu biện minh cho việc sở hữu một GPU, đồng thời gửi lưu lượng tổng quát đến một thứ được vận hành phía sau cùng endpoint. Cụ thể, các phiên bản tổng quát cùng dòng của hai mô hình cơ sở này đều có thể gọi được — Qwen3-VL-8B-Instruct với giá $0,18 cho mỗi triệu token đầu vào và $0,70 cho mỗi triệu token đầu ra trên ngữ cảnh 131.072 token, cùng với dòng Qwen 3.8 và các checkpoint mở khác — tất cả thông qua một API duy nhất của OrcaRouter bao phủ hơn 200 mô hình, với giá niêm yết từ nhà cung cấp được chuyển nguyên với mức cộng thêm 0% và tự động chuyển đổi dự phòng giữa các nhà cung cấp. Không chuyên gia nào có thể định tuyến ở đây hoặc ở bất kỳ nơi nào khác mà chúng tôi có thể tìm thấy; thứ định tuyến được là mô hình tổng quát mà bạn dùng làm phương án dự phòng khi tác vụ hẹp đã hoàn tất, và đó chính là khác biệt giữa việc thử nghiệm một checkpoint nghiên cứu và biến nó thành một dependency chịu tải.

Chọn giữa chúng, nếu bạn thật sự buộc phải vậy.

Chọn MathForm-8B khi artifact phải biên dịch được. Chuyển đổi ngân hàng bài toán, kho ngữ liệu hình thức cho một trình chứng minh, định dạng trước các phát biểu cho bộ công cụ dựa trên Lean — đó chính là toàn bộ mô tả công việc, và nó là mô hình duy nhất trong hai mô hình được huấn luyện cho việc này. Hãy coi trọng các con số FATE khi bạn xác định phạm vi: trên những phát biểu thực tế khó nhất, khoảng một phần ba cho ra kết quả nhất quán, và dù thế nào bạn cũng sẽ phải xây dựng một bước đánh giá thủ công.

Chọn AesCode-8B khi artifact cần được render. Một bản brief đưa vào, một tài liệu HTML có thể chỉnh sửa xuất ra, bảng vẫn là bảng và biểu đồ là đặc tả biểu đồ, và toàn bộ thứ đó diff trong Git. Chấp nhận mức trần Style — 53.21, một chiều được định nghĩa là không cần chỉnh sửa hình ảnh thêm trước khi giao — như thước đo trung thực cho lượng chỉnh sửa còn lại, và chấp nhận rằng ngữ cảnh 24.576 token chỉ mới được kiểm chứng trên các trang infographic đơn lẻ thay vì các bộ slide nhiều trang mà mọi người thực sự muốn.

Lựa chọn mà hầu hết các đội thực sự sẽ phải đối mặt, tuy nhiên, không phải là một trong hai điều này. Vấn đề là liệu một trong những chuyên gia hẹp này có đáng để triển khai hay không, hay liệu mô hình tổng quát đứng sau nó, được gọi qua API, có đủ gần với khối lượng bạn có hay không. Đó là một buổi chiều thử nghiệm prompt chứ không phải mua GPU, và chính các con số của cả hai card cho bạn lý do để chạy thử: độ nhất quán trên bộ khó của MathForm-8B nằm ở 37%, và điểm Style của AesCode-8B nằm ở 53%, nên không mô hình nào là thứ bạn muốn đưa vào pipeline mà không giám sát.

Cả hai bản phát hành cho bạn thấy điều gì về cách các mô hình được tung ra hiện nay

Hai bản tinh chỉnh 8B, cách nhau tám tuần, đến từ hai phòng thí nghiệm khác nhau, được phát hành không thông báo, không trang sản phẩm và không đánh giá độc lập, cả hai đều xoay quanh một vòng lặp xác minh, cả hai đều Apache 2.0, và không bản nào được bất kỳ ai cung cấp dịch vụ. Chính khuôn mẫu đó mới là câu chuyện, hơn là bản thân mỗi mô hình. Phương pháp nghiên cứu đã dịch chuyển vào hàm thưởng — tín hiệu trình biên dịch của OpenBMB, các kênh đa phương thức tách rời của Microsoft — và những sản phẩm được công bố đã trở thành công thức huấn luyện cộng với trọng số, còn bài báo thì đến sau, nếu có.

Điều đó có nghĩa là với bất kỳ ai đọc một so sánh như thế này, trong một thời gian, số liệu của chính nhà cung cấp là tất cả những gì bạn có, và câu hỏi hữu ích không phải là chúng cao đến mức nào mà là chúng có thể kiểm chứng được đến mức nào. Tỷ lệ tràn của AesCode-8B và mức trần Style của nó là những tuyên bố có thể kiểm chứng được nhưng được trình bày như những thất bại. Chỉ số nhất quán FATE-X của MathForm-8B cũng vậy. Đó là những con số cần đọc, và là những con số bạn nên quay lại tự chạy lại ngay khi các công cụ kiểm tra có thể tái lập được từ đầu đến cuối.