Hiểu biết sâu sắc về DeepSeek và thực tiễn doanh nghiệp (Phần 4): Chiến lược tối ưu hóa hiệu suất và triển khai toàn bộ sức mạnh 671B

Lời nói đầu

Trong các bài viết trước của loạt bài này trong vài ngày qua, chúng tôi đã khám phá sâu sắc tìm kiếm sâukỹ thuật chưng cất, chiến lược lượng tử hóa cũng như các yếu tố cần thiết khi triển khai và đánh giá hiệu suất của các mô hình lượng tử hóa 7B, 32B và 671B. Điều này đã giúp người đọc lựa chọn giải pháp triển khai mô hình phù hợp với những hạn chế về nguồn lực khác nhau.

• Hiểu biết sâu sắc về DeepSeek và thực tiễn doanh nghiệp (Phần 1): Chắt lọc, triển khai và đánh giá
• Hiểu biết sâu sắc về DeepSeek và thực tiễn doanh nghiệp (Phần 2): Nguyên tắc, làm mát phần cứng và kiểm tra hiệu suất của suy luận đa GPU 32B
• Hiểu biết sâu sắc về DeepSeek và thực tiễn doanh nghiệp (Phần 3): 671B Phương pháp triển khai và đánh giá hiệu suất với chi phí cực thấp

Khi các doanh nghiệp tăng cường khám phá các ứng dụng AI, mô hình toàn năng 671B của dòng DeepSeek, với khả năng suy luận đặc biệt cho các tác vụ cực kỳ phức tạp, đã trở thành tài sản quan trọng để tăng cường khả năng cạnh tranh. Tuy nhiên, kích thước tham số lớn của nó có nghĩa là việc triển khai GPU đơn hoặc máy đơn không thể phát huy hết tiềm năng của nó. Việc triển khai nhiều máy, nhiều GPU kết hợp với nền tảng ZStack AIOS là rất quan trọng để khai thác các khả năng của nó. Bài viết này sẽ trình bày chi tiết quy trình thực tế triển khai mô hình toàn năng 671B trên nền tảng AIOS bằng cách sử dụng nhiều máy và GPU, phân tích hiệu suất của nó, đồng thời cung cấp hỗ trợ và hướng dẫn mạnh mẽ cho các doanh nghiệp áp dụng công nghệ AI.

1. Phân tích lý thuyết về hiệu suất suy luận của mô hình DeepSeek

Đối với các model lớn hiện nay, quy trình vận hành GPU có thể được đơn giản hóa thành các bước sau:

1. Chuyển đổi văn bản đầu vào (ví dụ: ký tự hoặc từ tiếng Trung) thành số (vectơ và mã hóa vị trí) mà mô hình có thể hiểu được.
2. Thực hiện tính toán dựa trên các tham số của mô hình. Ví dụ: với Qwen2.5-72B, điều này liên quan đến việc tải 145GB dữ liệu vào đơn vị điện toán.
3. Tạo phản hồi, về cơ bản là tạo ra các từ ứng cử viên và phân bổ xác suất của chúng.

Trong quá trình này, hai thông số phần cứng GPU là quan trọng nhất:

1. Hiệu suất nhân ma trận, thường được gọi là GPU TFlops.
2. Băng thông bộ nhớ GPU, vì các tham số mô hình phải được đọc từ bộ nhớ. Điều này phụ thuộc vào việc sử dụng bộ nhớ GDDR hay HBM.

Đối với các GPU hiện đại, “hiệu ứng thắt cổ chai” của cái sau thường lớn hơn cái trước. Dưới đây là so sánh về sức mạnh tính toán và băng thông bộ nhớ của một số GPU phổ biến:

Lấy RTX 4090 làm ví dụ: với FP8, nó có thể xử lý 82TB dữ liệu mỗi giây, nhưng băng thông bộ nhớ của nó chỉ cho phép tải 1TB mỗi giây. Do đó, trong suy luận mô hình lớn, khi tính đồng thời thấp, băng thông bộ nhớ thường là nút thắt cổ chai. Chỉ khi khả năng tương tranh đủ cao thì nút cổ chai mới chuyển từ “bộ nhớ” sang “sức mạnh tính toán”. Điều này giải thích tại sao nhiều thử nghiệm mô hình 671B cho thấy thông lượng tăng lên với khả năng xử lý đồng thời cao hơn.

Ước tính hiệu suất lý thuyết cho Mô hình 671B

Đối với DeepSeek V3 và R1, tổng số tham số là 671B. Nhờ kiến ​​trúc MoE (Hỗn hợp các chuyên gia), chỉ có 37B tham số được kích hoạt trong thời gian chạy. Với biểu diễn FP8 (1 byte cho mỗi tham số), dữ liệu được đọc trên mỗi mã thông báo là:

37B × 1 byte = 37 GB

Lưu ý: Đối với biểu diễn FP16, con số này tăng gấp đôi lên 74 GB/mã thông báo.

Giả sử băng thông bộ nhớ GPU xấp xỉ 1979 GB/s, không phân chia song song trên một GPU, thời gian tính toán trên mỗi byte là:

Điều này tương ứng với thông lượng khoảng 53,5 token/s.

Lưu ý: Tính toán này thể hiện giới hạn dưới về mặt lý thuyết trong các điều kiện “cực đoan”. Trong thực tế, các yếu tố như tính toán chồng chéo, số lần truy cập bộ đệm, số lần đọc bộ đệm KV (tăng theo độ dài chuỗi) và các kỹ thuật tối ưu hóa hoặc điều kiện hiển thị khác nhau có thể làm thay đổi kết quả.

Mặc dù ước tính này là sơ bộ và không tính đến việc tối ưu hóa song song tensor (trong đó mỗi GPU tải ít tham số được kích hoạt hơn), chi phí liên lạc và đồng bộ hóa từ song song tensor, cùng với việc giảm mức sử dụng băng thông bộ nhớ, phù hợp chặt chẽ với các thử nghiệm suy luận một người dùng thực tế của chúng tôi cho DeepSeek. Nếu không tối ưu hóa tích cực, hiệu suất suy luận của một người dùng hiếm khi vượt quá 53,5 mã thông báo/giây.

2. Chiến lược tối ưu hóa hiệu suất suy luận của mô hình DeepSeek

Đối với suy luận mô hình lớn, chiến lược tối ưu hóa được chia thành ba loại:

1. Tối ưu hóa cấp dữ liệu: Ví dụ: nén lời nhắc hoặc giảm các mã thông báo không cần thiết. Tuy nhiên, nút thắt cổ chai hiện tại của chúng tôi không nằm ở việc giải mã nhanh chóng và mục tiêu của chúng tôi là TPS (mã thông báo mỗi giây) thay vì QPS (truy vấn mỗi giây), vì vậy đây không phải là ưu tiên hàng đầu.
2. Tối ưu hóa cấp độ mô hình: DeepSeek triển khai đào tạo MLA, MoE và FP8. Dưới đây là tổng quan ngắn gọn:
   Kiến trúc MLA: So với MHA truyền thống, MLA duy trì sức mạnh biểu đạt mạnh mẽ đồng thời giảm đáng kể kích thước bộ đệm KV, giảm băng thông bộ nhớ và nhu cầu VRAM.
   b. Kiến trúc Bộ GD: Bằng cách chia một mô hình dày đặc thành nhiều chuyên gia chuyên biệt và chỉ kích hoạt một tập hợp con (DeepSeek-V3 sử dụng 8 chuyên gia được định tuyến + 1 chuyên gia được chia sẻ), mỗi mã thông báo chỉ yêu cầu trọng số 37B thay vì 671B, giúp giảm đáng kể chi phí tính toán và truy cập bộ nhớ.
   
   c. Đào tạo và lượng tử hóa FP8 có độ chính xác thấp: Việc sử dụng trọng số FP8 giúp giảm một nửa khối lượng đọc/ghi dữ liệu, đồng thời lượng tử hóa bộ nhớ đệm KV (ví dụ: DeepSeek-V2 nén nó xuống mức trung bình 6 bit) giúp giảm đáng kể mức sử dụng bộ nhớ mà không làm giảm độ chính xác.
3. Tối ưu hóa cấp hệ thống: Bao gồm các cải tiến về tính song song, giải mã suy đoán và tính toán ngày càng tăng. Mặc dù hầu hết đều phổ biến, MTP để giải mã suy đoán là một tối ưu hóa dành riêng cho DeepSeek:
   Mô-đun MTP: Chủ yếu được sử dụng trong đào tạo để tăng cường dự đoán, trong quá trình suy luận, nó cải thiện hiệu quả giải mã thông qua lấy mẫu suy đoán. Dữ liệu chính thức cho thấy độ chính xác 85%–90% đối với các mã thông báo được dự đoán bổ sung, mang lại mức tăng TPS khoảng 1,8 lần.

3. Triển khai và thực hành ở cấp doanh nghiệp

Cân bằng chi phí và hiệu suất

Sơ đồ triển khai trong bài viết DeepSeek-V3 (sử dụng 352 GPU H800 trên mỗi đơn vị trên cụm H800) tận dụng tính song song cao để tối đa hóa hiệu suất GPU, đạt được thông lượng rất cao nhưng với chi phí cao. Để đạt được thông lượng cao với chi phí thấp hơn, trước tiên chúng tôi đã thử nghiệm hiệu năng với ít GPU hơn:

1. Kịch bản 8-GPU H200 đơn

Thiết lập môi trường

Kết quả thực hiện

Không có giải mã suy đoán:
Chúng tôi cũng đã thử nghiệm việc kích hoạt giải mã suy đoán MTP với các tối ưu hóa bổ sung

Những quan sát chính sau khi bật giải mã suy đoán MTP và các tối ưu hóa khác:

• Thông lượng so với độ trễ của mã thông báo đầu tiên: Ở mức đồng thời thấp (1-32), tối ưu hóa sẽ tăng thông lượng trong khi duy trì hoặc giảm độ trễ của mã thông báo đầu tiên—đôi bên cùng có lợi.
• Sự đánh đổi đồng thời cao: Ở mức đồng thời 128, cả độ trễ và thông lượng của mã thông báo đầu tiên đều hoạt động kém hơn so với dữ liệu trước khi tối ưu hóa.

Nhìn chung, giải mã suy đoán MTP duy trì thông lượng tốt trong khi cung cấp thời gian phản hồi mã thông báo đầu tiên tốt trong hầu hết các trường hợp. Tuy nhiên, ở mức đồng thời rất cao, thời gian phản hồi sẽ tăng do chi phí tính toán của việc giải mã suy đoán, điều này có thể bù đắp lợi ích của nó trong cài đặt song song quy mô lớn.

1. Kịch bản Dual H20 96GB 16-GPU

Vì khó có được GPU H200 hơn nên chúng tôi đã thử nghiệm với hai thiết lập H20 96GB * 8. Sau khi định cấu hình các điều kiện mạng, chúng tôi quan sát thấy hiệu suất với TP=16 trên các độ trễ mạng và đồng thời khác nhau.

Lưu ý: TP đề cập đến tính song song của Tensor.

Sơ đồ cấu trúc liên kết phần cứng nội bộ của Môi trường SetupServer:

Kết quả triển khai trên Nền tảng ZStack AIOS:

Tiếp theo, chúng tôi đã kiểm tra hiệu suất bằng công cụ đánh giá dịch vụ của ZStack AIOS:

Kết quả thực hiện TP16

Để đánh giá tác động của độ trễ mạng đối với sơ đồ triển khai TP16, chúng tôi đã giới thiệu độ trễ một cách giả tạo bằng cách sử dụng tc và so sánh thông lượng (TPS) trong các độ trễ mạng khác nhau:
Tóm tắt trong biểu đồ:

Những phát hiện chính:
Từ bảng và biểu đồ, khi độ trễ mạng tăng từ 0,193 mili giây lên 2,193 mili giây, thông lượng của TP16 giảm từ 18,943 mã thông báo/giây xuống 4,85 mã thông báo/giây—hiệu suất giảm tối đa là 74%. Điều này cho thấy độ trễ mạng tăng lên làm giảm đáng kể thông lượng TP16.

Vì đây là thử nghiệm đồng thời đơn lẻ nên tác động của độ trễ mạng đến thông lượng TP16 là rất rõ ràng. Do đó, khi thiết kế và triển khai các giải pháp TP16, việc giảm thiểu độ trễ mạng là rất quan trọng để tối ưu hóa thông lượng và hiệu suất.

4. Các chiến lược tối ưu hóa hơn nữa cho các ứng dụng sản xuất

Mặc dù các phương pháp trên đã cải thiện đáng kể hiệu quả suy luận, nhưng các chiến lược tối ưu hóa tích cực hơn trong môi trường cụm quy mô lớn có thể có khả năng nhân hiệu suất hơn nữa:

• Song song lai với DP+EP, TP+EP:
  Nguyên tắc: DP tăng tốc độ suy luận tổng thể cho các đầu vào hàng loạt lớn thông qua tính toán song song mà không làm quá tải các thiết bị riêng lẻ. EP tận dụng kích hoạt chuyên gia một phần của MoE để giảm mức sử dụng tài nguyên và tăng tốc độ. Kết hợp chúng giúp tăng cường hiệu suất suy luận mô hình lớn.
  b. Nghiên cứu điển hình: Mới hôm qua, DeepSeek có nguồn mở DeepEP, một thư viện giao tiếp được thiết kế riêng cho Hỗn hợp các chuyên gia (MoE) và Chuyên gia song song (EP). Nó cung cấp các chiến lược liên lạc và cân bằng tải, giải quyết tình trạng mất cân bằng tải và chi phí liên lạc cao trong các thiết lập DP+EP truyền thống, đạt được hiệu quả tính toán và khả năng mở rộng cao hơn trong đào tạo mô hình MoE quy mô lớn. Nó cũng hỗ trợ các hoạt động có độ chính xác thấp, bao gồm FP8.
• Tối ưu hóa các chiến lược chuyên gia dư thừa: Ngoài việc điều chỉnh linh hoạt số lượng chuyên gia dự phòng trên mỗi GPU, các chiến lược trong tương lai có thể bao gồm định tuyến toàn cầu thông minh hơn để cân bằng tải hơn nữa trên các thẻ. Các chiến lược hiện tại, chẳng hạn như việc sao chép các chuyên gia tải cao của DeepSeek và điều chỉnh định kỳ 10 phút một lần trong giai đoạn điền trước, đạt được một số cân bằng tải. Tuy nhiên, khi quy mô cụm và độ phức tạp của ứng dụng tăng lên, định tuyến toàn cầu thông minh có thể thích ứng tốt hơn trong thời gian thực, tối ưu hóa việc phân phối tải.
• Làm sâu sắc hơn sự giao tiếp và tách biệt PD: Tối ưu hóa giao tiếp cho NVLink nội nút và IB nút chéo có thể tận dụng bộ tăng tốc cấp phần cứng hoặc bộ đồng xử lý mạng để giảm độ trễ hơn nữa. Trong các cụm lớn có giao tiếp giữa các nút lớn (ví dụ: trong giai đoạn Giải mã), các kỹ thuật như truyền điểm-điểm IB và độ trễ thấp hơn IBGDA. Tuy nhiên, với nhu cầu suy luận ngày càng tăng, việc tối ưu hóa ở cấp độ phần cứng về cơ bản có thể tăng cường hiệu quả liên lạc, giảm bớt tắc nghẽn mạng và đảm bảo truyền dữ liệu nhanh chóng để đáp ứng các yêu cầu nghiêm ngặt về độ trễ thấp.
• Mở rộng chồng chéo nhiều vi hạt: Việc xử lý đồng thời hai vi hạt có thể che giấu thời gian nhàn rỗi tốt hơn trong quá trình liên lạc tiến và lùi, đạt đến giới hạn thông lượng lý thuyết. Chiến lược này tỏa sáng trong suy luận cụm lớn. Ví dụ: DeepSeek sử dụng hai microbatch có kích thước bằng nhau trong giai đoạn Prefill, chồng chéo tính toán Chú ý và MoE của một microbatch với các hoạt động Điều phối và Kết hợp của một microbatch khác, giúp tăng thông lượng. Trong giai đoạn Giải mã, các phương pháp tương tự đang được khám phá, chồng chéo tính toán sự chú ý của một microbatch với các hoạt động Dispatch + MoE + Combine của một microbatch khác. Việc mở rộng hơn nữa điều này có thể mở ra tiềm năng hiệu suất lớn hơn nữa.

5. Kết luận

Thông qua các thử nghiệm và phân tích lý thuyết ở trên, chúng tôi đã xác thực các điểm nghẽn về hiệu suất của mô hình lớn ở các mức độ đồng thời khác nhau. Bằng cách tận dụng các lợi thế kiến ​​trúc MLA và MoE độc đáo của DeepSeek, kết hợp với lượng tử hóa FP8 và mô-đun MTP, hiệu suất phần cứng GPU có thể được tận dụng tối đa. Về phía mạng, các chiến lược song song linh hoạt có thể được cấu hình dựa trên điều kiện mạng để tối ưu hóa thông lượng hệ thống.

Trong tương lai, các chiến lược như song song chuyên gia, song song dữ liệu, chuyên gia dự phòng, tối ưu hóa truyền thông và chồng chéo nhiều vi chương trình có thể nâng cao hơn nữa hiệu suất hệ thống, cung cấp nền tảng kỹ thuật vững chắc cho việc triển khai trên quy mô lớn.

Điều này kết thúc một phân tích toàn diện và triển vọng triển khai doanh nghiệp dựa trên lý thuyết hiện tại và thực tiễn triển khai mô hình DeepSeek. Chúng tôi hy vọng bài viết này cung cấp tài liệu tham khảo và nguồn cảm hứng cho các kỹ sư và người ra quyết định của doanh nghiệp trong việc triển khai mô hình lớn.

6. Triển vọng

Trong lĩnh vực AI, việc lặp lại mô hình phát triển nhanh chóng và mô hình đột phá tiếp theo có thể xuất hiện bất cứ lúc nào. Vì vậy, doanh nghiệp phải thiết lập cơ chế lựa chọn và đánh giá mô hình dài hạn để đón đầu các xu hướng công nghệ. Khi lựa chọn mô hình AI, doanh nghiệp nên chọn các mô hình có kích thước tham số và sơ đồ triển khai phần cứng phù hợp dựa trên nhu cầu kinh doanh thực tế, tạo ra sự cân bằng tối ưu giữa hiệu suất suy luận và chi phí.

Trong các bài viết tiếp theo, chúng ta sẽ khám phá:

• Chiến lược triển khai GPU trong nước: Cách chạy các mô hình DeepSeek trên GPU trong nước, cùng với hiệu suất và hiệu quả suy luận của chúng.

Hãy theo dõi các ZStack tài khoản công cộng! Chúng tôi sẽ tiếp tục tối ưu hóa và tập trung vào các giải pháp hiệu quả về chi phí và hiệu suất suy luận của mô hình DeepSeek, đồng thời đưa ra các chiến lược triển khai toàn diện và chi tiết cho các ứng dụng doanh nghiệp. Điều này sẽ giúp nhiều ngành nhanh chóng áp dụng công nghệ mô hình ngôn ngữ lớn và hiện thực hóa giá trị kinh doanh.