A.X-K2-DSpark: Mô hình nháp giải mã suy đoán của SK Telecom đã âm thầm ra mắt

A.X-K2-DSpark là một mô hình mà bạn có thể sẽ không bao giờ gọi trực tiếp — và đó chính là lý do nó đáng để tìm hiểu. SK Telecom đã âm thầm đăng tải nó trên Hugging Face, không có bài viết ra mắt hay thông cáo báo chí nào đi kèm; thẻ mô hình chỉ đơn giản mở đầu bằng việc checkpoint này "hiện đang trong giai đoạn xác thực cuối cùng và dự kiến phát hành công khai trong vài ngày tới." Đây là một checkpoint chỉ dành cho vai trò drafter trong speculative decoding, được xây dựng cho một nhiệm vụ duy nhất: giúp mô hình chủ lực A.X K2 688B tham số của SK Telecom được phục vụ nhanh hơn và rẻ hơn bằng cách đề xuất các token mà A.X K2 sau đó sẽ xác minh. Dưới đây là những gì kho lưu trữ thực sự cho chúng ta biết, những gì vẫn chưa được xác nhận, và lý do vì sao một mô hình trợ giúp nhỏ như thế này lại là nơi ẩn chứa đợt cắt giảm chi phí phục vụ LLM tiếp theo.

Bản chất thực sự của A.X-K2-DSpark

A.X-K2-DSpark không phải là một mô hình độc lập theo bất kỳ nghĩa thực chất nào. Thẻ mô hình nêu rõ điều này trong phần ghi chú mục đích sử dụng: nó là một "checkpoint chỉ dành cho mô hình dự thảo" với "không có mục đích sử dụng độc lập", được vLLM tải cùng với mô hình đích của nó, A.X K2, bên trong một vòng lặp giải mã suy đoán. Nó là giai đoạn dự thảo của một bộ tạo hai giai đoạn — một mô hình nhỏ nhanh chóng đề xuất các token ứng viên, và mô hình đích xác minh chúng trước khi bất kỳ token nào được chốt vào đầu ra.

Mục tiêu, để rõ bối cảnh, là một trong những mô hình open-weight lớn nhất hiện nay. A.X K2 là mô hình Mixture-of-Experts của SK Telecom với tổng cộng 688B tham số, 33B tham số kích hoạt, được phát hành trên Hugging Face vào cuối tháng 7 năm 2026 theo giấy phép Apache 2.0. Mô hình được xây dựng trên kiến trúc nền tảng kết hợp Multi-head Latent Attention với DeepSeek Sparse Attention, đồng thời bổ sung cải tiến ngữ cảnh dài Sparse Gate Attention do chính SK Telecom phát triển. A.X-K2-DSpark điều kiện hóa trên các trạng thái ẩn của A.X K2 và thêm mô hình hóa phụ thuộc cục bộ gọn nhẹ giữa các vị trí ứng viên, nhờ đó có thể đề xuất song song nhiều token thay vì soạn thảo tuần tự từng token theo đúng cơ chế tự hồi quy. Mỗi ứng viên sau đó được A.X K2 xác minh trước khi được chốt — chính vì vậy thẻ mô hình gọi kết quả là "lossless by construction" (không mất mát về mặt cấu trúc): phân phối đầu ra không thay đổi bởi mô hình soạn thảo; chỉ có tốc độ phục vụ là thay đổi.

Giải mã suy đoán hoạt động như thế nào, và tại sao một MoE 688B lại cần nó

{{1}}Giải mã suy đoán tồn tại vì quá trình sinh tự hồi quy mang tính tuần tự và bị ràng buộc bởi bộ nhớ.{{/1}} {{2}}Việc sinh từng token đồng nghĩa với việc đọc trọng số của mô hình từ bộ nhớ, và với một mô hình 688B thì đó là một số lượng byte khổng lồ cần di chuyển cho mỗi token{{/2}} {{3}}— ngay cả khi chỉ có 33B tham số hoạt động trong mỗi lượt truyền xuôi.{{/3}} {{4}}Mẹo ở đây là chi thêm một chút tài nguyên tính toán cho một mô hình nháp (drafter) nhỏ, có khả năng đoán trước vài token tiếp theo trong một lần,{{/4}} {{5}}sau đó để mô hình lớn xác minh tất cả các dự đoán trong một lượt truyền xuôi duy nhất{{/5}} {{6}}và giữ lại tiền tố dài nhất khớp với phân phối của chính nó.{{/6}} {{7}}Khi mô hình nháp hoạt động tốt, bạn nhận được hai hoặc ba token cho mỗi lượt truyền qua mô hình lớn thay vì chỉ một,{{/7}} {{8}}mà không làm thay đổi kết quả đầu ra cuối cùng.{{/8}}

Toàn bộ trò chơi nằm ở tỷ lệ chấp nhận. Một drafter dự đoán kém sẽ khiến các đề xuất của nó bị từ chối, và lượt xác minh vẫn tiêu tốn cùng một băng thông bộ nhớ, nên tốc độ tăng tốc biến mất. Đó là lý do vì sao drafter đã tự trở thành một chủ đề nghiên cứu nghiêm túc: đối với một mô hình cỡ A.X K2, sự khác biệt giữa tăng tốc 1.5x và 3x chính là sự khác biệt giữa một hạm phục vụ mười GPU và một hạm năm GPU. Các tầng hiệu quả kiểu này chính là nơi mà đợt giảm giá tiếp theo trong các API LLM lưu trữ sẽ đến — không phải từ con số chất lượng của mô hình nền tảng, mà từ ngăn xếp phục vụ bao quanh chúng.

DSpark là phương pháp — và nó đến từ đội ngũ DeepSeek

Tên gọi "DSpark" trong tên mô hình là một kỹ thuật cụ thể, không phải sáng chế của SK Telecom. Bảng thông tin mô hình trích dẫn bài báo "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv 2607.05147), một bản in trước ngày 6 tháng 7 năm 2026 từ nhóm 33 tác giả tại DeepSeek, đã triển khai phương pháp này trong hệ thống serving thời kỳ V4 của chính các tác giả trong điều kiện lưu lượng thực tế. SK Telecom đã điều chỉnh cùng kỹ thuật này cho mô hình mục tiêu của riêng mình.

Bài báo có hai đóng góp khớp trực tiếp với những gì thẻ A.X-K2-DSpark mô tả. Thứ nhất, kỹ thuật draft bán tự hồi quy: một backbone song song đề xuất các token trong một cửa sổ, trong khi một mô-đun tuần tự nhẹ mô hình hóa các mối phụ thuộc giữa các vị trí ứng viên, khắc phục vấn đề kinh điển rằng tỷ lệ chấp nhận của các mô hình draft song song suy giảm mạnh theo chuỗi được đề xuất. Thứ hai, xác minh theo lịch trình tin cậy: thay vì luôn xác minh một số token draft cố định, hệ thống ước tính xác suất mỗi tiền tố được giữ lại và đặt độ dài xác minh cho từng yêu cầu, được tinh chỉnh theo hồ sơ thông lượng của engine — do đó nỗ lực xác minh phụ thuộc vào tải thay vì đồng nhất.

Dựa trên chính các con số trong bài báo — {{1}}vốn là các phép đo của chính tác giả, chưa được xác minh độc lập{{/1}} — DSpark đã mang lại tốc độ sinh tạo trên mỗi người dùng nhanh hơn 60–85% so với đường cơ sở MTP-1 trong sản xuất ở cùng mức thông lượng, đồng thời ngăn chặn được tình trạng suy giảm thông lượng nghiêm trọng trong các ràng buộc tương tác chặt chẽ. {{2}}Có hai điểm cần lưu ý khi đọc bản phát hành này.{{/2}} Những kết quả đó được đo trên bộ công nghệ (stack) và mục tiêu của riêng tác giả, không phải trên A.X K2; đồng thời, thẻ mô hình (model card) A.X-K2-DSpark cũng nêu rõ rằng quá trình đánh giá của chính nó vẫn đang được tiến hành. Bài báo chứng minh phương pháp này hoạt động trong môi trường sản xuất. {{3}}Nhưng nó không chứng minh rằng checkpoint của SK Telecom tái tạo được những cải thiện đó{{/3}} — {{4}}đó chính xác là phần chưa được xác nhận.{{/4}}

Repo nói gì — và điều nó không nói

Đây là những gì có thể biết được từ kho lưu trữ hiện tại, tất cả đều từ thẻ mô hình:

• Vai trò — checkpoint chỉ dành cho drafter của A.X K2; không được sử dụng độc lập; chưa được xác thực với bất kỳ mục tiêu nào khác và "không tương thích với các mô hình không liên quan."

• Target — A.X K2, 688B tổng / 33B kích hoạt Mixture-of-Experts.

• Độ dài ngữ cảnh — 262.144 token (256K), khớp với cấu hình gốc của A.X K2.

• Giấy phép — Apache 2.0.

• Cơ chế — Soạn thảo bán tự hồi quy DSpark; mọi ứng viên được A.X K2 xác minh trước khi chốt (không mất mát).

• Trạng thái — "hiện đang trong giai đoạn xác nhận cuối cùng"; dự kiến phát hành "trong vài ngày tới."

Và đây là những gì vẫn chưa được xác nhận một cách rõ ràng:

• Độ chính xác và kích thước checkpoint — cả hai đều được liệt kê là TBD trên thẻ mô hình.

• Thông lượng, TPOT và độ dài chấp nhận trung bình — ba con số sẽ cho bạn biết liệu người soạn thảo có thực sự hoạt động hay không, tất cả đều TBD, với "đánh giá hiện đang được tiến hành."

• Kết quả theo từng lĩnh vực — thẻ hứa hẹn sẽ phân tích chi tiết cho tiếng Hàn, toán, khoa học và lập trình "sau này," mà không kèm ngày cụ thể.

• Một thông báo chính thức — SK Telecom chưa công bố A.X-K2-DSpark ở bất kỳ nơi nào chúng tôi tìm thấy; kho lưu trữ chính là thông báo.

• Điểm số độc lập — không có cái nào. Mọi thứ trên thẻ đều là tuyên bố của chính SK Telecom, và hầu hết vẫn chỉ là một lời hứa.

Con số quan trọng nhất chưa được xác nhận là độ dài chấp nhận trung bình — số token nháp trung bình mà A.X K2 chấp nhận cho mỗi lần xác minh. Chính con số đó quyết định liệu bộ tạo nháp này là một cải tiến nhỏ 1.2x hay một nâng cấp phục vụ 2.5x, và đây cũng là con số có khả năng cao nhất sẽ được lan truyền mà không rõ nguồn gốc khi bản phát hành chính thức ra mắt. Hãy nhìn nhận nó một cách hoài nghi khi nó xuất hiện: con số 60–85% trong bài báo DSpark được đo trên hạ tầng phục vụ của một mô hình khác, và A.X K2 có những đặc tính chấp nhận nháp riêng của nó.

Cách bạn thực sự sẽ chạy nó

Chạy bản drafter có nghĩa là phục vụ A.X K2 từ bản fork vLLM của SK Telecom. Ví dụ trong model card, được cắt gọn nhẹ, là:

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

với bản fork được cài đặt từ kho lưu trữ SKT-AI vLLM trên nhánh axk2-v0.23.0. Một vài lưu ý mà thẻ này nêu rõ ngay từ đầu: thiết lập nhắm đến cấu hình ngữ cảnh 256K gốc của A.X K2, và tốc độ tăng phụ thuộc vào khối lượng công việc — độ đồng thời, độ dài đầu ra, tỷ lệ chấp nhận, và chi phí tương đối của việc soạn thảo so với xác minh đều ảnh hưởng đến kết quả. Nói cách khác, đây là hạ tầng phục vụ, không phải script tải về và chạy là xong. Bạn cần trọng số của A.X K2, một cụm máy đủ lớn cho tensor-parallel 8, và sự kiên nhẫn để tinh chỉnh num_speculative_tokens theo lưu lượng truy cập của riêng bạn. Đó là một dự án có ý nghĩa đối với một đội ngũ đã vận hành A.X K2; nó không phải là lý do để dựng lên một hệ thống mới.

Về mặt kinh tế: các lớp hiệu quả vượt trội hơn các tuyên bố về chất lượng.

Lý do khiến mô hình draft cho mô hình 688B đáng chú ý là cuộc đua benchmark của mô hình nền gần như đã bão hòa, trong khi cuộc đua chi phí phục vụ thì chưa. Bản thân SK Telecom khi ra mắt đã nghiêng về hiệu quả — thay đổi Sparse Gate Attention được tuyên bố giúp tăng tổng thông lượng token lên 67,7% so với thế hệ trước ở đầu vào 120K token — và mô hình draft cũng chính là luận điểm tương tự áp dụng cho giai đoạn giải mã. Mỗi token draft được chấp nhận là một lượt truyền xuôi của mô hình lớn mà bạn không phải trả tiền.

Đối với những ai sử dụng các mô hình này qua API thay vì tự lưu trữ chúng, mô hình nháp là vô hình — và đó chính là điểm cốt lõi. Khi một nhà cung cấp thêm giải mã suy đoán (speculative decoding) vào hệ thống phục vụ của họ, bạn không thấy một mô hình mới nào; bạn thấy chính mô hình đó trở nên nhanh hơn và rẻ hơn trên mỗi token. Tầng định giá cũng quan trọng vì lý do tương tự: tại OrcaRouter, chúng tôi chuyển thẳng giá niêm yết của nhà cung cấp với mức chênh lệch 0%, vì vậy khi kết quả tối ưu hóa hiệu quả phục vụ của nhà cung cấp được phản ánh qua việc giảm giá, mức giá mới sẽ có hiệu lực ngay tại phía chúng tôi trong cùng ngày — không cần đàm phán lại, không cần thay đổi hợp đồng. Và đối với một mô hình chưa được kiểm chứng, bất kể nó có thành công hay không, định tuyến với chuyển đổi dự phòng tự động là cách để dùng thử nó mà không cần đặt cược cả một quy trình sản xuất vào nó: chỉ cần một khóa API, yêu cầu sẽ tự động chuyển dự phòng sang nhà cung cấp khác nếu nhà cung cấp đầu tiên suy giảm hiệu năng.

Một lưu ý minh bạch dành riêng cho bản phát hành này: A.X-K2-DSpark là một checkpoint chỉ dành cho drafter, nên không phải thứ mà bất kỳ API mô hình lưu trữ nào có thể định tuyến — kể cả của chúng tôi. Drafter là một thành phần phía phục vụ (serving-side), không phải một sản phẩm có thể gọi trực tiếp. Khi drafter được phát hành và các số liệu đánh giá (eval) được công bố, thứ xuất hiện trong bảng giá sẽ là một A.X K2 nhanh hơn, rẻ hơn — chứ không phải một endpoint mới tên là "DSpark."

Một vài câu hỏi đáng trả lời

Tôi có thể sử dụng A.X-K2-DSpark một cách độc lập không? Không — đó là đặc điểm xác định của bản phát hành này. Đây là một checkpoint chỉ dành cho drafter, không có mục đích sử dụng độc lập và không có API công khai; nó chỉ tồn tại như một trình trợ giúp bên trong vòng lặp giải mã suy đoán (speculative decoding) của vLLM phục vụ A.X K2, và thẻ ghi chú rằng nó chưa được xác thực với bất kỳ mục tiêu nào khác.

A.X-K2-DSpark có phải là đối thủ cạnh tranh của A.X K2 không? Ngược lại. Nó là bộ tăng tốc cho A.X K2 — cùng một mô hình sẽ chạy nhanh hơn, với phân phối đầu ra không thay đổi. Hãy coi nó như một bộ phận hiệu suất lắp thêm, không phải một sản phẩm mới trong dòng sản phẩm.

Khi nào nó thực sự được phát hành? Thẻ mô hình cho biết nó đang trong giai đoạn xác thực cuối cùng và dự kiến phát hành công khai "trong vài ngày tới." Đó là tất cả những gì được xác nhận. Ngày cần theo dõi là ngày các số liệu TBD — throughput, TPOT và mean accepted length — được điền vào, vì đó là lúc việc phát hành không còn là một lời hứa mà trở thành thứ bạn có thể đánh giá.

Tôi có cần phải cân nhắc điều đó nếu tôi sử dụng A.X K2 thông qua API không? Có lẽ là không trực tiếp. Ngăn xếp phục vụ đằng sau một API quyết định liệu có một bộ soạn thảo trong vòng lặp hay không; bạn thấy kết quả dưới dạng giá và độ trễ, chứ không phải một cờ hiệu. Điều này quan trọng nhất đối với các nhóm tự lưu trữ A.X K2, nơi việc chọn tham gia là một thay đổi cấu hình vLLM mà họ kiểm soát.

Câu chuyện ở đây không phải là bản drafter — mà là điều drafter báo hiệu. Công việc tối ưu hóa hiệu quả đang âm thầm trở thành một hạng mục phát hành riêng, và các mô hình mới thú vị nhất năm nay ngày càng là những trợ thủ giúp mô hình lớn trở nên rẻ, chứ không phải các mô hình lớn hơn. A.X-K2-DSpark là ví dụ rõ ràng nhất cho đến nay: một checkpoint không có công dụng độc lập, được đăng tải trước khi có thông báo chính thức, mang phần lớn bằng chứng của chính nó dưới dạng TBD. Hãy theo dõi con số độ dài được chấp nhận khi nó được công bố, coi những cải thiện trong bài báo DSpark là nguồn gốc phương pháp chứ không phải lời hứa cho checkpoint này, và nếu bạn tự triển khai A.X K2, hãy dự trù ngân sách cho benchmark — đó là cách duy nhất để biết liệu drafter được đăng tải âm thầm kia là một điểm cộng 1.2x hay là thứ thật sự.