Microsoft-Decision-1 vs Intern-Decision-2B: Nhanh hơn chín mili giây và kém hiệu chỉnh hơn một cách đo lường được

Có một con số trong chính bảng của InternLM đáng lẽ không nên tồn tại, và đó chính là lý do khiến phép so sánh này đáng giá hơn cả một bảng thông số kỹ thuật. Intern-Decision-2B — 2.213.241.664 tham số, được tinh chỉnh từ Qwen/Qwen3.5-2B, tải lên Hugging Face lúc 05:36:19 UTC ngày 26 tháng 9 năm 2026 mà không hề có một thông báo nào — đạt 33,28 ms độ trễ trung bình mỗi truy vấn trên một chiếc RTX 4090 duy nhất, tức nhanh hơn đôi chút so với người anh em 852 triệu tham số của chính nó ở mức 33,98 ms. Nó cũng đạt mức hiệu chuẩn tệ nhất trong gia đình mình: sai số hiệu chuẩn kỳ vọng là 0,100 so với 0,066 của bản 0,8B, cùng nhiệt độ khớp là 2,100509348278 so với 2,747760550703 của bản 0,8B. Trong khi đó Microsoft-Decision-1, vốn được cung cấp rộng rãi trên Microsoft Foundry kể từ ngày 8 tháng 10 năm 2026, lại không công bố con số độ trễ lẫn sai số hiệu chuẩn — chỉ có một đoạn phương pháp luận mô tả cách đo cả hai. Vậy nên câu hỏi mà cuộc đối đầu này thực sự đặt ra không phải là trong hai bên, bên nào tốt hơn. Mà là bạn đang mua thứ gì khi mua kích thước tầm trung của bất cứ thứ gì.

Cả hai mô hình đều là bộ chấm điểm quyết định: đầu vào là trạng thái, đầu vào là tập câu hỏi có giới hạn, đầu ra là xác suất đã hiệu chỉnh, không có văn bản được sinh ra và không có token nào cần phân tích. Chính hợp đồng chung đó khiến những khác biệt trở nên rõ ràng. Microsoft-Decision-1 là một API Foundry chỉ văn bản, được host, trên nền Qwen3.5-9B với cửa sổ 32.768 token, không có trọng số phân tán và không có lộ trình tinh chỉnh. Intern-Decision-2B là một checkpoint Apache-2.0 với giấy phép Qwen thượng nguồn được giữ nguyên dưới dạng LICENSE-QWEN, khoảng 4,46 GB repository, mã suy luận tùy chỉnh và không có endpoint được host ở bất kỳ đâu.

Cỡ trung thực sự để làm gì

InternLM tung ra ba checkpoint trong bốn mươi giây: bản 0.8B lúc 05:35:57, bản này lúc 05:36:19, bản 4B lúc 05:36:37. Trên mức trung bình bảy bộ kiểm thử của chính nhà cung cấp, dòng mô hình này tăng dần theo đúng thứ tự bạn hẳn mong đợi — 79.38, 84.68, 90.02 — và đây là chỗ duy nhất bản 2B trông giống một lựa chọn hợp lý để mua. Ở mọi chỗ khác, nó trông như kích cỡ mà không ai lại cố ý chọn.

Xử lý prompt chiếm ưu thế trong một cuộc gọi quyết định, và đó là lời giải thích mang tính cơ học cho sự đảo ngược độ trễ chứ không phải một điều bí ẩn. Một bộ chấm điểm thực hiện đúng một lượt truyền xuôi qua một prompt có độ dài được quyết định bởi state, schema và các mô tả lựa chọn — không bao giờ bởi bất cứ thứ gì mô hình viết ra, vì nó không viết gì cả. Trong chế độ đó, số lượng tham số là một chi phí bậc hai, nên lý do thông thường để tìm đến checkpoint nhỏ nhất không còn áp dụng: bạn không tiết kiệm thời gian, bạn tiết kiệm bộ nhớ. Toàn bộ repository của 0.8B vào khoảng 1.73 GB so với 4.46 GB của mô hình này, và đó là lý do chân thực để thích nó hơn. Tuyên bố thực sự duy nhất của 2B là việc nó tình cờ là cái nhanh nhất trong nhóm nhanh, với khoảng cách nhỏ đến mức chỉ là nhiễu.

So với Microsoft-Decision-1, tuyên bố đó gần như không liên quan, bởi vì hai mô hình không nằm trong cùng một chế độ độ trễ. Tốc độ của một endpoint được lưu trữ là một hàm của hình thức triển khai của bạn — serverless so với thông lượng được cấp phát trên cùng một SKU tiêu chuẩn — trước khi nó là một hàm của mô hình, và Microsoft không công bố số liệu trên mỗi cuộc gọi để so sánh. Những gì Microsoft công bố là một ràng buộc vận hành cứng nhắc đi theo hướng ngược lại: suy luận theo lô bị vô hiệu hóa. Không có kênh ngoại tuyến để phân bổ dần một lần chấm điểm hàng loạt, vì vậy một pipeline Microsoft-Decision-1 phải trả chi phí tương tác cho mỗi quyết định, trong khi một checkpoint tự lưu trữ phải trả bằng giờ GPU dù có đang chấm điểm hay không.

Cột hiệu chuẩn, nơi phần giữa thua

Đọc ba thẻ Intern-Decision cùng nhau và họ mô hình không còn hành xử theo cách có thể dự đoán được nữa. Độ chính xác là đơn điệu theo kích thước; hiệu chuẩn thì không. Bản 2B mang ECE là 0,100 — yếu nhất trong ba — và nhiệt độ khớp là 2.100509348278, thấp hơn đáng kể so với 2.747760550703 của bản 0.8B. Thẻ hướng dẫn bạn dùng mô-đun suy luận đi kèm với kích thước bạn đã tải xuống, vì các hiệu chuẩn mặc định là theo từng checkpoint; bất kỳ ai sao chép một wrapper từ mô hình anh em này sang mô hình anh em khác đều âm thầm áp dụng sai nhiệt độ.

Bản thân phép biến đổi này đáng để hiểu trước khi bạn coi con số 0.100 đó như một phán quyết về các trọng số. Nó là một softmax trên các logits ứng viên của trường, tiếp theo là một softmax thứ hai trên log của phân phối đó chia cho nhiệt độ. Vì nó chạy sau softmax đầu tiên và bảo toàn thứ tự, nó hoàn toàn không thể thay đổi argmax. Nó dịch chuyển độ tin cậy, xác suất "có" và giá trị kỳ vọng của một câu hỏi điểm số, và giữ nguyên nhãn. Nếu pipeline của bạn đọc nhãn, nhiệt độ là một thao tác rỗng và ECE chỉ là chuyện lạ. Nếu pipeline của bạn đọc xác suất — đặt ngưỡng cho chúng, xếp hạng theo chúng, đưa chúng vào một phép tính giá trị kỳ vọng — thì ECE 0.100 chính là sự khác biệt giữa một ngưỡng mang đúng ý bạn viết và một ngưỡng không như vậy. Phản ứng đúng đắn là tự khớp nhiệt độ của riêng bạn trên chính các trường hợp đã gán nhãn của bạn, chứ không phải kết luận rằng các trọng số là tồi.

Microsoft-Decision-1 đòi hỏi đúng cùng một công việc, nhưng với ít dữ liệu khởi đầu hơn. Tab Benchmarks của nó nêu rằng độ chính xác, sai số hiệu chuẩn, recall an toàn, tỷ lệ dương tính giả và tính nhất quán công bằng đã được đo trên các benchmark ra quyết định công khai và cộng đồng cùng các bộ kiểm thử nội bộ được giữ riêng, rằng thứ tự lựa chọn đã được thay đổi, rằng các kiểm định thống kê theo cặp đã được áp dụng, và rằng mô hình “hoạt động ngang bằng với các mô hình ra quyết định hàng đầu và vượt trước các mô hình ra quyết định mở khác được đánh giá bằng cùng phương pháp luận.” Không có ECE. Không có Brier. Không có temperature. Không có bảng độ chính xác. Mô hình mà toàn bộ đề xuất giá trị của nó là một xác suất đáng tin cậy lại chính là mô hình trong so sánh này không có một con số hiệu chuẩn nào được công bố cả.

Ranh giới hợp đồng: bốn điều mà mô hình được host sẽ không làm

Hai mô hình nhận được thứ có vẻ là cùng một lệnh gọi, và những khác biệt nằm ở các rìa của nó.

• Phương thức — Microsoft-Decision-1 được nêu rõ là chỉ hỗ trợ văn bản và không nhận hình ảnh, âm thanh hay video. Intern-Decision-2B chấp nhận tối đa tám hình ảnh cùng với trạng thái, điều này khiến nó trở thành ứng viên cho việc sàng lọc ảnh chụp màn hình và kiểm tra bố cục mà API được lưu trữ không thể đáp ứng ở bất kỳ mức độ chính xác nào.

• Giới hạn đầu vào và chế độ lỗi — Microsoft-Decision-1 thực hiện một lần gọi duy nhất trên tối đa 32.768 token. Intern-Decision-2B khai báo DecisionEngine(max_length=8192) và từ chối đầu vào vượt quá kích thước thay vì cắt bớt, đây là hành vi đúng đắn đối với một bộ chấm điểm, đồng thời cũng là một rào cản cứng, bởi vì trạng thái, lược đồ và khung đều phải hiện diện trong một lượt; không có chiến lược chia nhỏ nào bảo toàn được giao kèo.

• Hình dạng câu hỏi — InternLM ghi nhận từ một đến mười sáu câu hỏi mỗi lần gọi, với tối đa 62 lựa chọn cho mỗi câu, trải trên ba kiểu trường (choice, score, noul), trong đó noul là dạng nhị phân có/không, trả về một xác suất, còn score trả về giá trị kỳ vọng có trọng số theo xác suất trên một thang đo do bạn đặt tên. Microsoft ghi nhận các định dạng — có/không, trắc nghiệm, đánh giá, phân loại, rubric — cùng một tùy chọn không trả lời được hỗ trợ tường minh, chẳng hạn "cannot tell", khi bằng chứng không đủ, và đây chính là dòng hữu ích nhất trên trang đối với bất kỳ ai đang viết logic leo thang.

• Giá — trang mô hình Microsoft-Decision-1 không ghi mức giá; các liên kết định giá dẫn ra ngoài đến trang định giá của Microsoft, vì vậy chi phí cho mỗi quyết định là thứ bạn đọc từ Azure hoặc từ hóa đơn, với 0% trong đó có thể quy cho token đầu ra vì không có token đầu ra nào. Intern-Decision-2B không tốn gì cho mỗi lần gọi và tốn mọi thứ ở thời gian GPU, và nó không có nhà cung cấp dịch vụ lưu trữ. Dung lượng lưu trữ của nó vào khoảng 4.46 GB, trải khắp một phân mảnh ngôn ngữ 3.76 GB, một tháp thị giác 612.5 MB và một bộ chiếu 50.3 MB.

Điều gì đã được xác nhận, và điều gì chỉ là lời từ phía nhà cung cấp

Giữ tách bạch hai hạng mục đó chính là toàn bộ nguyên tắc của dòng này. Được xác nhận bởi một bản liệt kê tệp hoặc một phản hồi HTTP: số lượng tham số, bản đồ phân mảnh, cặp giấy phép, mô hình cơ sở, kiến trúc bên dưới — một Qwen3_5ForConditionalGeneration với 24 lớp, kích thước ẩn 2,048, 8 đầu truy vấn đối lại 2 đầu khóa-giá trị, chiều đầu là 256, một mẫu lặp lại gồm ba lớp chú ý tuyến tính ứng với một lớp chú ý đầy đủ, một lớp dự đoán đa token được giữ lại và trần nhúng 262,144 vị trí mà trần engine 8,192 token khiến cho gần như không còn ý nghĩa trên thực tế.

Do nhà cung cấp báo cáo và không thể tái lập: mọi con số độ chính xác, mọi chỉ số độ trễ và cả temperature. Không có bài báo, không có mục trên arXiv, không có bài đăng ra mắt, không có nhật ký thay đổi và không có đánh giá độc lập. Space demo trả về 401, nghĩa là nó không công khai chứ không phải bị hỏng. Kho GitHub xuất hiện sau khi mô hình ra đời — ba commit, mã huấn luyện, hai backend suy luận, một gói đánh giá với 10.751 dòng kiểm thử, một benchmark hiệu chỉnh 96 trường hợp và một hướng dẫn tái lập — có nhiều tài liệu hơn mức mà hầu hết các bản phát hành âm thầm nhận được, và nó không kèm trọng số, không kèm dữ liệu huấn luyện và không kèm giấy phép mã nguồn. Microsoft đang ở một vị thế khác nhưng kề cận: phương pháp luận của họ là có thật và tuyên bố của họ mang tính định tính, và hiện tại cả hai công ty đều không ở vị thế để con số trung tâm của mình được kiểm chứng bởi bất kỳ ai ngoài bạn.

OrcaRouter nằm ở đâu trong một pipeline như thế này

Cả hai mô hình đều không có trong danh mục của chúng tôi, và không có gì ở đây nên được hiểu là một tuyên bố về tính khả dụng. Một mô hình trả về xác suất thay vì văn bản không phải là thứ bạn định tuyến các chat completion tới, và điều đó đúng với cả hai mô hình này. Thứ chúng tôi thực sự cung cấp là nửa sinh tạo của vòng lặp mà những bộ chấm điểm kia tồn tại để phục vụ: hơn 200 mô hình nằm sau một khóa tương thích OpenAI, chuyên viết bộ tiêu chí đánh giá, soạn thảo các câu trả lời ứng viên và phát ra lệnh gọi công cụ mà sau đó một bộ chấm điểm sẽ chấm trước khi nó thực thi. Giá niêm yết của nhà cung cấp được chuyển tiếp với mức chênh lệch 0%, nên khi nhà cung cấp cắt giá ở phía sinh tạo thì giá bên chúng tôi cũng được cập nhật ngay trong cùng ngày, và nếu bạn muốn đặt ngưỡng của mình vào một giám khảo duy nhất, DSL định tuyến có thể kết hợp nhiều mô hình vào một lệnh gọi duy nhất và tính năng hợp nhất mô hình báo cáo kết quả đó như một trường mà bạn có thể chấm điểm. Cơ chế chuyển đổi dự phòng tự động giữ cho phía đó luôn hoạt động khi một nhà cung cấp đơn lẻ bị suy giảm, điều này càng quan trọng trong một vòng lặp chấm điểm mọi thứ nó thấy hơn là ở một vòng lặp chỉ thỉnh thoảng trả lời người dùng.

Điểm mấu chốt

Microsoft-Decision-1 đã chính thức khả dụng trên Microsoft Foundry kể từ ngày 8 tháng 10 năm 2026: được lưu trữ dưới dạng dịch vụ, chỉ văn bản, 32,768 token, một mô hình nền Qwen3.5-9B do Microsoft hậu huấn luyện, không có trọng số phân tán, và một phần benchmark ghi lại phương pháp luận của nó mà không in ra một con số nào — kể cả không đưa ra độ trễ, với suy luận theo lô đã bị tắt. Intern-Decision-2B là một checkpoint Apache-2.0 có 2,213,241,664 tham số từ ngày 26 tháng 9 năm 2026, nhanh nhất trong ba mô hình anh em của nó ở 33.28 ms trên 4090 và có hiệu chuẩn tệ nhất với ECE là 0.100, với nhiệt độ được khớp là 2.100509348278, thứ không thể thay đổi nhãn nhưng sẽ thay đổi mọi độ tin cậy mà bạn dùng để đặt ngưỡng. Nếu bạn muốn kích thước ở giữa, lý lẽ trung thực dành cho nó rất mỏng manh: hãy trả thêm 2.7 GB để có độ chính xác của 4B hoặc chấp nhận mức tiêu tốn tài nguyên của 0.8B, và dù bạn chọn hướng nào, hãy tự khớp hiệu chỉnh của riêng bạn trước khi một ngưỡng tiến đến gần môi trường production.

Điều chúng tôi thực sự cung cấp là nửa phần sinh tạo của vòng lặp mà những bộ chấm điểm kia tồn tại để phục vụ: hơn 200 mô hình đằng sau một API key tương thích với OpenAI để viết ra tiêu chí chấm điểm, phác thảo các câu trả lời ứng viên và phát ra lệnh gọi công cụ mà sau đó một bộ chấm điểm sẽ chấm trước khi nó được thực thi.