Kev: Ra mắt dòng mô hình ra quyết định nhỏ gọn dựa trên Qwen3.5

Các mô hình quyết định nhỏ kiểu Jev mà bạn có thể tự huấn luyện và chạy.

Kev là một dòng mô hình quyết định nhỏ được xây dựng trên Qwen3.5 và dựa trên kiến trúc được mô tả trong "Jev's Architecture Unmasked". Bạn có thể sử dụng các trọng số đã được huấn luyện sẵn hoặc tự huấn luyện mô hình của riêng mình. API của nó tương thích với System One của TypeSafe, vì vậy bạn có thể trỏ SDK Python của họ vào máy chủ cục bộ của bạn.

Điểm nổi bật

Bắt đầu nhanh

Bạn sẽ cần Python 3.12+ và uv.

Lệnh này khởi chạy Kev-4B cục bộ. Lần chạy đầu tiên sẽ tải xuống adapter và mô hình cơ sở. --run cũng chấp nhận một thư mục checkpoint cục bộ hoặc một bản sửa đổi trên Hub, chẳng hạn như jaredpalmer/kev-4b@qwen3 cho thế hệ trước.

Trong một terminal khác, hãy gửi cho nó một ticket:

Ví dụ phản hồi từ Kev-4B, chạy ở định dạng bf16 trên Apple M5:

Ticket đề cập đến việc trả hàng, giao hàng trễ và vấn đề thanh toán, và các xác suất theo bộ phận cho thấy điều đó. Đó chính là mục đích của việc nhận lại các xác suất thay vì chỉ một nhãn duy nhất.

Python

SDK TypeSafe đã được bao gồm trong uv sync --extra serve:

Playground

Khi máy chủ vẫn đang chạy, hãy mở một terminal khác. Bạn sẽ cần Node 20.9+:

Mở localhost:3001, tải một preset, sau đó chỉnh sửa văn bản và các câu hỏi. Nhấn ⌘↵ để chạy. "Packed vs separate" so sánh việc hỏi tất cả các câu hỏi cùng lúc với việc hỏi từng câu một. "Permute" chạy một câu hỏi dạng Choice với sáu thứ tự tùy chọn khác nhau. Ngoài ra còn có các preset để kiểm tra tính cô lập của câu hỏi và các token phân cách giả.

Cũng có một bản demo cờ vua. Bàn cờ là đầu vào, các nước đi hợp lệ là các tùy chọn Choice, và một câu hỏi Score sẽ đánh giá vị trí đó. Bạn có thể chơi với Kev hoặc để nó tự chơi với chính mình. Các ván đấu được lưu trong localStorage.

Các mô hình

Hãy bắt đầu với Kev-4B. Sử dụng Kev-9B khi độ chính xác và hiệu chuẩn quan trọng hơn bộ nhớ. Sử dụng Kev-0.8B nếu bạn cần mô hình nhỏ nhất. Cả ba đều được xây dựng trên nền tảng Qwen3.5 với cùng dữ liệu huấn luyện và cài đặt.

Mỗi ô là phát triển / kiểm thử. "Trained sources" nghĩa là các ví dụ tách biệt từ các tập dữ liệu được dùng để huấn luyện Kev. "New sources" nghĩa là các tập dữ liệu và loại quy tắc chính sách mà Kev chưa từng được huấn luyện. Mọi mô hình đều được đánh giá trên cùng các tập phát triển (decision-v7, transfer-v4) và cùng các tập kiểm thử, vốn được đọc một lần cho mỗi checkpoint được phát hành, sau khi đã chọn mô hình. Chỉ số Brier thấp hơn là tốt hơn.

Kev-9B kém hơn Jev khoảng 4,5 điểm trên tập phát triển nguồn mới. Chúng tôi không biết Jev được huấn luyện trên những tập dữ liệu nào, vì vậy đây không phải là một so sánh có kiểm soát giữa hai kiến trúc.

Tất cả các trọng số đều nằm trong bộ sưu tập Kev và bản phát hành trên GitHub, bao gồm các tệp tarball và mã kiểm tra SHA-256.

Dòng Kev đầu tiên sử dụng nền tảng Qwen3 với cùng dữ liệu và cài đặt. Các trọng số đó vẫn được công bố và là lựa chọn nhanh hơn trên Mac (xem phần Hiệu suất phục vụ), nhưng chúng không còn được phát triển nữa.

Vì chỉ có mô hình cơ sở thay đổi, hai thế hệ này là một so sánh có kiểm soát. Trên tập phát triển, mức tăng độ chính xác nằm trong phạm vi nhiễu; trên tập kiểm thử, Kev-9B dẫn trước Kev-8B 7,3 điểm (95% CI +2,8 đến +11,7) với điểm Brier thấp hơn 0,08, Kev-4B dẫn trước phiên bản tiền nhiệm 2,9 điểm (−0,9 đến +6,4), và Kev-0.8B dẫn trước Kev-0.6B 4,8 điểm (+0,2 đến +9,3). PLAN_Qwen35.md chứa toàn bộ thí nghiệm, bao gồm các tiêu chí chúng tôi đặt ra trước đó và cách các kết quả đo lường dựa trên các tiêu chí đó.

Kev-0.5B gốc sử dụng Qwen2.5-0.5B và được giữ lại để tham khảo; xem thẻ mô hình của nó.

API

POST /v1/systemone

state là văn bản cần đánh giá. Mỗi câu hỏi có các hướng dẫn và, khi cần, một tập hợp các câu trả lời để lựa chọn.

Đối với Choice với K > 1 tùy chọn, độ tin cậy là (p_max − 1/K) / (1 − 1/K). Một tùy chọn duy nhất có độ tin cậy là 1. Độ tin cậy của Score đo lường mức độ gần gũi của phân phối với mức có khả năng xảy ra cao nhất của nó. Đây là một phép xấp xỉ công thức của TypeSafe, vốn không được công khai. Cả hai trường này không phải là tỷ lệ chính xác đo lường được.

Các đối tượng và mảng được chuyển đổi thành văn bản có nhãn. Các chuỗi giống như dấu phân cách trong đầu vào của người dùng được thoát (escape) trước khi token hóa. Các yêu cầu không hợp lệ sẽ trả về mã 422. usage.output_tokens đếm các token trong các câu trả lời đã được tuần tự hóa, không phải các token được tạo ra.

Máy chủ liên kết với 127.0.0.1 và không có xác thực. Hãy giữ nó ở cục bộ trừ khi bạn tự thêm xác thực.

Cách thức hoạt động

Mỗi checkpoint là một adapter LoRA rank-16 và một đầu pointer nhỏ trên mô hình cơ sở Qwen. Trên một mô hình cơ sở chỉ có attention (Qwen3), trạng thái và các câu hỏi đi vào một chuỗi token:

Mặt nạ attention cho phép một token đọc trạng thái và câu hỏi của chính nó, nhưng không đọc được các câu hỏi khác hoặc các token tương lai. ID vị trí của mỗi câu hỏi bắt đầu lại ngay sau trạng thái. Điều này cho phép mô hình xử lý trạng thái một lần và trả lời từng câu hỏi một cách độc lập.

Qwen3.5 kết hợp các lớp attention với các lớp Gated DeltaNet, vốn có tính hồi quy và bỏ qua mặt nạ attention. Đối với các mô hình đó, mỗi câu hỏi chạy như một hàng riêng biệt: trạng thái theo sau bởi câu hỏi đó, với các vị trí giống như trên. Các hàng là độc lập, vì vậy sự cô lập là chính xác, và máy chủ tính toán trạng thái một lần và tái sử dụng bộ nhớ đệm của nó cho mỗi hàng. Trên các mô hình chỉ có attention, hai hình thức này cho ra các xác suất giống hệt nhau (tests/test_v3.py).

Đầu pointer chấm điểm trạng thái ẩn </opt> của mỗi tùy chọn so với trạng thái ẩn <decide> của câu hỏi. Một hàm softmax chuyển đổi các điểm số đó thành xác suất. Vì <decide> nằm ở cuối, nó có thể chú ý đến toàn bộ danh sách tùy chọn.