Ember-1 so với MathForm-8B: Hai mô hình được xây dựng bằng cách thu hẹp một cơ sở vay mượn

Ember-1 và MathForm-8B cùng chia sẻ một chiến lược mà cả hai phòng thí nghiệm đều không quảng cáo như một chiến lược: cả hai đều là những phiên bản thu hẹp của một mô hình do người khác huấn luyện. Ember-1 là sản phẩm phái sinh chuyên biệt hóa của Fireworks Research từ Kimi K3 của Moonshot AI, công bố ngày 23 tháng 9 năm 2026, được huấn luyện lại để đạt độ chính xác của K3 với lượng token ít hơn khoảng 40%. MathForm-8B là mô hình tự hình thức hóa 8B của OpenBMB, âm thầm ra mắt ngày 14 tháng 8 năm 2026 dưới dạng bản tinh chỉnh theo giấy phép Apache-2.0 từ Qwen3-8B của Alibaba, có khả năng chuyển toán học phi hình thức thành các phát biểu định lý Lean 4 mà trình biên dịch có thể kiểm tra. Một bản thu hẹp đã loại bỏ phần suy luận lãng phí và giữ nguyên năng lực tổng quát. Bản còn lại đã loại bỏ gần như toàn bộ năng lực tổng quát và đổi lấy khả năng kiểm chứng. Đặt chúng cạnh nhau là cách rõ ràng nhất để thấy cái giá thực sự của một sự chuyên biệt hóa, bởi hai mô hình đã dành ngân sách huấn luyện của mình cho hai phía đối lập của bảng cân đối đó.

Hai loại thu hẹp

Can thiệp của Fireworks Research mang tính hành vi. Ember-1 giữ nguyên kiến trúc của Kimi K3 và độ bao phủ của nó — toán học, lập trình, tuân theo hướng dẫn, hội thoại, tìm kiếm, sử dụng công cụ và kỹ thuật phần mềm đều xuất hiện trong hỗn hợp huấn luyện — và chỉ thay đổi thời gian mô hình cân nhắc trước khi trả lời. Kết quả được báo cáo là độ dài suy luận giảm 35–50% mà không mất độ chính xác trên bảy bài đánh giá và hai thử nghiệm A/B sản xuất của khách hàng, với một khối lượng công việc lập trình sản xuất giảm từ 49,3K xuống 29,9K token đầu ra trong khi điểm số giữ ở mức 0,753 so với 0,751. Mọi số liệu đều do nhà cung cấp báo cáo và chưa được tái lập.

Sự can thiệp của OpenBMB mang tính hợp đồng. MathForm-8B lấy Qwen3-8B và dồn toàn bộ ngân sách huấn luyện vào một dạng đầu ra duy nhất: một câu lệnh Lean 4 với phần tiêu đề imports và một định lý có tên. Quy trình là tinh chỉnh có giám sát trên FormalVerse — một kho ngữ liệu gồm khoảng 367.000 ví dụ Lean 4 đã được kiểm chứng mà OpenBMB xây dựng và phát hành cùng với mô hình — tiếp theo là học tăng cường sử dụng việc biên dịch Lean và phản hồi nhất quán ngữ nghĩa làm tín hiệu phần thưởng. Mô hình không giải chứng minh. Nó viết câu lệnh mà một trình chứng minh sẽ hoàn thiện, và cách bài báo tự định khung mô tả đánh giá sáu bộ chuẩn là điểm mấu chốt của toàn bộ việc này.

Mỗi người đã từ bỏ điều gì

Ember-1 đánh đổi rất ít trên giấy tờ, và đó chính là toàn bộ tuyên bố. Bảng công bố của nó cho thấy thắng lợi trên Terminal Bench 2.1 với 82,0% so với 80,9% của Kimi K3 Max và trên DeepSWE 1.1 với 75,2% so với 66,4%, cùng những thất bại sát nút trên SWE-bench Verified với 92,2% so với 93,2% và SWE-Interact với 20,0% so với 21,3%. Đó là các con số do nhà cung cấp đưa ra trên những bộ do nhà cung cấp tự chọn, nhưng hình dạng thì nhất quán: một mô hình không hẳn đã mất năng lực mà đúng hơn là đã chuyển hướng nơi nó dành nỗ lực. Tuy nhiên, mức tiết kiệm token dao động từ 51,9% trên Terminal Bench xuống 5,9% trên τ-2 Bench Airline, nên “khoảng 40%” là một mức trung bình trải trên một biên độ rất rộng.

MathForm-8B đã từ bỏ phần lớn những gì Qwen3-8B được biết đến. Nó không thể duy trì một cuộc trò chuyện tổng quát, không bao gồm 119 ngôn ngữ và phương ngữ mà Qwen3-8B được huấn luyện, và không chấp nhận hình ảnh hay âm thanh. Ngân sách tạo của nó được thiết kế cho đầu ra Lean, không phải cho suy luận hỗn hợp mở rộng. Những gì nó giữ lại là một giấy phép permissive và một dấu chân nhỏ: bốn mảnh safetensors trong BF16, chạy dưới Transformers, vLLM hoặc SGLang phía sau một endpoint tương thích OpenAI, với một đường biên dịch yêu cầu một Kimina Lean Server trên Lean 4.21.0.

Những con số đo những thứ khác nhau, và khoảng cách chính là điểm mấu chốt

Con số nổi bật của Ember-1 là tỷ lệ phần trăm các tác vụ được một tác nhân hoàn thành chính xác — Terminal Bench 2.1, 89 mẫu, 82.0%. Các con số nổi bật của MathForm-8B là điểm Pass@8 trung bình trên sáu bài kiểm chuẩn tự động hình thức hóa: 88.06% theo kiểm tra cú pháp và 72.37% theo kiểm tra tính nhất quán nghiêm ngặt hơn. Những con số đó không nằm trên cùng một trục. Một bên đo lường liệu một tác nhân có hoàn thành một công việc trong terminal hay không; bên kia đo lường liệu một phát biểu định lý được tạo ra có phân tích cú pháp được hay không và liệu nó có cùng ý nghĩa với bài toán không chính thức mà nó xuất phát từ đó hay không.

Chênh lệch 88,06 so với 72,37 trong chính kết quả của MathForm mới là con số đáng suy ngẫm hơn. Khoảng cách giữa “cái này biên dịch được” và “cái này biên dịch được và nói đúng điều tôi muốn nói” vào khoảng mười sáu điểm, và đó chính là kiểu thất bại khiến tự động hình thức hóa trở nên khó: một phát biểu vượt qua kiểm tra kiểu nhưng lại âm thầm làm yếu tuyên bố gốc còn tệ hơn một lỗi rõ ràng, bởi vì không có gì ở các bước sau đánh dấu nó. Trên những bộ khó nhất, kiểm tra tính nhất quán giảm xuống 63% trên FATE-H và 37% trên FATE-X, trong khi những bộ dễ như FormalIMATH đứng ở 95,06% và ProverBench ở 94,83%. Đó là một chuyên gia trung thực về chỗ mà một chuyên gia còn yếu, và điều đó hữu ích hơn một con số trung bình duy nhất.

Sự tương phản, xét theo từng chiều

• Mô hình cơ sở — Ember-1: Kimi K3. MathForm-8B: Qwen3-8B.

• Việc huấn luyện đã thay đổi điều gì — Ember-1: mô hình suy luận trong bao lâu, với năng lực được giữ nguyên. MathForm-8B: mô hình xuất ra gì, với tính tổng quát phần lớn bị đánh mất.

• Tham số — Ember-1: không được tiết lộ. MathForm-8B: ~8B, dense, BF16.

• Hợp đồng đầu ra — Ember-1: văn bản thông thường và các lệnh gọi công cụ, ở chất lượng cấp K3. MathForm-8B: một phát biểu Lean 4 với phần tiêu đề và một định lý có tên.

• Giấy phép và trọng số — Ember-1: không công bố; bản xem trước nghiên cứu thông qua nền tảng riêng của nhà cung cấp. MathForm-8B: Apache 2.0, cả trọng số lẫn bộ dữ liệu đều có thể tải xuống.

• Tiêu đề được báo cáo — Ember-1: 82.0% Terminal Bench 2.1 với số token ít hơn 51.9%. MathForm-8B: Pass@8 trung bình 88.06% theo kiểm tra cú pháp, 72.37% theo kiểm tra tính nhất quán.

• Xác minh độc lập — không bên nào; cả hai đều do nhà cung cấp báo cáo và chưa được tái lập.

Dòng giấy phép quyết định nhiều hơn các bài kiểm chuẩn

Dù có khác biệt về các con số, khác biệt thực tế giữa hai bản phát hành này nằm ở cách phân phối. MathForm-8B là một tệp. OpenBMB đã công bố trọng số, bộ dữ liệu FormalVerse và bài báo trong cùng một ngày, theo Apache 2.0, không có thông báo và không có API chạy sẵn — thẻ mô hình chính là buổi ra mắt. Bạn có thể tải nó về vào chiều nay và chạy nó trên một GPU duy nhất, và không ai có thể lấy lại nó. Ember-1 là một dịch vụ. Không có trọng số, không có giá công bố, và cửa sổ truy cập được mô tả là khoảng thời gian serverless hai tuần mà việc tiếp tục phụ thuộc vào nhu cầu. Hôm nay bạn có thể gọi nó, nhưng bạn không thể chắc rằng mình có thể gọi nó vào tháng 11.

Sự khác biệt đó cũng quyết định mỗi mô hình có thể được dùng để làm gì. Một thành phần hình thức hóa nằm bên trong một pipeline do bạn kiểm soát, được ghim vào một phiên bản, với bộ công cụ Lean trên cùng máy — đó là lý do vì sao một checkpoint Apache-2.0 không bị gated là hình dạng phù hợp cho công việc của MathForm-8B, và vì sao liên kết mã GitHub bị thiếu trên README của nó (vẫn là placeholder tại thời điểm viết) là một khoảng trống khó chịu hơn bất kỳ con số benchmark nào. Một mô hình chi phí suy luận thuộc về phía sau một API, nơi hóa đơn token là thứ đang được tối ưu hóa, và nơi các nhà cung cấp cạnh tranh về giá và độ trễ. Hình dạng của Ember-1 cũng phù hợp với công việc của nó; điều đó chỉ có nghĩa là sự phụ thuộc mang tính thương mại chứ không phải kỹ thuật.

Nơi mà một pipeline sẽ sử dụng cả hai

Hai mô hình này bổ trợ cho nhau chứ không cạnh tranh, và cách kết hợp rất dễ mô tả: một chuyên gia hình thức hóa chuyển một bài toán thành một phát biểu có thể kiểm chứng, còn một mô hình suy luận làm việc trên phát biểu đó hoặc phần kỹ thuật xung quanh. Cả hai đều không có trên OrcaRouter — MathForm-8B chỉ được tự lưu trữ, còn Ember-1 nằm trên bản xem trước của chính nhà cung cấp — nhưng bản thân cách kết hợp này là một mẫu mà DSL định tuyến của chúng tôi tồn tại vì nó. Kết hợp nhiều mô hình vào một lệnh gọi duy nhất là cách một pipeline có được một chuyên gia và một mô hình tổng quát mà không cần duy trì hai đường tích hợp và hai hợp đồng, còn hợp nhất mô hình tiến xa hơn một bước bằng cách cho phép một nhóm mô hình cùng trả lời khi chế độ thất bại của một mô hình đơn lẻ là tốn kém.

Đối với một ngăn xếp hình thức hóa cụ thể, lập luận ủng hộ việc hợp thành mạnh hơn thường lệ. Chế độ thất bại có thể thấy được là một phát biểu biên dịch được và mang ý nghĩa hơi khác, và biện pháp phòng vệ rẻ nhất trước một lỗi âm thầm là một mô hình thứ hai đọc cùng vấn đề — đó là một quyết định định tuyến, không phải quyết định huấn luyện.

Cái nào đáng mua hơn

Nếu bạn cần toán học có thể kiểm chứng bằng máy, MathForm-8B là mô hình duy nhất trong hai mô hình tạo ra được loại toán đó, và cái giá chính của nó là tính tổng quát mà dù sao bạn cũng sẽ chẳng dùng đến cho tác vụ này. Hãy tải nó về, dự trù ngân sách cho máy chủ Lean, và tự xây dựng đánh giá của riêng bạn — bài báo của OpenBMB sẽ không cho bạn biết nó hoạt động ra sao trên phân phối của bạn.

Nếu bạn cần một bộ suy luận tổng quát với chi phí token thấp hơn, Ember-1 là dành cho bạn, và bước tiếp theo đúng đắn là chạy shadow traffic đối chiếu với bất kỳ thứ gì bạn đang vận hành hôm nay, thay vì so sánh benchmark. Rủi ro của nó nằm ở tính sẵn sàng, không phải năng lực, và đó là rủi ro bạn có thể phòng ngừa bằng cách giữ lớp định tuyến giữa ứng dụng của bạn và mô hình.

Kết luận khó chịu cho bất kỳ ai hy vọng một trong hai sẽ giải quyết được câu hỏi là cả hai đều chưa được đánh giá một cách độc lập. MathForm-8B đã công khai được sáu tuần và chưa có bên thứ ba nào công bố bản tái lập; Ember-1 mới công khai được một ngày. Cả hai đều yêu cầu bạn trở thành người đánh giá, đó là tình trạng bình thường khi chọn một mô hình chuyên biệt vào năm 2026.

Điều chúng chứng minh là chiến lược thu hẹp hoạt động theo cả hai hướng. Một mô hình tiên phong có thể được làm cho rẻ hơn mà không bị làm cho kém đi, và một mô hình nền tảng nhỏ có thể được làm cho chặt chẽ bằng cách hướng việc huấn luyện của nó vào một trình biên dịch. Câu hỏi thú vị không phải là cách tiếp cận nào trong hai cách này sẽ thắng, mà là mỗi cách còn cần thiết thêm bao lâu nữa một khi các kỹ thuật bên trong chúng trở thành thông lệ tiêu chuẩn.