Phân tích từ SemiAnalysis: Vì sao HBM 4-hi sẽ trở thành cấu hình tối ưu cho suy luận AI

High Bandwidth Memory (HBM) là công nghệ then chốt thúc đẩy cuộc cách mạng AI. Bất chấp chi phí của HBM cao hơn so với các loại bộ nhớ khác, các nhà thiết kế chip vẫn tích hợp ngày càng nhiều HBM vào các bộ tăng tốc AI (AI accelerators). Khách hàng thúc đẩy việc thiết kế các thế hệ HBM mới hơn, đồng thời tăng dung lượng trên mỗi XPU bằng cách bổ sung thêm các khối (cubes) cũng như các chồng (stacks) dày hơn và cao hơn. Điều này dẫn đến việc HBM tiêu thụ ngày càng lớn tỷ trọng công suất tấm wafer DRAM tổng thể, gây ra tình trạng thiếu hụt DRAM trầm trọng mà chúng ta đang chứng kiến hiện nay.

Chúng ta hiện đang ở ngưỡng của sự thay đổi xu hướng này, do một loạt các lý do liên quan đến cả kỹ thuật và chuỗi cung ứng. Các bộ tăng tốc thế hệ tiếp theo đang chuyển sang tiêu chuẩn chồng 8-hi, thay vì 12-hi như hiện nay. Nvidia đã quyết định thực hiện điều này với Rubin Ultra, một sự cắt giảm từ 288GB xuống còn 192GB trên mỗi GPU so với Rubin tiêu chuẩn và B300 – thay đổi mà SemiAnalysis là đơn vị đầu tiên đưa tin. Chuỗi cung ứng hiện đang chuẩn bị để 8-hi trở thành tiêu chuẩn mới, trong khi chỉ chưa đầy một năm trước, ngành công nghiệp vẫn kỳ vọng sẽ tiến tới 16-hi và hơn thế nữa.

Tuy nhiên, chúng tôi nhận thấy xu hướng này còn đi xa hơn như đã đề cập trong Mô hình Bộ nhớ (Memory Model) của chúng tôi. Đối với các tác vụ suy luận (inference workloads) nơi băng thông bộ nhớ là quan trọng nhất, HBM 4-hi mang lại tỷ lệ $/băng thông tốt nhất và do đó có chi phí trên mỗi token thấp nhất. Dung lượng chỉ quan trọng cho đến một ngưỡng nhất định; vượt quá điểm đó, việc tăng thêm dung lượng HBM mang lại lợi ích giảm dần trong khi các bit tăng thêm đó vẫn phải chịu cùng một mức phí BOM (Bill of Materials). Đây là điều mà các đội ngũ phần cứng tại các phòng thí nghiệm lớn muốn triển khai trong các chương trình ASIC của họ từ thế hệ HBM4 trở đi. Tương tự như cách các nhà thiết kế phần cứng tập trung vào việc tối đa hóa số token/Watt trong bối cảnh hạn chế về nguồn điện DC, 4-hi chính là cách để tối đa hóa số token trên mỗi tấm wafer HBM, vốn là một nguồn tài nguyên khan hiếm khác.

Báo cáo này sẽ đi sâu vào lý do đằng sau những thay đổi trong phương trình dung lượng, chứng minh rằng dung lượng HBM thường bị lãng phí (stranded), và cho thấy điều này có thể là đôi bên cùng có lợi cho cả TCO của các phòng thí nghiệm và lợi nhuận của nhà cung cấp bộ nhớ.

HBM là dạng bộ nhớ làm việc chính cho các tác vụ AI vì nó cung cấp sự cân bằng tốt giữa dung lượng và băng thông, có thể được sử dụng cho các chip đa năng cho cả huấn luyện và suy luận. SRAM, mặc dù rất nhanh, lại bị hạn chế về dung lượng, khiến nó trở nên đắt đỏ và chỉ giới hạn ở một số tác vụ nhất định. DDR DRAM truyền thống cung cấp nhiều dung lượng hơn trên mỗi đô la nhưng băng thông lại quá kém.

Với việc AI là một tác vụ đòi hỏi khắt khe về bộ nhớ, không có gì ngạc nhiên khi dung lượng HBM trên mỗi bộ tăng tốc liên tục tăng qua từng thế hệ: nhiều khối hơn trên mỗi bộ tăng tốc, các khối dày đặc hơn và các chồng cao hơn.

Lượng HBM được vận chuyển trên mỗi chip ngày càng tăng cũng là một yếu tố đóng góp lớn vào việc tăng chi phí. Tuy nhiên, trong vài tháng qua, xu hướng này đã bị phá vỡ. Thế hệ Rubin Ultra tiếp theo sẽ chỉ có 192GB HBM trên mỗi bộ tăng tốc so với 288GB của Rubin truyền thống và thậm chí là Blackwell Ultra! Đây là một sự thụt lùi lớn so với những kỳ vọng chưa đầy một năm trước rằng Rubin Ultra sẽ có 1TB HBM trên mỗi GPU! Công bằng mà nói, đó là khi Rubin Ultra dự kiến có 4 die tính toán thay vì chỉ 2 như hiện nay. Ngay cả khi chuẩn hóa cho điều này, đây vẫn là mức giảm từ 256GB trên mỗi die GPU xuống chỉ còn 96GB.

Quyết định giảm mật độ HBM này phần lớn được thúc đẩy bởi nguồn cung. Các tấm wafer HBM rất khan hiếm. Đơn giản là không có đủ wafer để cung cấp số lượng khối 12-hi cần thiết nhằm hỗ trợ logic N3 và CoWoS mà Nvidia đã đảm bảo cho năm tới. Chuyển sang 8-hi đồng nghĩa với việc có nhiều khối hơn từ số lượng wafer hạn chế và giúp thu hẹp khoảng cách này.

Sự gia tăng lớn về chi phí HBM vào năm tới cũng không giúp ích gì, mặc dù Nvidia đang có được thỏa thuận tốt hơn so với các khách hàng lớn khác. Ngay cả trong thời điểm nhu cầu GPU vượt xa nguồn cung, Nvidia vẫn phải hy sinh một phần biên lợi nhuận khi chi phí linh kiện tăng lên, trong đó bộ nhớ là thành phần lớn nhất.

Xu hướng tăng mật độ HBM không ngừng hiện đã bị phá vỡ và không chỉ vì nguồn cung, mà còn vì các lý do kiến trúc và yêu cầu thay đổi của tác vụ. Mặc dù nguồn cung và chi phí là những yếu tố rất quan trọng, Nvidia sẽ không đưa ra quyết định này nếu dung lượng bổ sung đó là cần thiết cho khách hàng và mang lại hiệu suất/TCO tốt hơn rõ rệt. Trọng tâm của bài viết này là chứng minh rằng trong nhiều trường hợp, dung lượng HBM bổ sung trên mỗi GPU không xứng đáng với chi phí bỏ ra và HBM 4-hi trong tương lai thường là cấu hình tối ưu.

Một động lực quan trọng mà chúng tôi muốn nhắc nhở độc giả là việc giảm dung lượng trên mỗi GPU bằng cách giảm chiều cao chồng hoàn toàn không làm ảnh hưởng đến băng thông. Băng thông khả dụng trên mỗi khối HBM là như nhau bất kể chiều cao chồng. Trong số 2048 I/O dữ liệu trên mỗi khối HBM4 hoặc HBM4e, các đường dẫn dữ liệu này được chia đều cho tổng số die DRAM cốt lõi trong chồng. Tối đa trên mỗi die là 512 I/O, nghĩa là 4-hi là chiều cao chồng thấp nhất có thể truy cập vào tất cả 2048 I/O và tối đa hóa băng thông. Tuy nhiên, chi phí cho nhà cung cấp và khách hàng cuối được thúc đẩy chủ yếu bởi lượng nội dung DRAM trên mỗi khối. Giá HBM chủ yếu dựa trên GB trên mỗi chồng, trong khi giá trị mà khách hàng nhận được từ HBM thường là băng thông. Do đó, chiều cao chồng thấp hơn đồng nghĩa với đề xuất $/băng thông thấp hơn nhiều cho khách hàng cuối, nghĩa là việc chọn chiều cao chồng thấp hơn gần như là một lợi ích miễn phí.

Mặc dù các tác vụ AI khác nhau đòi hỏi cả dung lượng và băng thông, nhưng tùy thuộc vào tác vụ mà nhu cầu sẽ nghiêng về băng thông hay dung lượng. Chúng ta có thể chia tính toán AI thành 3 nhóm chính: tính toán tiền huấn luyện (pre-training), tính toán hậu huấn luyện/học tăng cường (post-training/reinforcement learning), và tính toán suy luận (inference). Học tăng cường rất giống với suy luận nên đòi hỏi các kiến trúc tương tự. Trong 3 nhóm này, giải mã suy luận (inference decode) chủ yếu bị giới hạn bởi băng thông: mỗi token được tạo ra đòi hỏi phải đọc tất cả các tham số mô hình đang hoạt động cũng như KVCache của người dùng được lưu trữ trong bộ nhớ. Học tăng cường (giống như suy luận) vẫn nghiêng về việc bị giới hạn bởi băng thông nhưng đòi hỏi nhiều dung lượng hơn suy luận do tập trung vào các lô (batches) lớn. Trong khi đó, tiền huấn luyện nhạy cảm với dung lượng hơn nhiều vì HBM được sử dụng để lưu trữ trọng số, gradient và kích hoạt trong quá trình huấn luyện, thay vì chỉ trọng số và KV của người dùng cho một lượt truyền suy luận.

Một thay đổi lớn là tỷ trọng tính toán dành cho tiền huấn luyện đã giảm đáng kể khi nhu cầu token cuối cùng tăng lên và các kỹ thuật hậu huấn luyện trở thành vectơ chính cho việc mở rộng mô hình. Kết quả là phần lớn tính toán được phân bổ hiện đã trở nên nhạy cảm với băng thông hơn là nhạy cảm với dung lượng.

Điều này không có nghĩa là dung lượng không liên quan đến suy luận, dung lượng quan trọng đến một mức độ nhất định. Một trong những điểm yếu lớn của các máy SRAM Cerebras và Groq là thiếu dung lượng mặc dù băng thông SRAM dồi dào cho phép phục vụ token rất nhanh. Tóm lại, có một ngưỡng dung lượng cần thiết: một hệ thống suy luận cần có đủ dung lượng bộ nhớ băng thông cao để chứa trọng số mô hình cũng như KVCache của người dùng. Vượt quá ngưỡng đó, việc có thêm dung lượng sẽ mang lại lợi ích giảm dần như chúng tôi sẽ chứng minh.

Một điểm quan trọng khác là đây không phải là bộ nhớ trên mỗi chip, mà là bộ nhớ tổng hợp trên mỗi hệ thống. Kích thước các mô hình tiên phong (frontier models) từ lâu đã không còn khả năng nằm gọn trong bộ nhớ của một chip đơn lẻ và cần được phân mảnh (sharded) trên bộ nhớ của nhiều chip. Đây là lý do tại sao mạng lưới (networking) là một phần không thể thiếu trong thiết kế hệ thống AI. Đối với kiến trúc MoE mà tất cả các mô hình tiên phong hiện nay áp dụng, hệ thống tối ưu thường là một thế giới mở rộng (scale up world) đơn lẻ với khả năng giao tiếp nhanh và độ trễ thấp (như NVLink trong toàn bộ rack) có thể hỗ trợ song song chuyên gia (expert parallelism) rộng rãi, nơi chỉ một vài chuyên gia được tải lên mỗi GPU. Thiết lập này cho phép mỗi chuyên gia xử lý các lô token lớn hơn và cải thiện hiệu suất sử dụng băng thông tính toán và bộ nhớ, với cái giá phải trả là chi phí giao tiếp all-to-all giữa các GPU cao hơn nhiều.

Trong khi cả yêu cầu về dung lượng trọng số mô hình và KVCache người dùng đều tăng, sự gia tăng khổng lồ về quy mô thế giới mở rộng đã cho phép bộ nhớ tổng hợp trên mỗi node theo kịp và vượt xa. Trong kỷ nguyên Hopper, một hệ thống H100 HGX cung cấp 640GB HBM tổng hợp. Các trọng số từ Llama 3.1 405B (mô hình nguồn mở tốt nhất vào thời điểm đó) sẽ tiêu thụ 63% dung lượng đó, để lại một ít (nhưng không nhiều) khoảng trống cho KVCache. Đây là lý do tại sao 61GB bổ sung trên mỗi GPU mà H200 cung cấp lại quan trọng đến vậy. Với 1.128GB bộ nhớ trên mỗi máy chủ, điều này cung cấp nhiều khoảng trống tăng thêm để chứa thêm KVCache và phục vụ nhiều người dùng đồng thời hơn.

Với các giải pháp quy mô rack GB300 NVL72, Nvidia đã cung cấp quy mô thế giới mở rộng gấp 9 lần, bên cạnh việc tăng gấp đôi HBM trên mỗi GPU bằng cách sử dụng HBM 12-hi và tăng số lượng khối HBM trên mỗi GPU. Điều này dẫn đến sự gia tăng gấp 18 lần dung lượng HBM tổng hợp so với H200 HGX. Con số này đã vượt xa mức tăng trưởng gần 7 lần về tham số của mô hình nguồn mở lớn nhất hiện nay: Kimi K3 2.8T. Gánh nặng dung lượng cũng giảm đáng kể nhờ việc lượng tử hóa xuống độ chính xác 4 bit từ 16/8 bit. Một bản sao của Kimi K3 2.8T được lưu trữ ở định dạng MXFP4 chỉ chiếm 1.561GB, chưa đến 8% trong tổng số gần 21TB HBM khả dụng trên GB300 NVL72. Sự gia tăng quy mô thế giới mở rộng cũng không hề chậm lại. Bản nâng cấp lớn với Rubin Ultra là chuyển sang NVL576, tăng thêm 8 lần so với NVL72, giúp bù đắp hơn mức giảm một phần ba dung lượng HBM trên mỗi GPU.

Trong kỷ nguyên máy chủ quy mô rack và xa hơn nữa, dung lượng bộ nhớ khả dụng cao hơn nhiều so với mức cần thiết cho trọng số mô hình, cung cấp một lượng khoảng trống rất thoải mái cho KVCache người dùng. Các hệ thống hiện có thể thoải mái hỗ trợ các yêu cầu suy luận với độ dài ngữ cảnh (context length) rất lớn và ở mức độ đồng thời đủ tốt để hỗ trợ biên lợi nhuận suy luận rất cao. Điều này làm giảm bớt nhiều áp lực về dung lượng HBM và cho phép mật độ HBM trên mỗi chip được nới lỏng. Đây là một mô hình khác biệt so với kỷ nguyên trước đây của các triển khai phục vụ nhỏ hơn, nơi trọng số mô hình tiêu thụ một phần đáng kể tổng bộ nhớ. Khi đó, việc tăng mật độ HBM trên mỗi GPU là một cách quan trọng để có được khoảng trống dung lượng quý giá.

Mặc dù lập luận về các chồng thấp hơn và băng thông rẻ hơn là một lập luận hợp lý, chúng ta chỉ mới thấy xu hướng các chồng cao hơn đảo ngược gần đây khi ngưỡng dung lượng HBM tối thiểu trên mỗi chip mới chỉ giảm xuống thấp hơn nhiều. Chúng tôi nghĩ rằng xu hướng này còn đi xa hơn nữa. Các đội ngũ silicon và phần cứng tại các phòng thí nghiệm tiên phong coi HBM 4-hi là SKU tối ưu cho nhiều tác vụ suy luận vì nó mang lại hiệu suất/TCO tốt nhất, và bây giờ chúng ta sẽ đi sâu hơn vào lý do tại sao.

Có một tỷ lệ tối ưu giữa băng thông và dung lượng, và thường thì dung lượng này cuối cùng bị cung cấp thừa hoặc lãng phí khi băng thông trên mỗi token không đủ để đọc tất cả dung lượng khả dụng trong HBM.

Hãy bắt đầu với một ví dụ đơn giản. Mỗi chồng HBM4E cung cấp 3.328 GB/s băng thông đỉnh danh nghĩa (giả sử 2048 chân ở tốc độ 13 Gbps mỗi chân). Đối với HBM4E, mỗi die cốt lõi là 32-Gb, dẫn đến 16 GB, 32 GB và 48 GB tương ứng cho các chồng 4-hi, 8-hi và 12-hi. Một chuỗi đơn minh họa gồm 100 token/s, 3.328/100 = 33,28GB băng thông bộ nhớ khả dụng trên mỗi token. Sau đó, chúng ta chia băng thông khả dụng trên mỗi token này cho dung lượng khối để có được số lần đọc tổng dung lượng chồng mà mỗi token có thể thực hiện. Ở mức 1 lần đọc chồng trên mỗi token, điều này có nghĩa là dung lượng và băng thông được khớp hoàn hảo: một token có băng thông khả dụng để đọc tất cả dữ liệu làm việc được lưu trữ trong HBM, không hơn không kém.

Một con số trên 1 có nghĩa là băng thông bị "cung cấp thừa" so với dung lượng, vì một token chỉ cần một lần đọc tập dữ liệu làm việc (tức là một lượt truyền xuôi). Tuy nhiên, băng thông hiếm khi là "dư thừa" vì ngân sách băng thông bổ sung có thể được sử dụng bằng cách tăng số token mỗi giây. Một con số dưới 1 có nghĩa là một token không có đủ băng thông khả dụng để đọc tất cả dung lượng HBM khả dụng. Để phục vụ các token ở thông lượng đó, tập dữ liệu làm việc không thể lớn hơn băng thông khả dụng trên mỗi token, vì vậy nó phải thấp hơn tổng dung lượng bộ nhớ. Điều này dẫn đến dung lượng bộ nhớ dư thừa bị cung cấp quá mức.

Như chúng ta có thể thấy trong bảng minh họa ở trên, việc tăng số token/s làm giảm băng thông khả dụng trên mỗi token, đẩy tỷ lệ đọc chồng/token xuống thấp hơn, do đó làm tăng khả năng dung lượng bị cung cấp thừa. Điều này tạo ra sự bất đối xứng khi việc có nhiều băng thông thường được ưu tiên hơn so với việc có nhiều dung lượng. Băng thông thường có thể được sử dụng hết hoàn toàn, trong khi dung lượng dư thừa không phải lúc nào cũng có thể được sử dụng hết trong khi vẫn phải chịu một chi phí ngày càng tăng.

Tất nhiên, đây là một phân tích đơn giản bỏ qua việc gom nhóm (batching) các yêu cầu để phục vụ nhiều người dùng đồng thời. Gom nhóm đóng vai trò quan trọng trong kinh tế học suy luận vì nó có thể tối đa hóa tổng thông lượng token ở các mức độ tương tác nhất định. Khoản tiết kiệm lớn từ việc gom nhóm đến từ việc phân bổ một lần đọc trọng số cho nhiều yêu cầu của người dùng. Mức độ đồng thời cao hơn cũng tiêu thụ dung lượng bộ nhớ vì KVCache của mỗi người dùng cá nhân cần được tải vào bộ nhớ. Tăng kích thước lô thường là cách các tác vụ suy luận trở nên bị giới hạn bởi dung lượng bộ nhớ thay vì bị giới hạn bởi băng thông. Khi dung lượng HBM đủ để chứa trọng số mô hình, lợi ích của việc có thêm dung lượng HBM là nó có thể mang lại thông lượng token cao hơn, và đó là lý do tại sao các bit bổ sung có thể xứng đáng với chi phí BOM.

Khi tính đến việc gom nhóm, kết quả là đường cong tổng quát ở trên. Nếu các yếu tố khác không đổi, việc có các chồng HBM cao hơn mang lại thông lượng cao hơn cho đến một mức SLA độ trễ trên mỗi người dùng nhất định, tại đó dung lượng bổ sung trở nên dư thừa. Những điểm này được thể hiện bằng các điểm nơi các đường cong khác nhau chồng lên nhau.

"SLA độ trễ trên mỗi người dùng" là một giả định về mức độ tương tác tối thiểu. Đây là mức tối thiểu thay vì mức tương tác thực tế. Trong các trường hợp mức độ đồng thời bị giới hạn bởi dung lượng, điều đó có nghĩa là có thêm băng thông khả dụng để hỗ trợ số token/s/người dùng cao hơn. Vì vậy, ngay cả khi 4-hi có thể mang lại mức độ đồng thời thấp hơn, số token/s/người dùng nhanh hơn sẽ bù đắp toàn bộ hoặc một phần tác động của kích thước lô thấp hơn để tăng tổng thông lượng token.

Mức độ đồng thời dựa trên mức thấp hơn giữa: mức độ đồng thời tối đa khi bị giới hạn bởi dung lượng (số lượng bộ KVCache của người dùng cá nhân có thể vừa với bộ nhớ); và khi bị giới hạn bởi băng thông (số lượng người dùng tối đa có thể được phục vụ ở mức tương tác tối thiểu của chúng ta, có tính đến tính toán băng thông khả dụng trên mỗi token ở trên). Nhân số người dùng với số token/s/người dùng sẽ ra tổng số token được tạo mỗi giây, đó chính là thông lượng.

Những đường cong này có thể cho chúng ta biết giá trị mà dung lượng bổ sung mang lại về mặt hiệu suất suy luận bằng cách cho thấy thông lượng token lớn hơn bao nhiêu có thể đạt được với nhiều dung lượng hơn (thông qua việc gom nhóm nhiều hơn), đồng thời cho thấy tại các điểm tương tác tối thiểu nào thì dung lượng bổ sung không mang lại giá trị.

Điều này phụ thuộc rất nhiều vào kích thước mô hình, hay nói cách khác là % dung lượng HBM cần dành cho trọng số mô hình. Nhìn chung, kích thước mô hình càng lớn, các đường cong sẽ dịch chuyển sang phải để các chồng cao hơn mang lại nhiều thông lượng hơn tại các điểm tương tác cao hơn. Ngoài ra, các chồng cao hơn cũng sẽ mang lại sự gia tăng lớn hơn về thông lượng đỉnh. Điều này quay trở lại với kinh tế học gom nhóm. Mỗi bước đọc trọng số một lần bất kể kích thước lô, vì vậy dấu chân trọng số càng lớn, mỗi người dùng đồng thời bổ sung càng mở khóa được nhiều thông lượng hơn.

Hãy đưa các con số thực tế vào đây để xem điều này trông như thế nào đối với mô hình nguồn mở lớn nhất hiện nay: Kimi K3. Đây là phân tích roofline, trên thực tế, băng thông bộ nhớ đạt được thực tế thấp hơn đáng kể so với băng thông đỉnh. Kết quả thực tế sẽ thấy các ngưỡng tương tác tối thiểu dịch chuyển sang trái, vì vậy các kết luận chung sẽ giống nhau. Ngoài ra, bài tập này chỉ tập trung vào nhóm giải mã (decode pool) trong thiết lập PD phân tách. Để biết kết quả thực tế, hãy xem các điểm chuẩn InferenceX và AgentX của chúng tôi.

Chúng tôi sử dụng hệ thống Rubin Ultra NVL576 vì đây sẽ là quy mô thế giới mở rộng đại diện hơn trong kỷ nguyên HBM4E. Chúng tôi giả định HBM là HBM4E với tốc độ 13Gbps. 4-hi, 8-hi và 12-hi có nghĩa là 128GB, 256GB và 384GB trên mỗi GPU tương ứng. Đối với Kimi K3 trên hệ thống NVL576 này, mỗi GPU chứa 16,8GB trọng số, tương đương 2,1GB trên mỗi chồng HBM. Chúng ta có thể thấy rằng ở mức SLA tối thiểu là 105 tok/s/người dùng, HBM 12-hi không mang lại thông lượng cao hơn HBM 8-hi. Sau đó, khi mức độ tương tác được tăng gấp đôi lên 213 tok/s/người dùng, việc có các chồng cao hơn 4-hi không mang lại lợi ích gì. Về lợi ích thông lượng tối đa, 8-hi mang lại mức tăng 8% về tổng số token/s tối đa so với 4-hi, trong khi 12-hi mang lại mức cải thiện 10%. Tuy nhiên, một lần nữa, việc giảm xuống mức thông lượng tối đa mà 4-hi có thể mang lại cho phép mức độ tương tác cao hơn gấp đôi. Chúng tôi cũng nhắc lại rằng trên thực tế, vì không phải tất cả băng thông bộ nhớ thô đều có thể được sử dụng, kết quả thực tế sẽ dịch chuyển các đường cong này sang trái, nghĩa là các điểm hòa vốn dung lượng cao hơn sẽ thấp hơn và có thể đẩy vào các tốc độ mà người dùng thấy thấp đến mức không thể chấp nhận được.

Chúng ta có thể thấy rằng mặc dù nhiều dung lượng hơn có thể mang lại thông lượng token cao hơn một chút cho các mô hình này (bỏ qua lợi ích của token nhanh hơn). Câu hỏi đặt ra là liệu thông lượng bổ sung đó có xứng đáng với chi phí BOM bổ sung liên quan đến bộ nhớ nhiều hơn hay không. HBM là một phần đáng kể trong chi phí BOM của bộ tăng tốc, và với việc HBM khan hiếm như vậy, chi phí trên mỗi GB sẽ tăng mạnh vào năm tới.

Khi tính đến chi phí, chúng tôi mô hình hóa mức tăng chi phí BOM mà chủ sở hữu cuối cùng phải trả so với hệ thống Rubin Ultra dựa trên HBM4E 4-hi cơ bản cho hệ thống Rubin Ultra NVL576. Mức tăng chi phí hệ thống tổng thể (mà chúng tôi coi là TCO vì chi phí hệ thống tổng thể chiếm phần lớn TCO) của 8-Hi là 12,1% so với hệ thống 4-hi cơ bản và đối với 12-hi, mức phí bảo hiểm trở thành 26,3%. Sau đó, chúng ta có thể so sánh mức tăng thông lượng token so với mức tăng chi phí tại các điểm khác nhau trên mức tương tác tối thiểu để cho thấy liệu nhiều bộ nhớ hơn có thể mang lại chi phí trên mỗi token thấp hơn tại bất kỳ điểm nào trong số đó hay không.

Nhìn chung, chúng tôi thấy rằng mức tăng thông lượng do HBM 12-hi hoặc 8-hi mang lại thấp hơn chi phí hệ thống tăng thêm liên quan đến bộ nhớ nhiều hơn, nghĩa là ở mức giá bộ nhớ này (cùng với cấu trúc biên lợi nhuận của Nvidia), HBM 12-Hi và 8-Hi dẫn đến chi phí trên mỗi token cao hơn so với HBM 4-hi. Điều này xảy ra trước khi chúng ta tính đến các kỹ thuật tiết kiệm HBM hơn, cụ thể là giảm tải KVCache xuống các tầng bộ nhớ thấp hơn. Phần tiếp theo này sẽ cho thấy một quá trình sản xuất thực tế mà chúng tôi đã thực hiện để cho thấy bộ nhớ thấp hơn ảnh hưởng như thế nào đến thông lượng thực tế.