Granite Switch 4.1 8B: Một checkpoint 8B duy nhất vừa trò chuyện, vừa ra quyết định, vừa chuyển thành văn bản

Tám tỷ ba trăm tám mươi triệu tham số đi vào. Tám tỷ bảy trăm bảy mươi sáu triệu tham số đi ra. 4,72% đó chính là toàn bộ khác biệt giữa mô hình nền tảng của IBM và Granite Switch 4.1 8B, và đó là con số thú vị nhất trong bản phát hành này, bởi vì gói gọn trong phần chênh lệch nhỏ xíu ấy là một bộ phân loại an toàn, một cỗ máy ra quyết định và một bộ nhận dạng giọng nói — tất cả đều trả lời từ một điểm cuối duy nhất, tất cả đều đọc và ghi cùng một bộ đệm KV mà mô hình nền tảng vốn dĩ đã tạo ra.

Các trọng số đã được đăng tải lên Hugging Face vào ngày 14 tháng 10 năm 2026. Bài blog ra mắt của chính IBM, Granite Switch 4.1: Chat, Decisions, and Speech from One Endpoint, tiếp nối vào ngày 15 tháng 10, và điều này đáng nói thẳng ngay từ đầu: đây không phải là một bản phát hành âm thầm mà ai đó tình cờ tìm thấy trong một mirror. Đây là một bản phát hành đã được công bố, tính đến thời điểm viết bài chỉ mới khoảng hai ngày tuổi, và phiên bản câu chuyện đáng quan tâm không phải là "IBM đã tuyên bố điều gì" mà là "bạn thực sự có thể xác minh được gì từ checkpoint đang nằm trên Hub ngay lúc này." Hai điều đó không giống nhau, và bài viết này tách bạch chúng.

Checkpoint thực sự chứa những gì

Granite Switch không phải là một kiến trúc mới. Nó là một tổ hợp: một mô hình nền đóng băng, một tập hợp các bộ điều hợp hạng thấp có thể được bật và tắt theo từng token, và — trong bản dựng cụ thể này — một bộ mã hóa được gắn thêm cho âm thanh. Composer nằm trong granite-switch repository và manifest bản dựng cho checkpoint này được lưu ngay cạnh các trọng số, nghĩa là mọi khẳng định về cấu trúc bên dưới đều có thể đọc trực tiếp từ Hub thay vì lấy từ thông cáo báo chí.

Mô hình cơ sở là Granite 4.1 8B — chỉ gồm bộ giải mã dày đặc, attention truy vấn nhóm với 32 đầu truy vấn so với 8 đầu khóa/giá trị, SwiGLU, RMSNorm, cửa sổ 131.072 token và từ vựng 100.352 token. Checkpoint được hợp thành kế thừa toàn bộ những điều đó và bổ sung hai bộ điều hợp LoRA đã kích hoạt:

• guardian-core — hạng 16, alpha 64, chỉ gắn với các phép chiếu attention (k_proj, o_proj, q_proj, v_proj), được lấy từ bản phát hành Guardian Library và được mô tả là có khả năng phát hiện tác hại, jailbreaking, ngôn từ tục tĩu, bạo lực, nội dung khiêu dâm, thiên kiến xã hội và hành vi phi đạo đức.

• quyết định — rank 64, alpha 128, được gắn vào cả bảy phép chiếu bao gồm MLP (down_proj, gate_proj, up_proj), và được huấn luyện để làm một việc gì đó hẹp hơn và kỳ lạ hơn: với một trạng thái và một câu hỏi có các lựa chọn được gán nhãn, trả về một phân phối xác suất đã hiệu chỉnh trên các nhãn lựa chọn đó chỉ trong một lượt truyền xuôi.

Cả hai đều được kích hoạt bởi các token điều khiển — <|guardian-core|> và <|decision|> — mà mẫu trò chuyện sẽ tự chèn cho bạn khi bạn truyền một đối số adapter_name. Bạn không tự viết các token này, và chi tiết đó quan trọng hơn vẻ ngoài của nó: nó có nghĩa là việc chọn adapter là một tham số yêu cầu, chứ không phải một mô hình thứ hai để triển khai.

Tại sao delta của tham số lại nhỏ đến vậy

Câu chuyện nằm ở phép tính. Mô hình cơ sở có 8.380.551.168 tham số. Mô hình tổng hợp có 8.776.400.896. Đó là +395,8 triệu, tức +4,72%, cho hai adapter. Lý do con số vẫn thấp đến vậy là một quyết định thiết kế có tên chuẩn hoá KV-cache: mỗi adapter đều nhìn thấy bộ đệm khóa/giá trị của mô hình cơ sở thay vì duy trì bộ đệm riêng. Trong một thiết lập đa adapter thông thường, mỗi adapter bổ sung là một tập trạng thái attention thứ hai, và chi phí bộ nhớ tăng theo số lượng adapter mà bạn chuyển đổi qua lại. Ở đây thì không. Tuyên bố của IBM trong bài đăng ra mắt là mô hình tổng hợp chiếm "xấp xỉ cùng lượng VRAM trên GPU như mô hình cơ sở sẽ dùng khi đứng một mình", và dù chưa có ai bên ngoài IBM đo đạc điều đó, mức chênh lệch trọng số 4,72% vẫn nhất quán với nó — và không giống như tuyên bố về VRAM, mức chênh lệch trọng số chỉ là một con số trong manifest mà bạn có thể đọc.

Bộ điều hợp quyết định là nửa thú vị

Đọc ra một phân phối xác suất từ một mô hình ngôn ngữ thì không có gì mới; điều đáng để hiểu là làm được điều đó chỉ trong một lượt forward pass với một bộ nhãn lựa chọn cố định, và thu được những con số đủ chuẩn để hành động dựa vào. Công thức gọi được ghi lại trong card: một system prompt cố định cho decision engine, một State: lượt được đánh giá trên base đã đóng băng, rồi đến một ### DECISION lượt trình bày câu hỏi và các lựa chọn được gán nhãn bằng một token duy nhất. Sau đó bạn yêu cầu server trả về logprobs của đúng các token id nhãn đó — vLLM cung cấp điều này qua logprob_token_ids — rồi lấy exp. Ví dụ trong tài liệu trả về đại loại như A: 0.982, B: 0.0035, C: 0.014.

Có một vấn đề kỹ thuật thực sự ở đây mà phiên bản marketing của bản phát hành này bỏ qua. vLLM giới hạn logprob_token_ids ở mức 128 id mỗi yêu cầu. Nếu câu hỏi quyết định của bạn có nhiều hơn 128 lựa chọn, bạn sẽ nhận HTTP 400, và cách khắc phục là chia các id nhãn thành các khối 128, gửi một yêu cầu cho mỗi khối với một prompt giống hệt nhau, rồi nối lại — bởi vì các logprobs được trả về nằm trên toàn bộ từ vựng, giá trị của mỗi nhãn không phụ thuộc vào việc khối nào đã hỏi nó, nên một softmax duy nhất trên toàn bộ tập nhãn là hoàn toàn giống về mặt toán học với một lệnh gọi không bị giới hạn. Đó là thêm một yêu cầu cho mỗi 128 lựa chọn. Đó là một chi tiết thực sự hữu ích, và nó đúng kiểu điều chỉ tồn tại trong repo.

Con số công bố duy nhất gắn với adapter này là Decision Index (JEV), phiên bản v0.3, tập con nhanh công khai gồm 1.068 dòng: Tổng thể 42,9, Kiến thức 29,1, Ngôn ngữ 48,9, Truy xuất 49,8, Công cụ 59,8, Nghệ thuật 18,0. Hãy coi đó là số liệu do nhà cung cấp tự báo cáo, vì đúng là như vậy: IBM đã chạy nó, công bố nó, và chưa có bên thứ ba nào tái lập được. Cũng đáng để đọc hình dạng hơn là con số hào nhoáng — 59,8 ở Công cụ bên cạnh 18,0 ở Nghệ thuật là một hồ sơ rất không đồng đều, và chính tấm card cảnh báo rằng các xác suất lựa chọn là "một tiên nghiệm để hỗ trợ ra quyết định, chứ không phải một phân loại đã được chứng nhận" trên những lĩnh vực mà adapter chưa được huấn luyện.

Chuyển giọng nói thành văn bản là có thật, và phạm vi hẹp hơn tiêu đề.

Đường dẫn âm thanh nhúng Granite Speech 5.0 TurboCTC, một bộ mã hóa CTC conformer phi tự hồi quy với 470M tham số, và phiên âm âm thanh đến trước khi ghép bản phiên âm vào ngữ cảnh trò chuyện thay cho phần nội dung âm thanh. Việc gọi nó không làm thay đổi dạng thức yêu cầu: nó là một input_audio phần nội dung trong một chat completion thông thường, và quá trình phiên âm chạy trên cùng endpoint với chat và các quyết định, nên không cần dựng thêm một máy chủ giọng nói thứ hai.

Các lưu ý, tất cả đều đến từ chính thẻ của IBM chứ không phải từ một nhà phê bình: bộ mã hóa chỉ dành cho tiếng Anh, đầu ra của nó là chữ thường và không có dấu câu, không có điều hướng ở thời điểm giải mã, và — điều đáng lẽ phải khiến bạn dừng lại — bộ mã hóa giọng nói và LLM không được huấn luyện chung. Không có phép chiếu đã được huấn luyện nào gắn kết chúng. Do đó, một lỗi phiên âm có thể âm thầm thay đổi thứ mà mô hình, hoặc một bộ điều hợp, phản hồi. Nếu bạn đang xây dựng bất cứ thứ gì mà lỗi phiên âm gây ra hậu quả, thì câu đó chính là toàn bộ phần đánh giá bảo mật.

Điều gì đã được xác nhận, điều gì do nhà cung cấp báo cáo, điều gì chưa ai kiểm tra

• Đã xác nhận từ repo — danh tính mô hình cơ sở và số lớp, hai rank adapter và các mô-đun mục tiêu tương ứng, các id token điều khiển, số tham số đã hợp thành, cửa sổ 131.072 token, giấy phép Apache-2.0, và các phiên bản vLLM cùng Transformers được ghi tài liệu mà card yêu cầu.

• Do nhà cung cấp báo cáo, chưa được tái lập — điểm số Decision Index, tuyên bố rằng Granite Speech 5.0 TurboCTC là mô hình ASR nhanh nhất trên bảng xếp hạng OpenASR, tuyên bố "cùng dung lượng VRAM như mô hình cơ sở", và phần ghi chú thêm trong bài đăng ra mắt rằng một mô hình Granite Switch 3B tùy chỉnh chơi Doom với tốc độ 60–100 quyết định mỗi giây, so với mức 10 quyết định mỗi giây được báo cáo của một mô hình quyết định đóng. IBM cho biết sẽ công bố thêm dữ liệu "trong những tuần tới", đây là một sự thừa nhận rằng bằng chứng hiện tại còn mỏng.

• Chưa có ai kiểm chứng — mọi thứ còn lại. Không có đánh giá độc lập, không có mục nào trên bảng xếp hạng của bên thứ ba, không có API nào do IBM lưu trữ, và không có phép đo độ trễ hay thông lượng nào được công bố từ bất kỳ ai không phải IBM. Repo trên Hub cho thấy vài chục lượt tải xuống và một vài lượt thích: mô hình này mới ra đời được hai ngày và phần lớn vẫn chưa được ai để mắt tới.

Chi phí vận hành là bao nhiêu, và OrcaRouter phù hợp ở đâu

Granite Switch 4.1 8B hiện là một câu chuyện tự triển khai (self-host). Thẻ (card) liệt kê HuggingFace Transformers và vLLM là các backend, ghim một cửa sổ hỗ trợ khá hẹp (Transformers 5.16–5.17, vLLM 0.26–0.28), và checkpoint hoạt động với cả hai mà không cần thay đổi mã. Không có endpoint được quản lý nào để trỏ tới, điều mà với hầu hết các nhóm có nghĩa là một GPU và một container trước yêu cầu đầu tiên.

Nói thẳng về phần còn lại: Granite Switch hiện không có trong danh mục của OrcaRouter, và cũng không có bất kỳ mô hình Granite nào khác — vậy nên nếu bạn muốn checkpoint này, con đường là bản phát hành của chính nhà cung cấp cùng phần cứng của bạn, chứ không phải chúng tôi. Điều mà OrcaRouter mang lại là quyết định xoay quanh đó. Nền tảng này định tuyến hơn 200 mô hình đằng sau một khóa duy nhất với tính năng chuyển đổi dự phòng tự động, và chuyển tiếp đúng giá niêm yết của nhà cung cấp với mức chênh lệch 0%, nên khi một mô hình bạn đang đánh giá thực sự có được endpoint dạng host, việc so sánh nó với mô hình hiện hữu trên chính lưu lượng của bạn chỉ là một thay đổi cấu hình thay vì phải ký thêm hợp đồng thứ hai. Điều đó đặc biệt quan trọng đúng trong tình huống này: một checkpoint mới hai ngày tuổi chưa có đánh giá độc lập là một ứng viên, chứ không phải mô hình hiện hữu, và việc tốn ít chi phí nên làm với một ứng viên là giữ nó trong thế chạy song song so sánh thay vì đấu dây lại một đường dẫn sản xuất xoay quanh nó.

Câu hỏi mở

Granite Switch 4.1 8B là một canh bạc rằng thành phần cấu thành quan trọng hơn quy mô đối với một lớp công việc cụ thể: những ứng dụng cần trả lời, ra quyết định và phiên âm, nơi mà chạy ba mô hình đồng nghĩa với ba lần triển khai, ba độ trễ và ba hóa đơn. Phần kỹ thuật để biến canh bạc đó thành rẻ — KV cache dùng chung, chuyển đổi adapter theo từng token, các control token được phân giải trong chat template — thực sự khác thường, và đó chính là phần của bản phát hành này mà vẫn sẽ còn quan trọng sau một năm nữa.

Điều chưa được làm rõ là liệu câu trả lời được tổng hợp có tốt. Hồ sơ đã công bố của bộ điều hợp quyết định thì không đồng đều, đường tiếng nói chỉ dành cho tiếng Anh và không được huấn luyện chung, và toàn bộ thứ này mới chỉ hai ngày tuổi với không có lần chạy độc lập nào đằng sau nó. Hãy đọc bản kê khai bản dựng, tự mình chạy lệnh tổng hợp, và đánh giá chuẩn bộ điều hợp quyết định trên tập nhãn của riêng bạn trước khi bạn tin con số 42.9 của bất kỳ ai.