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 suy luận đa GPU 32B, làm mát phần cứng và kiểm tra hiệu suất

Lời nói đầu

Trong bài viết 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á, chúng tôi đã khám phá các kỹ thuật chắt lọc và lượng tử hóa của các mô hình sâu, cũng như những kiến thức cơ bản về triển khai của mô hình 7B. Thông thường, bộ nhớ của một GPU có thể xử lý đầy đủ các yêu cầu về thông số của mô hình 7B. Tuy nhiên, khi số lượng tham số tăng lên mức 32B (32 tỷ), bộ nhớ của một GPU thường không thể hỗ trợ hoạt động đầy đủ của nó. Đây là lúc việc suy luận song song đa GPU trở nên cần thiết, bên cạnh việc cân nhắc xem liệu kiến ​​trúc phần cứng của máy chủ có thể hỗ trợ nhiều GPU hay không.

Bài viết này triển khai DeepSeek-Chưng cất-Qwen-32B như một ví dụ. Chúng ta sẽ đi sâu vào các nguyên tắc song song đa GPU và những cân nhắc chính để triển khai nhiều GPU trong một máy chủ. Ngoài ra, chúng tôi sẽ đánh giá hiệu suất thời gian chạy và khả năng suy luận của mô hình 32B, đưa ra phân tích và đề xuất cho các trường hợp sử dụng phù hợp.

I. Đánh giá yêu cầu bộ nhớ để triển khai mô hình 32B

Khi triển khai mô hình 32B, các yếu tố như độ chính xác, độ dài ngữ cảnh và kích thước lô ảnh hưởng đáng kể đến nhu cầu bộ nhớ và tính toán. Chúng tôi đã đề cập đến các yếu tố ảnh hưởng cốt lõi trong bài viết trước nên sẽ không nhắc lại chúng ở đây. Thay vào đó, chúng tôi sẽ trực tiếp cung cấp các giá trị được đánh giá:

Do sự phức tạp của các phương pháp lượng tử hóa hiện đại (ví dụ: đóng gói dữ liệu, lượng tử hóa định dạng FP8, v.v.), việc gắn nhãn chúng là Int8 hoặc Int4 sẽ kém chính xác hơn. Vì vậy, chúng tôi sẽ sử dụng Lượng tử hóa 8 bit và Lượng tử hóa 4 bit để ước tính ở đây.

Các biến thể bổ sung có thể phát sinh do chiến lược lượng tử hóa cho các lớp khác nhau, độ chính xác của cấu trúc dữ liệu, liệu lượng tử hóa bộ đệm KV có được bật hay không hoặc việc sử dụng các khung suy luận khác nhau.

II. Giải thích nguyên tắc suy luận đa GPU

Từ các tính toán ở trên, rõ ràng là với bối cảnh lớn—đặc biệt là ở độ chính xác dữ liệu cao hơn—một GPU sẽ gặp khó khăn trong việc đáp ứng nhu cầu bộ nhớ. GPU dành cho người tiêu dùng thông thường thường cung cấp bộ nhớ lên tới 24GB, trong khi thẻ tập trung vào suy luận đạt tới 48GB. Chỉ một số GPU cao cấp cung cấp 64–141GB.

Như vậy, đối với những dòng máy có thông số từ 32B trở lên thì việc suy luận đa GPU là điều gần như khó tránh khỏi. Các chiến lược song song đa GPU chính hiện nay là Song song Tensor và Song song đường ống.

1. Sự song song của tenxơ
   Chia một tensor theo các kích thước, cho phép tính toán song song cùng một hoạt động trên nhiều GPU.

1. Ưu điểm: Tính toán và truyền thông có thể chồng chéo, nâng cao hiệu quả.
2. Nhược điểm: Độ phức tạp triển khai cao. Nó đòi hỏi băng thông liên lạc giữa các GPU cao và độ trễ thấp. Phép chia phải tuân theo lũy thừa của 2 (ví dụ: 2, 4, 8, 16).

2. Song song đường ống
   Gán các lớp mô hình khác nhau cho các GPU khác nhau. GPU ngược dòng và xuôi dòng chuyển các giá trị kích hoạt một cách tuần tự, giống như một dây chuyền lắp ráp.

1. Ưu điểm: Giảm chi phí liên lạc đồng bộ hóa. Nó có nhu cầu thấp hơn về băng thông và độ trễ.
2. Nhược điểm: Có thể xảy ra bong bóng đường ống, gây lãng phí tài nguyên.

3. So sánh các chiến lược song song

Từ bảng trên, Tính song song của Tensor vượt trội trong việc tăng thông lượng tổng thể. Tuy nhiên, Pipeline Parallelism dễ triển khai hơn và phù hợp với các kịch bản suy luận hỗn hợp CPU-GPU. Đây là lý do tại sao llama.cpp (công cụ suy luận được sử dụng bởi ollama) chọn Song song đường ống. Nó cũng giải thích tại sao hiệu suất đa GPU của llama.cpp tương đối yếu hơn.

III. Triển khai phần cứng máy chủ và cấu hình GPU

1. Những thách thức khi cài đặt nhiều GPU trong máy chủ 2U
   Như đã lưu ý trước đó, việc cài đặt GPU có lũy thừa 2 (ví dụ: 2, 4, 8, 16) sẽ tối ưu hóa hiệu suất của tính song song của Tensor. Đối với các máy chủ 2U được sử dụng phổ biến, việc lắp 2 GPU thường rất đơn giản. Tuy nhiên, 4 GPU đặt ra nhiều thách thức.

Hầu hết các GPU đều có chiều rộng gấp đôi, chiếm hai khe cắm PCIe. Ngay cả khi không có các thiết bị khác sử dụng khe cắm, máy chủ 2U thông thường chỉ có thể chứa được ba GPU. Vì điều này không phù hợp với lũy thừa 2 nên chỉ có thể sử dụng tối đa hai GPU.

2. Giải pháp

Giảm số lượng ổ đĩa mặt trước: Giải phóng không gian và cải thiện khả năng làm mát bằng cách sử dụng ổ đĩa có dung lượng lớn hơn thay vì nhiều ổ đĩa nhỏ hơn.

Sử dụng mô-đun đa GPU: Một số nhà cung cấp máy chủ cung cấp các mô-đun GPU chuyên dụng. Chúng dành toàn bộ không gian 1U phía trên cho GPU, cho phép tối đa 4 GPU có chiều rộng gấp đôi cạnh nhau.

Tại thời điểm này, bảng điều khiển phía trước phải dự trữ luồng không khí để làm mát. Như vậy, nó chỉ có thể chứa được 8 ổ đĩa 3,5 inch. Cần có ổ đĩa dung lượng lớn hơn để đảm bảo đủ dung lượng lưu trữ.

Để có nhiều ổ đĩa hơn hoặc làm mát tốt hơn, cần có máy chủ 3U, 4U hoặc cao hơn. Thiết lập tối ưu phụ thuộc vào nguồn điện của tủ và mức tiêu thụ điện năng của GPU.

IV. Triển khai DeepSeek-Distilled-Qwen-32B bằng một cú nhấp chuột trên AIOS Helix

1. Các bước triển khai
   Cấu hình môi trường

Các bước triển khai

1. Chuẩn bị môi trường: Cài đặt ZStackVòng xoắn AIOS. Đảm bảo hệ thống đáp ứng các yêu cầu về thời gian chạy.
2. Triển khai bằng một cú nhấp chuột:
   Sử dụng ZStack AIOS Helix để chọn và tải mô hình.
   b. Chỉ định GPU và tính toán thông số kỹ thuật để triển khai.
3. Chạy thử: Hãy thử trò chuyện trong hộp demo hoặc kết nối qua API với các ứng dụng khác.

Đánh giá hiệu suất
Sử dụng thử nghiệm hiệu suất của ZStack AIOS Helix, chúng tôi đã nhanh chóng đánh giá hiệu suất của mô hình trên phần cứng hiện tại. Dữ liệu được tóm tắt như sau:

Kết hợp những kết quả này, chúng ta có thể phân tích môi trường hiện tại:

Thông lượng (TPS) so với đồng thời

1. TPS tăng mạnh từ 1 lên 16 đồng thời (23→256). Ở mức đồng thời 32, tốc độ tăng trưởng chậm lại đáng kể (chỉ tăng 15%).
2. Phạm vi đồng thời được đề xuất: 4–16 mang lại mức tăng thông lượng tốt.
3. Điểm bước ngoặt đỉnh cao: Ngoài 16, hệ thống gần như bị tắc nghẽn về hiệu suất.

Những phát hiện chính về độ trễ phản hồi

1. TTFT (Thời gian tạo mã thông báo đầu tiên) tăng vọt lên 25 giây ở 32 lần đồng thời (so với 0,06 giây ở 1).
2. Tổng độ trễ vượt quá 64 giây ở 32 lần đồng thời—cao hơn 2,7 lần so với mức đồng thời thấp.
3. Lời khuyên về kịch bản thời gian thực: Đối với các trường hợp nhạy cảm với độ trễ (ví dụ: hệ thống trò chuyện), hãy giữ mức đồng thời ≤4.

Phân tích hiệu quả tài nguyên

1. Thông lượng một phiên là 23,248. Ở mức đồng thời 32, nó giảm xuống còn 9,198 (giảm 60%).
2. Lợi ích cận biên trên mỗi phiên bổ sung sẽ giảm dần sau 16 lần đồng thời.
3. Lời khuyên tối ưu hóa: Chia tỷ lệ thông qua 16 đồng thời * nhiều phiên bản, tỷ lệ đồng thời một phiên bản không cao.

Cấu hình được đề xuất cho các tình huống khác nhau

Với các công cụ đánh giá của ZStack AIOS Helix và điều kiện thực tế, việc tìm kiếm kế hoạch kinh doanh và mô hình triển khai phù hợp trở nên dễ dàng hơn.
Lưu ý: Các thử nghiệm cho thấy 16 lần đồng thời là mức cân bằng thông lượng/độ trễ tối ưu. Ngoài ra, hiệu suất giảm đáng kể. Xác thực bằng các bài kiểm tra căng thẳng dựa trên tài nguyên phần cứng trong quá trình triển khai thực tế.

V. Đánh giá năng lực: MMLU, HumanEval và các tiêu chuẩn khác

1. Số liệu kiểm tra

1. 1. Trả lời chính xác: Hiệu suất về hỏi đáp kiến thức chuyên môn (MMLU), phản ánh khả năng kiến thức toàn diện.
   2. Tạo mã: Được đánh giá dựa trên HumanEval, trong đó mã phải biên dịch và vượt qua các bài kiểm tra đơn vị.
   3. Lý luận toán học: Đã thử nghiệm trên tập dữ liệu Toán học, thể hiện khả năng hiểu và suy luận vấn đề toán học.

      2. Kết quả đánh giá

VI. Kịch bản ứng dụng và triển vọng cho Mô hình 32B

Mô hình 32B vượt trội ở nhiều lĩnh vực:

• Tốc độ suy luận: Tính song song đa GPU được tối ưu hóa giúp tăng tốc độ suy luận, cân bằng chi phí và khả năng.
• Khả năng toán học: Tỏa sáng trong các phép tính phức tạp và công thức phái sinh.
• Lý luận logic: Nắm bắt và suy luận thông qua các mối quan hệ logic phức tạp.
• Tạo mã: Cung cấp khả năng viết và sửa mã chất lượng cao. Tuy nhiên, nó tụt hậu một chút so với các mô hình lớn hơn trong việc tạo mã dài và hoàn chỉnh. Nó phù hợp hơn cho việc xem xét và hoàn thiện mã.

Vì vậy, chúng tôi đã xác định được các trường hợp sử dụng tiềm năng cho tìm kiếm sâu-Chưng-Qwen-32B:

• Hỗ trợ giáo dục: Tận dụng kiến thức và sự hiểu biết của nó để hỗ trợ giảng dạy, giải thích và hỏi đáp.
• Đánh giá mã: Sử dụng khả năng hiểu và tạo mã để tự động đánh giá, phát hiện sự cố và đề xuất cải tiến.
• Tên miền chuyên biệt: Cung cấp khả năng tạo văn bản chất lượng cao, truy xuất kiến thức và hỗ trợ ra quyết định trong các lĩnh vực như luật, y học và tài chính.

VII. Triển vọng: Chiến lược triển khai cho các mô hình tham số lớn hơn

Thông qua việc khám phá này, chúng tôi đã có được những hiểu biết sâu sắc về việc triển khai đa GPU của DeepSeek-Chưng cất-Qwen-32B, yêu cầu phần cứng và hiệu suất trên các chiến lược chính xác và song song. Khả năng mạnh mẽ của mô hình 32B mở ra những khả năng mới cho các ứng dụng doanh nghiệp. Nhìn về phía trước, chúng tôi dự đoán sẽ thấy được giá trị và tiềm năng của nó trong nhiều tình huống thực tế hơn.

Trong các bài viết tiếp theo, chúng tôi sẽ đề cập đến:

• Triển khai lượng tử hóa các mô hình DeepSeek R1: Triển khai mô hình quy mô 671B với nguồn lực hạn chế.
• Triển khai hoàn toàn chính xác các mô hình DeepSeek R1: Tối đa hóa các mô hình lớn trong môi trường hiệu suất cao.

Bằng cách so sánh các mô hình có kích thước và độ chính xác khác nhau, chúng tôi mong muốn cung cấp các kế hoạch triển khai chi tiết, toàn diện để doanh nghiệp sử dụng. Điều này sẽ giúp các ngành áp dụng công nghệ mô hình ngôn ngữ lớn một cách nhanh chóng, mở ra giá trị kinh doanh.
Lưu ý: Một số dữ liệu trong bài viết này mang tính minh họa. Điều kiện thực tế có thể khác nhau. Việc kiểm tra và xác nhận chi tiết được khuyến nghị trong quá trình thực hiện.