DSpark: Tăng tốc suy luận LLM bằng speculative decoding [pdf]

 (github.com/deepseek-ai)
1 điểm bởi GN⁺ 7 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • DSpark: khung speculative decoding kết hợp sinh bán tự hồi quy (semi-autoregressive) và lập lịch theo độ tin cậy
  • Parallel drafter đề xuất các khối token dài chỉ với một lần lan truyền xuôi, nhưng gặp vấn đề acceptance decay giảm mạnh ở phần sau do thiếu phụ thuộc giữa các token; DSpark xử lý đồng thời vấn đề này bằng cấu trúc bán tự hồi quy và xác minh nhận biết tải
  • Kết hợp backbone song song nặng với mô-đun tuần tự nhẹ để đưa phụ thuộc nội khối vào, giữ tốc độ draft trong khi giảm suffix decay
  • Confidence head ước lượng xác suất sống sót của tiền tố theo từng vị trí, còn bộ lập lịch nhận biết phần cứng điều chỉnh động độ dài xác minh cho từng yêu cầu theo đường cong thông lượng của engine
  • Trong benchmark offline, mô hình cho accepted length tăng ổn định so với baseline tự hồi quy (Eagle3) và baseline song song (DFlash), đồng thời giảm lãng phí xác minh khi triển khai thực tế trên DeepSeek-V4
  • So với baseline production trước đó là MTP-1, đạt tăng tốc 60–85% tốc độ sinh theo từng người dùng ở cùng thông lượng, mở ra vùng hiệu năng trước đây không thể đạt dưới các ràng buộc tương tác nghiêm ngặt và mở rộng Pareto frontier

Định nghĩa vấn đề — hai nút thắt của parallel drafter

  • LLM sinh token theo kiểu tự hồi quy, mỗi token đều cần một lần lan truyền xuôi được điều kiện hóa trên toàn bộ các token trước đó, nên độ trễ suy luận tỷ lệ với độ dài đầu ra; mức sử dụng GPU thấp và độ chờ cao trở thành nút thắt chính của hệ thống serving production
  • Speculative decoding để một draft model nhẹ đề xuất khối ứng viên, còn target model xác minh bằng một lần lan truyền xuôi duy nhất; thông qua rejection sampling, hệ thống chấp nhận tiền tố dài nhất khớp với phân phối của target, nhờ đó tăng tốc mà không mất chất lượng

  • Giới hạn của drafter tự hồi quy

    • Mỗi vị trí được điều kiện hóa trên token trước đó nên có năng lực mô hình hóa mạnh, nhưng chi phí drafting tăng tuyến tính theo kích thước khối (𝑇draft ∝ 𝛾), khiến nó bị giới hạn ở khối nhỏ và kiến trúc nông

  • Giới hạn của drafter song song

    • Sinh mọi vị trí cùng lúc nên độ trễ draft gần như không phụ thuộc vào kích thước khối, cho phép dùng khối lớn (ví dụ: 𝛾=16)
    • Dự đoán độc lập từng vị trí nên không thể mô hình hóa phụ thuộc giữa các token, gây ra multi-modal collision và làm tỷ lệ chấp nhận giảm mạnh ở phần sau
    • Nếu xác minh vô tội vạ toàn bộ khối dài, thông lượng sẽ giảm; đặc biệt trong môi trường đồng thời cao, các token có nguy cơ bị từ chối cao sẽ chiếm dung lượng batch
    • Độ dài xác minh lý tưởng biến động theo hai trục — phía dữ liệu (yêu cầu có cấu trúc như code có tỷ lệ chấp nhận cao, chat mở có tỷ lệ thấp) và phía hệ thống (khi tải thấp thì xác minh thêm gần như miễn phí, khi tải cao thì lại lấn chiếm năng lực của các yêu cầu đang hoạt động khác)

Kiến trúc — hai thành phần bổ sung cho nhau

  • Độ trễ trên mỗi token là 𝐿 = (𝑇draft + 𝑇verify)/𝜏, nên tăng tốc quy về ba đòn bẩy: giảm 𝑇draft, tăng 𝜏 và giảm 𝑇verify hiệu dụng

  • Chu kỳ decoding: từ prompt ABC, target model sinh token kế tiếp D (đóng vai trò anchor) → backbone song song và head tuần tự sinh draft EFGH cùng điểm tin cậy c1–c4 → scheduler giữ lại tiền tố EFG và loại token H có độ tin cậy thấp → target model xác minh song song; nếu E và F được chấp nhận còn G bị từ chối thì sinh token hiệu chỉnh G*

  • Sinh bán tự hồi quy (Semi-Autoregressive Generation)

    • Parallel drafter có thể sinh các tổ hợp thiếu nhất quán như “of problem” trong các trường hợp có nhiều chuỗi tiếp diễn như “of course”/“no problem”, vì mỗi vị trí được marginalize theo mọi tiền tố khả dĩ thay vì tiền tố đã được lấy mẫu thực sự
    • Giai đoạn song song (Parallel stage): backbone song song (dùng DFlash) chạy một lần lan truyền xuôi cho toàn bộ khối, tạo hidden state và logits cơ sở; xử lý chính anchor như vị trí dự đoán đầu tiên để với 𝛾 đầu vào sinh ra 𝛾 logits, giúp giảm tính toán draft
    • Giai đoạn tuần tự (Sequential stage): cộng bias chuyển tiếp phụ thuộc tiền tố 𝐵𝑘 vào logits cơ sở để mỗi vị trí được điều kiện hóa trên các token đã lấy mẫu trước đó trong khối, từ đó tạo ra phân phối khối nhân quả theo phân rã tự hồi quy; vì xử lý tuần tự nên nó phải nhẹ hơn nhiều so với giai đoạn song song (𝑇sequential ≪ 𝑇parallel)
      • Markov head: đơn giản hóa về chuyển tiếp bậc 1 chỉ phụ thuộc token ngay trước đó, xấp xỉ toàn bộ ma trận 𝑉×𝑉 bằng phân rã hạng thấp 𝐵 = 𝑊1𝑊2 (mặc định 𝑟=256), giảm thiểu lưu trữ và tính toán ở mỗi bước; sau khi lấy mẫu “of” thì tăng cường “course” và triệt giảm “problem”, nhờ đó giảm xung đột chéo mode
      • RNN head: dùng trạng thái hồi quy 𝑠𝑘 để tích lũy toàn bộ lịch sử tiền tố trong khối, cho phép truy cập cả thông tin trước token liền kề thông qua cập nhật cổng; tuy nhiên độ phức tạp triển khai cao và không thuận lợi khi triển khai thực tế

  • Xác minh lập lịch theo độ tin cậy (Confidence-Scheduled Verification)

    • Tỷ lệ chấp nhận draft thay đổi theo từng miền (code cao, chat mở thấp), và chi phí xác minh token bổ sung cũng thay đổi theo tải của engine, nên cần một cơ chế thống nhất để chỉ chuyển phép tính của target tới các token có lợi nhuận kỳ vọng dương
    • Confidence head: tại mỗi vị trí 𝑘 xuất ra một ước lượng vô hướng 𝑐𝑘 ∈ (0,1), mô hình hóa xác suất có điều kiện để token ở vị trí 𝑘 vượt qua xác minh, giả sử toàn bộ các token trước đó đều đã được chấp nhận; cấu trúc gồm phép chiếu tuyến tính nhẹ + sigmoid
      • Được huấn luyện có giám sát bằng tỷ lệ chấp nhận từng bước phân tích được 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (khoảng cách total variation giữa phân phối draft và target)
    • Hiệu chỉnh hậu kỳ — Sequential Temperature Scaling (STS): lập lịch nhận biết phần cứng cần giá trị tuyệt đối của xác suất chấp nhận tích lũy, nhưng độ tin cậy từ mạng nơ-ron có xu hướng overconfident; do mỗi 𝑐𝑖 là xác suất có điều kiện nên có thể phân rã bằng tích lũy tiền tố, sau đó dùng 1D grid search từ trái sang phải trên tập kiểm định held-out để tối thiểu hóa ECE; đây là phép biến đổi bảo toàn thứ tự nên thứ hạng token được giữ nguyên
    • Hardware-Aware Prefix Scheduler: chính thức hóa việc chọn độ dài xác minh thành bài toán tối đa hóa thông lượng toàn cục; với 𝑅 yêu cầu đang hoạt động, dùng SPS(𝐵) (bảng chi phí được profile một lần khi engine khởi tạo), với mục tiêu cực đại hóa 𝛩 = 𝜏·SPS(𝐵)
      • Vì xác suất sống sót 𝑎𝑟,𝑗 đơn điệu không tăng theo 𝑗 nên có thể dùng sắp xếp toàn cục và chọn tham lam, đồng thời tự nhiên tôn trọng phụ thuộc tiền tố trong khối; việc admit gia tăng chỉ cần tra bảng chi phí 𝑂(1)
      • Speculative decoding không mất mát yêu cầu tính chất non-anticipating; vì đặc trưng Markov phụ thuộc vào token đã lấy mẫu trước đó nên tìm kiếm toàn cục hậu nghiệm sẽ làm rò rỉ thông tin 𝑥𝑟,𝑘 và gây selection bias
      • Cơ chế early-stopping dừng ngay khi thông lượng giảm, đảm bảo quyết định admit chỉ phụ thuộc vào tiền tố đã được xử lý đến bước đó để cưỡng chế tính nhân quả; chỉ khi mục tiêu 𝛩 là unimodal mới đảm bảo tìm được cực đại toàn cục

Huấn luyện (Training)

  • Lấy mẫu ngẫu nhiên nhiều vị trí anchor từ chuỗi target để tạo dữ liệu huấn luyện gồm các khối 𝛾 token
  • Target model được giữ cố định (frozen) trong toàn bộ quá trình; draft model cũng chia sẻ embedding layer và LM head và được giữ cố định; chỉ cập nhật backbone drafter, khối tuần tự và confidence head
  • Mục tiêu huấn luyện là tổng có trọng số của ba hạng — mất mát cross-entropy Lce, mất mát khớp phân phối Ltv, và mất mát độ tin cậy Lconf
    • Mọi hạng đều được gán trọng số vị trí 𝑤𝑘 = exp(−(𝑘−1)/𝛾), nhấn mạnh các vị trí đầu vì chúng đóng góp nhiều hơn vào độ dài chấp nhận kỳ vọng trong xác minh dựa trên tiền tố
    • Ltv phạt khoảng cách total variation; vì xác suất chấp nhận từng bước bằng 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1, nên tối thiểu hóa Ltv cũng chính là tối đa hóa tỷ lệ chấp nhận kỳ vọng
    • Trọng số mặc định là 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

Thí nghiệm — benchmark offline

  • Thiết lập

    • Target model: Qwen3-{4B, 8B, 14B}, Gemma4-12B / drafter so sánh: DFlash là parallel drafter SOTA, Eagle3 là drafter tự hồi quy
    • Toàn bộ được huấn luyện lại trên cùng framework và dữ liệu; căn chỉnh TTT horizon (7) của Eagle3 với kích thước khối (7) của DFlash và DSpark; số tầng draft: Eagle3 là 1, DSpark và DFlash là 5
    • Dữ liệu huấn luyện: Open-PerfectBlend với 1,3 triệu mẫu (chat 17.6%, math 39.4%, code 38.9%, instruction-following 4.1%); chỉ dùng prompt, còn phản hồi được từng target model sinh lại; huấn luyện 10 epoch
    • Miền đánh giá: toán (GSM8K, MATH500, AIME25), code (MBPP, HumanEval, LiveCodeBench), chat thường ngày (MT-Bench, Alpaca, Arena-Hard), nhiệt độ lấy mẫu 1.0, báo cáo độ dài chấp nhận mỗi vòng 𝜏

  • Kết quả chính

    • Đánh giá offline tắt confidence scheduler để tách riêng chất lượng draft thuần túy trong khối cố định
    • Trên Qwen3-4B·8B·14B, độ dài chấp nhận trung bình macro tăng 30.9%·26.7%·30.0% so với Eagle3 và 16.3%·18.4%·18.3% so với DFlash; trên Gemma4-12B cũng có lợi ích nhất quán, xác nhận khả năng khái quát qua các họ mô hình
    • Độ dài chấp nhận ở các tác vụ có cấu trúc cao hơn chat mở (với Qwen3-4B: toán 5.57, code 5.12 so với chat 3.49); sự phân tán về mức độ dự đoán được của dữ liệu gây lãng phí với độ dài xác minh tĩnh và là động lực cho lập lịch theo độ tin cậy

Phân tích thí nghiệm

  • Vì sao sinh song song vượt qua tự hồi quy

    • Có một quan sát phản trực giác rằng drafter song song và bán tự hồi quy lại cho độ dài chấp nhận lớn hơn Eagle3 tự hồi quy hoàn toàn; điều này được phân tích bằng tỷ lệ chấp nhận có điều kiện theo vị trí (mẫu số chỉ tính khi toàn bộ vị trí trước đó đã được chấp nhận)
    • Ưu thế năng lực ở vị trí 1: vị trí đầu chỉ phụ thuộc vào ngữ cảnh target; Eagle3 bị giới hạn bởi độ trễ 𝑂(𝛾) nên chỉ dùng mạng nông, trong khi parallel drafter 𝑂(1) có thể dùng mạng sâu; DFlash khởi đầu cao hơn Eagle3 (toán 0.88 so với 0.81, chat 0.72 so với 0.53), và vì từ chối ở token đầu sẽ làm vô hiệu toàn bộ khối nên ưu thế ban đầu ảnh hưởng lớn tới độ dài chấp nhận cuối cùng
    • Giới hạn độc lập ở các vị trí sau: từ vị trí 2–7, Eagle3 duy trì hoặc tăng nhờ khai thác độ chắc chắn có điều kiện (chat 0.53→0.74), còn DFlash giảm mạnh (code 0.87→0.78, chat 0.72→0.63), vì multi-modal collision tạo ra hậu tố thiếu nhất quán
    • Bán tự hồi quy giảm suffix collapse: DSpark kế thừa mức chấp nhận ban đầu cao của backbone song song sâu (toán bắt đầu ở 0.93) và dùng head tuần tự nhẹ để kiềm chế suy sụp ở phần sau, nhờ đó giữ tỷ lệ chấp nhận có điều kiện cao và ổn định trên toàn khối

  • Ít tự hồi quy vẫn mang lại hiệu quả lớn

    • Độ sâu drafter: với kích thước khối cố định là 7, hiệu năng DSpark tăng đơn điệu khi số tầng tăng từ 1→5; mức lợi ích cận biên lớn nhất xuất hiện ở 1→2 tầng; DSpark 2 tầng vượt DFlash 5 tầng trên mọi miền, chứng minh hiệu quả tham số của head tuần tự
    • Độ dài đề xuất: cố định 5 tầng, khi mở rộng độ dài draft {4,8,12,16}, DSpark luôn vượt DFlash ở mọi độ dài; chênh lệch còn tăng theo 𝛾 (ở 𝛾=7: toán 16%, code 15%, chat 18%; ở 𝛾=15: 30%, 26%, 22%); RNN head chỉ mang lại lợi ích bổ sung nhỏ ở độ dài lớn nên Markov head được chọn làm mặc định
    • Overhead độ trễ: với batch 128 và độ dài ngữ cảnh trung bình {512,1024,2048,4096}, độ trễ của khối tuần tự là không đáng kể; khi tăng độ dài draft từ 4→16, tổng độ trễ mỗi vòng chỉ tăng thêm 0.2–1.3% nhưng độ dài chấp nhận tăng tới 30%

  • Vai trò của confidence head — xác minh thông minh hơn chứ không chỉ dài hơn

    • Dùng Qwen3-4B để quét ngưỡng tĩnh; khi tăng ngưỡng, các token dễ bị từ chối bị lọc ra làm tỷ lệ chấp nhận tăng, hiệu quả rõ nhất ở chat (45.7%→95.7%), còn toán (76.9%→92.5%) và code (67.6%→92.0%) tăng nhẹ hơn
    • Ngưỡng tĩnh bỏ qua tải hệ thống nên không tối ưu trong serving động; mô hình độ tin cậy có khả năng phân biệt mạnh (ROC-AUC 0.81–0.90) nhưng bị overconfident (ECE 3–8%); sau khi áp dụng STS, ECE trung bình giảm xuống khoảng 1%, tạo ước lượng sống sót đáng tin cậy

Triển khai thực tế

  • Huấn luyện có thể mở rộng

    • Được triển khai chung với DeepSeek-V4-Flash·Pro preview; backbone song song gồm 3 tầng MoE áp dụng mHC và sliding window attention 128, dùng kích thước khối tối đa 𝛾=5 và Markov head; confidence head được huấn luyện end-to-end rồi hiệu chỉnh bằng STS
    • Truyền thông hidden state: thay vì truyền toàn bộ logits từ vựng (𝑉≈10⁵), hệ thống chỉ truyền hidden state ngay trước LM head và chạy LM head cục bộ trên draft worker chỉ tại vị trí được lấy mẫu, giảm độ phức tạp truyền thông mỗi token xuống 𝑂(𝑑)
    • Anchor-bounded sequence packing: lấy mẫu số lượng anchor draft cố định để đóng gói dày đặc các khối dự đoán cô lập; dùng chỉ số attention theo token để giữ causal masking giữa nhiều chuỗi độc lập mà không cần padding overhead

  • Áp dụng scheduler trong thực chiến

    • Có hai xung đột — thuật toán giả định đường cong năng lực trơn và unimodal, nhưng SPS(𝐵) thực tế lại rời rạc và giảm theo bậc thang; còn lập lịch token động theo từng bước lại xung đột với CUDA graph replay liên tục và Zero-Overhead Scheduling (ZOS)
    • Thích ứng bằng lập lịch bất đồng bộ; vì ZOS cần biết kích thước batch tiếp theo trước khi bước hiện tại hoàn tất, hệ thống xấp xỉ năng lực xác minh bằng đầu ra độ tin cậy từ hai bước trước; các ứng viên ở bước hiện tại được sắp xếp theo độ tin cậy tích lũy mới nhất, còn dự đoán quá khứ chỉ dùng để quyết định độ dài cắt động (𝐾), rồi ánh xạ bằng chọn top-𝐾 động
    • Loại bỏ early-stopping để bật tìm kiếm toàn cục không ràng buộc; vì chỉ đánh giá dựa trên lịch sử từ hai bước trước nên nó tách biệt với việc hiện thực hóa token hiện tại 𝑥𝑟,𝑘 và tạo hàng rào nhân quả, cho phép vừa tối đa hóa thông lượng vật lý khi vượt qua các ngưỡng phần cứng, vừa bảo toàn chính xác phân phối target

  • Suy luận thông lượng cao, độ trễ thấp

    • Serving production cần tối ưu đồng thời độ trễ theo từng yêu cầu và tổng thông lượng; trong triển khai này, do giới hạn dung lượng KV-cache và lưu lượng người dùng, kích thước batch hiệu dụng nằm dưới ngưỡng bão hòa GPU nên hai mục tiêu không cạnh tranh mà có tương quan cao, giúp bài toán đơn giản hơn
    • Hỗ trợ truy vấn độ dài biến thiên là thách thức; nếu xử lý thẳng trên kernel decode độ dài cố định sẽ gây padding và tải không đồng đều làm GPU bị sử dụng kém; hệ thống làm phẳng mọi token của yêu cầu và xử lý như phần tử độc lập, còn phụ thuộc trong chuỗi được truyền qua marker tensor của sparse attention; trên DeepSeek-V4 chỉ cần sửa index-attention và compress kernel để hỗ trợ định tuyến độ dài biến thiên

  • Hiệu năng trên lưu lượng người dùng thực

    • So sánh DSpark-5 (𝛾=5) với baseline MTP-1 trên engine production V4-Flash và Pro; MTP-1 được giữ ở cấu hình một token vì MTP-3/5 đa token tĩnh làm giảm thông lượng trong điều kiện đồng thời cao, và sau 2 tuần kể từ khi DeepSeek-V4-preview ra mắt đã được thay bằng DSpark
    • V4-Flash: ở SLA 80 tok/s/user, thông lượng tăng 51%; ở 120 tok/s/user, MTP-1 gần chạm giới hạn vận hành nên DSpark có ưu thế danh nghĩa 661% (không nên hiểu là bội số tuyệt đối mà là bằng chứng cho việc mở rộng frontier tương tác); ở cùng thông lượng, tốc độ sinh theo từng người dùng tăng 60–85%
    • V4-Pro: ở 35 tok/s/user tăng 52%; ở 50 tok/s/user có ưu thế danh nghĩa 406%; ở cùng năng lực, tăng tốc 57–78%, nhìn chung đẩy frontier throughput–interactivity ra ngoài
    • Hành vi thích ứng tải: ở mức đồng thời trung bình (V4-Flash dưới 200 và V4-Pro dưới 150 yêu cầu), scheduler mở rộng cấu hình tĩnh 2 token của MTP-1 lên khoảng 4–6 token cho mỗi yêu cầu, làm tăng số token được chấp nhận trên mỗi lần lan truyền xuôi; khi đồng thời bão hòa, nó thu hẹp nhẹ độ dài xác minh để cắt bỏ token độ tin cậy thấp trước khi chúng chiếm mất dung lượng batch

  • Hạn chế

    • Prefix scheduler giảm tối đa lãng phí xác minh của target, nhưng vẫn tồn tại chi phí draft cố định cho việc sinh khối 𝛾 token ban đầu bằng backbone song song; với các truy vấn phức tạp vốn có tỷ lệ chấp nhận thấp, phần tính toán đi trước này về bản chất không thể thu hồi
    • Trong tương lai có thể cải thiện bằng cơ chế early exiting nhận biết độ khó ngay trong draft model để các yêu cầu đó bỏ qua việc sinh cả khối

Kết luận

  • Về mặt cấu trúc, DSpark dùng mô hình bán tự hồi quy kết hợp backbone song song nặng và head tuần tự nhẹ để giảm hiện tượng suffix collapse mạnh của các parallel drafter độc lập
  • Về mặt hệ thống, bài toán chọn độ dài xác minh được chính thức hóa thành tối đa hóa thông lượng toàn cục; ngân sách xác minh được điều chỉnh động nhờ prefix scheduler nhận biết phần cứng dựa trên xác suất sống sót đã hiệu chỉnh và tải engine thời gian thực
  • Trong đánh giá offline diện rộng, mô hình vượt các baseline SOTA tự hồi quy và song song; khi triển khai thực trên DeepSeek-V4, nó chứng minh giá trị thực dụng bằng khả năng duy trì đồng thời cao, tăng tốc sinh theo từng người dùng và mở rộng Pareto frontier của serving LLM

Bài viết liên quan

1 bình luận

 
GN⁺ 7 giờ trước
Ý kiến trên Hacker News

  • DeepSeek không chỉ mở rộng các giới hạn, mà còn công bố cả những bài báo xuất sắc giải thích họ đã đạt được cải thiện hiệu năng như thế nào
    Đáng tiếc là các phòng thí nghiệm Mỹ không còn công bố như vậy nhiều nữa, và có vẻ những công việc thú vị nhất trong AI hiện nay đang được các phòng thí nghiệm Trung Quốc thực hiện

    • Google vẫn công bố khá nhiều nghiên cứu kiến trúc LLM
      Họ đã giới thiệu speculative decoding cho LLM vào năm 2022[1], và năm nay cũng công bố mã thực hiện speculative decoding trên mô hình Gemma 4[2]

      [1] https://arxiv.org/abs/2211.17192

      [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

    • Các công ty AI Mỹ phải chịu trách nhiệm trước những khoản đầu tư khổng lồ, nên có vẻ họ đang cố tìm một con hào ma thuật để biện minh cho định giá
      Nếu công bố các tối ưu hóa như thế này thì lợi thế cạnh tranh sẽ giảm đáng kể

    • Có thể đây là sự cởi mở vì nhu cầu
      Vì các phòng thí nghiệm Mỹ đang khai phá ở tuyến đầu, nên suy đoán là DeepSeek muốn open source những gì họ có để san phẳng sân chơi cạnh tranh

    • DeepSeek đang hàng hóa hóa phần cải thiện hiệu năng mà các phòng thí nghiệm Mỹ dựa vào để kiếm tiền cho nhà đầu tư

    • Đã đến lúc phương Tây từ bỏ cách nhìn người Trung Quốc chỉ là “những kẻ rất xấu dưới chế độ độc tài”

  • Mô hình trên Hugging Face đã được đưa lên rồi, và trông có vẻ như mô hình gốc có tích hợp sẵn mô-đun speculative decoding, khá hay

    Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

    Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

    Rất mong chờ xem nó có được đưa vào DwarfStar cho suy luận cục bộ không
    Tôi đã dùng mô hình Flash khá nhiều kể từ khi antirez công bố lượng tử hóa 2 bit

    • Liệu có khả năng thứ này được áp dụng cho Qwen 27B không?

  • Cảm giác hiện tại là DeepSeek gần như là công ty AI duy nhất thực sự muốn đổi mới, thay vì chỉ nhắm đến hạng nhất benchmark
    Những nơi như OpenAI, Anthropic, Google có vẻ tập trung nhiều hơn vào cạnh tranh lẫn nhau thay vì tiếp tục đổi mới

    • Tôi nghĩ cũng nên tính cả các phòng thí nghiệm Trung Quốc khác như Moonshot (nhà phát triển Kimi) và Z.ai (nhà phát triển GLM)
      Họ cũng đang đổi mới và tiếp tục chia sẻ nghiên cứu công khai
      Tôi nhớ là nhà sáng lập Moonshot còn đăng một video 40 phút trên Twitter giải thích kỹ thuật đứng sau Kimi

    • Nhiều công ty Mỹ từ lâu đã lấy chiến lược giữ chân người dùng bằng mọi cách
      Chất lượng và đổi mới là yếu tố thứ hai; họ muốn chiếm lĩnh thị trường, khóa chặt người dùng, rồi dùng ảnh hưởng lên quy định và vận động hành lang để duy trì quyền lực

    • Các công ty đó cũng đang cạnh tranh với nhau bằng đổi mới
      Đổi mới mang lại lợi ích lớn hơn cho khách hàng, chỉ là công nghệ không được công bố mà thôi
      Bí mật kinh doanh là bí mật vì có lý do của nó

      Lý do DeepSeek trông có vẻ “đổi mới nhất” có thể là vì đó là thứ quan sát được từ bên ngoài
      Nó giống như ngộ nhận rằng vì không phải ai cũng công bố ảnh của mình cho công chúng, nên các mô hình được công bố là đẹp nhất trong toàn bộ dân số

    • Các phòng thí nghiệm lớn đã làm những thứ như thế này từ ít nhất một năm trước rồi

    • Qwen cũng vậy

  • Tôi đã dùng DeepSeek v4 pro trong Kilo Code được một tháng và nó rất tuyệt
    Nhanh, ổn định, có cửa sổ ngữ cảnh lớn và thật sự rẻ
    Tháng này tôi dùng 1,5 tỷ token mà tốn 40 đô la; dù phần lớn là cache nhưng vẫn rẻ

    • Tôi đang dùng DeepSeek trong omp làm agent task và quicktask, còn Sonnet cho các mục đích còn lại
      Chi phí AI giảm mạnh, từ 40 đô la mỗi ngày xuống 10 đô la mỗi ngày
    • Tôi tò mò bạn đã dùng nhà cung cấp nào
      Trên OpenRouter thì 40 đô la hết khá nhanh
      Không có nhiều lượt hội thoại khứ hồi, ngữ cảnh khoảng 300 nghìn, đầu ra khoảng 15 nghìn dòng
      Tôi đang dùng opencode nhưng không chắc có thể hiển thị tổng số token không
    • Tôi tò mò bạn đã so sánh Kilo với Pi hay OpenCode chưa
      Tôi quen với hai cái đó, nhưng luôn tìm lựa chọn thay thế
    • Có cách nào xem đã dùng bao nhiêu token trong Claude Code Pro không?

  • Cái này có mới hơn hoặc tốt hơn speculative decoding năm 2022 không? https://arxiv.org/abs/2211.17192

    • Bài đó được trích dẫn trong các phần ‘introduction’ và ‘background’ của bài này
      Bài này nói về việc cải thiện bằng cách loại bỏ một số nút thắt cổ chai
    • Có vẻ trọng tâm là cải thiện draft model và chính sách xác minh để ở quy mô của DeepSeek, suy đoán không biến thành công việc kiểm chứng lãng phí mà dẫn đến tăng tốc thuần túy

  • Thời điểm này có vẻ không phải ngẫu nhiên
    Có vẻ họ đang thể hiện sự đối lập giữa tính công khai và quản lý chặt

    • Trung Quốc = công khai, Mỹ = quản lý chặt nghe như một timeline kỳ lạ
      Tuy nhiên việc này khả thi vì nó phù hợp với mục tiêu của Tập
    • Không ai ép Anthropic phải thực hiện chiến dịch truyền thông thổi phồng rủi ro của các mô hình AI mới
      Nói thật là tự làm tự chịu

  • Tiêu đề không hay
    Đây không phải tiêu đề bài báo, mà là lấy dòng đầu tiên của phần tóm tắt
    Speculative decoding cho suy luận LLM đã được công bố từ năm 2022: https://arxiv.org/abs/2211.17192

    Bài này có vẻ là cải tiến của speculative decoding, nhưng tôi chưa đọc

  • Vì cái tên nên ban đầu tôi tưởng nó liên quan đến DGX Spark
    Tình cờ là gần đây có nhiều công việc cải thiện hiệu năng suy luận của DGX Spark, và MTP đã đem lại tăng tốc 50–100%, nên DSpark có vẻ cũng sẽ khá hữu ích cho mục đích đó

  • Có lẽ thứ này đã được dùng trong production một thời gian, và có thể là một trong những lý do họ hạ giá mạnh một tháng trước

    • Đúng vậy
      Chương 5 nói về triển khai thực tế
      Mục 5.1 viết “DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro”, và mục 5.4 viết “MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release”
    • Lookahead Sparse Attention chắc cũng đóng vai trò lớn
      Vì nó giảm đáng kể mức sử dụng bộ nhớ
    • Nhận xét đúng
      Họ đã giảm giá 75%, và có vẻ khớp chính xác với lợi ích từ tối ưu tốc độ và suy luận

  • Có vẻ sắp đến một thế giới nơi tồn tại vô số mô hình nhỏ cho speculative decoding riêng cho từng use case, công ty, thậm chí từng cá nhân

    • Hy vọng là vậy, và hy vọng phần cứng không trở nên bất khả thi để mua

    • Đúng vậy
      Chúng sẽ bị ràng buộc mạnh bởi các guardrail tinh vi

      Chắc chắn mọi thứ đang đi theo hướng này
      Những mô hình khổng lồ muốn nuốt trọn cả thế giới có mức lợi suất giảm dần nghiêm trọng khi so sánh

    • Có vẻ bạn rõ ràng chưa đọc các bài báo speculative decoding gần đây
      Từ lâu rồi, bất kỳ mô hình nào cũng đã có thể được dùng để suy đoán cho một mô hình khác
      Vấn đề token hóa từng ngăn cản việc này trước đây đã được giải quyết