Trình xác minh nhà cung cấp Kimi - Xác minh độ chính xác của nhà cung cấp suy luận

• Kimi Vendor Verifier (KVV) là một công cụ công khai được thiết kế để kiểm chứng độ lệch trong triển khai suy luận phát sinh trên các hạ tầng khác nhau sau khi mô hình mã nguồn mở được triển khai, từ đó giúp phân biệt giới hạn vốn có của mô hình với lỗi kỹ thuật triển khai
• Dựa trên API chính thức, công cụ công bố các kết quả OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8, đồng thời công khai cả thiết lập Temperature, TopP, MaxTokens của từng bài đánh giá và tệp kết quả đánh giá K2VV
• Kết quả điều tra các dấu hiệu bất thường benchmark do cộng đồng báo cáo cho thấy phần lớn bắt nguồn từ việc dùng sai tham số giải mã, và ở chế độ Thinking áp dụng Temperature 1.0 cùng TopP 0.95 bắt buộc, đồng thời kiểm tra việc chuyển tiếp lại nội dung
• Quy trình xác minh được cấu trúc theo hướng sau bước tiền xác minh để kiểm tra ràng buộc tham số, sẽ dùng OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench... nhằm kiểm tra tiền xử lý Vision, đầu ra dài, gọi công cụ và cả agentic coding
• Toàn bộ workflow mất khoảng 15 giờ khi chạy tuần tự trên hai máy chủ NVIDIA H20 8-GPU, và dự án đang thúc đẩy mở rộng mô hình xác minh ưu tiên độ chính xác thông qua leaderboard công khai và quyền truy cập sớm

---

Xây dựng lại chuỗi tin cậy (Chain of Trust)

• Cùng với việc công khai mã nguồn Kimi Vendor Verifier (KVV), công cụ này được thiết kế để người dùng mô hình mã nguồn mở có thể xác minh độ chính xác của triển khai suy luận
• Nó được phát hành đồng thời với mô hình Kimi K2.6, và việc chỉ công bố mô hình là chưa đủ; còn cần một quy trình để xác nhận mô hình có hoạt động đúng trong nhiều môi trường khác nhau hay không
• Khi hệ sinh thái mô hình mã nguồn mở ngày càng mở rộng việc công bố trọng số và đa dạng hóa các đường triển khai, cấu trúc khó kiểm soát chất lượng ngày càng bộc lộ rõ
• Nếu người dùng không thể phân biệt khiếm khuyết hiệu năng vốn có của mô hình với độ lệch do triển khai kỹ thuật, niềm tin vào hệ sinh thái mã nguồn mở có thể sụp đổ

Cách giải quyết

• Từ các dấu hiệu bất thường riêng lẻ đến vấn đề mang tính cấu trúc

  • Sau khi K2 Thinking được công bố, cộng đồng thường xuyên gửi phản hồi về hiện tượng điểm benchmark bất thường
  • Kết quả điều tra xác nhận rằng trong phần lớn trường hợp, nguyên nhân là việc dùng sai tham số giải mã
  • Như một biện pháp giảm thiểu tức thời, một tuyến phòng thủ cấp API đã được dựng lên
    • Ở chế độ Thinking, bắt buộc Temperature=1.0, TopP=0.95
    • Áp dụng kiểm tra bắt buộc để xác nhận nội dung thinking được chuyển tiếp lại chính xác
  • Ở một số bài đánh giá LiveBenchmark cụ thể, quan sát thấy chênh lệch lớn giữa API bên thứ ba và API chính thức
  • Kết quả kiểm thử diện rộng với nhiều nhà cung cấp hạ tầng xác nhận rằng những khác biệt này tồn tại trên diện rộng

• Quy trình xác minh và vận hành

  • Công bố các chỉ số benchmark theo API chính thức
    • Độ chính xác OCRBench 91.0
    • AIME2025 avg@32 98.4
    • Độ chính xác MMMU Pro Vision 78.8
  • Đồng thời nêu rõ các giá trị cấu hình đánh giá
    • Cả ba hạng mục đều dùng Temperature 1.0, TopP 0.95
    • MaxTokens lần lượt là OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
  • Cung cấp liên kết tới tệp kết quả đánh giá K2VV của Kimi API, đồng thời nêu rõ mục đích dùng để tính điểm F1
  • Vận hành giai đoạn Pre-Verification
    • Xác minh xem các ràng buộc tham số API như temperature, top_p... có được áp dụng đúng cách hay không
    • Chỉ tiến hành đánh giá benchmark sau khi vượt qua toàn bộ bài kiểm tra
  • Sử dụng OCRBench
    • Đóng vai trò là bài smoke test 5 phút cho pipeline đa phương thức
  • Sử dụng MMMU Pro
    • Xác minh tiền xử lý đầu vào Vision thông qua nhiều bài test đầu vào thị giác khác nhau
  • Sử dụng AIME2025
    • Đóng vai trò stress test cho đầu ra dài
    • Phát hiện lỗi KV cache và suy giảm hiệu năng do lượng tử hóa mà benchmark ngắn khó bộc lộ
  • Sử dụng K2VV ToolCall
    • Đo độ nhất quán kích hoạt (F1) và độ chính xác của JSON Schema
    • Phát hiện sớm trước khi lỗi công cụ tích lũy trong agent
  • Sử dụng SWE-Bench
    • Đóng vai trò là bài kiểm tra agentic coding toàn diện
    • Không mở mã nguồn do phụ thuộc vào sandbox
  • Phối hợp làm việc cùng cộng đồng vLLM, SGLang, KTransformers
  • Không chỉ dừng ở phát hiện triệu chứng mà hướng tới sửa nguyên nhân gốc rễ
  • Thay vì chờ nhận khiếu nại sau khi triển khai, dự án cung cấp quyền truy cập sớm cho các nhà cung cấp hạ tầng
  • Mục tiêu là để mỗi nhà cung cấp có thể tự xác minh stack của mình trước khi người dùng gặp sự cố
  • Dự kiến sẽ tiếp tục vận hành leaderboard công khai về kết quả của các nhà cung cấp
  • Sự minh bạch này được thiết kế để thúc đẩy các nhà cung cấp ưu tiên độ chính xác hơn
  • Toàn bộ workflow đánh giá đã được xác minh hoàn chỉnh
    • Sử dụng hai máy chủ NVIDIA H20 8-GPU
    • Mất khoảng 15 giờ nếu chạy tuần tự
  • Đã áp dụng tối ưu hóa script cho các kịch bản suy luận kéo dài
    • Suy luận streaming
    • Tự động thử lại
    • Bao gồm cơ chế tiếp tục từ checkpoint
  • Nêu rõ nguyên tắc rằng khi trọng số đã được công khai thì tri thức để chạy chúng đúng cách cũng phải được công khai
  • Đang tiếp tục mở rộng phạm vi bao phủ nhà cung cấp và tìm kiếm các bài test agentic nhẹ hơn

[ng0301]

Đây đúng là một dự án mà tôi thực sự mong sẽ thành công.

[GN⁺]

Ý kiến trên Hacker News

• Tôi thích ý tưởng này. Nó có vẻ có thể tạo ra áp lực xã hội khá hiệu quả để buộc các nhà cung cấp suy luận sửa những vấn đề tồn đọng lâu nay. Ví dụ, AWS Bedrock có lỗi nghiêm trọng trong stack phục vụ mô hình K2 và K2.5 của Kimi, khiến 20%~30% số lần thử lẽ ra phải xuất ra tool call lại âm thầm kết thúc cuộc hội thoại mà không xuất token nào. Vì vậy AWS trên thực tế trở nên gần như vô nghĩa với tư cách một nhà cung cấp suy luận nghiêm túc cho Kimi, và có cảm giác như đang đẩy người dùng sang các mô hình Anthropic đắt hơn cho hiệu năng tác vụ agent tương tự
  • Tôi không nghĩ đây là chuyện mới, mà là điều Kimi đã làm từ vài tháng nay rồi. K2 Vendor Verifier, Kimi Vendor Verifier đều đã có từ trước, thậm chí còn trước cả khi K2.5 và K2.6 ra mắt
• Theo cách tôi hiểu, mô hình đe dọa ở đây là ngăn suy giảm hiệu năng do vô ý, chứ có lẽ không bao gồm cả tác nhân ác ý. Ví dụ, nếu một nhà cung cấp mờ ám nói rằng họ đang chạy mô hình mới nhất tốt nhất nhưng thực ra dùng một mô hình rẻ hơn, kém hơn để ăn chênh lệch, thì dạng kiểm thử này có thể không giúp được nhiều. Nếu họ phát hiện ra đang bị kiểm tra, họ có thể làm cho nó chỉ hoạt động đúng vào lúc đó như vụ bê bối khí thải của Volkswagen
  • Các nhà cung cấp như OpenRouter về cơ bản chọn nhà cung cấp rẻ nhất, mà nhiều khi họ rẻ vì dùng lượng tử hóa quá mức và tinh chỉnh để tối ưu thông lượng hơn là chất lượng. Vì vậy có vẻ đây là nỗ lực của kimi nhằm ngăn các nhà cung cấp giá rẻ phá hỏng thương hiệu bằng cách không đại diện đúng hiệu năng của mô hình
  • Chỉ cần bắt được drift phát sinh do vô ý thôi cũng đã rất có giá trị. Ý tưởng này gần như giống hệt kiểm thử hồi quy hiệu năng trong CI, không phải thứ người ta dùng vì dự đoán ai đó sẽ cố tình phá hoại. Thông thường nó được dùng để bắt những vấn đề bình thường như cập nhật một dependency rồi thông lượng giảm 15%. Nếu ai đó cố tình lách kiểm tra, thì về mặt pháp lý đó cũng là tình huống khá khác so với việc âm thầm triển khai một mức lượng tử hóa rẻ hơn
  • Tôi nghĩ là vừa đúng vừa không. Nếu là tác nhân thật sự ác ý thì lo ngại đó là đúng. Nhưng cơ chế này biến tình huống từ "lượng tử hóa mô hình mà không thông báo thì chưa chắc đã là gian lận rõ ràng" thành "cho kiểm thử đi qua bằng một mô hình, còn xử lý yêu cầu thật của khách hàng bằng mô hình khác", tức là gian lận có chủ đích. Tôi đoán sẽ có khá nhiều bên nửa vời sẵn sàng làm vế đầu nhưng không dám làm vế sau
  • Trông như một bài toán khá hay cho các hệ thống này. Chẳng hạn nó khiến tôi nghĩ tới trường hợp fromtier labs phục vụ mô hình lượng tử hóa trong điều kiện tải cao
• Đây cũng là vấn đề thực tế trong benchmark của chúng tôi. Trong số các nhà cung cấp OpenRouter, nên cẩn thận với những nơi không nêu rõ mức lượng tử hóa hoặc dùng mức thấp hơn kỳ vọng. OpenRouter có cung cấp tùy chọn cấu hình liên quan, nhưng làm vậy thường khiến số lựa chọn giảm đi rất nhiều. Ngoài chuyện đó, ngay cả khi dùng nhà cung cấp tốt nhất thì Kimi-K2-thinking trong benchmark của chúng tôi vẫn hơi thất vọng và chậm, nhưng lại thú vị và hữu ích về mặt nhiệt độ và độ đa dạng. Trong khi đó, Kimi K2.6 hiện có vẻ là người dẫn đầu mã nguồn mở mới. Đánh giá agent cũng đang được tiến hành, còn benchmark suy luận code one-shot thì đã sẵn sàng
  • OpenRouter có tùy chọn exacto để ưu tiên các nhà cung cấp chất lượng cao hơn cho một số mô hình nhất định. Tôi tò mò không biết bạn đã từng thấy lợi ích từ việc dùng nó chưa. Ngoài ra, Kimi K2 được nói là dùng int4 cho cả huấn luyện lẫn suy luận, nên khi xem thảo luận liên quan, tôi tự hỏi liệu việc các tác giả gguf chuyển đổi khác nhau có thể ảnh hưởng tới chất lượng hay không
• Một bài kiểm thử chạy tới 15 giờ trên phần cứng mạnh thì không dễ để tái hiện hoặc mở rộng. Dù vậy, nó chạm đúng một mối lo phổ biến trên nhiều dịch vụ đám mây. Điểm cốt lõi là đối tượng tôi ping có thể không phải là đối tượng tôi thực sự nhận được
  • Theo cách tôi hiểu thì đối tượng đầu tiên của bài kiểm thử này là chính các vendor hơn là người dùng. Lý do bài kiểm thử dài và toàn diện cũng là để giúp vendor có được sự tự tin về chất lượng tự host của mình
  • Tôi nghĩ ban đầu chỉ cần chạy toàn bộ bộ kiểm thử một lần cho từng vendor, sau đó cứ mỗi 2 hoặc 4 tuần thì xoay vòng chạy từng phần để mô phỏng mẫu sử dụng thông thường. Như vậy có thể giữ cho việc đánh giá luôn được cập nhật theo thời gian
• Tôi mừng vì thứ này tồn tại. Các nhà cung cấp suy luận vẫn thường âm thầm tráo đổi mức lượng tử hóa, và đa số người dùng thậm chí còn không kiểm tra. Một trình xác minh tiêu chuẩn do chính nhà làm mô hình đưa ra có lẽ là đáp án gần đúng nhất, và tôi mong các lab khác cũng phát hành thứ tương tự
• Tôi cũng thấy bài viết liên quan của fireworks.ai giải thích vì sao cần những trình xác minh như vậy khi vận hành mô hình open-weight khá đáng đọc. Đó là quality-first with kimi k2p5
• Sau Anthropic, Moonshot cũng nổi bật là một nhà cung cấp mô hình hạn chế việc điều chỉnh tham số lấy mẫu. Dù vậy, tôi vẫn thích chính ý tưởng vendor verifier này
  • Tôi tò mò "hạn chế việc điều chỉnh tham số lấy mẫu" ở đây nghĩa là gì
  • Nếu hậu huấn luyện được thực hiện với một bộ tham số lấy mẫu cụ thể, thì tôi nghĩ việc dùng thực tế cũng nên bám theo các tham số đã được huấn luyện là hợp lý
• Tôi thực sự thấy đây là một ý tưởng rất tuyệt. Tôi điều hành AI gateway Glama, và từng thấy một số nhà cung cấp bên thứ ba nói dối trắng trợn về lượng tử hóa nên đã gỡ toàn bộ họ khỏi danh sách. Nếu có thể xác minh nhà cung cấp, đó sẽ là cải thiện lớn vì tôi có thể tự tin cung cấp cấu hình nhà cung cấp đa dạng hơn
• Tôi lo rằng nếu các vendor bắt đầu tối ưu để vượt qua 6 benchmark KVV, thì rốt cuộc ta sẽ chỉ đo mức tuân thủ KVV chứ không phải độ trung thực của mô hình. Tôi tò mò không biết có chiến lược luân phiên nào để ngăn điều đó không