Vì sao DeepSeek rẻ ở quy mô lớn nhưng lại đắt khi chạy cục bộ

• Một số mô hình AI như DeepSeek-V3 rẻ và nhanh khi được cung cấp ở quy mô lớn, nhưng lại chậm và tốn kém khi chạy cục bộ
• Lý do nằm ở sự đánh đổi căn bản giữa throughput (thông lượng) và latency (độ trễ), vốn liên quan đến hiệu quả khai thác GPU
• Khi tăng kích thước batch, GPU hoạt động hiệu quả hơn, nhưng người dùng phải chờ đến khi đủ token được gom lại nên xảy ra hiện tượng độ trễ tăng
• Các mô hình có kiến trúc Mixture-of-Experts và pipeline sâu cần batch lớn và độ trễ cao
• Trong môi trường một người dùng cục bộ, rất khó tạo được batch đủ lớn, dẫn tới hiệu năng giảm và chi phí tăng
• OpenAI, Anthropic... đạt được phản hồi nhanh nhờ tối ưu hóa chính kiến trúc, chiến lược batching tinh vi hoặc đơn giản là cấp phát quá nhiều GPU

---

Suy luận theo batch và hiệu quả GPU

• GPU là phần cứng được tối ưu cho nhân ma trận quy mô lớn (GEMM)
• Khi gom token của nhiều người dùng để chạy theo batch thành một ma trận lớn, overhead khứ hồi thấp và hiệu quả bộ nhớ tốt giúp thông lượng tăng mạnh
• Máy chủ suy luận sẽ xếp token từ nhiều yêu cầu vào hàng đợi, chọn batch có kích thước phù hợp và thực hiện các phép GEMM lớn
• Trong quá trình này, máy chủ phải chọn sự đánh đổi giữa kích thước batch (thông lượng tăng) và thời gian chờ (độ trễ tăng)

Vì sao một số mô hình được tối ưu cho batch lớn

Mixture of Experts (MoE) và batch

• Kiến trúc MoE (ước đoán ở DeepSeek-V3, GPT-4) là nguyên nhân chính khiến hiệu quả GPU thấp
• Hàng trăm khối “expert” mỗi khối đều yêu cầu phép nhân ma trận riêng, nên ở batch nhỏ, mỗi expert có quá ít việc để làm và hiệu quả giảm mạnh
• Chỉ khi có nhiều yêu cầu đồng thời mới có thể tận dụng đầy đủ mọi expert, vì vậy ở cấp độ dịch vụ, batch lớn là bắt buộc
• Với thời gian chờ ngắn (cửa sổ 5ms), các expert thường xuyên nhàn rỗi; với thời gian chờ dài (cửa sổ 200ms), có thể tối đa hóa hiệu suất cao

Vấn đề batch ở mô hình pipeline sâu

• Các transformer lớn với hàng trăm tầng được chia theo layer trên nhiều GPU để chạy theo kiểu pipeline
• Nếu số token trong một batch ít hơn số bước của pipeline, sẽ xuất hiện hiện tượng pipeline bubble, làm giảm thông lượng
• Để tránh điều này, batch lớn (tức chờ lâu hơn) là điều bắt buộc, và vì vậy thời gian phản hồi của mô hình tăng lên

Vì sao không thể lúc nào cũng lấp đầy hàng đợi

• Về lý thuyết, nếu lúc nào cũng có lượng truy cập đồng thời lớn để lấp đầy hàng đợi thì có vẻ có thể tránh bubble
• Nhưng trên thực tế, ở bước Attention của transformer, kích thước ma trận (độ dài) phải giống nhau mới có thể batch hóa, nên rất khó để một hàng đợi đơn hoạt động hoàn hảo
• Ngoài ra, nếu tách riêng các bước FFN và attention thì overhead bộ nhớ tăng mạnh và nảy sinh vấn đề di chuyển dữ liệu kém hiệu quả

Tóm tắt và kết luận

• Xử lý batch lớn là điều thiết yếu để giảm chi phí GPU và tăng thông lượng, nhưng người dùng sẽ phải chờ lâu hơn
• Các mô hình có Mixture-of-Experts và kiến trúc pipeline lớn về bản chất được tối ưu cho môi trường batch hiệu quả cao dựa trên chờ đợi
• Trong môi trường ít lưu lượng như chạy cục bộ, không thể cấu hình batch lớn tối ưu nên hiệu quả GPU giảm mạnh và chi phí vận hành tăng
• OpenAI, Anthropic... có thể cho thấy độ phản hồi nhanh, và lý do có thể là:
  • (1) Có thể họ dùng kiến trúc hiệu quả hơn thay vì MoE
  • (2) Áp dụng tối ưu hóa batch/pipeline và các kỹ thuật suy luận tinh vi
  • (3) Có thể họ cấp phát nhiều GPU hơn mức cần thiết để “mua” tốc độ

Bổ sung: khác biệt giữa batch prefill và batch phần thân

• Transformer có thể chạy theo batch cho prefill của một prompt người dùng (đầu vào dài), nhờ đó suy luận ban đầu diễn ra nhanh hơn
• Tuy nhiên, batch được thảo luận trong bài là sự đánh đổi thông lượng-độ trễ xảy ra ở giai đoạn sinh token chính thức của nhiều yêu cầu người dùng
• Batch prefill không liên quan trực tiếp đến kiểu batch đồng thời quy mô lớn được nhắc trong bài

Ghi chú tham khảo

• Các hệ thống suy luận thực tế cũng sử dụng continuous batching để chạy ngay khi batch đã đủ
• Tuy nhiên, cấu trúc đánh đổi căn bản giữa throughput-latency vẫn được áp dụng như nhau

[GN⁺]

Ý kiến trên Hacker News

• Tôi đang tự chạy DeepSeek V3 tại nhà, và cảm thấy chi phí không quá nặng trong khi tốc độ lẫn hiệu năng đều khá hài lòng. Nhiều người nghĩ không có GPU thì không thể chạy được model lớn, nhưng theo trải nghiệm của tôi thì máy chủ CPU lại tiêu thụ điện ít hơn và thực tế hơn. Máy chủ tại nhà dùng bo mạch Supermicro với dòng EPYC 9004 tầm trung và 384GB RAM, tổng chi phí khoảng 4000 USD. Nếu không dùng GPU mà chỉ trang bị nhiều RAM, điện năng tiêu thụ trong nhiều trường hợp còn thấp hơn cả desktop gaming. Tôi dùng model Unsloth Dynamic GGUF với khoảng 270GB RAM, và trên thực tế có thể hỗ trợ nhiều tác vụ với chất lượng gần như tương đương bản gốc. Bình thường tôi chạy ở ngữ cảnh 16k và khi cần thì mở rộng lên 24k. Tốc độ sinh token là 9~10 token/giây, khi tăng ngữ cảnh lớn thì xuống còn 7. Cũng có trường hợp dùng môi trường 2 CPU chạy toàn bộ model với tốc độ token còn nhanh hơn thế này
  • Tôi tò mò Unsloth Dynamic GGUF thực sự cho hiệu năng gần bản gốc đến mức nào. Theo kinh nghiệm của tôi, với tác vụ đơn giản thì khác biệt không lớn, nhưng ở bài toán phức tạp hoặc ngữ cảnh dài thì có lúc chênh lệch hiện ra khá rõ. Đúng là Unsloth đang làm rất tốt, nhưng vẫn tiếc vì thiếu tài liệu đánh giá so sánh trực tiếp với model gốc chưa lượng tử hóa. Cũng phải thừa nhận rằng nhiều người và công ty không đủ khả năng để tự chạy bản gốc
  • Tôi đang thắc mắc liệu có thể dùng DeepSeek cho mục đích sinh mã bằng công cụ như Ollama trên CPU 40 lõi và 256GB RAM hay không. Tôi đang tính phân bổ khoảng 200GB bộ nhớ cho model
  • Có người nhắc rằng website cá nhân đang không truy cập được. Họ tự giới thiệu là Jeff Carr, đồng sáng lập DigitalOcean, và mong có thể liên lạc được
  • Tôi cứ nghĩ GPU có bộ nhớ tốc độ cao là bắt buộc, nên muốn hỏi liệu thật sự có thể suy luận chỉ với bộ nhớ dung lượng lớn mà không cần GPU hay không. Tôi tò mò làm sao chuyện đó khả thi chỉ với bộ nhớ không hợp nhất
  • Tôi đồng ý rằng DeepSeek V3 thực sự rất thực dụng trong số các model open-weight. Nhiều tác vụ thực ra không cần nhiều reasoning token ở mức đó, và việc không phải chờ đợi là một lợi thế. Nếu cần thì lúc nào cũng có thể chọn tùy chọn reasoning cao hơn, điều này cũng rất hấp dẫn. Nếu không tự chạy, cũng có một vài nhà cung cấp cam kết không dùng dữ liệu, cung cấp toàn bộ ngữ cảnh (16k) và 80tps. Ví dụ dùng home server 9004 đúng là một cấu hình rất đẹp
• Có nhận xét rằng bài blog này rất ấn tượng. Kết luận “cần batching” thì đồng ý, nhưng cho rằng phần bàn về suy luận với model MoE cần đa chiều hơn. Lý do batch lớn quan trọng là vì suy luận LLM bị nghẽn không phải do thiếu năng lực tính toán, mà do phải tải toàn bộ weight từ VRAM. Nếu so TFLOPS và băng thông bộ nhớ của H100, có thể tính ra thực tế còn dư địa xử lý 300 FLOP trên mỗi byte. Batch càng lớn thì càng có thể thực hiện nhiều phép tính hơn cho mỗi tham số đã nạp, nên cần tối đa hóa batch size. Vì vậy mới dùng thuật ngữ “roofline model”. Khi model ngày càng lớn và không còn vừa toàn bộ trong VRAM, phải phân tán qua nhiều GPU hoặc nhiều node. Nhưng ngay cả NVLink hay Infiniband cũng không nhanh bằng việc nạp trực tiếp từ VRAM nên vẫn phát sinh nút thắt. Điểm mạnh của MoE là expert parallelism, tức là đưa các expert khác nhau lên bộ nhớ của các node khác nhau để giảm tối đa giao tiếp liên node. Tuy nhiên điều này chỉ khả thi khi có đủ node để chứa toàn bộ expert trong VRAM và còn chịu được các overhead như KV cache. Cuối cùng thì batch size gần như bắt buộc phải tăng tự nhiên, và phải như vậy mỗi GPU mới hoạt động hiệu quả
  • Có đề xuất gán các "expert" khác nhau vào cùng một node theo kiểu round-robin, rồi chỉ gom batch một cách cơ hội khi nhiều request dùng chung expert. Tức là thay batching bằng hàng đợi, nên độ trễ sẽ tăng nhưng trong các môi trường như workflow nghiên cứu chuyên sâu thì vẫn hoàn toàn chấp nhận được
  • Có ví dụ thực tế cho thấy khi model không thể nằm gọn trên một GPU, vẫn có thể suy luận bằng cách chia theo layer rồi gửi các vector nhỏ sang GPU chịu trách nhiệm layer tiếp theo để tính toán. Cerebras dùng cách này trên Llama 4 Maverick và đạt 2500 tỷ token mỗi giây. Việc truyền vector trên fabric rất nhanh nên gần như không có idle time
  • Có người hình dung nếu toàn bộ node và weight được bố trí trên mạch analog thì có thể chạy nhanh hơn rất nhiều
  • Một trong những luận điểm để đầu tư vào AMD là toàn bộ model có thể nằm trong một chassis duy nhất, vừa tận dụng ưu điểm kiểu map/reduce vừa giảm chi phí thiết bị mạng. Có người muốn nghe insight phản biện
• Tóm tắt một dòng cho ai muốn tiết kiệm thời gian: câu trả lời là suy luận theo batch. Đây là cách đưa prompt của nhiều người vào cùng lúc trên một instance model, hiệu quả thực tế cao hơn nhiều so với chỉ chia thời gian thật dày. Vì vậy mà dù cố định nhiệt độ và seed, phản hồi của dịch vụ vẫn có thể khác nhau mỗi lần, do bạn không kiểm soát được prompt của mình bị ghép batch với những gì. Cũng có người hình dung hiện tượng này có thể trở thành một vector tấn công để đánh cắp dữ liệu
  • Một lợi ích của batch là khi muốn đánh giá lặp lại cùng một nội dung để xem thực sự có "hallucination" hay không, bạn có thể ném vào cùng lúc bằng đúng batch-size. Thực ra khái niệm batch đã có từ đầu trong LLM, nhưng phải sau một thời gian người ta mới cảm nhận rõ giá trị của nó
  • Tôi từng đơn giản giả định rằng nhà cung cấp dịch vụ luôn luôn batching trên mọi model, nhưng giờ lại tò mò liệu nó chỉ áp dụng cho một số họ model nhất định hay không
  • Tôi thắc mắc vì sao việc bị batch chung với prompt khác lại có thể làm phản hồi của model thay đổi
  • Nếu prompt có thể bị gộp chung với của người khác, thì đúng là có thể trở thành một vector tấn công rất hiệu quả
• Tóm gọn lại như sau:<br>- Model có độ sparsity cao cần batch lớn, tức nhiều request đồng thời, để một phép nhân ma trận trở nên đủ đậm đặc về tính toán<br>- Để xử lý được batch lớn cỡ này thì cần khoảng 8~16 GPU để nhét được weight của model cùng MLA/KV cache vào HBM. Nhưng với chỉ 8~16 GPU thì tổng throughput vẫn thấp, nên tốc độ phản hồi cho từng người dùng sẽ rất chậm. Muốn trải nghiệm mượt thì có lẽ phải cần khoảng 256 GPU
  • Tôi đang vận hành dịch vụ DeepSeek trên môi trường 16 H100 (2 node). Tốc độ đạt 50~80 token/giây cho mỗi request, và tổng throughput ổn định lên đến hàng nghìn token. Thời gian tạo token đầu tiên cũng ổn định, và trải nghiệm nhanh hơn bất kỳ dịch vụ cloud nào mà chúng tôi từng dùng
  • Có ý kiến rằng nói độ sparsity cao = cần batch lớn thì mối liên hệ đó vẫn chưa thật dễ hiểu. Có phần mỉa mai rằng sparse matmul về cơ bản cũng chỉ là matmul có rất nhiều số 0
• Có nhận xét đây là một bài giải thích rất hay từ góc nhìn LLM. Các công ty LLM hyperscale có lẽ đang phân tích cực kỹ trace tính toán thực tế để tìm nút nghẽn, rồi nghiêm túc tối ưu workload bằng load balancer, kiến trúc pipeline, scheduler, v.v. Điều kiện tiên quyết là phải batching để đạt hiệu quả, nhưng điều này lại bất lợi cho các ứng dụng cần bảo mật cao, vì chi phí để cô lập từng truy vấn trở nên cực đắt. Ảo hóa vGPU của nVidia chia bộ nhớ GPU theo lát thời gian, nhưng có nghi ngờ rằng mỗi lần context switch đều phải unload/reload và không có khử trùng lặp. MIG cũng chia cứng bộ nhớ theo người dùng, và nếu muốn điều chỉnh lại thì phải reboot GPU, nên ai cũng hiểu cảm giác không muốn cắt một GPU 96GB thành 4x24GB. Có người tưởng tượng nếu thêm bộ nhớ thứ cấp (DRAM) trên bo mạch GPU thì có thể nạp nhiều loại dữ liệu ma trận nhanh hơn PCIe không, với HBM đóng vai trò cache.<br>Lối viết thẳng thắn trong Software Engineering - cẩm nang thực chiến kiểu sinh tồn cũng được khen ngợi
• Có ý kiến rằng vẫn còn rất nhiều dư địa tối ưu phần mềm cho DeepSeek. Hiện tại tối ưu chủ yếu theo hướng dễ tiếp cận: hoặc là GPU nhỏ với RAM lớn (ktransformers), hoặc là hệ thống có VRAM cực lớn. Kiến trúc có 192GB VRAM + phần còn lại là bộ nhớ thường, như DGX station hay 2xRTX Pro 6000, nhờ sức mạnh của MoE có thể chạy DeepSeek 4bit khá nhanh. Với DeepSeek, nếu không dùng prompt tiếng Trung thì phần lớn expert sẽ không được kích hoạt. Việc pruning cũng dễ hơn trong môi trường này. Hệ enthusiast sắp tới có vẻ sẽ đi theo hướng phù hợp với các tối ưu phần mềm như vậy. Trên Reddit cũng có ví dụ hệ 16x3090 (Pcie 3.0 x4) chạy llama.cpp đạt khoảng 7 token/giây, và chỉ riêng một chiếc 3090 cũng có thể quét toàn bộ VRAM 39 lần mỗi giây, nên có vẻ còn một nút thắt hiệu năng nào khác
  • Hệ 16x3090 tiêu thụ điện tới 5KW. Nếu tính tiền điện thì dùng API còn rẻ hơn. Từ chuyện DeepSeek ít kích hoạt expert nếu không dùng prompt tiếng Trung, có người hình dung cách làm nhẹ model và định tuyến token tới expert gần hơn
  • Một chiếc MI300x có thể cung cấp 192GB VRAM
• Tôi không phải nhà nghiên cứu ML cũng không phải kỹ sư, nên xin cứ nghe với sự dè dặt đó. DeepSeek V3/R1 lớn hơn hẳn các model local trước đây nên việc chạy local là đắt thật. Số tham số được kích hoạt ít hơn tổng kích thước, nhưng điều đó chỉ giảm yêu cầu tính toán chứ không giảm yêu cầu bộ nhớ, nên trên thực tế hầu như không thể dùng nghiêm túc nếu không có GPU khổng lồ. Cũng không thể so trực tiếp với các model frontier chính yếu mang tính proprietary vì thông tin như kích thước không được công khai. Không có cơ sở gì để kỳ vọng các model đó sẽ chạy local rẻ hơn. Ngược lại, MoE lại đem đến đánh đổi phù hợp hơn cho môi trường local hoặc một người dùng, vì kém hiệu quả do batching không phải vấn đề quá lớn. Khi tăng batch, độ trễ chờ của mỗi token có thể lên tới 200ms, nhưng bù lại phép tính feed-forward (GEMM) lớn hơn nên được tính hiệu quả hơn. Tôi cũng thắc mắc liệu batch lớn lên thì bản thân ma trận có lớn hơn hay không. Mô hình trong đầu tôi là mục đích của batch không phải để “tăng kích thước ma trận đầu vào”, mà là để “chuyển nút thắt từ băng thông bộ nhớ sang tính toán”. Weight vốn đã được chia nhỏ theo layer để đưa từ HBM sang SRAM, nhân ma trận theo từng mảnh rồi cuối cùng cộng kết quả lại. Khi batching, ưu điểm là cùng một weight có thể phục vụ nhiều phép tính song song, giúp tối đa FLOPS hiệu quả. Tôi cũng thấy chưa thật thuyết phục rằng các model quy mô lớn của OpenAI, Anthropic, v.v. phản hồi nhanh hơn là một thực tế rõ ràng, vì bài blog không đưa số liệu time to first token
  • Tôi là tác giả bài gốc. Tôi không phải nhà nghiên cứu ML, chỉ là một kỹ sư quan tâm đến chủ đề này. Với kịch bản local một người dùng của MoE, ý tôi là không có lợi ích batch đa người dùng nên throughput trên mỗi GPU giảm rất mạnh, trừ khi bạn có số lượng request suy luận song song cực lớn. Khi tăng kích thước ma trận đầu vào nhờ batch, nếu batch là 1 thì phép tính là ma trận 1xdim, còn khi batch tăng thì thành batch-size x dim nên mức sử dụng GPU tăng vọt, tức có thể chuyển sang nút thắt tính toán. Cuối cùng, nếu dùng DeepSeek nhiều thì cũng sẽ cảm nhận rõ là nó chậm hơn các model khác
• mixture of experts cần batch lớn, nhưng nếu dùng Apple Silicon thì vẫn có thể chấp nhận được với batch size 1. Nhờ unified memory mà có thể chạy model lớn ở local, nhưng băng thông và FLOPS thấp nên chạy tương đối chậm. Điểm của MoE là số tham số phải xử lý mỗi lần ít hơn nên gánh nặng tính toán thấp hơn. Thực tế có khá nhiều người đã chạy DeepSeek trên Mac ở tốc độ đủ dùng với suy luận một batch. Tất nhiên, chi phí mua máy có đủ RAM vẫn rất đắt. Nếu sau này xuất hiện thêm nhiều máy kiểu Mac hoặc kiến trúc tương tự, đây sẽ là sự kết hợp rất lý tưởng với model MoE. So ra thì chạy model dense trên Mac nâng RAM lớn còn đau đầu hơn nhiều
• Khi nói chuyện với đồng nghiệp, tôi đi đến kết luận rằng các LLM dùng để hỗ trợ lập trình đang phát triển theo hướng lệch khỏi tối ưu cốt lõi. Theo quy định nội bộ, tôi gần như luôn so sánh model local 4~30B với nhiều dòng GPT cho hầu hết công việc, và đặc biệt GPT-4o cho kết quả trung bình rất tốt nhưng lại có xu hướng “bịa ra một phần câu trả lời”, khiến tôi phải tốn khá nhiều thời gian để kiểm chứng và lặp lại. Kết quả là tôi thấy “sự khác biệt so với model local ít tham số, tính trên công sức bỏ ra, không lớn như tưởng tượng”. Vấn đề là cả hai đều quá chậm, khiến không thể lặp nhanh. Tôi thấy một model ngữ cảnh lớn, chất lượng có thấp hơn một chút nhưng trả lời gần như tức thì, còn tiện hơn nhiều. Điều tôi mong là “tốc độ lặp mà người dùng cảm nhận được” quan trọng hơn cả việc chỉ cải thiện điểm số đánh giá chất lượng
• Có người phản đối nhận định “chậm và đắt”. Họ đưa ví dụ rằng ngay cả trên workstation cũ dùng bộ nhớ DDR4, với llama.cpp thì hệ thống khoảng 1000 USD vẫn có thể xuất được 3 token/giây
  • Có người chỉ ra rằng có thể bạn đang nhầm và thực ra dùng bản distill chứ không phải model DeepSeek thật. Nếu không có từ 192GB RAM trở lên thì không thể chạy model thật