Bonsai 2 đã có mặt trên Ollama trước khi bất kỳ ai thông báo rằng nó sẽ ra mắt

Vào khoảng rạng sáng ngày 17 tháng 10 năm 2026, Ollama bắt đầu phục vụ Bonsai 2 — một mục thư viện chín thẻ bao gồm Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B và Bonsai 2 27B, mỗi cái có hai gói đóng gói cộng với một bí danh mặc định. Prism ML chưa nói gì về nó. Không có bài đăng nào trên trang tin tức của nhà cung cấp, không có dòng nào trong thông báo ngày 15 tháng 10 về các mô hình nhỏ — bài đăng đó nêu tên llama.cpp và MLX là các runtime và một bảng điều khiển được lưu trữ làm bản demo, và không hề đề cập đến Ollama. Danh sách chỉ đơn giản tồn tại, với cả chín thẻ đều được đóng dấu cùng thời điểm cách đây vài giờ, đó là dấu hiệu của một lần đẩy mới chứ không phải là một đợt triển khai dần dần.

Vậy nên sự phân tách trung thực là thế này. Có thể biết ngay lúc này, từ registry và các tệp: các tag, tên của chúng, kích thước byte chính xác, digest nội dung của chúng, và — vì Ollama phát hành GGUF — kiến trúc cùng các chuỗi metadata bên trong chính các trọng số. Chưa được xác nhận: ai đã đóng gói chúng, vì sao thông báo của nhà cung cấp lại bỏ qua nền tảng, liệu các kernel ternary có nằm ở thượng nguồn trong engine của chính Ollama hay được nhúng từ ngoài, và liệu có con số nào của nhà cung cấp còn giữ nguyên sau chặng đường đó hay không. Đó là những câu hỏi riêng biệt và bài viết này giữ chúng tách biệt.

Thực sự thì có gì trên kệ?

Chín tag, bốn kích thước, ba cách đóng gói cùng một bộ trọng số. Trang thư viện của Ollama liệt kê một bí danh mặc định cho mỗi kích thước và một biến thể -q2_0 cho mỗi kích thước:

• bonsai-2:latest — 3.2 GB, tương ứng với 9B (digest c8b5462f8688)

• bonsai-2:2b và bonsai-2:2b-q2_0 — 911 MB, cùng digest de2ccb4e7328

• bonsai-2:4b và bonsai-2:4b-q2_0 — 1.6 GB, cùng digest 93edd652c932

• bonsai-2:9b và bonsai-2:9b-q2_0 — 3,2 GB, cùng digest c8b5462f8688

• bonsai-2:27b và bonsai-2:27b-q2_0 — 8,3 GB, cùng digest f3c4f4208659

Cách đặt tên đang làm nhiều việc hơn vẻ ngoài của nó. Hai thẻ cho mỗi kích cỡ dùng chung một digest không phải là bản trùng lặp — đó là một lời khẳng định về việc Ollama đã chọn cách đóng gói nào. Kéo manifest của bonsai-2:9b và lớp model là 2.557 GB. Đó là tệp Q2_0 của Ternary Bonsai 2 9B, được đo trên Hugging Face đúng 2.557 GB đến từng byte. PQ2_0 có dung lượng 2.417 GB, còn gói PTQ1_0 — nhỏ nhất với 1.997 GB — hoàn toàn không có ở đây.

Lựa chọn đó có một hệ quả đáng để nói thẳng ra, bởi vì đây chính là kiểu chuyện dễ biến thành một chuỗi thảo luận hỗ trợ. Trên thẻ mô hình của nhà cung cấp, llama.cpp thượng nguồn chỉ chạy đúng một trong ba kiểu đóng gói: Q2_0, "bản master gần đây, vốn bao gồm runtime kích hoạt Hadamard." Nó từ chối PQ2_0 và PTQ1_0 vì đó là những kiểu không xác định, bởi chúng cần bản fork llama.cpp của Prism ML. Ollama phục vụ engine riêng của mình. Q2_0 là gói mà một trình đọc GGUF nguyên bản có thể chạy được một cách hợp lý — và Q2_0 đúng chính là gói mà Ollama đã phát hành. Việc Ollama tự phát triển các nhân ternary của riêng mình hay định tuyến đến một bản build được nhúng sẵn là điều mà registry không cho bạn biết. Điều nó cho bạn biết là họ đã không phát hành tệp vốn không thể tải được.

Siêu dữ liệu GGUF cho bạn biết nhiều hơn cả trang đó.

Trang của Ollama báo cáo bốn dữ kiện cho mỗi thẻ: kích thước tính bằng byte, huy hiệu ngữ cảnh “256K”, kiểu đầu vào là văn bản kèm hình ảnh, và dấu thời gian tương đối. Mọi thứ còn lại đều nằm trong tệp. Đọc phần đầu GGUF của từng lớp mô hình sẽ cho ra những điều sau, và nó đáng đọc vì một lý do cụ thể: đây là phần duy nhất trong câu chuyện này không phải là tuyên bố tiếp thị của ai đó.

• general.architecture — qwen35 trên cả bốn kích thước

• general.name — Ternary-Bonsai-2-2B, -4B, -9B trên ba mô hình nhỏ; lớp 27B báo cáo chuỗi chung Hf với general.basename = folded

• general.file_type — 41 trên cả bốn, với general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, khớp với tên thẻ

• Số lượng Tensor — 320 cho 2B, 426 cho 4B, 427 cho 9B, 851 cho 27B

Chuỗi kiến trúc mới là phần thú vị. qwen35 là xương sống attention lai của Qwen3.5, và nó xác nhận từ chính artefact điều mà các model card nói bằng văn xuôi: ba mô hình nhỏ là Qwen3.5-2B, -4B và -9B với kiến trúc không đổi, còn trọng số thì được thay thế. Nó cũng để lộ một mối nối đặt tên mà ghi chú phát hành của chính nhà cung cấp cố che đi. Bài đăng ngày 15 tháng 10 nói rằng các mô hình mới "dựa trên Qwen3.5." Mô hình 27B lại là một nền tảng hoàn toàn khác — Qwen3.8-27B, được công bố ngày 17 tháng 9. Bốn kích cỡ, một tên dòng mô hình, hai mô hình nền tảng. Mọi điều bạn đọc về hành vi của "Bonsai 2" được đo trên 27B đều không tự động chuyển xuống 9B, và header GGUF chính là nơi bạn có thể thấy vì sao.

Metadata của 27B cũng rõ rệt là kém gọn gàng hơn so với phần còn lại: general.name = Hf, general.basename = folded, general.version = v5, và một khóa sampling thừa mà ba mô hình nhỏ không mang. Đó chính là dạng đầu ra trung gian của một pipeline chuyển đổi khi bị đẩy lên mà không qua bước đổi tên cuối cùng. Đó không phải là lỗi — các tensor vẫn là các tensor — nhưng nó là một dấu vết nhận dạng, và nó gợi ý rằng thẻ 27B đã đi qua một con đường khác so với ba mô hình nhỏ.

Những con số của Ollama không có nghĩa là gì

Đây là chỗ hầu hết các bài viết về một danh sách thư viện đều sai, nên đáng để chậm lại mà xem xét kỹ. Kích thước byte trên trang Ollama là kích thước container, và ở mọi mức dung lượng chúng đều lớn hơn tệp mô hình bên trong. Thẻ 2B ghi 911 MB, trong khi lớp mô hình là 0.547 GB và bộ chiếu thị giác là 0.365 GB. Thẻ 27B ghi 8.3 GB, trong khi lớp mô hình là 7.626 GB và bộ chiếu là 0.629 GB. Cộng thêm các blob giấy phép và tham số thì phép tính khớp: Ollama đang tính toàn bộ tạo tác được kéo về, bao gồm cả tháp thị giác.

Điều đó có nghĩa là 3.2 GB trên trang Ollama cho mô hình 9B không thể so sánh với con số "2GB" của nhà cung cấp cho cùng mô hình đó, và khoảng cách này không phải là một sai lệch cần báo cáo — đó là hai phép đo khác nhau của hai thứ khác nhau. 0.43 GB / 0.95 GB / 2 GB của Prism ML chỉ là riêng các mô hình ngôn ngữ. Vision tower được offload và chỉ được nạp khi thực sự có ảnh đến, nên một triển khai chỉ văn bản không bao giờ phải trả chi phí cho nó, nhưng một lần ollama pull thì có. Nếu bạn đang chọn cấu hình thiết bị dựa trên các con số của nhà cung cấp rồi sau đó pull từ Ollama, bạn sẽ vượt ngân sách 0.5 đến 1 GB trước khi chạy bất cứ thứ gì.

Cảnh báo tương tự cũng áp dụng cho nhãn “256K”. Ngữ cảnh thực sự bên dưới là 262.144 token, được kế thừa từ kiến trúc nền Qwen3.5 — 24 lớp attention tuyến tính và 8 lớp full-attention trên bản 9B — và nhãn của Ollama làm tròn xuống để hiển thị. Ngữ cảnh này là thật và được kế thừa, không phải thứ do Ollama thêm vào. Điều không được nêu ở bất kỳ đâu trên trang là việc một ngữ cảnh dài tốn bao nhiêu bộ nhớ, và trên một mô hình attention lai với bộ nhớ đệm full-attention trên một tập con các lớp, đó không phải là một con số nhỏ. Không có gì trên trang Ollama cho bạn biết liệu 262K có thực sự vừa với bất cứ nơi nào bạn định chạy nó hay không.

Ai đã đóng gói cái này, và liệu điều đó có quan trọng không

Chưa được trả lời, và nó nên được gắn cờ là chưa trả lời thay vì đoán. Có ba khả năng: Prism ML đã đẩy nó lên, Ollama đã kéo nó từ các repo GGUF công khai của nhà cung cấp như một phần trong công việc lập danh mục của chính họ, hoặc một bên thứ ba đã làm điều đó. Registry không thể cho bạn biết đó là khả năng nào.

Điều có thể kiểm tra được là nguồn gốc của sản phẩm, và nó khớp hoàn toàn. Mô tả mô hình của chính Ollama viết rằng "Bonsai 2 của Prism ML là một họ mô hình thị giác được xây dựng cho trọng số tam phân (−1, 0 hoặc +1): kích thước chỉ bằng khoảng một nửa so với các mô hình 4-bit tiêu chuẩn, với chất lượng gần đạt mức chính xác đầy đủ" và dẫn liên kết tới tổ chức Hugging Face của nhà cung cấp, whitepaper Bonsai 2 27B, và Apache 2.0. Khối giấy phép được nhúng trong từng một trong bốn manifest kích thước là nguyên văn nội dung Apache 2.0. Khối tham số của 2B, 4B và 9B ghi {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — đúng là chế độ suy nghĩ, chính là công thức lấy mẫu mà nhà cung cấp khuyến nghị trong các thẻ mô hình, với min_p được lược bỏ đúng như thẻ 27B nói rằng các tệp GGUF lược bỏ nó. Đó không phải là một phỏng đoán của ai đó; đó là một bản chuyển đổi đã đọc thẻ mô hình.

Điều đó nghe thì yên tâm, nhưng vẫn chẳng nói cho bạn biết gì về thứ thực sự quyết định trải nghiệm của bạn: liệu các kernel ternary có nằm trong engine mà bạn đang chạy hay không. Quan điểm trung thực là một lần pull thành công chỉ chứng minh tệp là GGUF đúng định dạng, và không hơn gì nữa. Hãy tự kiểm chứng trên phần cứng của bạn trước khi xây dựng dựa trên nó.

Những tuyên bố của nhà cung cấp, và những gì đã được kiểm tra

Mọi con số chất lượng gắn với dòng mô hình này đều đến từ Prism ML, trên bộ kiểm thử riêng của Prism ML, và không có con số nào được tái lập một cách độc lập. Điều đó là bình thường ở giai đoạn này và nên được nói thẳng ra thay vì chỉ ngụ ý. Bài đăng ngày 15 tháng 10 báo cáo 19 benchmark trên sáu nhóm kỹ năng đối với các mô hình nhỏ, cùng với mức duy trì so với các baseline Qwen3.5 độ chính xác đầy đủ:

• 2B — agentic 95.5%, toán 107.8%, tuân thủ hướng dẫn 121.5%, lập trình 115.0%, kiến thức 82.9%, thị giác 89.0%

• 4B — 90,0% / 99,3% / 106,0% / 100,7% / 90,9% / 91,3%

• 9B — 92,4% / 98,2% / 100,0% / 100,1% / 93,0% / 92,5%

Một số mục trong đó vượt quá 100%, đây không phải lỗi đánh máy và cũng không phải sai lệch do làm tròn — điều đó có nghĩa là mô hình ternary đạt điểm cao hơn mô hình độ chính xác đầy đủ mà nó được dẫn xuất từ đó ở hạng mục ấy. Khả năng tuân thủ chỉ dẫn ở mức 121,5% đối với 2B là ví dụ nổi cộm nhất. Hãy nhìn nhận điều đó với sự hoài nghi xứng đáng: một mô hình đã nén vượt qua chính đường cơ sở của nó trên một benchmark do nhà cung cấp lựa chọn nói lên điều gì đó về quá trình huấn luyện và harness ít nhất cũng nhiều như về biểu diễn, và điểm số ở hạng mục mô hình nhỏ nhiễu hơn rất nhiều so với của 27B. Các con số của 27B thận trọng hơn và đáng tin hơn về hình dạng — 84,78 so với 86,32 của FP16, tỷ lệ giữ lại 98,2% trên 14 benchmark chế độ suy nghĩ, với toán ở mức 96,57 so với 97,06 và trình độ lập trình ở mức 89,42 so với 89,07, và phần sụt giảm tập trung vào kiến thức/lập luận và thị giác. Khi một họ mô hình đánh mất năng lực dưới một biểu diễn 1,7-bit, đó chính là hồ sơ mà bạn sẽ dự đoán.

Tuyên bố duy nhất trong bài đăng về mô hình nhỏ màkhông phải là một benchmark lại là tuyên bố đáng được xem xét nghiêm túc nhất: mô hình 9B "sử dụng ít hơn khoảng 40% token trên các tác vụ tuân thủ chỉ dẫn tiêu chuẩn và toán thường ngày." Đó là một tuyên bố về độ dài dòng, không phải về năng lực, và đây là kiểu điều bạn có thể kiểm tra trong một buổi chiều bằng chính các prompt của mình. Nó cũng liên quan đến một cảnh báo trên chính model card của nhà cung cấp — chế độ thinking có thể đốt hơn 3.000 token cho một câu hỏi tầm thường, nên hãy đặt ít nhất 8.192 token đầu ra, và đừng chạy giải mã tham lam (greedy decoding) khi bật thinking vì nó có thể bị kẹt trong suy luận. Một mô hình ít dài dòng hơn 40% mà vẫn cần ngân sách 8.192 token đang nói với bạn rằng nó dài dòng ở một chỗ cụ thể.

Điều này đưa bạn đến đâu

Nếu bạn đã chạy Ollama và muốn thử một mô hình lớp 27B trên laptop mà không có GPU của trung tâm dữ liệu, thì bốn tag là con đường ngắn nhất hiện có: chỉ một lần pull, không fork, không build kernel. Nếu bạn cần bản đóng gói thực sự nhỏ nhất, hoặc các mô hình nháp giải mã suy đoán mà nhà cung cấp phát hành cho 4B và 9B, thì danh sách trên Ollama không có chúng — đó là bản tải xuống từ Hugging Face và bản build Prism ML llama.cpp, và đã như vậy kể từ ngày 15 tháng 10.

Điều đáng biết thêm là chạy cục bộ không phải cách duy nhất để dùng một mô hình low-bit, và cũng không phải lúc nào cũng là cách đúng. OrcaRouter đặt một API duy nhất đứng trước hơn 200 mô hình được lưu trữ với mức markup 0% — giá niêm yết của nhà cung cấp được chuyển nguyên — cùng khả năng tự động chuyển đổi dự phòng giữa các nhà cung cấp, để bạn có thể đánh giá một mô hình trên khối lượng công việc thực tế trước khi quyết định liệu nó có xứng đáng có một chỗ trên laptop của bạn hay không. Hiện tại không có kích cỡ nào của Bonsai 2 được phục vụ qua OrcaRouter, và bài viết này không khẳng định điều ngược lại: dòng mô hình này là bản tải về để bạn tự chạy, và sẽ vẫn như vậy cho đến khi nhà cung cấp công bố một endpoint. Điều mà lớp định tuyến mang lại cho bạn là nửa còn lại của quyết định — những mô hình được lưu trữ mà bạn sẽ so sánh với nó, nằm sau một khóa duy nhất, với tính năng hợp nhất mô hình và DSL định tuyến sẵn có khi một mô hình đơn lẻ là chưa đủ.

Những điều cần theo dõi, theo mức độ chúng sẽ thay đổi cục diện: một tag Ollama có thêm một ptq1_0 cùng loại, điều đó có nghĩa là các kernel dense-trit đã được đưa vào upstream; một bài đăng của nhà cung cấp công nhận nền tảng này, điều đó sẽ trả lời câu hỏi về nguồn gốc; và bất kỳ benchmark độc lập nào về 9B hoặc 27B, đây là thứ duy nhất có thể đưa các số liệu về độ giữ lại ra khỏi cột do nhà cung cấp báo cáo. Cho đến khi một trong những điều đó thành hiện thực, mục niêm yết này là một cơ chế phân phối, không phải một mô hình mới — và mô hình mà nó phân phối đã công khai từ ngày 15 tháng 10.

Không có gì trong số đó là giả thuyết: các lỗi AI và sự cố tác nhân được ghi nhận đằng sau những bản phát hành như bản này đều được tập hợp trong OrcaRouter AI Incident Archive, nơi mỗi mục đều có nguồn, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp riêng.