Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Hạ tầng & Đám mây
#GPU가상화#MIG#vGPU#MPS#타임슬라이싱
Cập nhật lần cuối · 2026-10-14

Ảo hóa và các kỹ thuật chia sẻ GPU (vGPU, MIG, MPS, Time-Slicing)

1. Khái quát

Ảo hóa GPU (GPU Virtualization) là tên gọi chung cho các kỹ thuật trừu tượng hóa một GPU vật lý sao cho nhiều máy ảo, container hoặc tiến trình có thể chia sẻ nó một cách an toàn, hoặc ngược lại gom nhiều GPU thành một tài nguyên logic duy nhất. Theo nghĩa hẹp, nó chỉ các kỹ thuật phân chia cho phép nhiều người dùng chia sẻ (sharing) một GPU, được hiện thực theo ba trục: phân chia thời gian (temporal), phân chia không gian (spatial) và phân chia phần cứng (hardware partition).

Ảo hóa GPU nổi lên vì khoảng cách mang tính cấu trúc giữa nhu cầu bộ tăng tốc và hiệu quả sử dụng tài nguyên. Khi nhu cầu về AI tạo sinh, huấn luyện học sâu, suy luận và HPC bùng nổ, GPU trở thành tài nguyên đắt nhất và khan hiếm nguồn cung nhất trong trung tâm dữ liệu. Giá mua một chiếc NVIDIA H100 lên tới hàng chục nghìn USD, và khi cộng thêm chi phí điện và làm mát, ngay cả 1% công suất nhàn rỗi cũng chuyển ngay thành chi phí. Thế nhưng trên thực tế, hiếm khi một tải công việc đơn lẻ lấp đầy GPU đến 100%. Các tải như dịch vụ suy luận tương tác, phân tích dữ liệu dựa trên notebook, các lần kiểm thử quy mô nhỏ trong pipeline CI thường chỉ dùng 10–30% đơn vị tính toán (SM) và bộ nhớ của GPU, để phần còn lại nhàn rỗi. Lấp đầy khoảng trống "hiệu suất thấp của một tài nguyên đắt tiền" này là lý do tồn tại hàng đầu của kỹ thuật chia sẻ GPU.

Động lực thứ hai là yêu cầu về đa người thuê (multi-tenancy) và cô lập. Trong đám mây công cộng hay cụm dùng chung nội bộ, các nhóm hoặc khách hàng khác nhau chia nhau cùng một GPU, nhưng công việc của một người thuê không được dòm ngó bộ nhớ của người thuê khác hay làm xói mòn hiệu năng của họ. Nói cách khác, sự cô lập cho phép "chia sẻ nhưng không can thiệp lẫn nhau" là tiền đề. Các kỹ thuật ảo hóa GPU phân nhánh chính xác ở chỗ chúng thỏa hiệp tại điểm nào giữa hai mục tiêu xung đột là hiệu suất sử dụng (utilization) và cô lập (isolation). Chúng tạo thành một phổ trải từ time-slicing, vốn gần như từ bỏ cô lập để đuổi theo hiệu suất, cho đến MIG, vốn cô lập hoàn toàn ở mức phần cứng nhưng cố định độ hạt phân chia.

Động lực thứ ba là sự bất đối xứng với ảo hóa CPU. Ảo hóa CPU đã trưởng thành qua hàng chục năm nên hypervisor có thể tự do phân chia và overcommit lõi và bộ nhớ, nhưng GPU là thiết bị đặc thù với hàng nghìn lõi (SM), bộ nhớ chuyên dụng và bộ lập lịch riêng, nên hypervisor đa dụng không thể xử lý trực tiếp. Do đó các nhà cung cấp GPU đã cung cấp phương tiện ảo hóa chuyên dụng ở tầng driver, firmware và phần cứng, và thành quả là time-slicing, MPS, MIG và vGPU bàn đến dưới đây.

Khoảng cách này quy đổi thành chi phí bao nhiêu có thể thấy rõ bằng phép tính đơn giản. Chẳng hạn nếu một node GPU tiêu tốn tổng cộng cả mua lẫn vận hành khoảng 40.000 USD mỗi năm mà dừng ở hiệu suất trung bình 20%, thì thực chất khoảng 32.000 USD giá trị tính toán mỗi năm bị ném vào hư không. Nếu chia cùng node đó cho bốn công việc bằng kỹ thuật chia sẻ để nâng hiệu suất trung bình lên 70%, lượng tính toán khả dụng tăng 3,5 lần mà không cần đầu tư phần cứng bổ sung. Trong các cụm AI quy mô hàng trăm đến hàng nghìn GPU, khoảng cách hiệu suất này dẫn đến chênh lệch chi phí vốn và vận hành lên tới hàng tỷ won, nên chia sẻ GPU mang tính chất một quyết định tài chính chứ không đơn thuần là lựa chọn kỹ thuật.

2. Phân loại phương thức chia sẻ và cấu trúc tổng thể

Khung tốt nhất để hiểu các kỹ thuật chia sẻ GPU là "lấy gì làm cơ sở để phân chia". Tài nguyên của GPU chia lớn thành tài nguyên tính toán (SM, Streaming Multiprocessor) và tài nguyên bộ nhớ (VRAM, băng thông bộ nhớ, cache L2), và các kỹ thuật chia sẻ được phân loại theo việc dùng hai thứ này luân phiên theo thời gian hay chẻ theo không gian để dùng đồng thời. Hình dưới đặt bốn kỹ thuật tiêu biểu trên các trục phân chia thời gian, không gian và phần cứng.

flowchart TB
  ROOT["Kỹ thuật chia sẻ GPU"]
  ROOT --> T["Phân chia thời gian (Temporal)"]
  ROOT --> S["Phân chia không gian (Spatial)"]
  ROOT --> H["Phân chia phần cứng (Hardware)"]
  T --> TS["Time-Slicing<br/>chạy luân phiên qua chuyển ngữ cảnh"]
  T --> VG["vGPU (chế độ mặc định)<br/>hypervisor phân chia thời gian"]
  S --> MPS["MPS (Multi-Process Service)<br/>kernel của nhiều tiến trình chạy cùng lúc"]
  H --> MIG["MIG (Multi-Instance GPU)<br/>phân chia vật lý SM, bộ nhớ, cache"]
  H --> VGM["MIG-backed vGPU<br/>cô lập phần cứng + gán VM"]
  TS -.->|Cô lập yếu, hiệu suất cao| G1["hướng overcommit"]
  MIG -.->|Cô lập mạnh, độ hạt cố định| G2["hướng đa người thuê"]

Chia sẻ thời gian (temporal sharing) là phương thức trong đó nhiều công việc chiếm một GPU luân phiên theo đơn vị thời gian ngắn. Nguyên lý giống lập lịch vòng tròn (round-robin) của CPU: tại một thời điểm chỉ một công việc dùng GPU, nhưng mắt người thấy như chúng chạy đồng thời. Mỗi lần chuyển đều tốn chi phí chuyển ngữ cảnh (context switch), và trong khi một công việc giữ GPU thì các công việc khác chờ nên độ trễ (latency) tăng. Ngoài ra bộ nhớ không được phân chia vật lý, nên nếu một công việc chiếm VRAM quá mức thì công việc khác có thể thất bại vì OOM (Out of Memory). Đổi lại cô lập yếu, nó đơn giản để hiện thực và tự do overcommit, phù hợp với môi trường phát triển và kiểm thử ưu tiên hiệu suất hơn hết.

Chia sẻ không gian (spatial sharing) là phương thức trong đó nhiều công việc chia nhau các đơn vị tính toán của GPU tại cùng một thời điểm. Để tránh hàng nghìn SM nhàn rỗi liên tục, khi một công việc chỉ dùng một phần SM thì các SM còn lại được kernel của công việc khác lấp vào. Hiện thực tiêu biểu là MPS thuộc nhóm này. Nó đạt thông lượng (throughput) cao hơn chia sẻ thời gian, nhưng không gian bộ nhớ và lỗi vẫn chưa được tách biệt hoàn toàn.

Phân chia phần cứng (hardware partition) chẻ vật lý bên trong GPU sao cho mỗi mảnh có SM riêng, bộ nhớ riêng, bộ điều khiển bộ nhớ riêng và lát cache L2 riêng. MIG là tiêu biểu: một thực thể đã phân chia về bản chất hoạt động như một GPU nhỏ độc lập, nên can nhiễu hiệu năng (noisy neighbor) và xâm phạm bộ nhớ bị chặn từ gốc. Cô lập mạnh nhất, nhưng vì ranh giới phân chia cố định ở phần cứng nên tính linh hoạt kém hơn.

3. Nguyên lý và kiến trúc của các kỹ thuật chính

Bốn kỹ thuật đưa ra những câu trả lời khác nhau cho một câu hỏi duy nhất "thỏa hiệp ở đâu giữa hiệu suất và cô lập". Dưới đây xem xét nguyên lý theo thứ tự từ cô lập yếu đến mạnh. Sự khác biệt của mỗi kỹ thuật trở nên rõ khi so sánh theo các loại cô lập mà nó cung cấp (cô lập bộ nhớ, cô lập hiệu năng, cô lập lỗi).

A. Time-Slicing

Time-slicing là hình thức chia sẻ cơ bản nhất, trong đó bộ lập lịch tích hợp của GPU chạy nhiều ngữ cảnh (context) CUDA luân phiên theo đơn vị thời gian. Khi việc thực thi kernel của một công việc kết thúc hoặc lát thời gian của nó hết hạn, GPU lưu trạng thái thực thi như thanh ghi và bộ đếm chương trình, khôi phục trạng thái của công việc kế tiếp rồi tiếp tục thực thi. Lần chuyển này ở mức vài đến vài chục micro giây, nhưng khi việc chuyển diễn ra thường xuyên thì chi phí tích lũy trở nên lớn.

Giới hạn quyết định của time-slicing là gần như không có cô lập. Vì bộ nhớ không được tách biệt vật lý, hai công việc chia sẻ cùng một pool VRAM, và rò rỉ bộ nhớ hay chiếm dụng quá mức của một công việc lan sang thất bại của công việc khác. Hơn nữa, nếu một công việc chạy kernel dài, độ trễ của công việc khác tăng khó lường, sinh can nhiễu hiệu năng. Khi cấu hình time-slicing trong Kubernetes, có thể quảng bá (advertise) một GPU vật lý thành chẳng hạn 4 "bản sao (replica)" và gán cho 4 pod; điều này không có nghĩa bộ nhớ chia tư, mà chỉ là có 4 khe lập lịch. Do đó nếu cấp phát vượt tổng bộ nhớ thì OOM xảy ra y nguyên.

Tuy vậy time-slicing vẫn được dùng rộng rãi vì hoàn toàn không ràng buộc phần cứng (chạy được trên mọi GPU) và cấu hình đơn giản. Trong môi trường mà "tính sẵn sàng và chi phí quan trọng hơn cô lập" — một cụm Jupyter notebook nội bộ do hàng chục người dùng, một CI runner chỉ dùng GPU gián đoạn — việc overcommit một GPU cho 8–16 công việc để lấp thời gian nhàn rỗi lại hợp lý hơn.

Tuy nhiên, khi định hệ số overcommit, phải lấy tỷ lệ công việc hoạt động đồng thời làm căn cứ. Nếu 16 người mở notebook nhưng trung bình chỉ 2–3 người thực sự chạy ô lệnh, thì overcommit 8 lần là an toàn, nhưng khoảnh khắc tất cả cùng chạy huấn luyện lớn thì chuyển ngữ cảnh tăng vọt và VRAM cạn kiệt tức thì. Do đó nguyên tắc vận hành giảm thất bại là chỉ áp dụng time-slicing cho các tải "đồng thời đỉnh thấp và dễ thử lại", và đặt kèm trần bộ nhớ.

B. MPS (Multi-Process Service)

MPS là phương thức chia sẻ cho phép các kernel CUDA do nhiều tiến trình gửi lên chạy đồng thời (theo không gian) bên trong một ngữ cảnh GPU duy nhất. Nếu time-slicing chạy "luân phiên" thì MPS chạy "cùng nhau". Vốn CUDA không thể chạy đồng thời kernel của các tiến trình khác nhau mà tuần tự hóa chúng; MPS gộp các kernel của các tiến trình thành một ngữ cảnh máy chủ và thực thi đồng thời ở mức SM, qua đó chồng các tải nhỏ mà một tiến trình đơn không thể lấp đầy GPU để nâng hiệu suất.

Vì sao MPS nâng thông lượng được giải thích bằng số học về mức chiếm SM. Nếu một kernel suy luận nào đó chỉ dùng 30% SM của GPU thì khi chạy đơn lẻ 70% đơn vị tính toán còn lại không làm gì trong thời gian đó. Nếu ba tiến trình đặt cùng kernel đó bằng MPS, ba kernel lấp các SM khác nhau và mức chiếm trên lý thuyết lên tới 90%, kết quả là cùng phần cứng xử lý gần ba lần số yêu cầu. Nếu là time-slicing thì ba công việc luân phiên và để trống 70% mỗi khoảng; khác biệt giữa "luân phiên" và "cùng nhau" nằm chính ở việc thu hồi SM nhàn rỗi này.

Lợi ích của MPS là không có chi phí chuyển ngữ cảnh, và các kernel nhỏ lấp các SM còn lại để nâng thông lượng. Ngoài ra, từ thế hệ Volta trở đi đã bổ sung tính năng đặt trần tỷ lệ tài nguyên tính toán cho mỗi client (ví dụ 50% GPU) cùng một mức bảo vệ bộ nhớ nhất định. Tuy nhiên, về căn bản MPS có cô lập lỗi yếu. Vì chia sẻ một ngữ cảnh GPU, nếu một tiến trình gây lỗi chí mạng (ví dụ vi phạm truy cập bộ nhớ) thì có thể ảnh hưởng cả các tiến trình khác gắn vào cùng máy chủ MPS. Bảo vệ bộ nhớ cũng gần với ranh giới phần mềm hơn là cô lập phần cứng hoàn toàn. Do đó MPS hiệu quả nhất trong môi trường đơn người thuê mà thông lượng quan trọng hơn cô lập, như dịch vụ suy luận đa tiến trình giữa các bên tin cậy lẫn nhau (cùng nhóm, cùng công việc). Chẳng hạn khi đặt nhiều mô hình suy luận nhỏ nhạy độ trễ lên một GPU, chạy đồng thời bằng MPS có thể hạ độ trễ đuôi (tail latency) của từng yêu cầu đồng thời nâng thông lượng tổng.

C. MIG (Multi-Instance GPU)

MIG là kỹ thuật phân chia GPU ở mức phần cứng được giới thiệu ở thế hệ NVIDIA Ampere (A100, A30) và kế thừa sang thế hệ Hopper (H100, H200) và Blackwell (B200). Nó chẻ một GPU thành tối đa 7 thực thể độc lập (GPU Instance), mỗi thực thể có tập SM riêng, VRAM riêng, băng thông bộ nhớ riêng, lát cache L2 riêng và bộ điều khiển bộ nhớ riêng. Tức là đường phân chia được vẽ trên silicon chứ không phải bởi bộ lập lịch phần mềm, nên công việc của một thực thể không thể chạm vật lý vào bộ nhớ hay hiệu năng của thực thể khác. Đây là cơ sở cho cô lập bộ nhớ, hiệu năng và lỗi hoàn toàn mà MIG cung cấp.

flowchart LR
  subgraph GPU["GPU vật lý (ví dụ: H100 80GB)"]
    direction TB
    subgraph I1["GI 3g.40gb"]
      SM1["lát SM x3"]
      M1["VRAM 40GB"]
    end
    subgraph I2["GI 2g.20gb"]
      SM2["lát SM x2"]
      M2["VRAM 20GB"]
    end
    subgraph I3["GI 1g.10gb"]
      SM3["lát SM x1"]
      M3["VRAM 10GB"]
    end
    L2["Cache L2 và bộ điều khiển bộ nhớ cũng được phân chia theo lát"]
  end
  I1 --> T1["Người thuê A (huấn luyện)"]
  I2 --> T2["Người thuê B (suy luận)"]
  I3 --> T3["Người thuê C (notebook)"]

Đơn vị phân chia của MIG được cung cấp dưới dạng các tổ hợp cố định gọi là profile. Lấy H100 80GB làm ví dụ, chỉ có thể chọn các kích thước định sẵn từ 1g.10gb (mảnh nhỏ nhất, tối đa 7) qua 2g.20gb, 3g.40gb đến 7g.80gb (toàn bộ GPU), và kích thước mảnh được ký hiệu bằng tổ hợp "số lát tính toán (g)" và "dung lượng bộ nhớ (gb)". Tên profile và các tổ hợp khả dĩ khác nhau theo từng SKU; ví dụ sản phẩm H100 94GB dùng ký hiệu bộ nhớ khác như 1g.12gb và 7g.94gb. Vì độ hạt như vậy cố định ở phần cứng, không thể tạo kích thước tùy ý như "thực thể bộ nhớ 7,5GB", và thay đổi cấu hình phân chia kèm ràng buộc phải rút hết công việc trên GPU đó rồi cấu hình lại.

MIG là phương tiện cốt lõi của đám mây đa người thuê. Ví dụ nếu chẻ một H100 thành bảy thực thể 1g.10gb, có thể đặt bảy tải suy luận/thử nghiệm quy mô nhỏ hoàn toàn cô lập với nhau, sao cho một người thuê chạy loạn không ảnh hưởng những người khác. Việc nhà cung cấp đám mây có thể bán "1/7 GPU" như một sản phẩm, hay doanh nghiệp có thể dựng thể chế tính phí và hạn mức cấp mảnh GPU theo nhóm, cũng nhờ sự cô lập phần cứng này.

Một thế mạnh khác của MIG là tính dự đoán được của hiệu năng (predictability). Vì một thực thể đã phân chia có băng thông bộ nhớ và cache chuyên dụng, phần hiệu năng của nó được bảo đảm ổn định bất kể các thực thể lân cận làm gì. Điều này đặc biệt quan trọng với dịch vụ suy luận phải cam kết SLA: với time-slicing hay MPS, độ trễ dao động theo tải của hàng xóm, nhưng với MIG, phương sai của độ trễ đuôi nhỏ nên thiết kế tính phí và SLA trở nên đơn giản. Ngược lại, vì độ hạt phân chia cố định, có thể sinh phân mảnh (fragmentation) kiểu "một mảnh dư nhưng một công việc lớn hơn nó phải chờ", nên cần hoạch định dung lượng thiết kế trước cấu hình profile khớp với phân bố tải.

D. vGPU (GPU ảo)

vGPU là kỹ thuật chia một GPU vật lý cho nhiều máy ảo (VM) ở tầng hypervisor, dùng chủ yếu trong môi trường ảo hóa dựa trên VM (VMware vSphere, KVM, Citrix, v.v.) và trong VDI (máy tính để bàn ảo) và đám mây IaaS. Mỗi VM được cài một driver vGPU, và trên GPU vật lý có một trình quản lý hợp tác với hypervisor để trung gian các yêu cầu GPU của các VM. vGPU mặc định cấp GPU cho các VM luân phiên bằng phân chia thời gian, nhưng bảo đảm tách biệt về mặt bộ nhớ bằng cách cố định kích thước framebuffer (VRAM) cấp cho mỗi VM bằng profile. vGPU khác với ba kỹ thuật trước ở chỗ là một ngăn xếp phần mềm thương mại cần giấy phép.

Đáng chú ý là MIG-backed vGPU, kết hợp vGPU với MIG. Trong cấu hình này, các thực thể đã phân chia phần cứng bằng MIG được cấp cho mỗi VM dưới dạng vGPU, nên có được cả cô lập phần cứng của hiệu năng tính toán — thứ mà vGPU phân chia thời gian không cung cấp được — ở độ hạt VM. Nói cách khác, đây là cách lấy "sự tiện lợi vận hành của ảo hóa VM + cô lập mạnh của MIG" cùng lúc, và được ưa chuộng trong các đám mây ảo hóa có yêu cầu cô lập giữa người thuê nghiêm ngặt như tài chính và khu vực công.

4. So sánh các kỹ thuật và tiêu chí lựa chọn

Khác biệt giữa bốn kỹ thuật rốt cuộc quy về bảo đảm cô lập nào bằng phần cứng, và đổi lại từ bỏ bao nhiêu tính linh hoạt, tính đa dụng. Bảng dưới là phụ trợ cho so sánh; "vì sao sinh khác biệt như vậy" cần hiểu từ nguyên lý ở các mục trước.

Hạng mục Time-Slicing MPS MIG vGPU (mặc định)
Trục phân chia Thời gian Không gian Phần cứng Thời gian (có thể kết hợp MIG)
Cô lập bộ nhớ Không Yếu (SW) Mạnh (HW) Có (profile)
Cô lập hiệu năng Không Một phần Mạnh (HW) Yếu
Cô lập lỗi Không Yếu Mạnh Theo VM
Độ hạt phân chia Tự do (số khe) Tự do Cố định (profile) Cố định (profile)
Yêu cầu phần cứng Mọi GPU Phần lớn GPU A100–B200, v.v. GPU hỗ trợ + giấy phép
Dùng tiêu biểu Overcommit phát triển/kiểm thử Suy luận đơn người thuê Tính phí đa người thuê VDI, đám mây VM

Một hiểu lầm phổ biến là kỳ vọng "chia sẻ thì chắc chắn nâng thông lượng tổng". Thực tế nếu tải đã bão hòa GPU đủ, thì chia sẻ chỉ thêm chi phí chuyển và tranh chấp, lại chậm hơn. Tiền đề để chia sẻ có lợi là mỗi công việc không lấp đầy GPU và để lại dư địa ở SM và bộ nhớ; không có dư địa này thì đáp án đúng là cấp phát chuyên dụng chứ không phải phân chia. Do đó trước khi áp dụng chia sẻ, phải lập hồ sơ (profiling) mức chiếm SM thực tế và lượng dùng VRAM của các tải tiêu biểu để xác nhận có dư địa chia sẻ hay không.

Cốt lõi cần đọc từ bảng này là sự đánh đổi chạy dọc, "cô lập càng mạnh thì độ hạt và tính đa dụng càng giảm". Time-slicing chia tự do trên mọi GPU nhưng không có cô lập, còn MIG có cô lập hoàn hảo nhưng đòi khung cố định là profile và phần cứng thế hệ cụ thể. Do đó lựa chọn xuất phát từ "tải của tôi có chia sẻ ranh giới tin cậy hay không". Nếu là công việc tin cậy của cùng nhóm, tốt hơn nên cực đại hóa hiệu suất bằng time-slicing/MPS; nếu là đa người thuê trộn các khách hàng, nhóm khác nhau, phải bảo đảm cô lập phần cứng bằng MIG (hoặc MIG-backed vGPU).

Trên thực tế đôi khi kết hợp chúng theo tầng. Ví dụ sau khi chẻ một H100 bằng MIG thành hai 3g.40gb cộng một 1g.10gb, lại chồng MPS lên trên thực thể MIG dùng cho suy luận để chạy nhiều mô hình nhỏ theo phân chia không gian. Làm vậy cho phép một "cấu trúc hai tầng của cô lập và hiệu quả", cô lập mạnh ranh giới ngoài bằng phần cứng trong khi nâng hiệu suất trở lại giữa các tải nội bộ tin cậy. Thực tế có báo cáo rằng một nền tảng suy luận đã nâng hiệu suất GPU lên gấp vài lần nhờ kết hợp MIG+MPS so với phương thức chiếm trọn một GPU, đến mức thiết kế kết hợp là đòn bẩy cốt lõi để giảm chi phí.

5. Chuyên sâu: Tích hợp Kubernetes và chuyển dịch sang DRA

Hiện trường nơi chia sẻ GPU thực sự vận hành phần lớn là Kubernetes. Truyền thống Kubernetes xử lý GPU bằng mô hình Device Plugin. Khi device plugin NVIDIA của node quảng bá một tài nguyên mở rộng như nvidia.com/gpu, bộ lập lịch cấp trọn một GPU theo yêu cầu tài nguyên của pod. Thêm cấu hình time-slicing lên trên thì có thể quảng bá một GPU thành nhiều khe bản sao, và MIG có thể phơi ra bằng chiến lược single (mọi thực thể cùng profile) hoặc mixed (trộn các profile khác nhau). Tuy nhiên mô hình device plugin được thiết kế để xử lý GPU theo "đơn vị nguyên khối", và giới hạn không thể biểu đạt một cách nguyên bản việc chia sẻ, cấu hình theo từng tải, yêu cầu tô-pô và ràng buộc năng lực là rõ rệt.

Thứ xuất hiện để vượt giới hạn này là DRA (Dynamic Resource Allocation, cấp phát tài nguyên động). DRA là mô hình trong đó khi một tải khai báo qua ResourceClaim "cần tài nguyên có năng lực nào và bao nhiêu", driver cấp phát và cấu hình GPU một cách động để đáp ứng nhu cầu đó, tự định vị như kiến trúc kế thừa của device plugin. API liên quan (resource.k8s.io/v1) đã đạt chính thức (GA) ở Kubernetes 1.34, và driver DRA của NVIDIA cho phép cấu hình khai báo các phương thức chia sẻ như time-slicing và MPS trên khung này (một số tính năng vẫn được cung cấp qua feature gate giai đoạn alpha). Tuy nhiên, không thể dùng đồng thời ngăn xếp DRA và ngăn xếp device plugin cũ trong một cụm, nên người vận hành phải chọn một trong hai.

Một trục khác của xu hướng mới nhất là overcommit bộ nhớ ảo và chia sẻ KV cache. Trong suy luận mô hình ngôn ngữ lớn, trọng số mô hình và KV cache xâm thực VRAM, nên các tầng phần mềm dùng Unified Memory và API quản lý bộ nhớ ảo CUDA (VMM) để overcommit bộ nhớ GPU, hay cho nhiều yêu cầu suy luận chia sẻ các trang KV cache (ví dụ quản lý attention cache theo trang) đang phát triển nhanh. Tức là "cô lập tĩnh" lấy phân chia phần cứng (MIG) làm trung tâm và "chia sẻ/overcommit động" lấy phần mềm làm trung tâm đang cùng trưởng thành theo hai chiều, và có thể xem DRA là nỗ lực hợp nhất cả hai dưới một giao diện khai báo.

Ngoài ra, ở tầng vGPU, mô hình tính phí/giấy phép và lựa chọn chế độ (vCS hướng tính toán, vWS cho máy trạm, v.v.) bước vào như biến số của thiết kế vận hành. Khi đánh giá kỹ thuật chia sẻ, phải cân nhắc không chỉ đặc tính hiệu năng và cô lập thuần túy mà cả chi phí giấy phép, thế hệ phần cứng hỗ trợ và độ trưởng thành của tích hợp hypervisor và Kubernetes để đạt lời giải tối ưu theo quan điểm tổng chi phí sở hữu (TCO).

6. Điểm cân nhắc và hàm ý

  • Chiến lược áp dụng (phân nhánh theo tính chất tải): Điểm xuất phát của thiết kế chia sẻ GPU là "ranh giới tin cậy". Tải theo lô (batch) và phát triển tin cậy của cùng nhóm nên cực đại hóa hiệu suất bằng time-slicing/MPS, còn đa người thuê trộn khách hàng ngoài và tổ chức khác phải bảo đảm cô lập phần cứng bằng MIG. Suy luận thời gian thực nhạy độ trễ, với nó can nhiễu hiệu năng là chí mạng, an toàn nhất là tránh time-slicing và dùng thực thể MIG chuyên dụng hoặc thiết lập trần MPS. Thay vì lấy một kỹ thuật làm chuẩn toàn công ty, áp dụng chính sách chia sẻ phân biệt theo loại tải có lợi cho cả chi phí lẫn tính ổn định. Trên thực tế, tách node pool thành "pool cô lập MIG / pool chia sẻ time-slicing / pool chuyên dụng" và định tuyến tải tới pool thích hợp theo namespace và nhãn làm cho vận hành đơn giản hơn.

  • Đánh đổi (cô lập đối hiệu suất đối linh hoạt): Ba mục tiêu không thể cực đại hóa đồng thời. MIG mua cô lập nhưng trả bằng mất linh hoạt ở profile cố định và chi phí cấu hình lại (phải rút hết công việc), còn time-slicing được linh hoạt và hiệu suất nhưng từ bỏ cô lập. Tổ chức phải định lượng "quy mô thiệt hại khi cô lập thất bại (rò rỉ dữ liệu, vi phạm SLA)" và "giá trị chi phí của 1 điểm phần trăm hiệu suất" rồi quyết định tường minh thỏa hiệp ở đâu. Đặc biệt lưu ý nghịch lý khi chỉ đuổi theo hiệu suất và overcommit quá mức khiến OOM và độ trễ đuôi tăng vọt, làm thông lượng hữu hiệu lại giảm.

  • Quan trắc và vận hành (tính nhìn thấy của môi trường chia sẻ): Chia sẻ càng nhiều thì càng khó tìm nguyên nhân nghẽn và can nhiễu nếu không nhìn thấy "công việc nào dùng bao nhiêu trên mảnh nào". Hãy thu thập hiệu suất GPU (mức chiếm SM), lượng dùng VRAM, băng thông bộ nhớ và điện năng theo từng thực thể bằng phương tiện như DCGM ở mức mảnh, và trong đa người thuê thì kết nối với hạn mức và tính phí theo từng người thuê. "Hiệu suất GPU 90%" đơn thuần không phân biệt được SM thực sự đang làm việc hay chỉ chiếm bộ nhớ, nên KPI của môi trường chia sẻ phải chi tiết hơn.

  • Triển vọng và công nghệ liên kết: Kỹ thuật chia sẻ tiến hóa đan xen với Kubernetes DRA, quản lý bộ nhớ ảo CUDA, chia sẻ KV cache ở máy chủ suy luận, và các công nghệ mở rộng bộ nhớ như kết nối GPU (NVLink, NVSwitch) và CXL. Sắp tới, phân chia phần cứng tĩnh và overcommit phần mềm động dự kiến hội tụ dưới một giao diện khai báo (DRA), làm cho các pool GPU co giãn "tự động phân chia và thu hồi đúng theo năng lực được yêu cầu" trở nên phổ biến. Dưới quan điểm Kỹ sư chuyên nghiệp, năng lực cốt lõi trở thành việc thiết kế quản trị tài nguyên GPU bao trùm cô lập, hiệu suất, tính phí và quan trắc, thay vì bị khóa vào kỹ thuật của một nhà cung cấp cụ thể.

Tài liệu tham khảo

Tóm tắt một câu: Ảo hóa GPU là một phổ công nghệ thỏa hiệp các mục tiêu xung đột giữa hiệu suất thấp của GPU đắt tiền và cô lập đa người thuê qua phân chia thời gian (time-slicing), phân chia không gian (MPS), phân chia phần cứng (MIG) và phân chia VM (vGPU); nó mang đánh đổi rằng cô lập càng mạnh thì độ hạt và tính linh hoạt càng mất, và đang tiến hóa theo hướng cô lập tĩnh và chia sẻ động hội tụ một cách khai báo qua Kubernetes DRA và bộ nhớ ảo CUDA.