NaiveAI ra mắt mô hình lập trình siêu nhanh Naive-N0.5-Flash

Nhà phát triển Trung Quốc NaiveAI vừa cho ra mắt Naive-N0.5-Flash, một mô hình ngôn ngữ mã nguồn mở (open-weights) được tối ưu hóa cho tốc độ suy luận cực nhanh trong các tác vụ lập trình. Được công bố vào ngày 10 tháng 11 năm 2026, một bài đánh giá kỹ thuật từ Latent Space đã so sánh tân binh này với các đối thủ lâu năm như DeepSeek V4.1 Flash 1017 và GLM 5.3 Flash để xác định xem liệu tốc độ thô có làm giảm chất lượng code hay chiều sâu suy luận hay không.

Chuyện gì đã xảy ra

Naive-N0.5-Flash được xây dựng dựa trên kiến trúc của MiMo-V2.5 thuộc Xiaomi, một mô hình Mixture-of-Experts thưa thớt với 310 tỷ tham số. NaiveAI đã mở rộng nền tảng này bằng khoảng 3,25 nghìn tỷ token huấn luyện bổ sung, tập trung mạnh mẽ vào khả năng suy luận với ngữ cảnh dài. Khoảng 3 nghìn tỷ token trong số đó được xử lý ở độ dài ngữ cảnh cố định là một triệu token với tốc độ học không đổi. Mô hình kết quả tích hợp các lớp DeepSeek Sparse Attention và chạy trên engine suy luận độc quyền NaiveRT của NaiveAI, được thiết kế để giảm thiểu độ trễ thông qua kỹ thuật giải mã dự đoán (speculative decoding).

Lời hứa cốt lõi của mô hình là khả năng tự cải tiến đệ quy và lặp lại nhanh chóng cho các quy trình làm việc kỹ thuật. Để kiểm chứng những tuyên bố này, Latent Space đã thực hiện một loạt benchmark so sánh Naive-N0.5-Flash với hai mô hình phổ biến thuộc dòng "Flash": DeepSeek V4.1 Flash 1017 và GLM 5.3 Flash. Các bài kiểm tra đo lường thông lượng, thời gian phản hồi, mức độ dài dòng và khả năng lập trình thực tế trên ba prompt xây dựng ứng dụng khác nhau. Mục tiêu của đánh giá là tìm hiểu xem lợi thế tốc độ của mô hình có duy trì được dưới tải suy luận phức tạp hay dẫn đến các đầu ra hời hợt.

Kết quả làm nổi bật sự đánh đổi đáng kể giữa thời gian suy nghĩ và tốc độ đầu ra. Trong khi Naive-N0.5-Flash cung cấp câu trả lời nhanh hơn trong các trường hợp trung vị, nó tiêu thụ lượng token lớn hơn nhiều khi hoạt động ở chế độ suy luận sâu. Hành vi này cho thấy mô hình rất hiệu quả cho các vòng lặp nhanh nhưng có thể trở nên đắt đỏ đối với các tác vụ yêu cầu xử lý chuỗi suy nghĩ (chain-of-thought) mở rộng. Đánh giá cung cấp một cái nhìn tinh tế về vị trí của mô hình mới này trong bối cảnh hiện tại của các công cụ phát triển hỗ trợ bởi AI.

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

Hiệu suất của Naive-N0.5-Flash phụ thuộc phần lớn vào cơ sở hạ tầng suy luận chứ không chỉ riêng trọng số mô hình. Nó sử dụng một engine tùy chỉnh tên là NaiveRT, áp dụng kỹ thuật giải mã dự đoán để đẩy nhanh quá trình tạo sinh. Trong quy trình này, một mô hình nháp nhỏ hơn sẽ dự đoán nhiều token tương lai, sau đó mô hình mục tiêu lớn hơn sẽ xác minh chúng song song. Phương pháp này giảm số lượng bước tuần tự cần thiết để tạo văn bản. Các nhà phát triển báo cáo rằng một vòng giải mã dự đoán đầy đủ mất 3,4 mili giây trong NaiveRT, so với 12,3 mili giây trong các triển khai tiêu chuẩn như SGLang.

Các chỉ số tốc độ thay đổi đáng kể tùy thuộc vào việc mô hình đang ở trạng thái "suy nghĩ" hay không. Khi tắt tính năng suy nghĩ, tỷ lệ chấp nhận token nháp là 70,6%, cho phép tốc độ giải mã đạt khoảng 1.816 token mỗi giây. Khi bật tính năng suy nghĩ, tỷ lệ chấp nhận giảm xuống còn 43,4% và tốc độ giảm xuống khoảng 984 token mỗi giây trong giai đoạn suy luận. Tốc độ đỉnh có thể đạt tới 2.100 token mỗi giây, nhưng đây là giới hạn trên trong điều kiện luồng đơn lý tưởng trên một node Blackwell gồm 8 GPU.

Chi tiết chính

• Naive-N0.5-Flash dựa trên MiMo-V2.5 của Xiaomi và được huấn luyện thêm trên 3,25 nghìn tỷ token.
• Mô hình nhắm tới mức giá $0,10 cho mỗi triệu token đầu vào và $0,40 cho mỗi triệu token đầu ra.
• Thời gian phản hồi trung vị khi bật chế độ suy nghĩ là 3,1 giây, nhanh hơn GLM 5.3 Flash (5,3s) và DeepSeek V4.1 (10,1s).
• Đối với các câu hỏi khó, thời gian phản hồi trung bình là 89,8 giây, chậm hơn so với DeepSeek V4.1 Flash 1017 ở mức 79,7 giây.
• Chế độ suy nghĩ làm tăng độ dài dòng một cách kịch tính, trung bình 108.500 token hoàn thành trên các tác vụ khó so với khoảng 12.000 token của các đối thủ.
• Điểm benchmark đặt mô hình này vượt lên trên cả hai đối thủ trên NL2Repo-Bench với điểm số 71,9.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm xây dựng agent AI hoặc trợ lý lập trình tương tác, độ trễ suy luận thường là nút thắt cổ chai chính. Naive-N0.5-Flash chứng minh rằng thời gian phản hồi trung vị dưới một giây là khả thi ngay cả với các mô hình phức tạp, miễn là cơ sở hạ tầng hỗ trợ kỹ thuật giải mã dự đoán hiệu quả. Tốc độ này cho phép các nhà phát triển lặp lại prompt và gỡ lỗi các đoạn code gần như theo thời gian thực, cải thiện tính mượt mà trong cộng tác giữa người và AI. Tuy nhiên, mức tiêu thụ token cao trong các giai đoạn suy luận nghĩa là tối ưu hóa chi phí vẫn là yếu tố then chốt cho các triển khai sản xuất.

Đánh giá cũng nhấn mạnh tầm quan trọng của việc đo lường hiệu suất trung vị thay vì trung bình. Một vài yêu cầu ngoại lệ với dấu vết suy luận cực kỳ dài có thể làm lệch các chỉ số trung bình, khiến mô hình trông có vẻ chậm hơn hoặc dài dòng hơn so với thực tế thông thường. Các nhà phát triển nên thiết kế ứng dụng của mình để xử lý độ dài đầu ra biến động và cân nhắc triển khai timeout hoặc ngân sách token để ngăn chặn chi phí bùng nổ trong các tác vụ suy luận phức tạp. Hiểu rõ những khác biệt về phân phối này là chìa khóa để chọn đúng mô hình cho các trường hợp sử dụng cụ thể.

Bạn có thể làm gì

• Thử nghiệm Naive-N0.5-Flash trên các tác vụ lập trình đơn giản để tận dụng độ trễ trung vị thấp cho các vòng lặp phản hồi nhanh.
• Triển khai ngân sách token nghiêm ngặt khi sử dụng chế độ suy nghĩ để tránh chi phí bất ngờ từ các dấu vết suy luận dài dòng.
• So sánh tỷ lệ chấp nhận giải mã dự đoán trong cơ sở hạ tầng của bạn để xác định các cơ hội tối ưu hóa tiềm năng.
• Sử dụng thời gian phản hồi trung vị thay vì trung bình khi đánh giá hiệu suất mô hình cho các ứng dụng hướng tới người dùng.
• Đánh giá mô hình trên các tác vụ kiểu NL2Repo-Bench nếu quy trình làm việc của bạn liên quan đến việc tạo toàn bộ repository từ ngôn ngữ tự nhiên.
• Giám sát hiệu quả của code JavaScript hoặc Python được tạo ra, vì tốc độ tạo sinh nhanh hơn không luôn đồng nghĩa với hiệu suất runtime tốt hơn.