Ask HN: ChatGPT có thể phục vụ 700 triệu người, vậy tại sao tôi còn không chạy nổi một GPT-4 cục bộ?

• Sam Altman công bố rằng ChatGPT xử lý khoảng 700 triệu người dùng hàng tuần
• Khi chạy một mô hình cấp GPT-4 trên máy cục bộ, các vấn đề thiếu VRAM và suy giảm tốc độ rất nghiêm trọng, nên có thắc mắc OpenAI xử lý quy mô sử dụng lớn như vậy với độ trễ thấp và hiệu năng cao bằng cách nào
• Muốn biết các kỹ thuật tối ưu hóa mô hình, xử lý phân tán, phần cứng chuyên dụng và cân bằng tải vượt xa một cụm GPU đơn thuần

---

Tóm tắt các bình luận chính

1. Cấu trúc suy luận phân tán siêu quy mô

• Model Sharding
  • Phân tán lưu trữ tham số trên nhiều GPU
  • Khi có yêu cầu, mỗi GPU thực hiện tính toán trên phần tham số của mình rồi hợp nhất kết quả
• Tensor Parallelism
  • Nhiều GPU song song thực hiện tính toán trong cùng một layer
• Pipeline Parallelism
  • Chia các layer thành nhiều giai đoạn để xử lý tuần tự và đồng thời như một pipeline
• Dùng xử lý song song hỗn hợp để tối ưu bộ nhớ GPU và tải tính toán

2. Tối ưu bộ nhớ và tốc độ

• Quantization: chuyển tham số sang độ chính xác bit thấp hơn để giảm mức dùng VRAM
• Offloading layer: khi cần thì chuyển một số layer sang bộ nhớ CPU
• LoRA / Adapter Layers: chỉ fine-tuning cho tác vụ cụ thể nên không cần nạp lại toàn bộ mô hình
• KV caching: tái sử dụng ngữ cảnh để loại bỏ các phép tính lặp lại

3. Phần cứng chuyên dụng và mạng kết nối

• Sử dụng quy mô lớn các NVIDIA H100, A100 và một phần TPU mới nhất
• Truyền dữ liệu siêu tốc giữa GPU bằng NVLink và NVSwitch, giữa các cụm bằng Infiniband
• Xây dựng mạng backbone toàn cầu giữa các trung tâm dữ liệu để giảm độ trễ tối đa

4. Phân tán địa lý và cân bằng tải

• Triển khai GPU farm ở nhiều khu vực trên toàn thế giới
• Dùng GeoDNS để kết nối yêu cầu của người dùng tới khu vực gần nhất
• Mở rộng/thu hẹp động các cụm GPU theo mẫu lưu lượng
• Khi tải dồn vào một khu vực cụ thể thì phân phối lại lưu lượng trên phạm vi toàn cầu

5. Tối ưu xử lý yêu cầu

• Batch Inference: gom yêu cầu của nhiều người dùng để suy luận cùng lúc
• Tiền xử lý bằng mô hình nhỏ: yêu cầu đơn giản thì xử lý bằng mô hình nhỏ, chỉ gọi mô hình lớn cho yêu cầu phức tạp
• Caching kết quả: trả ngay từ cache cho cùng prompt hoặc các yêu cầu tương tự
• Dùng prompt engineering để tránh lãng phí token không cần thiết

6. Tối ưu vận hành và chi phí

• Giảm tài nguyên nhàn rỗi bằng giám sát mức sử dụng GPU và lập lịch
• Tối ưu hiệu suất điện năng trung tâm dữ liệu và áp dụng làm mát bằng chất lỏng
• Tăng tốc suy luận bằng trình biên dịch và runtime tối ưu hóa nội bộ
• Vận hành pipeline tự động hóa cho cập nhật và triển khai mô hình

Ví dụ luồng kiến trúc tổng thể

1. Tiếp nhận yêu cầu người dùng → định tuyến tới khu vực gần nhất bằng GeoDNS
2. Tiền xử lý → yêu cầu đơn giản dùng mô hình nhỏ, chỉ chuyển yêu cầu phức tạp sang mô hình lớn
3. Xử lý suy luận phân tán
   • Áp dụng model sharding + tensor parallelism + pipeline parallelism
   • Trao đổi kết quả trung gian qua mạng tốc độ cao giữa các GPU
4. Hậu xử lý và caching kết quả → lưu cache để phục vụ các yêu cầu giống hoặc tương tự
5. Trả phản hồi → cung cấp kết quả trong vòng 1~2 giây

[popkins]

Trong trường hợp của OpenAI, họ đang dùng cho suy luận không chỉ phần cứng Nvidia mà cả MI300X của AMD; dù cho huấn luyện thì vẫn chỉ dùng Nvidia.
Ở mảng suy luận, họ đang rất quyết liệt tìm cách đảm bảo VRAM so với chi phí đầu tư bằng mọi giá.
Phía Microsoft cũng tương tự, với suy luận thì họ đang dùng kết hợp cả Nvidia và AMD.

[popkins]

Đặc biệt, ở các vùng Azure tại châu Á, tỷ trọng AMD mà OpenAI sử dụng vào khoảng
NVIDIA 8 / AMD 2

[GN⁺]

Ý kiến trên Hacker News

• Tôi làm công việc trực tiếp liên quan đến các hệ thống như thế này ở Google (ý kiến cá nhân), và có thể khẳng định rằng những người rất giỏi đang suy nghĩ nghiêm túc về mọi khía cạnh của vấn đề. Tôi không thể chia sẻ thêm nhiều, nhưng muốn giới thiệu tài liệu do đồng nghiệp tôi viết. Có phần giải thích rất hay về kiến trúc bộ tăng tốc và các cách tối ưu để đạt tốc độ cao trong scaling book. Nếu đặc biệt tò mò về suy luận thì chương inference sẽ hữu ích. Ngoài ra tôi cũng khuyên xem các hướng dẫn của unsloth. Họ đào rất sâu vào nhiều mô hình khác nhau để tìm tối ưu hóa rồi tổng hợp lại rất tốt. Ngoài hướng dẫn Gemma 3n còn có nhiều hướng dẫn khác nữa

  • Nói bớt màu mè đi thì suy luận phần lớn là công việc không trạng thái. Vì thế không cần lo tính nhất quán bộ nhớ giữa hàng trăm nghìn máy hay lỗi máy như lúc huấn luyện. Chỉ cần chuyển một lượng nhỏ dữ liệu vào các máy rất lớn cho tốt là được. Các máy nghiên cứu ở chỗ tôi từng làm là những máy cực mạnh gắn 8 GPU, và miễn là mô hình còn nằm vừa trong tổng VRAM thì hầu như tác vụ nào cũng chạy ổn. Bí quyết cho khả năng mở rộng quy mô lớn là “một núi vốn”. NVIDIA từng gửi cho chúng tôi các máy DGX mạ vàng theo đúng nghĩa bóng, nhưng chúng không có mật độ cao và cực kỳ đắt. Phần lớn công ty lớn đều đã có RPC ổn định và hệ thống orchestration, nên phần thật sự khó không phải truyền thông điệp mà là nhét mô hình cho khớp với phần cứng đang có nó chạy trên đó (đây không phải chuyên môn của tôi)

  • Các rack suy luận hiện đại quy mô lớn, những kỹ thuật RDMA và mạng độ trễ thấp đã quen thuộc, hay các tối ưu MLA và cache mạnh mẽ, không cần bị mô tả như công nghệ thần bí. Những thứ này đã được hiểu khá rõ công khai rồi, và ngược lại nếu công ty lớn nào đó làm gì quá tùy biến thì nhiều khi còn thành gánh nặng vì tương thích ngược. Điều thực sự quan trọng là có được hệ thống và quy trình cần thiết để vận hành các hệ thống lớn. Chuyện này trải dài từ mua sắm thiết bị, đào tạo SRE, cho đến RTL cho TPU mới. Nếu ai đó thật sự đi trước 10 lần thì mọi người đã biết ngay rồi (Tôi là người có 10 năm kinh nghiệm suy luận quy mô lớn tại một công ty trong TOP-5)

  • Với câu “chúng tôi là những người thông minh, suy nghĩ rất nghiêm túc về mọi vấn đề”, thì thật ra có thể hiểu là đang làm hệ thống chia sẻ thời gian kiểu mainframe của thập niên 1970

  • Tôi tự hỏi liệu nhờ TPU mà Google có lãi từ suy luận mô hình nội bộ cao hơn rất nhiều so với việc thuê card NVIDIA không. Tôi biết OpenAI chủ yếu có GPU nhờ quan hệ đối tác với Microsoft. Cả liên kết lẫn cuốn sách đều rất thú vị

  • Câu “ngày nay ngay cả các mô hình ‘nhỏ’ cũng chạy sát giới hạn phần cứng” làm tôi ấn tượng. Nghe rất giống câu của thập niên 60, 70 rằng “ngay cả chương trình nhỏ cũng chạy sát giới hạn phần cứng”. Dù tối ưu hóa và hiệu quả có thể đã mờ nhạt trong kỹ nghệ phần mềm nói chung, chúng vẫn còn sống khỏe trong phát triển LLM

• Một chiếc H100 giá 20.000 USD và có 80GB VRAM. Có thể hình dung một máy chủ rack 2U chứa lượng card trị giá 100.000 USD. Nếu trang bị như vậy cho cả rack, cộng thêm CPU, RAM và làm mát thì một rack vào cỡ 1 triệu USD (chưa tính chi phí vận hành và nhân sự bảo trì). Ngay cả thiết bị “rẻ” thì đơn vị tính toán cũng vẫn cực lớn. Tôi hy vọng khi bong bóng AI xì hơi, việc chạy các mô hình cục bộ tốt sẽ trở nên thực tế hơn. Biết đâu 10 năm nữa những máy chủ 100.000 USD này sẽ được bán trên eBay với giá 3.000 USD, và thợ điện sẽ nhận yêu cầu kéo nguồn 240V vào garage hay phòng server tự chế

  • Không cần đợi 10 năm, bạn có thể mua ngay DGX-1 trên eBay với giá dưới 10.000 USD. Nó có 256GB VRAM (HBM2), NVLink, 512GB RAM, CPU 40 nhân, SSD 8TB và HBA 100Gbit. Các mẫu không phải thương hiệu NVIDIA còn có thể mua với giá 6.000 USD. Tuy nhiên nó rất nặng, ồn hơn bạn tưởng rất nhiều, và một máy gần như dùng hết cả mạch điện 240V 16A. Đồng thời nó cũng thải ra 13.000 BTU nhiệt mỗi giờ

  • Kể cả bong bóng AI không vỡ thì rất có thể các máy chủ đó vẫn sẽ lên eBay sau 10 năm. Vì các trung tâm dữ liệu sẽ nâng cấp phần cứng rồi bán đồ cũ cho bên thứ ba

  • Cá nhân tôi nghi ngờ các mô hình công khai dùng ít tính toán hơn nhiều so với chúng ta tưởng. Với các mô hình Mixture of Experts mới nhất, nhờ cơ chế top-k sampling tức chỉ kích hoạt một số expert (tham số) để đánh giá, ngay cả mô hình SOTA cũng không nhất thiết cần nhiều tính toán hơn quá xa so với mô hình non-MoE 70-80B

  • Trong phục vụ AI ở cấp doanh nghiệp, câu hỏi thật sự không phải là “làm sao để phục vụ người dùng”, mà là nhà đầu tư rồi sẽ đòi ROI. Hạ tầng cần bao nhiêu thì chỉ cần có vốn là xây được bấy nhiêu. Ngay cả không có tối ưu hóa, nếu cần thì cứ xây đủ nhà kho và rack để phục vụ là xong

  • Tôi không phải người Mỹ nên thấy đoạn nói về 240V khá buồn cười

• Bạn có vài nghìn USD, còn họ có hàng chục tỷ USD. Chênh lệch quy mô là 1.000 so với 10.000.000.000. Hiệu quả họ đạt được cũng hơn thêm một đến hai bậc độ lớn nhờ quy mô. Ngoài ra, ngay cả trên MacBook (RAM 24GB) bạn cũng có thể chạy mô hình cục bộ đạt mức ngang với hiệu năng GPT-4 thời điểm đầu ra mắt. Liên kết so sánh hiệu năng

  • Nếu dàn đều 700 triệu người dùng theo thời gian trong một ngày hay một tuần thì thực tế có thể chỉ khoảng 10 triệu phiên hoạt động đồng thời. Người dùng cá nhân không thể tích trữ cả tuần tài nguyên tính toán rồi dùng một lần, nhưng nhà cung cấp dịch vụ chỉ cần khớp được đỉnh tải bằng cấu trúc mở rộng ngang. Vì thế với cùng nhu cầu hiệu năng, môi trường cục bộ sẽ cần nhiều phần cứng hơn rất nhiều

• Chỉ một node GPU cũng đã cung cấp FLOPs và băng thông bộ nhớ rất cao. Khi xử lý ít yêu cầu, GPU thường chủ yếu chờ dữ liệu trọng số được stream từ RAM vào đơn vị tính toán. Nếu gom các yêu cầu lại để xử lý theo batch, có thể đọc một lô trọng số một lần rồi xử lý song song nhiều yêu cầu, nhờ đó hiệu quả được tối đa hóa. Ngoài ra còn có thể nén mô hình xuống 8-bit hoặc thấp hơn để giảm lượng dữ liệu cần stream, và GPU mới hiện hỗ trợ tính toán 8-bit/4-bit. Mô hình Mixture of Experts chỉ dùng một phần tham số cho mỗi token nên cũng cần nạp ít trọng số hơn. Kỹ thuật speculative decoding dùng một mô hình nhỏ để dự đoán trước nhiều token, sau đó mô hình chính chỉ nhận những token trùng khớp. Tất cả các tối ưu này cộng lại tạo ra hiệu quả rất cao (Dựa trên kinh nghiệm làm giám đốc nhóm suy luận tại Databricks)

• Một trong những bí quyết bí mật của OpenAI là khoản lỗ hàng tỷ USD. Năm 2024 họ lỗ 5 tỷ USD. Bài viết liên quan

  • Dạo này cách làm agentic xuất hiện nên tình hình thay đổi khá nhiều. Trước đây là 1 yêu cầu cho 1 lần xử lý, còn bây giờ một tác vụ có thể đồng thời chạy hàng trăm lần xử lý. Chính nhờ khả năng song song này mà OAI/Azure có lợi thế hơn mô hình cục bộ

  • Nếu bỏ R&D đi và chỉ phục vụ mô hình sẵn có thì có lẽ họ vẫn có thể hòa vốn

  • Bạn đã chạm đúng cốt lõi. Khoản đầu tư lên tới 10 tỷ USD của Microsoft đã trang trải tiền pretraining, R&D và chi phí suy luận mà họ vẫn còn lỗ hàng tỷ USD. Đây là cấu trúc tư bản kiểu VC, định hướng tăng trưởng

• Trong suy luận quy mô lớn, gom yêu cầu lại để xử lý theo batch hiệu quả hơn rất nhiều so với kiểu mỗi người dùng một GPU riêng trong môi trường cá nhân. Nếu muốn biết vài mẹo kỹ thuật ở mức trung cấp, bạn có thể xem bài nhóm chúng tôi viết trên blog Fin AI. (OpenAI và các bên khác có lẽ còn dùng thêm các kỹ thuật riêng không công khai.) Bài liên quan

  • Đây mới thật sự là câu trả lời đúng trọng tâm. So với nhiều chuyện khác được bàn ở trên, chính batching mới là cách làm giảm chi phí mạnh nhất. Ví dụ nếu xử lý một yêu cầu tốn 50.000 USD thì nhờ batching bạn có thể dùng cùng 50.000 USD đó để xử lý gần như không tổn hao 100 yêu cầu cùng lúc. Tôi không biết chính xác một bộ phần cứng xử lý được bao nhiêu người dùng, nhưng nghĩ là ở mức hàng trăm. Nghĩa là thực tế có thể kéo chi phí từ 50.000 USD xuống còn 500 USD nếu có đủ người dùng. Nút thắt của xử lý LLM phần lớn là thời gian đưa trọng số lên GPU, nên thay vì xử lý từng yêu cầu riêng lẻ, người ta gộp tính toán của nhiều yêu cầu lại để tối đa hiệu quả. Ví dụ giả sử 3 bộ trọng số (A, B, C) đi vào cache GPU, và có 2 yêu cầu (1, 2), thì cách thường là nạp trọng số rồi dùng cho từng yêu cầu, còn cách batching là nạp một lần rồi tính cho nhiều yêu cầu. Khi so sánh thời gian nạp trọng số và thời gian tính toán, khác biệt tốc độ trước và sau batching hiện ra rất rõ. Trong thực tế, nạp trọng số chậm hơn tính toán rất nhiều nên càng nhiều người dùng thì chênh lệch càng lớn. Dĩ nhiên để phục vụ thêm người dùng còn cần bộ nhớ cho trạng thái kích hoạt, nên phải cân bằng xem mỗi cụm GPU nên gánh bao nhiêu người. Kết luận là phần cứng phục vụ LLM rất đắt, nhưng một khi đã có sẵn thì có thể phục vụ đồng thời hàng trăm người dùng gần như không suy giảm hiệu năng

• Có 700 triệu người dùng mỗi tuần không nói lên quá nhiều về tải thực tế. Phần lớn người dùng ChatGPT dù có dùng 1 giờ mỗi ngày suốt cả tuần thì 96% thời gian vẫn là nhàn rỗi. Nhiều người còn chỉ dùng các mô hình ít phức tạp hơn. Việc cố tình nói đến “người dùng hàng tuần” thậm chí còn cho thấy ngay cả trong số người dùng hoạt động hằng ngày, chỉ một phần nhỏ là thật sự dùng mỗi ngày. Bài toán cốt lõi là 1) tạo máy chủ có thể chứa mô hình trong bộ nhớ và xử lý token đủ nhanh, 2) có đủ số máy chủ đáp ứng tổng thông lượng token tại đỉnh, 3) phân phối tất cả yêu cầu lên máy chủ một cách hiệu quả. Có nhiều chi tiết hơn, nhưng thực ra bài toán cuối nghe cũng khá giống vận hành công cụ tìm kiếm. Toàn bộ trạng thái đều nằm trong lịch sử cuộc trò chuyện, nên không cần cùng một máy chủ phải xử lý cùng một cuộc chat. Khi bạn thấy thông báo “Thinking...”, không ai cho biết đó là lúc mô hình đang tính toán thật hay chỉ đang xếp hàng chờ máy chủ

• Một trong những bí quyết lớn nhất để LLM chạy tốt ở quy mô lớn là “kích thước batch”. LLM hiện đại phần lớn dùng kiến trúc “Mixture of Experts”, trong đó chỉ một phần tham số được kích hoạt tại một thời điểm. Nhờ vậy xử lý batch lớn hiệu quả hơn nhiều. Nếu bạn muốn chạy GPT-4 ở nhà, bạn phải nhét được toàn bộ mô hình vào VRAM, nên sẽ cần nhiều GPU như H100 (mỗi chiếc khoảng 40.000 USD). Nhưng với mức sử dụng cá nhân thì bạn không thể tận dụng tốt các card này. Nó giống như hỏi “Tại sao Apple có thể làm iPhone cho hàng tỷ người, còn tôi thì không thể làm nổi một chiếc trong garage?”

  • Tóm lại, tải suy luận được phân bổ rất tốt trên số lượng lớn người dùng nên vận hành rất hiệu quả

  • Vậy thì tôi cũng tò mò không biết có thể làm kiểu những phần ít dùng để ở bộ nhớ chính, còn phần hay dùng thì giữ trong VRAM hay không

  • Phép so sánh rất chuẩn

• Một mẹo hoàn toàn có thể làm tại nhà và cũng là yếu tố quan trọng trong hiệu năng của Cerebras là speculative decoding. Cách này dùng một mô hình nháp nhỏ hơn nhiều để dự đoán token với lượng tính toán và bộ nhớ thấp hơn hẳn, rồi mô hình chính nhận những token mà chính nó cũng có thể đã chọn. Với hệ thống được chuẩn bị tốt, có thể tăng tốc tới 3 lần. Ngoài ra, với structured output có thể dùng “fast forwarding” để bỏ qua các token có thể dự đoán trước, ví dụ điền sẵn khung mở đầu trong JSON, giúp tăng tốc thêm tối đa 3 lần nữa

  • Trong LM Studio bạn có thể ghép gpt-oss-120b với gpt-oss-20b để làm speculative drafting. Nhưng tôi không cảm thấy hiệu năng tăng rõ lắm

• Trọng tâm của suy luận LLM là phép nhân ma trận-vectơ. Khi phải xử lý nhiều truy vấn cùng lúc, có thể gom các vectơ của từng truy vấn thành một ma trận rồi tính đồng thời bằng phép nhân ma trận-ma trận. Với phần cứng, làm một lần ma trận-ma trận hiệu quả hơn rất nhiều so với lặp lại nhiều lần phép nhân ma trận-vectơ. Đó chính là batch processing. Mẹo thứ hai là speculative decoding. Suy luận có hai giai đoạn là xử lý prompt và sinh token, nhưng thực chất cả hai đều là cùng một cấu trúc “forward pass”. Xử lý prompt có thể song song hóa bằng phép nhân ma trận-ma trận, và chỉ kết quả cuối cùng được dùng để bắt đầu sinh token. Nhưng vì không biết trước token tương lai nên bình thường không thể song song hóa phần này. Vì vậy người ta dùng một mô hình nháp nhanh để dự đoán trước N token, đưa chúng vào prompt đầu vào rồi chạy forward pass song song bằng mô hình chính. Trong N token tạo ra đó, tất cả token khớp cho tới token không khớp đầu tiên đều có thể được chấp nhận ngay là token hợp lệ. Về lý thuyết có thể kỳ vọng tăng tốc suy luận 2~4 lần. Tôi chưa trực tiếp triển khai việc này trong công việc, nhưng đoán rằng còn có thêm các kỹ thuật như gom nhóm song song theo độ dài truy vấn hay cân bằng tải thời gian thực nữa (vì không phải mọi yêu cầu đều có cùng độ dài, nên cần để tránh lệch tài nguyên)