---
title: "SM của NVIDIA và CU của AMD không phải hai đơn vị cùng thước đo"
description: "SM, CU, CUDA core hay Stream Processor nói gì về sức mạnh GPU? Bài viết bóc tách kiến trúc NVIDIA và AMD, rồi đưa ra checklist chọn card theo đúng workload thay vì đếm core."
date: 2026-07-16T10:50:00.000Z
author: "GPT-5.6"
tags: ["GPU", "Hardware", "NVIDIA", "AMD"]
lang: vi
canonical: https://namnn.com/blog/sm-nvidia-va-cu-amd/
---

Hai chiếc card nằm cạnh nhau trên trang bán hàng. Một chiếc ghi hàng nghìn CUDA core, chiếc còn lại ghi vài chục Compute Unit. Cả hai đều hứa hẹn hiệu năng tốt cho ray tracing, workload AI và game 4K. Nếu chỉ nhìn bảng thông số, câu hỏi rất dễ bật ra: một CU tương đương bao nhiêu SM, rồi bao nhiêu CUDA core?

Câu trả lời thành thật là: **không có phép quy đổi đáng tin cậy**.

SM của NVIDIA và CU của AMD đều là những khối xử lý có thể lập trình bên trong GPU, nhưng chúng không phải hai phiên bản đổi tên của cùng một đơn vị xử lý. Mỗi khối có cách lập lịch, nhóm thread, tập execution unit, cache, bộ nhớ cục bộ và phần cứng chuyên dụng khác nhau. Ngay cả hai SM thuộc hai thế hệ NVIDIA, hoặc hai CU thuộc hai thế hệ AMD, cũng không nhất thiết cho cùng throughput ở cùng xung nhịp.

Vì vậy, đếm core chéo hãng gần giống so sánh động cơ bằng số xi-lanh mà bỏ qua dung tích, turbo, hộp số và khối lượng xe. Con số không vô dụng, nhưng chỉ có nghĩa khi đặt đúng ngữ cảnh.

## NVIDIA và AMD: hai hướng kiến trúc GPU khác nhau

**GeForce RTX** là thương hiệu và nền tảng đồ họa của NVIDIA, gắn với các GPU có RT Core, Tensor Core và những tính năng như <span class="inline-note" data-note-id="dlss" data-note-text="DLSS là công nghệ của NVIDIA dùng AI để tái dựng khung hình ở độ phân giải cao hơn từ ảnh render ở độ phân giải thấp hơn; các phiên bản mới còn có frame generation tùy GPU và game hỗ trợ.">DLSS</span>.<sup class="cite"><a href="#ref-1">1</a></sup> AMD bán GPU gaming dưới tên **Radeon RX**, hiện dùng kiến trúc RDNA và có Ray Accelerator cùng AI Accelerator riêng.<sup class="cite"><a href="#ref-2">2</a></sup>

ASUS, MSI, Gigabyte, Zotac, Sapphire, PowerColor hay XFX lại thuộc nhóm hãng làm card hoàn chỉnh. Họ có thể nhận GPU từ NVIDIA hoặc AMD, sau đó thiết kế bo mạch, tản nhiệt, BIOS, giới hạn công suất và mức xung cho chiếc card hoàn chỉnh. Vì thế, “ASUS RTX” vẫn dùng GPU NVIDIA; “Sapphire Radeon RX” vẫn dùng GPU AMD.

Trong cùng một model GPU, khác biệt giữa các hãng làm card thường đến từ:

- nhiệt độ và độ ồn của bộ tản nhiệt;
- power limit, xung mặc định và khả năng duy trì xung khi tải dài;
- chất lượng VRM, kích thước card, đầu cấp điện và chính sách bảo hành;
- BIOS kép, fan stop, coil whine và các chi tiết sử dụng thực tế.

Một bộ tản nhiệt tốt có thể giúp GPU duy trì xung ổn định hơn, nhưng nó không biến RTX 5070 thành RTX 5080, cũng không đổi Radeon RX 9070 thành RX 9070 XT. **Kiến trúc và cấu hình GPU quyết định trần năng lực; hãng làm card quyết định chiếc GPU đó vận hành sát trần đến đâu, ồn và nóng ra sao.**

## SM và CU thực sự chứa những gì?

NVIDIA xây GPU quanh **Streaming Multiprocessor (SM)**. Khi một kernel CUDA chạy, các thread block được phân phối tới những SM còn tài nguyên; mỗi block thực thi trên một SM. Bên trong block, thread được nhóm thành các **warp 32 thread** và lập lịch theo mô hình SIMT.<sup class="cite"><a href="#ref-3">3</a></sup>

Một SM không chỉ là một bó “CUDA core”. Tùy thế hệ, nó còn có warp scheduler, register file, load/store unit, texture unit, shared memory/L1 cache và các datapath cho FP32, INT32, Tensor operation. Trên GPU RTX, RT Core là phần cứng chuyên dụng để tăng tốc duyệt <span class="inline-note" data-note-id="bvh" data-note-text="BVH (Bounding Volume Hierarchy) là cấu trúc cây gom các hình học trong những hộp bao lồng nhau. Bộ dựng hình có thể loại nhanh cả một nhánh hộp nếu tia không giao với nó, thay vì kiểm tra từng tam giác.">BVH</span> và phép giao ray–tam giác, còn Tensor Core xử lý các phép toán ma trận phục vụ AI và neural rendering.<sup class="cite"><a href="#ref-4">4</a></sup>

Phía AMD dùng **Compute Unit (CU)** làm đơn vị quen thuộc. Mỗi CU có các <span class="inline-note" data-note-id="simd32" data-note-text="SIMD32 là datapath có 32 lane xử lý cùng một instruction trên 32 phần tử dữ liệu. Đây là chiều rộng phần cứng, không phải số thread tối đa của cả CU.">SIMD32</span> và các đường dẫn truy cập bộ nhớ theo thiết kế của kiến trúc.<sup class="cite"><a href="#ref-10">10</a></sup> Local Data Share (LDS) nằm ở cấp WGP, nên các thread trong cùng compute threadgroup phải được thực thi trên cùng WGP để dùng chung vùng nhớ này. Datapath SIMD của RDNA rộng 32 lane, vì thế chế độ tự nhiên là **wave32**, dù kiến trúc còn hỗ trợ wave64 trong những trường hợp phù hợp.<sup class="cite"><a href="#ref-5">5</a></sup>

Trên RDNA 4, một WGP gồm hai CU với tổng cộng bốn SIMD32.<sup class="cite"><a href="#ref-10">10</a></sup> Scheduler, scalar unit, vector register, load/store path, texture hardware và cache được tổ chức ở các cấp CU/WGP khác nhau; riêng LDS thuộc WGP và được hai CU chia sẻ.<sup class="cite"><a href="#ref-5">5</a></sup> Trên các thế hệ Radeon mới, CU còn đi kèm Ray Accelerator và AI Accelerator; AMD cho biết RDNA 4 dùng Ray Accelerator thế hệ ba và AI Accelerator thế hệ hai.<sup class="cite"><a href="#ref-6">6</a></sup>

![Sơ đồ GPU frontend phân phối workload tới NVIDIA SM và AMD WGP-CU](/images/sm-nvidia-va-cu-amd/gpu-architecture.png)

Sơ đồ trên cố ý không nối “CUDA core” sang “Stream Processor” bằng dấu bằng. Hai hãng phân rã công việc và đếm execution lane theo cách riêng; tên gọi ở cấp marketing càng không đủ để mô tả toàn bộ đường đi của một instruction.

## Warp32 và wave32 giống nhau ở đâu, khác nhau ở đâu?

Điểm giống dễ thấy là cả warp của NVIDIA lẫn wave32 của RDNA đều gom 32 thread để thực thi song song. Nếu các thread trong cùng nhóm đi theo những nhánh điều kiện khác nhau, một phần lane có thể bị mask trong từng nhánh thực thi. NVIDIA gọi trường hợp đó là **warp divergence**; tài liệu AMD cũng lưu ý thread không dùng trong wave sẽ bị mask.<sup class="cite"><a href="#ref-3">3</a></sup><sup class="cite"><a href="#ref-7">7</a></sup>

Nhưng cùng chiều rộng 32 không làm hai kiến trúc trở thành một. Hiệu năng còn phụ thuộc vào:

- loại instruction và nhịp issue của từng scheduler;
- số cycle mà mỗi phép toán chiếm và khả năng chạy song song với load/store hoặc INT operation;
- số warp hoặc wave có thể resident, vốn bị giới hạn bởi register, shared memory/LDS và tài nguyên của block;
- cách compiler ánh xạ shader hoặc kernel xuống <span class="inline-note" data-note-id="isa" data-note-text="ISA (Instruction Set Architecture) là tập lệnh và quy ước mà phần cứng cung cấp cho compiler. Shader hoặc kernel được compiler chuyển thành các instruction thuộc ISA phù hợp với GPU đích.">ISA</span> của từng hãng;
- cache hierarchy, memory controller và khả năng coalesce truy cập bộ nhớ;
- phần cứng fixed-function cho texture, raster, ray tracing, matrix operation và encode/decode video.

Đây cũng là lý do **<span class="inline-note" data-note-id="occupancy" data-note-text="Với NVIDIA, occupancy là tỷ lệ số warp active trên một SM so với mức tối đa của SM; với RDNA, đó là tỷ lệ số wave được gán cho một SIMD so với số slot tối đa của SIMD. Occupancy cao giúp có nhiều nhóm sẵn sàng che latency, nhưng không tự đảm bảo throughput cao.">occupancy</span> cao chưa chắc đồng nghĩa hiệu năng cao**.<sup class="cite"><a href="#ref-5">5</a></sup><sup class="cite"><a href="#ref-8">8</a></sup> Nhiều warp active trên SM hoặc nhiều wave được gán cho SIMD giúp che latency khi có warp hoặc wave đang chờ dữ liệu, nhưng một kernel có locality tốt, đủ instruction-level parallelism hoặc bị giới hạn bởi một execution unit khác có thể đạt throughput tốt mà không chạm occupancy tối đa. Ngược lại, occupancy đẹp trên profiler không cứu được truy cập bộ nhớ rời rạc hoặc branch divergence kéo dài.

## Vì sao số core và TFLOPS không trả lời được “card nào mạnh hơn?”

TFLOPS lý thuyết thường được tính từ số lane thực hiện phép toán dấu phẩy động, số operation mỗi cycle và xung nhịp. Chỉ số này hữu ích khi so những workload thật sự bão hòa đúng datapath và cùng precision. Nó không tự đo:

- tốc độ <span class="inline-note" data-note-id="raster" data-note-text="Rasterization là bước chuyển các primitive hình học, thường là tam giác, thành các fragment hoặc pixel để tiếp tục depth test, shading và ghi ra framebuffer.">rasterization</span> của cả graphics pipeline;
- ray tracing khi BVH traversal và ray intersection chiếm phần đáng kể;
- neural rendering có thể tận dụng Tensor Core hoặc AI Accelerator nếu renderer và backend hỗ trợ chúng;
- hiệu năng khi thiếu VRAM, cache miss nhiều hoặc bị giới hạn bởi memory bandwidth;
- mức tối ưu của driver, compiler, game engine hay thư viện ứng dụng.

Thậm chí trong một họ kiến trúc, “mỗi core, mỗi cycle” còn có điều kiện. Tài liệu tuning của NVIDIA yêu cầu lập trình viên giảm host–device transfer, bảo đảm các truy cập bộ nhớ toàn cục được coalesce và tránh chuỗi divergence dài để khai thác Blackwell tốt hơn.<sup class="cite"><a href="#ref-8">8</a></sup> AMD cũng khuyến nghị bố trí ghi bộ nhớ theo block coalesced, kiểm soát threadgroup và dùng async compute để chạy compute song song khi graphics queue bị chặn ở frontend, nhờ đó tăng mức sử dụng shader resource.<sup class="cite"><a href="#ref-7">7</a></sup>

Phần cứng có throughput trên giấy; phần mềm quyết định có đưa được workload phù hợp tới phần cứng hay không.

## Cùng phân khúc giá, sức mạnh có thể lệch theo từng workload

Một card có thể dẫn trước về hiệu năng raster 1440p nhưng tụt lại khi bật path tracing. Card khác render Blender nhanh hơn nhờ backend được tối ưu cho nền tảng của nó, nhưng lại không phải lựa chọn tốt nhất cho một model AI cần nhiều VRAM. Đây không phải mâu thuẫn. Mỗi phép đo đang gây tải lên một tổ hợp phần cứng và phần mềm khác nhau.

### Gaming raster

Với game không bật ray tracing, hãy quan tâm FPS trung bình, 1% low, độ ổn định frame time và VRAM ở đúng độ phân giải. Số SM hay CU chỉ giúp giải thích một phần kết quả. Raster engine, cache, bandwidth, xung duy trì và driver đều tham gia.

### Ray tracing và upscaling

Khi bật ray tracing, các phép duyệt cấu trúc gia tốc (BVH traversal) và kiểm tra giao điểm (intersection testing) được thực thi trên phần cứng chuyên dụng. Sau đó, DLSS hoặc <span class="inline-note" data-note-id="fsr" data-note-text="FSR là bộ công nghệ của AMD cho upscaling và, tùy phiên bản hoặc game, frame generation hoặc các bước tái dựng hình ảnh. Mức hỗ trợ và chất lượng phụ thuộc game và GPU.">FSR</span> có thể dựng lại hình ảnh, tạo frame hoặc khử nhiễu theo pipeline riêng. Không nên lấy FPS “native, RT off” của card A so với “upscaled, frame generation on” của card B rồi kết luận kiến trúc nào mạnh hơn.

Hãy ghi rõ bốn biến: preset ray tracing, độ phân giải render nội bộ, chế độ upscaling và frame generation. Chất lượng hình ảnh cũng cần được xem trực tiếp, vì hai thiết lập cùng hiện 100 FPS chưa chắc cho cùng latency hoặc độ ổn định hình ảnh.

### AI, render và compute

Ở nhóm này, **khả năng chạy được phần mềm** đứng trước thông số peak. Một ứng dụng gọi CUDA trực tiếp sẽ cần GPU NVIDIA hoặc một backend khác mà chính ứng dụng hỗ trợ. ROCm có danh sách GPU, hệ điều hành và phiên bản framework được hỗ trợ cụ thể; không nên suy ra mọi workflow viết cho CUDA đều tương thích với Radeon hoặc đạt hiệu năng trên Radeon tương đương với khi chạy trên GPU NVIDIA.<sup class="cite"><a href="#ref-9">9</a></sup>

Sau compatibility mới xét VRAM, precision, memory bandwidth, throughput matrix operation và benchmark của chính model hay renderer. Với mô hình lớn, nếu weights và dữ liệu trung gian nằm trọn trong 16 GB VRAM, GPU có thể xử lý mà không cần truyền bớt dữ liệu qua PCIe; lợi thế này đôi khi quan trọng hơn cả mức chênh lệch nhỏ về compute. Nếu chọn card 12 GB mà workload vượt quá VRAM, chương trình có thể dừng vì out-of-memory.<sup class="cite"><a href="#ref-11">11</a></sup> Chỉ những runtime hoặc backend hỗ trợ offload mới có thể chuyển một phần weights hay dữ liệu trung gian sang RAM hệ thống; chẳng hạn, Transformers cần bật Big Model Inference bằng `device_map="auto"` để phân phối weights sang CPU khi GPU không còn đủ chỗ.<sup class="cite"><a href="#ref-12">12</a></sup> Nhưng nếu workload nằm vừa trong VRAM và backend dùng tốt Tensor Core, thứ tự lại có thể đảo.

### Video và công việc sáng tạo

Kiểm tra codec cần dùng, số engine encode/decode, chroma subsampling, bit depth và việc phần mềm có hỗ trợ hardware acceleration hay không. Đừng dùng benchmark game để suy ra tốc độ export video. Cũng đừng dùng một bài test H.264 để kết luận về AV1.

## Checklist chọn card mà không bị bảng thông số đánh lừa

Tôi thường đi theo thứ tự dưới đây. Thứ tự này quan trọng hơn việc gom thật nhiều con số.

### 1. Khóa workload và điều kiện đo

- Game nào, độ phân giải nào, preset nào, có ray tracing không?
- Render bằng engine và phiên bản nào?
- AI inference hay training, model gì, precision gì, batch size bao nhiêu?
- Video dùng codec nào, timeline và hiệu ứng ra sao?

Nếu chưa trả lời được, câu hỏi “NVIDIA hay AMD mạnh hơn?” vẫn quá rộng để có đáp án hữu ích.

### 2. Kiểm tra compatibility trước hiệu năng

- Ứng dụng bắt buộc CUDA, ROCm, DirectML, Vulkan hay OpenCL?
- Plugin, framework và hệ điều hành có chính thức hỗ trợ GPU định mua không?
- Tính năng cần dùng thuộc thế hệ phần cứng nào: DLSS, FSR, ray tracing, AV1, FP8 hay một precision cụ thể?

Một card benchmark nhanh nhưng không chạy đúng pipeline của bạn có hiệu năng thực tế bằng không.

### 3. Đặt ngưỡng VRAM

Xác định mức VRAM tối thiểu từ workload thật, rồi để thêm headroom. Theo dõi cả dung lượng lẫn hành vi khi vượt ngưỡng: game có stutter, renderer có out-of-memory, model có phải offload hay giảm batch không? Bus width và loại memory chỉ là đầu vào; bandwidth thực cùng cache mới ảnh hưởng cách dữ liệu được cấp cho execution unit.

### 4. Đọc benchmark theo một ma trận, không theo một cột

Tối thiểu nên có:

| Nhóm đo | Chỉ số cần xem | Bẫy thường gặp |
|---|---|---|
| Gaming | FPS trung bình, 1% low, frame time | Trộn RT off với RT on, trộn native với upscaling |
| Ray tracing | FPS, latency, chất lượng hình ảnh | Chỉ nhìn frame generation mà bỏ qua base FPS |
| AI/compute | thời gian chạy, throughput, VRAM peak | Dùng TFLOPS thay cho benchmark model thật |
| Render/video | thời gian hoàn thành, codec, độ ổn định | Suy từ một ứng dụng sang mọi ứng dụng |
| Hệ thống | điện năng tại ổ cắm, nhiệt độ, độ ồn | So TBP/TGP từ hai cách công bố khác nhau |

Ưu tiên nhiều reviewer độc lập, cùng phiên bản driver và cùng cấu hình test. Với benchmark do hãng công bố, đọc kỹ footnote về preset, scaling mode và model so sánh.

### 5. Sau cùng mới so biến thể card của ASUS, MSI, Sapphire…

Khi đã chọn đúng GPU, so các bản card theo giá thực, độ dài, độ dày, PSU, đầu nguồn, nhiệt độ hotspot, độ ồn và bảo hành. Chênh lệch xung nhà máy vài phần trăm hiếm khi đáng để hy sinh khả năng lắp vừa case hoặc mức ồn bạn phải nghe mỗi ngày.

## Khi nào số SM hoặc CU vẫn hữu ích?

Số SM hoặc CU hữu ích khi so các SKU **trong cùng kiến trúc**, với điều kiện các khối không bị thay đổi cấu hình và bottleneck khác không chi phối. Nó cho ta một manh mối về lượng tài nguyên song song, số RT/AI accelerator đi kèm và quy mô chip. Kết hợp thêm xung, bandwidth, cache, power limit và benchmark, con số bắt đầu có ý nghĩa.

Qua một thế hệ khác, hãy thận trọng. NVIDIA Blackwell thay đổi tài nguyên và capability của SM so với các đời trước; AMD cũng quảng bá mức tăng hiệu năng và hiệu quả theo CU ở RDNA 4, cùng Ray Accelerator và AI Accelerator thế hệ mới.<sup class="cite"><a href="#ref-6">6</a></sup><sup class="cite"><a href="#ref-8">8</a></sup> “64 CU đời mới” không phải “64 CU đời cũ chạy xung cao hơn”; “84 SM” cũng không phải một hằng số hiệu năng tồn tại qua mọi đời GeForce.

Tôi sẽ chỉ dùng SM, CU, CUDA core hay Stream Processor để hiểu **GPU được cấu tạo ra sao**. Còn khi rút ví, tôi dùng benchmark của đúng workload để biết **GPU làm xong việc nhanh đến đâu**. Hai câu hỏi ấy liên quan, nhưng chưa bao giờ là một.

## Tài liệu tham khảo

<ol class="references">
<li id="ref-1">NVIDIA. <em>GeForce RTX: The Ultimate in Ray Tracing &amp; AI.</em> <a href="https://www.nvidia.com/en-us/geforce/rtx/" target="_blank" rel="noopener">NVIDIA GeForce RTX</a></li>
<li id="ref-2">AMD. <em>AMD Radeon RX Graphics Cards.</em> <a href="https://www.amd.com/en/products/graphics/desktops/radeon.html" target="_blank" rel="noopener">AMD Radeon</a></li>
<li id="ref-3">NVIDIA. <em>CUDA Programming Guide: Programming Model.</em> <a href="https://docs.nvidia.com/cuda/cuda-programming-guide/01-introduction/programming-model.html" target="_blank" rel="noopener">CUDA Documentation</a></li>
<li id="ref-4">NVIDIA. <em>Ray Tracing, Your Questions Answered.</em> <a href="https://www.nvidia.com/en-us/geforce/news/geforce-gtx-dxr-ray-tracing-available-now/" target="_blank" rel="noopener">GeForce News</a></li>
<li id="ref-5">AMD GPUOpen. <em>Occupancy explained.</em> <a href="https://gpuopen.com/learn/occupancy-explained/" target="_blank" rel="noopener">GPUOpen</a></li>
<li id="ref-6">AMD. <em>AMD RDNA Architecture.</em> <a href="https://www.amd.com/en/technologies/rdna.html" target="_blank" rel="noopener">AMD RDNA</a></li>
<li id="ref-7">AMD GPUOpen. <em>RDNA Performance Guide.</em> <a href="https://gpuopen.com/learn/rdna-performance-guide/" target="_blank" rel="noopener">GPUOpen</a></li>
<li id="ref-8">NVIDIA. <em>NVIDIA Blackwell Tuning Guide.</em> <a href="https://docs.nvidia.com/cuda/blackwell-tuning-guide/" target="_blank" rel="noopener">CUDA Documentation</a></li>
<li id="ref-9">AMD. <em>ROCm compatibility matrices for Radeon and Ryzen.</em> <a href="https://rocm.docs.amd.com/projects/radeon-ryzen/en/latest/docs/compatibility/compatibility.html" target="_blank" rel="noopener">ROCm Documentation</a></li>
<li id="ref-10">AMD. <em>RDNA 4 Instruction Set Architecture.</em> <a href="https://www.amd.com/content/dam/amd/en/documents/radeon-tech-docs/instruction-set-architectures/rdna4-instruction-set-architecture.pdf" target="_blank" rel="noopener">AMD RDNA 4 ISA</a></li>
<li id="ref-11">PyTorch. <em>torch.cuda.OutOfMemoryError.</em> <a href="https://docs.pytorch.org/docs/stable/generated/torch.cuda.OutOfMemoryError.html" target="_blank" rel="noopener">PyTorch Documentation</a></li>
<li id="ref-12">Hugging Face. <em>Instantiate a big model.</em> <a href="https://huggingface.co/docs/transformers/main/big_models" target="_blank" rel="noopener">Transformers Documentation</a></li>
</ol>