
A.X K2 DSpark so với A.X K2: Mô hình chỉ-soạn-thảo thực sự mang lại cho bạn điều gì
- AlibabaMỚIQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 trên 1 triệu token
- z-aiMỚIZ.ai: GLM 5.3 Flash2026-08-2658Trí tuệ72Lập trình
- DeepSeekMỚIDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 trên 1 triệu token
- z-aiMỚIZ.ai: GLM 5.32026-08-1860Trí tuệ75Lập trình
- obsidianQwen3.8 27B2026-08-1552Trí tuệ68Lập trình
- qwenQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1253Trí tuệ69Lập trình
- grokSpaceXAI: Grok 4.62026-08-1261Trí tuệ77Lập trình
- metaMeta: Muse Spark 1.22026-08-0557Trí tuệ72Lập trình
- qwenQwen: Qwen3.8 Max2026-08-0358Trí tuệ72Lập trình
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152Trí tuệ69Lập trình
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 trên 1 triệu token
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463Trí tuệ78Lập trình
- googleGoogle: Gemini 3.6 Flash2026-07-2152Trí tuệ69Lập trình
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137Trí tuệ49Lập trình
- metaMeta: Muse Spark 1.12026-07-1653Trí tuệ71Lập trình
- kimiMoonshotAI: Kimi K32026-07-1560Trí tuệ76Lập trình
- openaiOpenAI: GPT-5.6 Luna2026-07-0952Trí tuệ71Lập trình
Điều kỳ lạ nhất về việc so sánh A.X K2 DSpark với A.X K2 là đây thực sự không phải một cuộc so sánh. A.X K2 DSpark không thể dùng thay thế A.X K2 — thậm chí không thể tự hoạt động một mình. Đây là một "checkpoint chỉ dành cho drafter" mà SK Telecom âm thầm đăng tải lên Hugging Face vào đầu tháng 8 mà không có thông báo nào: một mô hình draft cho cơ chế giải mã suy đoán (speculative decoding), với toàn bộ nhiệm vụ là giúp A.X K2 — mô hình flagship Mixture-of-Experts trọng số mở 688 tỷ tham số của công ty — sinh token nhanh hơn trong khi vẫn giữ nguyên câu trả lời. Vì vậy, câu hỏi thực sự mà cuộc so sánh này xoay quanh không phải là "cái nào tốt hơn", mà là "bạn nên chạy A.X K2 kèm DSpark hay không?" Toàn bộ nội dung trong bài này đều được ghi chú nguồn, vì khoảng cách giữa những gì repo cho biết và những gì thực tế đã được đo lường chính là toàn bộ câu chuyện.
A.X K2 DSpark thực sự là gì
Thẻ mô hình của SK Telecom thẳng thắn một cách khác thường về mục đích của mô hình. A.X K2 DSpark {{1}}là một mô hình nháp giải mã suy đoán DSpark dành cho A.X K2{{/1}} và {{2}}một checkpoint chỉ dành cho mô hình nháp: nó không có công dụng độc lập và được thiết kế để vLLM tải cùng với A.X K2 thông qua giải mã suy đoán.{{/2}} Trong thực tế, điều đó có nghĩa là bạn tải nó về, trỏ một phiên bản vLLM tương thích vào cả nó và A.X K2, và cả hai hoạt động như một đội: DSpark đề xuất các token ứng viên, A.X K2 xác minh chúng, và chỉ những token đã được xác minh mới được phát ra.
Hai chi tiết của cơ chế draft có thể biết được từ repo. Thứ nhất, DSpark đề xuất nhiều token ứng viên song song thay vì viết chuỗi draft từng token một, dựa trên các biểu diễn ẩn của chính A.X K2 cùng với mô hình hóa phụ thuộc cục bộ nhẹ. Thứ hai, toàn bộ hệ thống được xây dựng để không mất mát (lossless): mọi ứng viên đều được mô hình đích xác minh trước khi được chấp nhận, do đó phân phối đầu ra của A.X K2 không thay đổi theo đúng thiết kế.
Bản phát hành này thực chất chỉ là một thông báo trước. Thẻ mô hình cho biết mô hình "hiện đang trong giai đoạn xác thực cuối cùng và dự kiến sẽ được phát hành công khai trong vài ngày tới", và rằng việc đánh giá "hiện đang được tiến hành" — mọi chỉ số throughput, TPOT và mean-accepted-length trên thẻ vẫn được ghi là TBD.
Tại sao "versus" này thực sự là "có so với không có"?
Vì A.X K2 DSpark không có mục đích sử dụng độc lập, nên không có tình huống nào bạn chọn nó thay cho A.X K2. Sự lựa chọn nằm giữa A.X K2 riêng biệt và A.X K2 kèm mô hình nháp. Về chất lượng đầu ra, hai cấu hình giống hệt nhau về mặt thiết kế; trục duy nhất có thể thay đổi là tốc độ giải mã.
Cần nói rõ, A.X K2 là: một bộ giải mã Mixture-of-Experts với tổng 688B tham số và 33B tham số kích hoạt, gồm 256 chuyên gia cùng một chuyên gia dùng chung (8 chuyên gia kích hoạt mỗi lượt truyền xuôi), 61 lớp, 64 đầu attention, và bộ từ vựng 163.840 token, được phát hành với trọng số mở theo giấy phép Apache 2.0 vào ngày 29 tháng 7. Mô hình được tiền huấn luyện trên khoảng 8,2 nghìn tỷ token ở định dạng MXFP8 nguyên bản, sử dụng Sparse Gated Attention của SK Telecom để tăng hiệu quả xử lý ngữ cảnh dài, và hỗ trợ ngữ cảnh 262.144 token (128K gốc mở rộng lên 256K qua YaRN). SK Telecom báo cáo mô hình đạt trung bình cao hơn A.X K1 +32,2 điểm phần trăm trên 14 benchmark, với các đánh giá ngữ cảnh dài và tác tử tăng khoảng 83,9 điểm — toàn bộ là số liệu do nhà cung cấp công bố, chưa có điểm tổng hợp độc lập nào được công bố.
DSpark được thiết kế riêng cho kiến trúc đó. Thẻ sản phẩm ghi rằng nó khớp với cấu trúc MoE, bố cục attention và cấu hình 256K gốc của A.X K2, và không được xác thực với bất kỳ mục tiêu nào khác. Nó kế thừa cùng ngữ cảnh 262.144 token, vì vậy chạy nó không khiến bạn mất gì về kích thước cửa sổ.

Đọc thẻ mô hình: có thể biết, chưa xác nhận
Repo cho bạn một bức tranh rõ ràng về mô hình là gì, cùng một danh sách ngắn những điều mà nó không cho bạn biết.
Có thể biết được hôm nay:
Đây là một checkpoint chỉ dành cho drafter, không có chức năng sử dụng độc lập, được tải bởi vLLM cùng với A.X K2 thông qua giải mã suy đoán.
Giấy phép là Apache 2.0; các trọng số được tải xuống và sử dụng miễn phí.
• Độ dài ngữ cảnh khớp với A.X K2 ở mức 262.144 token.
• Nó chạy thông qua bản fork vLLM của SK Telecom (kho SKT-AI/vllm, nhánh axk2-v0.23.0) sử dụng cờ --speculative-config.
• Phương pháp này được mô tả trong một bài báo, "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv:2607.05147, được đệ trình vào ngày 6 tháng 7 năm 2026) — bài báo đó cũng là nguồn của các con số tăng tốc mà bạn sẽ thấy được trích dẫn.
• Không có nhà cung cấp suy luận nào triển khai nó hiện nay, vì vậy không có API được lưu trữ để gọi.
Chưa được xác nhận:
• Một thông báo chính thức — thẻ hứa hẹn phát hành công khai "trong vài ngày tới."
• Bất kỳ con số tăng tốc cụ thể nào của A.X K2. Việc đánh giá đang được tiến hành và mọi chỉ số hiệu suất đều là TBD.
• Mức độ thực tế mà nó hỗ trợ khi chịu tải, điều mà thẻ đánh dấu là 'phụ thuộc vào khối lượng công việc.'
• Bất kỳ phép đo độc lập nào của bên thứ ba đối với mô hình nháp.

DSpark khác với giải mã suy đoán thông thường như thế nào
Giải mã suy đoán là một thủ thuật quen thuộc: một mô hình nháp nhỏ và nhanh đưa ra dự đoán cho vài token tiếp theo, và mô hình lớn kiểm tra toàn bộ dự đoán đó trong một lần truyền xuôi duy nhất, chấp nhận tiền tố vượt qua quá trình xác minh trước khi thực hiện một bước hiệu chỉnh. Làm tốt điều này giúp giảm đáng kể độ trễ mà không làm giảm chất lượng.
Vấn đề mấu chốt, như bài báo DSpark trình bày, là các bộ sinh nháp song song gần đây — vốn đề xuất các chuỗi dài trong một lần — mắc phải tình trạng "suy giảm chấp nhận nhanh chóng" vì các token ở sau trong bản nháp không phụ thuộc vào các token trước, nên chúng bị từ chối thường xuyên hơn nhiều. Và việc xác minh một cách mù quáng các khối dài sẽ lãng phí dung lượng lô cho các token có khả năng bị từ chối, điều này làm giảm thông lượng, đặc biệt là trong các hệ thống phục vụ có độ đồng thời cao.
DSpark tấn công cả hai vấn đề:
• Kỹ thuật dự thảo bán tự hồi quy. Phương pháp này kết hợp một mô hình nền song song với một mô-đun tuần tự nhẹ, bổ sung khả năng mô hình hóa sự phụ thuộc nội khối để các token dự thảo phía sau phụ thuộc vào các token phía trước — đây chính là yếu tố giúp giảm thiểu hiện tượng suy giảm hậu tố.
- Xác minh theo lịch trình độ tin cậy. Thay vì xác minh một độ dài khối cố định, phương pháp này điều chỉnh độ dài xác minh theo từng yêu cầu, dựa trên xác suất sống sót của tiền tố được ước tính và hồ sơ thông lượng của engine. Việc xác minh trở nên nhận biết tải.
Những con số trong bài báo — và điều chúng không cho bạn biết
Đây là con số bạn sẽ thấy được trích dẫn: DSpark "tăng tốc độ tạo sinh trên mỗi người dùng từ 60 đến 85 phần trăm" ở mức thông lượng tương đương, so với đường cơ sở sản xuất MTP-1. Bài báo cũng báo cáo độ dài được chấp nhận được cải thiện đáng kể so với các bộ dự thảo tự hồi quy và song song hiện đại trên các điểm chuẩn ngoại tuyến, và cho biết nó ngăn chặn sự suy giảm thông lượng nghiêm trọng dưới các ràng buộc tương tác nghiêm ngặt.
Hãy đọc kỹ phần in nhỏ, vì nó quan trọng cho trận đấu cụ thể này: con số 60–85% đó được đo trên hệ thống phục vụ của DeepSeek-V4 trong điều kiện lưu lượng người dùng trực tiếp — không phải trên A.X K2. Đó là một tuyên bố về phương pháp DSpark được triển khai trên stack của một mô hình khác. Ngược lại, thẻ DSpark của A.X K2 vẫn chưa có con số tăng tốc nào. Vì vậy, bảng điểm trung thực cho cặp đấu này là: đầu ra giống hệt nhau về mặt cấu trúc, và mức tăng tốc mà bài báo về phương pháp cho là hợp lý nhưng chính SK Telecom vẫn chưa đo đạc trên mô hình mà bản checkpoint dự thảo này được xây dựng cho.

Những gì việc chạy nó thực sự cần
{{1}}Điều kiện tiên quyết là phần khiến hầu hết mọi người bỏ cuộc:{{/1}} {{2}}bạn phải tự lưu trữ A.X K2.{{/2}} {{3}}Không có API lưu trữ sẵn cho mô hình mục tiêu{{/3}} — {{4}}nó là mô hình open-weight, và việc phục vụ một MoE 688B/33B-active là một cam kết hạ tầng nghiêm túc.{{/4}} {{5}}DSpark chỉ phù hợp với các đội nhóm{{/5}} {{6}}đã cam kết điều đó.{{/6}}
Nếu bạn có, chi phí biên của việc thêm mô hình nháp là nhỏ:
• Tải checkpoint dự thảo Apache 2.0 và chạy bản fork vLLM của SK Telecom (nhánh axk2-v0.23.0).
• Bật giải mã phỏng đoán (speculative decoding) bằng cờ --speculative-config, trỏ tới checkpoint DSpark.
• Hãy dự trù thêm bộ nhớ cho các trọng số draft, và chấp nhận rằng bạn đang dùng một bản fork của vLLM từ nhà cung cấp thay vì bản gốc — một điều cần cân nhắc về mặt bảo trì.
Hãy nhớ rằng bài báo tự cảnh báo rằng việc xác minh không miễn phí: trong điều kiện đồng thời cao, việc xác minh bất cẩn sẽ ngốn dung lượng lô, đó chính là chế độ lỗi mà xác minh theo lịch trình độ tin cậy được thiết kế để quản lý.
Còn một điều đáng biết nữa: Hugging Face cho biết lượt tải xuống "không được theo dõi cho mô hình này", vì vậy không có tín hiệu công khai nào cho thấy có bao nhiêu nhóm thực sự đã thử nó.
Ai nên chọn cái nào
Chạy bản A.X K2 thường nếu bạn thuộc bất kỳ trường hợp nào sau đây:
Bạn chạy vLLM gốc và không muốn có một checkpoint thứ hai hoặc bản fork từ nhà cung cấp trong quy trình.
• Khối lượng công việc của bạn bị giới hạn bởi thông lượng chứ không phải độ trễ, và người dùng chấp nhận việc chờ đợi trong các quá trình tạo sinh dài.
Bạn nên đợi bản phát hành chính thức và các phép đo độc lập đầu tiên.
Chạy A.X K2 cộng DSpark nếu đây là bạn:
• Bạn tự lưu trữ A.X K2 và độ trễ tạo sinh hoặc thông lượng token là thứ đang gây khó khăn.
Các tác vụ ngữ cảnh dài và tác vụ tác nhân khiến người dùng phải chờ đợi những đầu ra dài — chế độ mà giải mã suy đoán được thiết kế để phục vụ.
• Bạn thấy thoải mái khi chạy một thành phần thông báo trước có rủi ro giới hạn: trường hợp xấu nhất là nó không giúp ích gì, và nó không thể làm thay đổi chất lượng đầu ra.
Nếu bạn hoàn toàn không tự lưu trữ một MoE 688B nào cả, thì đừng chọn cả hai. Các thế mạnh về tính tự chủ và ngôn ngữ Hàn Quốc của A.X K2 chỉ đến được với bạn khi bạn vận hành nó, và nhiều đội ngũ sẽ thay vào đó tiếp cận các mô hình mở tiên tiến thông qua một danh mục được lưu trữ. Đó là lúc việc giữ tích hợp của bạn không phụ thuộc vào mô hình được đền đáp: một endpoint tương thích OpenAI duy nhất của OrcaRouter bao phủ hơn 200 mô hình với giá niêm yết của nhà cung cấp, mức chênh lệch 0%, chuyển đổi dự phòng tự động và DSL định tuyến để kết hợp nhiều mô hình trong một lệnh gọi. (Cả A.X K2 lẫn A.X K2 DSpark hiện không được lưu trữ ở bất kỳ đâu — kể cả trên OrcaRouter — vì vậy điều này nói về phần còn lại của stack của bạn, chứ không phải về việc định tuyến cặp mô hình này.) Cách tiếp cận đó vẫn áp dụng được: thử một mô hình chưa được kiểm chứng trên một phần nhỏ lưu lượng và tự động chuyển đổi dự phòng, thay vì đặt cược cả đường vận hành sản xuất vào nó.
Xem gì tiếp theo
Tình thế hiện tại rất đơn giản: kho mã nguồn là có thật, phương pháp đã được tài liệu hóa, nhưng các con số đo lường thì chưa có. Ba điều cần theo dõi là bản phát hành công khai đã được hứa hẹn (thẻ ghi chú nói "trong vài ngày tới"), các con số thông lượng hoặc độ trễ đầu tiên riêng cho A.X K2 sau khi SK Telecom hoàn tất quá trình đánh giá, và liệu có nhà cung cấp suy luận nào nhận triển khai cặp này hay không — điều sẽ giúp DSpark trở nên phù hợp với các đội ngũ không tự lưu trữ.
Câu hỏi thường gặp
A.X K2 DSpark có thể thay thế A.X K2 không?
Không. Đây là checkpoint chỉ dành cho drafter, không có mục đích sử dụng độc lập — nó tồn tại để giúp A.X K2 giải mã nhanh hơn, chứ không phải là một giải pháp thay thế cho nó. Bạn không thể chạy A.X K2 DSpark mà không có A.X K2.
DSpark có thay đổi chất lượng đầu ra của A.X K2 không?
Không, do cách xây dựng. Mọi token ứng viên đều được A.X K2 xác minh trước khi được chốt, vì vậy phân phối đầu ra không thay đổi — tài liệu mô tả phương pháp này là không mất mát.
Tôi có cần tự lưu trữ A.X K2 để sử dụng DSpark không?
Vâng. DSpark được vLLM tải cùng với A.X K2, nên không có gì để nó dự thảo trừ khi bạn đang chạy mục tiêu 688B. Hiện không có API lưu trữ cho cả hai mô hình.
DSpark có hoạt động với các mô hình khác không?
SK Telecom đã thiết kế nó cho kiến trúc MoE, cấu trúc attention và ngữ cảnh 256K của A.X K2, đồng thời chưa xác thực nó với bất kỳ mục tiêu nào khác.
Bản án
A.X K2 DSpark so với A.X K2 là một "versus" mà câu trả lời trung thực là "cả hai." Nếu bạn đã chạy A.X K2 và người dùng phải chờ đợi các lần sinh dài, mô hình draft là một thử nghiệm miễn phí, rủi ro thấp: trọng số Apache 2.0, trường hợp xấu nhất là không tăng tốc, và về mặt cấu trúc, không thể có suy giảm chất lượng. Nếu bạn không bị ràng buộc bởi độ trễ — hoặc hoàn toàn không tự triển khai một MoE 688B — bạn có thể an tâm bỏ qua nó cho đến khi các số liệu đánh giá của SK Telecom được công bố và bản phát hành công khai như đã hứa khiến mô hình trở thành chính thức. Điều bạn không nên làm là nhầm con số 60–85% trong bài báo với một phép đo của chính mô hình này: ngay lúc này, mọi thứ mang đặc thù DSpark của A.X K2 vẫn còn là TBD.
