Pareto 26.10 so với Pareto 26.9: Một con số tạo nên sự khác biệt giữa hai bản phát hành này

So sánh Pareto 26.10 với Pareto 26.9phần lớn là một nghiên cứu về những thứ không hề thay đổi. Cùng một nhà cung cấp, cùng kiến trúc tổng hợp, cùng mức phản hồi tối đa 131.072 token, cùng năm tham số được công bố, cùng mức giá công bố trên trang giá của chính nhà cung cấp, và — trên phép đo chuẩn duy nhất mà cả hai bản phát hành cùng chia sẻ — chênh lệch một phần mười điểm nghiêng về phía mô hình cũ hơn. Trên những khía cạnh mà người ta thường dùng để so sánh các mô hình, hai bản này là cùng một sản phẩm khoác lên mình những số phiên bản khác nhau. Nhưng ở một khía cạnh thì không, và đó chính là khía cạnh quyết định loại khối lượng công việc nào có thể dùng một trong hai mô hình này: cửa sổ ngữ cảnh, nơi 26.9 cung cấp 262.144 token và 26.10 cung cấp 1.048.576. Những sự cố AI và sự cố tác nhân đã được ghi nhận đằng sau các bản phát hành như bản này được tập hợp trong the OrcaRouter AI Incident Archive nơi mỗi mục đều đi kèm nguồn riêng, mức độ nghiêm trọng, cấp độ tin cậy và cờ tranh chấp.

Cả hai đều đang hoạt động. pareto-26.10 là bản phát hành đã trở thành mặc định đằng sau bí danh pareto vào ngày 15 tháng 10 năm 2026, khi Unbiased chuyển bản phát hành chính thức (GA) của mình sang bản này; pareto-26.9 là bản phát hành tháng Chín mà nhà cung cấp nói rằng "vẫn còn khả dụng" cho bất kỳ ai muốn ở lại. Đó là toàn bộ quyết định mà người gọi đang đối mặt hôm nay, và phần còn lại của trang này là thông tin chi tiết đằng sau quyết định đó.

Những sự thật xung quanh

Cả hai mô hình đều được tài liệu ghi nhận là nhận đầu vào văn bản và hình ảnh và trả về văn bản, và cả hai đều không công bố định danh Hugging Face — trọng số đều đóng ở cả hai phía của phép so sánh này, nên không có gì để tải xuống và tự vận hành. Không mô hình nào có benchmark độc lập. Cả hai đều được cung cấp bởi một nhà cung cấp duy nhất, chính Unbiased, nghĩa là không có máy chủ thứ hai để chuyển đổi dự phòng trong chính hệ thống của nhà cung cấp đối với cả hai bản phát hành. Do đó, phần so sánh dưới đây là giữa hai cấu hình của một dòng sản phẩm duy nhất thuộc một nhà cung cấp, chứ không phải giữa hai hệ sinh thái.

Ngữ cảnh chính là toàn bộ lập luận

Mức tăng ngữ cảnh 4× nghe như một dòng thông số kỹ thuật, cho đến khi bạn đối chiếu nó với những gì người ta thực sự làm với các mô hình ngữ cảnh dài.

Ở 262.144 token, một phiên tác nhân trên toàn bộ kho mã, một bản ghi hội thoại hỗ trợ dài hay một luồng nghiên cứu kéo dài nhiều giờ là một bài toán chia nhỏ. Bạn truy xuất, bạn tóm tắt, bạn giữ một cửa sổ trượt và bạn chấp nhận rằng mô hình nhìn thấy một bản tái dựng của nhiệm vụ chứ không phải chính nhiệm vụ đó. Ở 1.048.576 token, những khối lượng công việc đó vừa vặn — không phải lúc nào cũng thoải mái và không hề rẻ ở mức 0,80 đô la cho mỗi triệu token đầu vào khi không có lần trúng bộ nhớ đệm, nhưng chúng vừa vặn. Khác biệt thực tế giữa hai bản phát hành là liệu pipeline của bạn có cần một lớp truy xuất giữa dữ liệu và mô hình hay không.

Đó là một quyết định kỹ thuật thực sự, và cũng là quyết định duy nhất trên trang này có một câu trả lời có thể biện minh được. Mọi thứ còn lại đều đủ sát nhau đến mức nên đưa ra lựa chọn dựa trên điều gì đó khác ngoài chất lượng.

Song song, từng chiều một

• Chuỗi mô hình — pareto-26.10 (mặc định đứng sau pareto kể từ 2026-10-15) so với pareto-26.9 (được giữ lại, không phải mặc định).

• Cửa sổ ngữ cảnh — 1.048.576 token so với 262.144 token.

• Phản hồi tối đa — 131.072 token trên cả hai. Không thay đổi giữa các bản phát hành.

• Phương thức — đầu vào văn bản + hình ảnh, đầu ra văn bản, ở cả hai.

• Các tham số được khai báo — max_tokens, temperature, top_p, tools, tool_choice trên 26.10; cùng bộ tham số đó cộng thêm response_format trên 26.9.

• Gọi công cụ — tool_choice bị giới hạn ở auto trên {{1}}26.10{{/1}}; mô hình quyết định có gọi hay không, bạn không thể ép buộc.

• Trọng số — cả hai đều đóng; không có mã định danh Hugging Face trong bản ghi nào.

• Nhà cung cấp dịch vụ — một, chính là nhà cung cấp, trên cả hai.

• Mức giá công bố — $0.80 đầu vào / $0.03 bộ nhớ đệm / $3.20 đầu ra cho mỗi triệu trên cả hai, theo trang định giá hiện tại của nhà cung cấp.

• DeepSWE v1.1 — 69,9% với $0,24 mỗi tác vụ trên 26.10 so với 70,0% với $0,29 mỗi tác vụ trên 26.9, cả hai đều do nhà cung cấp vận hành.

Hai trong số những hàng đó xứng đáng có một đoạn văn riêng, vì chúng là những hàng thường bị báo cáo sai.

Sự khác biệt về đầu ra có cấu trúc mà không ai quảng cáo

Danh sách tham số không giống hệt nhau. Bản ghi danh mục cho 26.9 công bố response_format trong số các tham số được hỗ trợ; bản ghi cho 26.10 thì không. Phạm vi được công bố cho 26.10 là max_tokens, temperature, top_p, tools và tool_choice, hết.

Hãy đọc kỹ điều đó thay vì chỉ lướt qua như một tiêu đề: việc một tham số không xuất hiện trong danh sách được khai báo không phải bằng chứng rằng endpoint từ chối nó, và tài liệu API của chính nhà cung cấp cũng không liệt kê danh sách nào trong hai danh sách đó. Nhưng nếu pipeline của bạn phụ thuộc vào chế độ JSON hoặc đầu ra ràng buộc theo schema, và bạn đang chuyển từ 26.9 lên 26.10 với giả định rằng bản phát hành mới hơn là một tập cha nghiêm ngặt, thì giả định đó không được bất kỳ thứ gì đã công bố hỗ trợ. Hãy kiểm thử trên lưu lượng của chính bạn trước khi di chuyển, hoặc lên kế hoạch xác thực đầu ra ở phía client. Đó là một chuyện nhỏ có thể biến thành sự cố vào một ngày thứ Ba.

Hai bảng giá hiện hành không thống nhất về giá của 26.9

Đây là phần rối rắm nhất trong việc so sánh và cũng là phần dễ ảnh hưởng đến một quyết định thực tế nhất.

Unbiased công bố một bảng giá duy nhất — $0,80 đầu vào, $0,03 đầu vào được lưu đệm, $3,20 đầu ra — và không tạo phiên bản cho bảng giá này theo từng bản phát hành. Đọc theo nghĩa đen, điều đó có nghĩa là 26.10 và 26.9 có cùng chi phí trên mỗi token ở thời điểm hiện tại, khiến việc di chuyển trở nên miễn phí và việc tăng ngữ cảnh là biến số duy nhất. Trong khi đó, hồ sơ niêm yết kỹ thuật của chính mô hình vẫn mang các con số tháng Chín cho 26.9: $2,50 đầu vào, $0,25 được lưu đệm, $7,50 đầu ra. Cả hai nguồn đều còn hiệu lực khi bài này được viết. Không nguồn nào ghi ngày, và nhà cung cấp chưa công bố mục nhật ký thay đổi nào giải thích việc này, nên không có dòng "vào ngày này giá đã giảm" nào có thể trích dẫn ở bất kỳ đâu trong hồ sơ.

Hướng dẫn thực tế thì chẳng hào nhoáng gì. Hãy giả định theo thẻ thấp hơn, vì hai trong ba bề mặt bạn có thể đọc đều công bố nó và một trong số đó là trang mà khách hàng bị tính phí dựa theo — sau đó hãy kiểm tra lại trước khi bạn chốt một con số trong ngân sách. Nếu bạn đang ghim một trong hai bản phát hành để phân bổ chi phí, hãy biết rằng một tháng hỗn hợp trải qua mốc chuyển đổi ngày 15 tháng 10 sẽ không tách ra rõ ràng sau khi sự việc đã rồi, vì các bản phát hành được định giá khác nhau ở những thời điểm khác nhau và nhà cung cấp không ghi ngày cho các thay đổi của mình.

Một điểm, một phần mười điểm, và không có gì để kết luận.

Bài kiểm chuẩn duy nhất mà cả hai bản phát hành đều có chung là DeepSWE v1.1, và số liệu của chính nhà cung cấp cho thấy 26.9 đạt 70,0% còn 26.10 đạt 69,9%. Cả hai con số đều do nhà cung cấp tự chạy, bản cũ hơn chạy trên một phần 30 tác vụ thay vì toàn bộ tập đánh giá, và toàn bộ phép so sánh được Unbiased mô tả là chưa được xác thực độc lập.

Cách diễn giải trung thực là phép đo này không phân biệt được các bản phát hành. Một phần mười điểm trên một lát cắt nhiệm vụ từng phần nằm trong ngưỡng nhiễu của một lần chạy đơn lẻ, và coi đó là một thứ hạng theo bất kỳ hướng nào — "26.10 bị thoái bộ", hay "26.10 tốt hơn vì rẻ hơn trên mỗi nhiệm vụ" — thì cũng chỉ là bói toán. Các con số chi phí trên mỗi nhiệm vụ chênh lệch nhiều hơn ($0.24 so với $0.29), và ngay cả những con số đó cũng đến từ các lần chạy ở những tháng khác nhau trên một mô hình hỗn hợp mà nhà cung cấp không công bố thành phần cấu thành bên dưới.

Điều mà bảng này thực sự cho bạn biết là nơi không nên nhìn vào. Nếu bạn đang chọn giữa hai cái này dựa trên chất lượng, thì bạn đang chọn dựa trên một con số không thể chống đỡ được lựa chọn đó. Bằng chứng phân tách chúng mang tính kiến trúc — cửa sổ ngữ cảnh và bề mặt tham số — và cả hai đều có thể kiểm chứng theo cách mà các điểm số không thể.

Nên gọi cái nào, tùy theo khối lượng công việc

• Lập trình agentic trên toàn bộ kho mã — 26.10. Cửa sổ 1M chính là khác biệt giữa việc gửi cả kho mã và gửi một bản tóm tắt của nó.

• Phân tích tài liệu dài hoặc bản ghi dài — 26.10, vì lý do tương tự, và hãy để ý hóa đơn đầu vào: 1M token không có cache hit là $0.80 mỗi yêu cầu chỉ riêng phần đầu vào.

• Các pipeline đầu ra ở chế độ JSON hoặc bị ràng buộc theo schema — dùng 26.9 cho đến khi bạn tự kiểm tra hành vi của 26.10, vì danh sách tham số được khai báo của 26.9 có bao gồm response_format còn của 26.10 thì không.

• Một workload đã chạy trong môi trường production và vừa khít trong 262K — 26.9. Không có bằng chứng công bố nào cho thấy việc di chuyển giúp cải thiện đầu ra, và ghim (pinning) là quyết định ít tốn kém hơn.

• Bất kỳ thứ gì mà bạn muốn dùng mặc định hiện tại của nhà cung cấp mà không cần duy trì một pin — 26.10, thông qua alias pareto trần, với hiểu biết rằng alias tuân theo lịch của nhà cung cấp chứ không phải lịch của bạn.

Đối với các nhóm vận hành cả hai phía của vòng lặp xây dựng và xác minh, mô hình hữu ích là ghim 26.10 cho lượt ngữ cảnh dài và giữ 26.9 sẵn có làm nhánh so sánh — đó chính xác là mục đích của một lớp định tuyến. OrcaRouter không cung cấp bất kỳ mô hình Unbiased nào, vì vậy cả hai chuỗi đều được gọi qua API riêng của nhà cung cấp; điều chúng tôi cung cấp là một khóa và một tích hợp cho các mô hình mà bạn sẽ đánh giá 26.10 so với, nên việc đánh giá việc chuyển đổi không có nghĩa là phải ký hợp đồng thứ hai. OrcaRouter chuyển thẳng giá niêm yết của nhà cung cấp với mức tăng giá 0%, đây là tuyên bố về các mô hình chúng tôi thực sự phục vụ, không phải về mô hình này.

Cuộc di cư không ai lên kế hoạch

Lý do so sánh này mang tính thực tế thay vì hàn lâm là vì thay đổi đó đã xảy ra với những người không hề yêu cầu nó. Vào ngày 15 tháng 10, bí danh pareto đã chuyển từ bản phát hành tháng 9 sang 26.10. Bất kỳ ai gọi chuỗi trần đều nhận được cửa sổ ngữ cảnh tăng gấp bốn lần và một bề mặt tham số khác mà không cần thay đổi mã — và vì tài liệu của nhà cung cấp lưu ý rằng các định danh mô hình không xác định không bị từ chối, một chỉ định phiên bản bị gõ sai vẫn được phục vụ và tính phí như Pareto thay vì báo lỗi rõ ràng.

Nếu thay vào đó bạn đang ở trên chuỗi preview, con đường đó đã đóng: Unbiased đã bảo người dùng preview chuyển sang pareto hoặc pareto-26.10. Nếu bạn đang ở trên pareto và cho rằng nó ổn định, thì giả định đó giờ đã hiện rõ trong log của chính bạn, dù nó có gây ra vấn đề hay không.

Dù theo cách nào, cách khắc phục vẫn như nhau và chỉ tốn một dòng: hãy nêu rõ bản phát hành bạn đã kiểm thử. Một chuỗi có kèm phiên bản là thứ khiến mô hình chi phí có thể trừ được và một hồi quy có thể quy được nguyên nhân, và đó là cơ chế duy nhất nhà cung cấp này cung cấp cho bạn cho cả hai mục đích.

Điều gì vẫn chưa được xác minh

Cả hai bản phát hành đều không có benchmark độc lập. Artificial Analysis không có trang riêng cho bản nào, và chưa có đơn vị đánh giá nào công bố việc chạy lại harness của nhà cung cấp. Mọi con số trong so sánh này — bốn điểm số, các con số chi phí mỗi tác vụ, cửa sổ ngữ cảnh — hoặc do nhà cung cấp công bố, hoặc được đọc từ hồ sơ liệt kê kỹ thuật của mô hình, và riêng các điểm số mang đúng nhãn "sơ bộ" và "chưa được xác thực độc lập" của chính nhà cung cấp.

Đó không phải là lý do để tránh cả hai mô hình. Đó là lý do để quyết định dựa trên những điều có thể kiểm tra được: liệu khối lượng công việc của bạn có phù hợp với 262K hay không, liệu pipeline của bạn có cần response_format hay không, và liệu bạn muốn dùng alias hay dùng một bản pin. Ba câu hỏi đó đều có câu trả lời. Còn mô hình nào tốt hơn thì không, và đọc bao nhiêu bảng công bố cũng không tạo ra được câu trả lời.