Ternary Bonsai 2 27B: Điều gì vừa vặn trong 5,9 GB, và những gì 98,2% không cho bạn biết

Ternary Bonsai 2 27B là một mô hình ngôn ngữ đa phương thức 27,36 tỷ tham số mà Prism ML đã công bố vào ngày 17 tháng 9 năm 2026, và điều cần hiểu về nó là các trọng số ngôn ngữ của nó chỉ nhận một trong đúng ba giá trị. Mô hình cơ sở của nó là Qwen3.8 27B — một mô hình 27B hybrid-attention — và Bonsai giữ nguyên kiến trúc đó, quá trình huấn luyện đó và hình dạng đó, đồng thời thay thế các trọng số ma trận của mô hình ngôn ngữ bằng một biểu diễn ternary. Tệp được phát hành có dung lượng 5,93 GB. Tham chiếu độ chính xác đầy đủ là 53,81 GB. Tuyên bố chính của nhà cung cấp là nó giữ được 98,2% mức trung bình trên các bài kiểm tra chuẩn của bản gốc.

Hãy bắt đầu với phần mà hầu hết các bài đưa tin sẽ lướt qua: con số 98,2% đó là số liệu của chính Prism ML, được đo trên bộ 20 benchmark của chính Prism ML, bằng harness của chính Prism ML, và chưa có ai bên ngoài công ty tái lập được nó. Đó không phải là một lời buộc tội — đó là tình trạng bình thường vào một ngày sau khi phát hành, và đó chính xác là trạng thái bạn nên gán cho nó. Điều bạn có thể tự kiểm chứng một cách độc lập ngay hôm nay là tệp tin: API của Hugging Face liệt kê Ternary-Bonsai-2-27B-PTQ1_0.gguf ở mức 5,947 GB so với bản tham chiếu FP16 ở 53,808 GB, tức mức giảm 9,05 lần và khớp với con số "khoảng 9 lần" của nhà cung cấp mà không cần phải tin bất kỳ ai. Kích thước là một sự thật. Việc giữ được chất lượng là một phép đo của nhà cung cấp. Phần tài liệu thú vị nằm ở khoảng giữa — bảng phân tích theo hạng mục, cho thấy chính xác nơi việc nén là miễn phí và nơi thì không.

Bản phát hành này còn có một mặt thứ hai. Vào ngày 18 tháng 9, một ngày sau thông báo, OrcaRouter đã công bố một biến thể abliterated ở thời điểm chạy của cùng mô hình — OrcaRouter Ternary Bonsai 2 27B Uncensored — thứ loại bỏ một hướng từ chối đã học tại thời điểm suy luận và giữ các trọng số đồng nhất đến từng bit. Nó được đề cập trong phần riêng của nó bên dưới, vì kỹ thuật này là phần thú vị và vì những giới hạn của nó cũng mang tính chỉ dẫn như các kết quả của nó.

Đây là một Qwen3.8 27B đã được nén, không phải một mô hình mới được huấn luyện.

Sự khác biệt này chính là điểm phân biệt giữa việc giải thích một bản phát hành và việc lặp lại một thông cáo báo chí. Prism ML không huấn luyện một mô hình 27B từ đầu và cũng không chạy một công thức tiền huấn luyện mới. Điều họ làm là lấy Qwen3.8 27B và thay đổi cách biểu diễn số mà các trọng số của nó được lưu trữ và tính toán.

Kiến trúc không thay đổi, và nó là kiến trúc của mô hình cơ sở: một thiết kế attention lai với khoảng 75% là linear attention và 25% là full attention, cùng các khối SwiGLU MLP, RoPE và RMSNorm. Chính bộ khung lai đó cũng là lý do ngữ cảnh 262K token được mô tả là có khả năng full-context chứ không chỉ đơn thuần là được hỗ trợ — attention chủ yếu tuyến tính là thứ giữ cho ngữ cảnh dài có chi phí hợp lý trên một thiết bị. Mô hình là mô hình thị giác-ngôn ngữ: nó chấp nhận cả hình ảnh lẫn văn bản, và tháp thị giác là tháp Qwen nguyên bản, chưa lượng tử hóa, được đóng gói riêng.

Những gì Prism ML đóng góp là hai thứ. Thứ nhất là bản thân biểu diễn tam phân cùng với huấn luyện nhận biết lượng tử hóa khiến nó có thể tồn tại được. Thứ hai là các kernel — kernel bit thấp tùy chỉnh cho ngăn xếp attention lai đó trên Apple Silicon và CUDA, hoạt động trực tiếp trên các trọng số đã đóng gói thay vì giải nén chúng thành FP16 rồi nhân. Nếu không có đóng góp thứ hai thì đóng góp thứ nhất chỉ là một định dạng lưu trữ không có cách nào sử dụng nó với tốc độ cao.

Whitepaper của chính Prism ML báo cáo phân bổ tham số là 24,35B trong phần xương sống ngôn ngữ trải qua 64 khối, 2,54B trong embedding và LM head, và 0,47B trong tháp thị giác 27 khối, tổng cộng là 27,36B. Tháp thị giác là phần duy nhất thực sự là một artifact khác biệt: bản phát hành GGUF đóng gói nó dưới dạng tệp mmproj 4-bit khoảng 0,63 GB, chỉ được tải khi thực sự có ảnh đến, nên phục vụ chỉ văn bản không bao giờ mang nó theo.

Đây là Bonsai thế hệ thứ hai đến từ cùng một phòng thí nghiệm; chiếc Bonsai 27B đầu tiên ra mắt vào tháng 7 năm 2026, sớm hơn khoảng hai tháng, và việc so sánh giữa hai thế hệ là một câu hỏi hợp lý — câu hỏi mà chúng tôi sẽ đề cập trong phần đối đầu trực tiếp với Bonsai 27B thay vì lặp lại ở đây.

Cụ thể thì "ternary g128" nghĩa là gì

Nếu trước đây bạn chưa từng gặp trọng số tam phân, thì đây là đoạn khiến mọi thứ còn lại trở nên dễ hiểu, nên đây là nó mà không viết tắt.

Một trọng số thông thường trong mạng nơ-ron là một số dấu phẩy động 16 bit — khoảng 65.536 giá trị có thể phân biệt được trên một khoảng hữu ích, mỗi giá trị tốn 16 bit để lưu trữ. Một trọng số tam phân không phải là một số dấu phẩy động nhỏ. Nó là một lựa chọn giữa ba ký hiệu: −1, 0, hoặc +1. Đó là toàn bộ từ vựng. Lưu một ký hiệu như vậy một cách ngây thơ thì bạn sẽ tốn hai bit cho mỗi trọng số, vì hai bit cho bạn bốn trạng thái mà bạn chỉ cần ba.

Nếu chỉ riêng như vậy thì đó sẽ là một sự mất mát khả năng biểu đạt thảm khốc, và đó là lý do vì sao định dạng này không bao giờ chỉ là ký hiệu. Mỗi nhóm 128 trọng số liên tiếp dùng chung một hệ số tỷ lệ FP16, và giá trị trọng số thực tế là ký hiệu ternary nhân với hệ số tỷ lệ đó:

• w = ssub>g/sub> · t, trong đó t ∈ {−1, 0, +1} và ssub>g/sub> là một hệ số tỉ lệ FP16 dùng chung cho nhóm 128

Vậy nên mô hình vẫn biểu diễn được một dải độ lớn rộng — chỉ là nó biểu diễn chúng theo những bước thô, theo từng nhóm, thay vì theo từng trọng số riêng lẻ. Số 0 không phải là một sản phẩm phụ của việc làm tròn; nó là một trạng thái thứ ba thực sự, và chính việc có nó là điều cho phép một nhóm 128 trọng số phần lớn im lặng khi cần phải như vậy.

Cơ sở đã quay là phần khiến mọi người ngạc nhiên. Trước khi việc gán tam phân diễn ra, mỗi ma trận trọng số được biến đổi theo từng khối bằng một phép quay trực giao — một ma trận Walsh–Hadamard kết hợp với một đường chéo cố định gồm các dấu ±1, ở kích thước khối 1024 — và các giá trị tam phân được chọn trong không gian đã quay đó. Phép quay được gộp vào các trọng số được lưu trong quá trình chuẩn bị, nên nó không tốn thêm bit nào và không tốn thêm lưu lượng trọng số. Khi suy luận, runtime áp dụng phép biến đổi tương ứng cho các kích hoạt thay vào đó, và mô hình đã đóng gói khai báo phép quay của nó trong siêu dữ liệu của nó, nên một runtime hoặc áp dụng phép biến đổi tương ứng hoặc từ chối nạp tệp.

Việc này để làm gì? Bởi vì một phép quay Hadamard trải đều năng lượng của ma trận trọng số hơn trên các tọa độ, khiến việc lượng tử hóa ba mức sau đó ít gây tổn hại hơn nhiều so với khi thực hiện trên phân phối thô, lởm chởm. Phép quay không phải là trang trí; nó là lý do một mô hình ternary có thể giữ lại được bất cứ thứ gì gần với chất lượng của mô hình gốc. Cái giá phải trả là phép biến đổi nằm trên đường tới hạn của mọi phép chiếu ở batch size 1, đây là một vấn đề kỹ thuật thực sự — Prism ML hợp nhất phép lật dấu vào đường nạp của phép biến đổi trên Metal và song song hóa nó trên toàn bộ một thread block trên CUDA để giữ cho nó không chi phối quá trình giải mã.

Các con số, một cách cẩn thận: 1.585, 1.71, 1.72, 1.76

Bốn con số độ rộng bit đang được nhắc đến xoay quanh bản phát hành này, tất cả đều đúng, và chúng đo bốn thứ khác nhau. Nhầm lẫn chúng với nhau là lỗi dễ mắc nhất trong câu chuyện này. Dưới đây là từng con số và những gì nó thực sự bao quát.

• 1,585 bit trên mỗi trọng số — lượng thông tin của một ký hiệu tam phân, log₂3. Đây là thuộc tính của định dạng, không phải của bất kỳ tệp nào. Không có sản phẩm nào được phát hành chạy ở mức 1,585 bit/trọng số.

• 1,71 bit cho mỗi trọng số — chỉ tính riêng các tensor tam phân. Cộng thêm hệ số tỉ lệ nhóm FP16 16-bit được phân bổ đều trên 128 trọng số, bạn sẽ có log₂3 + 16/128 ≈ 1,71. Đây vẫn chưa phải là con số của một sản phẩm đã phát hành; đó chỉ là các tensor tam phân khi đứng riêng mà thôi.

• 1,72 bit trên mỗi trọng số — mọi tham số trong mô hình ngôn ngữ, bao gồm cả tập nhỏ được giữ ở trên biểu diễn bit thấp. Prism ML giữ 26.238.464 tham số — 0,0976% của mô hình ngôn ngữ, khoảng 52 MB ở bf16 — ở độ chính xác cao hơn, chủ yếu là đường trạng thái hồi tiếp của các lớp chú ý tuyến tính cùng với các trọng số chuẩn hóa. Những tensor đó không được xoay cũng không được lượng tử hóa, và chúng chính là thứ đưa con số từ 1,71 lên 1,72. Ở mức 1,72, dung lượng lý tưởng hóa là 5,80 GB, giảm khoảng 9,3 lần. Đây là dòng "True Ternary" của Prism ML, và nó là một mục tiêu chứ không phải một tệp bạn tải xuống.

• 1,76 bit trên mỗi trọng số — GGUF thực tế được phát hành. Các kernel hiệu quả cần một định dạng đóng gói, và PTQ1_0 của Prism ML đóng gói các trit một cách dày đặc, đạt mức 1,76 bit/trọng số trong 5,93 GB, khoảng 9,1 lần. Đây là tệp đằng sau cả “5,9 GB” và “nhỏ hơn 9 lần” mà thông báo đã nêu, và nó là tệp mà các phép đo ở trên xác nhận.

Cách đóng gói thứ hai là PQ2_0, lưu mỗi trit trong một ô 2 bit thay vì lưu dày đặc. Nó tốn nhiều không gian hơn để đổi lấy việc giải nén rẻ hơn: 2,16 bit/trọng số trong 7,25 GB, khoảng 7,4 lần. Không có cách đóng gói nào nhanh hơn một cách đồng đều — PTQ1_0 di chuyển lượng dữ liệu trọng số ít hơn khoảng 18% mỗi bước nhưng phải trả giá bằng tính toán để giải nén các trit dày đặc, vì vậy nó thắng trên các card thế hệ Ada và L4, nơi bộ nhớ là ràng buộc, và thua trên Hopper, Blackwell và Apple silicon, nơi giải mã batch-1 thay vào đó bị giới hạn bởi thông lượng lệnh. Xử lý prompt ưu tiên PQ2_0 ở mọi nơi, vì nó bị ràng buộc bởi tính toán.

Hai ghi chú kỹ thuật nhỏ cho bất kỳ ai đang đối chiếu những điều này với các nguồn. Thứ nhất, các tài liệu của chính Prism ML làm tròn hơi khác nhau — bảng dung lượng lưu trữ trong sách trắng ghi PTQ1_0 là 1,76 bit/trọng số ở 5,93 GB, trong khi thẻ mô hình GGUF trên Hugging Face ghi 1,75 và 5,95 GB, còn tệp đo được là 5,947 GB. Đây là cùng một tệp được mô tả ở các độ chính xác khác nhau, không phải là mâu thuẫn về thực chất. Thứ hai, mức giảm “hơn 9x” được công bố là của nhà cung cấp; khi đo dựa trên các tệp thực tế thì đó là 53,808 / 5,947 = 9,05x, điều này là nhất quán.

Bức tranh benchmark: không phải mức trung bình, mà là hình dạng.

Con số tiêu đề là mức trung bình 83,9 so với 85,4 của đường cơ sở Qwen3.8 27B FP16, tức là 98,2%. Mức trung bình là phần ít thú vị nhất trong đó. Hình dạng bên dưới mới là nơi chứa thông tin thực sự, và nó không đồng nhất.

• Tuân thủ hướng dẫn — 82.66 so với 81.25. Đây là hạng mục duy nhất mà mô hình nén đánh bại mô hình gốc có độ chính xác đầy đủ. Đây không phải là loại nhiễu mà bất kỳ ai có thể dễ dàng giải thích cho qua; đây là một thắng lợi ở cấp hạng mục trên chính bộ kiểm thử của nhà cung cấp.

• Toán — 96,57 so với 97,06, và lập trình — 81,58 so với 82,17.Cả hai về cơ bản ngang nhau: nửa điểm và sáu phần mười điểm trên điểm trung bình theo hạng mục. Đối với một mô hình chỉ bằng một phần chín dấu chân, đây chính là những kết quả mà toàn bộ kỹ thuật này đang được lập luận dựa trên.

• Kiến thức và lập luận — 83,95 so với 86,66. Mức giảm 2,7 điểm, và đây chính là nơi tập trung một phần đáng kể trong số 1,8 điểm còn thiếu của mức trung bình tổng.

• Thị giác — 78,59 so với 81,64. Mức giảm 3,05 điểm, mức sụt giảm lớn nhất ở một hạng mục đơn lẻ. Đáng lưu ý rằng bản thân tháp thị giác không phải là phần bị nén; mô hình ngôn ngữ đọc các đầu ra của nó mới là phần bị nén.

• Tác tử và gọi công cụ — 77.57 so với 79.74.Mức trung bình của hạng mục bao gồm τ 2-Bench ở 80.22 và BFCL v3 ở 74.92.

Các kết quả riêng lẻ đáng để biết, vì chúng không phải tất cả đều chỉ về cùng một hướng. Trên Terminal-Bench 2.1, mô hình đạt 52.8 so với 69.7 cho độ chính xác đầy đủ — khoảng ba phần tư — và trên SWE-bench Verified, nó đạt 60.8 so với 80.6, cũng khoảng ba phần tư. Đây là lần đầu tiên dòng mô hình này được đánh giá trên Terminal-Bench, và Prism ML nói rõ rằng những cải thiện về kỹ thuật phần mềm tầm xa mà họ đã hứa trong bản phát hành Bonsai đầu tiên là một phần, không phải hoàn chỉnh. Ngược lại: τ 2-Bench tăng lên 80.2 từ 73.6 trong bản phát hành trước, BFCL v3 giữ ở 74.9, và AA-LCR ở mức 77.0, trong phạm vi một điểm so với độ chính xác đầy đủ. AIME26 đạt 95.83 và LiveCodeBench đạt 90.07.

Nên tin ở đâu và không nên tin ở đâu.Hãy tin vào hình thái kết quả ở mảng toán, lập trình và tuân theo chỉ dẫn — đó là những hạng mục mà kỹ thuật này đã chứng minh được rằng nó đang làm đúng như những gì nó tuyên bố, và chúng được đo trên cùng một harness như đường cơ sở. Hãy thận trọng với các công việc agent dài hạn: hai benchmark thực sự gây áp lực lên năng lực kỹ thuật bền bỉ dựa trên công cụ, Terminal-Bench 2.1 và SWE-bench Verified, cho thấy khoảng cách lớn hơn đáng kể so với mức mà con số tổng hợp ngụ ý, và nhà cung cấp cũng nói rõ điều đó thay vì che giấu. Và hãy coi toàn bộ bảng số liệu này chỉ là kết quả đo của một phòng thí nghiệm trên một harness cho đến khi có ai đó khác chạy lại nó. Lưu ý đó ở đây không phải là chuyện hình thức — nó chính là khác biệt giữa "mô hình này giữ được 98.2%" và "nhà cung cấp của mô hình này đo được 98.2% trên một bộ bài kiểm tra do chính nhà cung cấp chọn." Cả hai đều đúng; nhưng chỉ một trong hai là sự thật về bản thân mô hình.

Vì sao cái này vượt trội hơn bản dựng IQ2_XXS của cùng mô hình cơ sở

Điều này xứng đáng có một mục riêng thay vì chỉ một dòng, vì đó là toàn bộ lập luận cho việc huấn luyện tam phân nhận biết lượng tử hóa thay vì lượng tử hóa sau huấn luyện.

Cách thông thường để làm cho Qwen3.8 27B nhỏ gọn là lượng tử hóa nó sau khi huấn luyện. Điểm so sánh trong sách trắng là một bản dựng IQ2_XXS GGUF của cùng mô hình cơ sở:

• Ternary Bonsai 2 27B — 1,76 bit/trọng số, 5,93 GB, trung bình 20 bài đánh giá là 83,9

• Qwen3.8 27B IQ2_XXS — 2,2 bit/trọng số, 7,3 GB, trung bình 20 bài kiểm chuẩn là 75,2

Mô hình được nén trong quá trình huấn luyện vừa nhỏ hơn vừa tốt hơn. Nó nhỏ hơn 1,23 lần so với bản dựng low-bit thông thường và đạt điểm cao hơn 8,7 điểm. Sự kết hợp đó không phải là một chi tiết tò mò nhỏ nhặt do làm tròn số; đó là tuyên bố rằng một cách biểu diễn được chọn trong quá trình huấn luyện có giá trị lớn hơn đáng kể so với cùng ngân sách bit danh nghĩa nhưng được áp dụng sau đó.

Phần mang tính hướng dẫn hơn nằm ở cách mà bản dựng thông thường thất bại, vì sự thất bại này mang tính chọn lọc và dễ bị bỏ sót. IQ2_XXS không suy giảm đồng đều. Nó vẫn trụ được ở kiến thức bề mặt — 85.79 trên MMLU-Redux — trong khi sụp đổ ở các tác vụ đòi hỏi những chuỗi lập luận liên tục: 78.6 trên AIME26, 70.05 trên LiveCodeBench, 65.45 trên GPQA Diamond. Bonsai 2 đạt 95.83, 90.07 và 85.76 trên chính ba tác vụ đó. Một bài kiểm tra trò chuyện thông thường sẽ thấy bản dựng IQ2_XXS hoàn toàn dùng được và không bao giờ phát hiện ra sự sụp đổ; tổn hại nằm chính xác ở nơi diễn ra lập luận dài và sinh mã. Chính sự bất đối xứng đó là lý do tại sao "tôi thử thì thấy ổn" không phải là bằng chứng về một mô hình lượng tử hóa.

Prism ML nén cùng một lập luận thành một con số dẫn xuất duy nhất mà nó gọi là mật độ thông minh — đại khái là năng lực benchmark trên mỗi gigabyte. Trên bộ 20 benchmark, nó báo cáo 0,444 mỗi GB cho Bonsai 2, 0,276 cho bản dựng IQ2_XXS, và 0,051 cho FP16. Chỉ số này do chính nhà cung cấp tự xây dựng và cách đánh trọng số của nó là một lựa chọn thiết kế, không phải một định luật; nhưng thứ tự mà nó tạo ra cũng chính là thứ tự mà bảng số liệu thô tạo ra, nên nó bổ sung cách diễn giải thay vì bằng chứng.

Thêm một lưu ý trung thực về phép so sánh này. Thẻ mô hình GGUF của Prism ML báo cáo một đánh giá thứ hai, hẹp hơn — một bộ gồm 14 benchmark ở chế độ suy nghĩ — trong đó cùng một chỉ số duy trì lại xuất hiện ở mức 84,78 so với 86,32, với IQ2_XXS ở mức 72,59. Việc hai bộ khác nhau cùng đạt mức 98,2% giống nhau là một sự củng cố nhẹ rằng tuyên bố tổng hợp không phải là một hiện tượng giả tạo do việc chọn một benchmark duy nhất. Tuy vậy, vẫn là cùng một phòng thí nghiệm chạy cả hai, trên cùng một hệ thống kiểm thử. Phân tích chi tiết đầy đủ hơn của chúng tôi về màn đối đầu này, bao gồm câu hỏi về định dạng đóng gói, nằm trong phần so sánh với các bản dựng GGUF Qwen3.8 27B.

Những gì thực sự cần để vận hành

Các số liệu thông lượng, từ phép đo tg128 được chuẩn hóa trong sách trắng ở kích thước lô 1 với tháp thị giác bị loại trừ:

• Apple M5 Max — 46,8 tok/s giải mã, 765 tok/s xử lý prompt

• Apple M5 Pro — giải mã 27,7 tok/s; một lần chạy cửa sổ dài hơn riêng biệt của gói PQ2_0 đo được 27,0 tok/s duy trì, tiêu thụ 27,0 W trên đường cấp nguồn GPU và 32,8 W trên cả CPU lẫn GPU

• Apple M4 Pro — giải mã 18,0 tok/s, với xử lý prompt ở mức khoảng 125 tok/s trở thành yếu tố giới hạn ràng buộc đối với các ngữ cảnh rất dài

• NVIDIA RTX 5090 — 142,5 tok/s giải mã trên gói PQ2_0 ở mức 0,582 mWh mỗi token

Tuyên bố thực tiễn mà Prism ML đưa ra không phải là một tỷ lệ tăng tốc mà là một sự vắng mặt: đường cơ sở FP16 ở 53.8 GB hoàn toàn không vừa trên một chiếc laptop 16 GB, nên phát biểu có ý nghĩa là một mô hình cấp 27B giờ đây chạy tương tác trên phần cứng thông dụng. Trên M5 Pro, tốc độ giải mã đo được truyền khoảng 201 GB/s trọng số, xác nhận đặc tính bị chi phối bởi băng thông bộ nhớ mà biểu diễn bit thấp được thiết kế để khai thác.

Rồi đến các trường hợp biên, những thứ quan trọng hơn cả các con số đỉnh cao.

Bạn không thể dùng llama.cpp nguyên bản. Các kernel attention lai ternary nằm trong bản fork llama.cpp riêng của Prism ML. llama.cpp nguyên bản từ chối các kiểu PTQ1_0 và PQ2_0 vì coi chúng là không xác định, và — nguy hiểm hơn — tải định dạng ternary Q2_0 cũ hơn mà không hề cảnh báo và tạo ra kết quả rác, vì nó không có runtime kích hoạt Hadamard. Nếu bạn chạy mô hình này trên một binary không áp dụng phép quay tương ứng, bạn sẽ không nhận được lỗi; bạn sẽ nhận được những nội dung vô nghĩa trông có vẻ trôi chảy. Đây chính là cách dễ xảy ra nhất khiến bạn lãng phí cả một buổi chiều với bản phát hành này.

Gói MLX không có đường CUDA. Bản phát hành MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) hướng đến Apple Silicon, nơi nó có các kernel tùy chỉnh cho ngăn xếp lai trong cả runtime Python và Swift. Phép nhân ma trận lượng tử hóa của nó có kernel Metal và CPU nhưng không có triển khai CUDA, nên trên máy NVIDIA, gói cụ thể đó hoàn toàn không được tăng tốc GPU. Suy luận trên CPU vẫn hoạt động, nhưng một lượt lan truyền xuôi 27B trên CPU có thể mất hàng phút — điều này khiến đường CPU Linux hữu ích cho việc kiểm thử triển khai và tái lập, nhưng vô dụng cho việc phục vụ.

Hai gói này là một sự đánh đổi thực sự, không phải là một bảng xếp hạng. Nếu bạn đang dùng card thế hệ Ada hoặc L4, hoặc bộ nhớ là yếu tố hạn chế, thì PTQ1_0 là lựa chọn ở mức 5.93 GB. Nếu bạn đang dùng Hopper, Blackwell hoặc 5090, PQ2_0 mang lại cho bạn tốc độ giải mã với mức 1.3 GB. Nếu bạn đang dùng Apple silicon, hãy lưu ý rằng các số liệu M5 Pro ở trên được đo trên PQ2_0, đây cũng là gói mà thiết lập demo tải xuống theo mặc định.

Một lưu ý về cách tính của chính gói MLX, vì đây là nguồn gây nhầm lẫn phổ biến. Container MLX là một định dạng 2-bit affine mà block của nó lưu cả một scale FP16 và một bias FP16 cho mỗi nhóm 128 trọng số. Các trọng số ternary của Bonsai chỉ cần scale — các mức được suy ra chỉ từ scale — nên bias là phần thừa vô ích, và block tốn 36 byte cho mỗi 128 trọng số thay vì 34. Điều đó đẩy tốc độ đóng gói của gói MLX lên 2.250 bit/trọng số, chứ không phải 1.72 và cũng không phải 1.76. Đây là một container khác mang cùng các giá trị ternary, và tệp đo được của nó trên Hugging Face là 8.005 GiB.

Biến thể đã được abliterate tại runtime

Vào ngày 18 tháng 9, OrcaRouter đã công bố OrcaRouter Ternary Bonsai 2 27B Uncensored, mô hình này áp dụng ablation theo hướng từ chối cho mô hình hoàn toàn ở thời gian chạy. Ý tưởng kỹ thuật đáng được quan tâm hơn cả sản phẩm, nên ý tưởng sẽ được trình bày trước.

Abliteration thông thường chỉnh sửa trọng số. Nó tìm một hướng trong không gian kích hoạt tương ứng với hành vi từ chối, rồi trực giao hóa các ma trận trọng số ghi vào luồng residual với hướng đó: W ← W − r(rᵀW). Trên một mô hình FP16 thông thường thì việc đó ổn — ma trận sau chỉnh sửa vẫn là một ma trận dấu phẩy động đặc, nên bạn lưu nó lại và đi tiếp. Trên một gói tam phân, đó là một ngõ cụt, và cụ thể đó là ngõ cụt vì chính lý do mà toàn bộ mô hình này tồn tại. Trực giao hóa một ma trận tam phân sẽ tạo ra một ma trận đặc có độ chính xác đầy đủ. Để lưu nó trở lại gói tam phân, bạn sẽ phải lượng tử hóa lại — và việc lượng tử hóa lại các trọng số đã chỉnh sửa không tái tạo được quá trình huấn luyện nhận biết lượng tử hóa đã tạo ra bản gốc. Bạn sẽ vứt bỏ đúng thứ đã bỏ ra để có được.

Vậy nên phép chiếu chuyển sang thời điểm suy luận thay vào đó. Thay vì thay đổi W, hãy thay đổi đầu ra của nó:

• y ← y − α · dot(y, r) · r, được tính bằng float32, trong đó y là một đóng góp phần dư và r là hướng từ chối đã được chuẩn hóa

Tại α = 1, thành phần song song với hướng từ chối của mỗi ghi residual bị loại bỏ. Tại α = 0, mô hình không bị thay đổi. α lớn hơn 1 chiếu quá mức và có thể làm giảm chất lượng. Vì α là một tham số runtime chứ không phải thuộc tính checkpoint, cùng một pack có thể được kiểm thử A/B với chính nó trong cùng một tiến trình — đúng như những gì các đánh giá của OrcaRouter thực hiện. Pack Bonsai gốc vẫn giống hệt từng bit: không có trọng số nào bị sửa đổi, không tái lượng tử hóa, không phát sinh thêm lỗi lượng tử hóa trọng số.

Hai chi tiết triển khai chính là chỗ mà một phiên bản ngây thơ của cách làm này sẽ thất bại.

129 điểm can thiệp, không phải 16.Mọi mô-đun có thể ghi vào luồng phần dư đều phải được bọc, và trong kiến trúc lai này, đó là 64 khối mlp.down_proj, 48 lớp linear_attn.out_proj, 16 lớp self_attn.o_proj, và model.embed_tokens — tổng cộng 129. Chỉ bọc self_attn.o_proj là sai lầm dễ thấy và nó chỉ bắt được 16 trong số đó, để 113 lượt ghi còn lại không được chiếu. Một script tự kiểm tra đo xem thành phần còn lại dọc theo hướng từ chối có được đẩy về khoảng 1e-6 của chuẩn phần dư hay không, và cảnh báo nếu nó không phát hiện đủ cả 129 vị trí.

Không xoay lại hướng.Gói ternary giữ các phép chiếu của nó trong một cơ sở đã xoay trên chiều đầu vào của chúng và bù lại ở phía kích hoạt. Phép chiếu từ chối hoạt động trên đầu ra của các phép chiếu đó, vốn đã trở lại cơ sở ẩn thông thường — nên hướng từ chối là một vectơ 5120 chiều thông thường và việc áp dụng thêm một phép quay Hadamard lên nó sẽ chiếu theo một cơ sở hoàn toàn sai.

Những gì OrcaRouter đã đo — số liệu của chính chúng tôi, không phải số liệu độc lập

Đây là các phép đo dựa trên quy tắc của chính OrcaRouter, và chúng nên được hiểu đúng như vậy: một bộ phân loại cụm từ mở đầu dựa trên quy tắc, không phải một giám khảo LLM, thinking off, giải mã tham lam, ngân sách 64 token, với base và ablated là cùng trọng số trong cùng một tiến trình tại α = 0 đối chiếu với α = 1. Chúng mang tính chỉ dấu, không đạt chuẩn công bố, và chúng không xác minh bất cứ điều gì Prism ML đã tuyên bố.

Về việc từ chối, được đo bằng tỷ lệ các lời nhắc nhận được lời từ chối:

• AdvBench (n=100) — 99,0% cơ sở, 6,0% đã cắt bỏ, với 56,0% được trả lời nhưng được gói kèm trong một tuyên bố miễn trừ trách nhiệm

• JailbreakBench (n=100) — 96,0% cơ sở, 4,0% đã loại bỏ, 52,0% có kèm lưu ý

• StrongREJECT (n=150) — 99,3% cơ sở, 3,3% đã cắt bỏ, 45,3% có kèm lưu ý

• HarmBench (n=150) — 98,7% cơ sở, 7,3% đã loại bỏ, 48,0% có lưu ý

• MaliciousInstruct (n=100) — 97,0% cơ sở, 0,0% đã gỡ bỏ, 52,0% có kèm lưu ý

• ForbiddenQuestions (n=150) — 75,3% cơ sở, 5,3% đã gỡ bỏ, 42,7% có kèm lưu ý

• SimpleSafetyTests (n=50) — 96,0% base, 18,0% ablated, 60,0% caveated — và con số này thực tế còn thấp hơn thế. Bộ dữ liệu đó chủ yếu gồm các prompt tự gây hại, và mô hình trả lời chúng bằng một câu chuyển hướng khủng hoảng mở đầu bằng "I am deeply sorry to hear…", thứ mà danh sách cụm từ chính xác của bộ phân loại bỏ sót và chấm thành hành vi tuân thủ. Tỷ lệ từ chối thực tế còn lại trên bộ đó cao hơn 18,0%. Bộ phân loại đã được cố ý giữ nguyên như vậy để các con số vẫn có thể so sánh được với các model card khác của OrcaRouter.

Không có phản hồi nào trong bất kỳ tập hợp nào cạn kiệt ngân sách token của nó, vì vậy không có tỷ lệ nào trong số này bị thổi phồng do việc cắt ngắn. Trên các câu lệnh lành tính, cùng phép chiếu đó cũng loại bỏ việc từ chối quá mức: XSTest-safe giảm từ 5,2% từ chối xuống 0,4%, và tập hợp con lành tính của JailbreakBench từ 25,0% xuống 0,0%. Gói đã xuất bản từ chối một phần tư số câu lệnh lành tính của bộ đánh giá đó; khi bị lược bỏ, nó không từ chối câu nào.

Về mặt năng lực, việc các trọng số giống hệt nhau từng bit nghĩa là không có việc lượng tử hóa lại nào phải trả giá, và các phép đo nhất quán với điều đó:

• MMLU (n=300) — 76,7% cơ sở, 77,7% đã loại bỏ, +1,0

• GSM8K (n=150) — 87,3% cơ sở, 86,0% đã loại bỏ, −1,3

• CMMLU (n=500) — 76,2% cơ sở, 75,6% đã loại bỏ, −0,6

Mọi thay đổi đều nằm trong ngưỡng nhiễu ở các cỡ mẫu này; một câu hỏi GSM8K duy nhất đáng giá 0,7 điểm. MMLU-Pro bị loại trừ thay vì được báo cáo: lời nhắc của nó yêu cầu suy luận trước câu trả lời, và 63–64% phản hồi ở cả hai phía đã không đạt tới một câu trả lời trong ngân sách token, nên bất kỳ con số độ chính xác nào cũng sẽ là mức sàn do ngân sách đặt ra chứ không phải là một phép đo.

Lưu ý quan trọng nhất

Hướng từ chối được ước tính từ mô hình cơ sở BF16 mà Bonsai pack được huấn luyện từ đó. Kiến trúc và cơ sở ẩn là giống hệt nhau, nên hình học khớp nhau. Nhưng mức độ mà hướng đó tồn tại qua huấn luyện nhận biết lượng tử hóa vẫn chưa được đo đầy đủ.

Runtime có thể chứng minh, bằng toán học và với độ chính xác khoảng 1e-6, rằng nó loại bỏ hướng được cung cấp khỏi mọi ghi dư. Nó không thể chỉ từ đó mà chứng minh rằng hướng đó vẫn nắm bắt cùng đặc trưng hành vi trong mô hình lượng tử hóa như nó đã nắm bắt trong mô hình dày đặc. Đó là những khẳng định khác nhau, và chỉ khẳng định đầu tiên là đã được giải quyết. Bất kỳ ai đọc bảng an toàn ở trên nên đọc nó với hiểu biết rằng can thiệp này hiệu quả đúng bằng giả định chuyển hướng, và giả định đó chính là câu hỏi mở.

Ngoài ra còn có cách đóng khung thực tế mà OrcaRouter đặt cho chính bản phát hành, điều này đáng được nhắc lại thay vì diễn giải cho mất đi: việc loại bỏ một hướng từ chối đã được học có thể khiến mô hình phản hồi những yêu cầu mà phiên bản gốc sẽ từ chối. Đây là một cơ chế nghiên cứu và kiểm soát suy luận, không phải bằng chứng rằng bất kỳ đầu ra nào tạo ra là an toàn, đúng đắn hoặc phù hợp, và các triển khai sử dụng nó nên áp dụng kiểm soát truy cập cùng việc thực thi chính sách của riêng họ. Loại bỏ từ chối không phải là một cải tiến miễn phí, và bài viết này không được viết như thể đó là như vậy.

Ba lưu ý thực tiễn bổ sung cho bất kỳ ai muốn tái tạo nó. Pack phải được nạp bằng runtime đi kèm của chính nó — một trình nạp MLX thông thường có thể trông như đã nạp thành công trong khi âm thầm tính toán sai, vì vậy nếu đầu ra trông sai ngay cả trước khi ablation được bật, hãy kiểm tra đường dẫn nạp trước tiên. Ablation chọn lọc theo lớp được hỗ trợ, nên can thiệp không nhất thiết phải là tất cả hoặc không có gì. Và đánh giá ablation được chạy trên bản mở rộng FP16 đã bung của pack thay vì để pack tự chạy các kernel của chính nó, bởi vì phép matmul lượng tử hóa đã đóng gói không có triển khai CUDA và backend CPU cần hàng phút cho mỗi lượt forward; bản mở rộng đó mang các giá trị ternary của pack một cách chính xác và tái tạo phân phối token kế tiếp của chính pack đến ba chữ số thập phân trong các kiểm tra nhanh, nhưng đó là một thay đổi container và đáng để biết. Mã và các bảng đầy đủ nằm trong repository OrcaRouter Ternary Bonsai 2 27B Uncensored. Một so sánh riêng đối chiếu bản dựng MLX đã được ablation với đường dẫn Qwen3.8 27B MLX chưa chỉnh sửa đi sâu hơn vào các chi tiết cụ thể của runtime.

Việc này sẽ đi đến đâu, và điều gì vẫn chưa được chứng minh

Việc một mô hình 27B gần như không mất mát trong khoảng sáu gigabyte thay đổi điều gì đối với các tác tử cục bộ chủ yếu xoay quanh thứ gì trở thành thường trú. Một mô hình ngôn ngữ vừa vặn cùng một cửa sổ ngữ cảnh thực trên chiếc laptop 16 GB có thể vẫn được nạp sẵn trong khi tác tử làm việc khác — đọc tệp, gọi công cụ, giữ một kế hoạch qua nhiều lượt — thay vì bị hoán đổi theo từng yêu cầu hoặc đẩy lên máy chủ. Đó là khác biệt giữa một mô hình cục bộ bạn dùng thử và một mô hình cục bộ bạn để chạy liên tục, và đó chính là thuộc tính cụ thể mà các con số mang tính tác tử, τ 2-Bench ở 80.2 và BFCL v3 ở 74.9, có mặt để hỗ trợ.

Điều chưa được chứng minh là một danh sách dài hơn những gì thông báo ngụ ý.

• Không có sự tái lập độc lập. Mọi con số chất lượng trong bài viết này — 83.9, 98.2%, điểm trung bình theo danh mục — đều là đo lường của chính Prism ML trên bộ kiểm thử của chính Prism ML. Đó không phải là lỗi trong bản phát hành; nó chỉ đơn giản là những gì một ngày tuổi trông như vậy. Đó cũng là điều đầu tiên sẽ thay đổi.

• Công việc tác nhân tầm xa là phần yếu nhất trong bảng của chính nhà cung cấp, chứ không phải phần mạnh nhất. Terminal-Bench 2.1 đạt 52.8 so với 69.7 là một khoảng cách thực sự, và nhà cung cấp nói rằng năng lực này chỉ ở mức một phần.

• Các prompt bạn chưa thử. Hồ sơ thất bại của các mô hình low-bit mang tính chọn lọc, và việc IQ2_XXS sụp đổ trên AIME26 và LiveCodeBench trong khi vẫn giữ 85.79 trên MMLU-Redux là bằng chứng rõ ràng nhất hiện có cho thấy điểm trung bình benchmark không cho bạn biết điều gì sẽ xảy ra trên khối lượng công việc của bạn. Bonsai 2 không thể hiện sự sụp đổ đó trên hai benchmark ấy, điều này đáng khích lệ và không đồng nghĩa với một bảo đảm.

• Câu hỏi về chuyển giao hướng trong biến thể đã abliterate ở trên, vốn dĩ không thể giải quyết do cách cấu trúc.

• Liệu các kernel có trụ vững khi các runtime thay đổi. Hiện tại, mô hình này cần một bản fork; llama.cpp gốc từ chối hai trong ba định dạng và âm thầm làm hỏng định dạng thứ ba. Cho đến khi những kernel đó được đưa vào upstream, “chạy ở mọi nơi llama.cpp chạy” vẫn chưa đúng với mô hình này.

Bản thân việc phát hành thì không có gì phải bàn cãi. Một mô hình đa phương thức lớp 27B ở mức 5,93 GB, chỉ bằng một phần chín dung lượng của thứ mà nó được nén từ đó, với năng lực toán và lập trình ngang bằng mô hình gốc và khả năng tuân theo chỉ dẫn nhỉnh hơn một chút, thực sự là một điểm vận hành khác biệt cho suy luận cục bộ. Lập trường hợp lý vào ngày 18 tháng 9 năm 2026 là coi kích thước tệp là sự thật, coi chỉ số duy trì như một tuyên bố thận trọng của nhà cung cấp được đưa ra một ngày trước trên một bộ kiểm thử do nhà cung cấp tự chọn, và hoãn đánh giá về khối lượng công việc của riêng bạn cho đến khi bạn đã chạy nó trên đó.

Mã ablation thời gian chạy, hướng từ chối và toàn bộ các bảng đánh giá được công bố bởi OrcaRouter, cùng với nền tảng định tuyến mà nhóm xây dựng.