Băng thông eGPU ảnh hưởng đến AI ở ba thời điểm: lúc tải mô hình vào VRAM, lúc mô hình không vừa VRAM phải chia với RAM hệ thống, và lúc ghép nhiều card. Khi mô hình đã nằm gọn trong VRAM, tốc độ sinh chữ gần như không phụ thuộc cáp — Thunderbolt 4 hay OCuLink đều cho kết quả sát nhau. Vì vậy, chọn kết nối cho AI nên dựa vào cách bạn dùng: chạy một mô hình vừa VRAM thì chuẩn nào cũng ổn; dùng mô hình lớn, mô hình MoE chia với RAM hoặc hay đổi mô hình thì nên ưu tiên OCuLink hoặc Thunderbolt 5.
Bài này là phần chi tiết của bài Dùng eGPU chạy AI trên máy, đi sâu vào từng giai đoạn mô hình làm việc và giai đoạn nào thật sự "kén" cáp.
Băng thông thực tế của các chuẩn eGPU
Con số quảng cáo (40, 80 Gbps) là tổng băng thông của cổng. Phần dành cho dữ liệu PCIe đến card đồ hoạ — thứ AI thực sự dùng — thấp hơn:
| Kết nối | Băng thông PCIe tối đa | Đo thực tế (ước tính) |
|---|---|---|
| Thunderbolt 3 / Thunderbolt 4 / USB4 40Gbps | PCIe 3.0 x4, khoảng 32 Gbps | khoảng 2,5–3 GB/s |
| Thunderbolt 5 | khoảng 64 Gbps | khoảng 5,6–5,8 GB/s |
| OCuLink (PCIe 4.0 x4) | khoảng 64 Gbps | khoảng 6,6–6,7 GB/s |
| Khe PCIe 4.0 x16 trên máy bàn (để so sánh) | khoảng 256 Gbps | khoảng 25–26 GB/s |
So sánh chi tiết các chuẩn có ở bài OCuLink vs Thunderbolt 5 vs USB4. Điều cần nhớ: ngay cả OCuLink cũng chỉ bằng khoảng một phần tư khe x16 của máy bàn. Câu hỏi là AI có cần nhiều băng thông đến vậy không.
Ba giai đoạn khi mô hình ngôn ngữ làm việc
Mỗi lần bạn gửi câu hỏi cho một mô hình chạy trên máy, có ba việc diễn ra, và mỗi việc dùng cáp eGPU rất khác nhau:
- Tải mô hình (load): chép trọng số từ ổ SSD vào VRAM. Chỉ xảy ra một lần khi mở mô hình. Dùng cáp nhiều nhất.
- Đọc câu lệnh (prompt processing, còn gọi là prefill): mô hình đọc toàn bộ câu hỏi, tài liệu đính kèm và lịch sử hội thoại. Đây là phần tính toán nặng, quyết định bạn phải chờ bao lâu trước khi chữ đầu tiên xuất hiện.
- Sinh chữ (token generation): mô hình viết câu trả lời từng token một. Đây là con số "token/giây" mà mọi người hay so sánh.
Khi mô hình nằm trọn trong VRAM, giai đoạn 2 và 3 diễn ra hoàn toàn bên trong card — cáp chỉ chuyển câu hỏi vào và chữ trả lời ra, lượng dữ liệu rất nhỏ. Chỉ giai đoạn 1 thật sự phụ thuộc băng thông.
Giai đoạn 1: thời gian tải mô hình
Thời gian tải ≈ dung lượng mô hình ÷ tốc độ chậm nhất giữa ổ SSD và cáp eGPU. Ước tính với SSD NVMe đủ nhanh:
| Dung lượng mô hình | TB3 / TB4 / USB4 (~2,8 GB/s) | Thunderbolt 5 (~5,7 GB/s) | OCuLink (~6,6 GB/s) |
|---|---|---|---|
| 5GB (mô hình 8B, Q4) | khoảng 2 giây | khoảng 1 giây | khoảng 1 giây |
| 12GB (mô hình 14–20B) | khoảng 4 giây | khoảng 2 giây | khoảng 2 giây |
| 20GB (mô hình 32B, Q4) | khoảng 7 giây | khoảng 3,5 giây | khoảng 3 giây |
| 27GB (mô hình 32B, Q6) | khoảng 10 giây | khoảng 5 giây | khoảng 4 giây |
Vài giây chênh lệch không đáng kể nếu bạn mở một mô hình rồi dùng cả buổi. Nó chỉ thành vấn đề khi phần mềm liên tục đổi mô hình — ví dụ Ollama mặc định tự giải phóng mô hình sau vài phút không dùng, hoặc quy trình agent gọi xen kẽ nhiều mô hình khác nhau.
Lưu ý ổ cứng: nếu mô hình nằm trên SSD SATA (khoảng 0,55 GB/s) hoặc ổ gắn ngoài qua USB, ổ cứng mới là nút thắt, không phải cáp eGPU. Mô hình 12GB trên SSD SATA mất hơn 20 giây dù dùng OCuLink.
Giai đoạn 2 và 3 khi mô hình nằm trọn trong VRAM
Đây là trường hợp phổ biến nhất và cũng là tin tốt cho eGPU. Tốc độ sinh chữ bị giới hạn bởi băng thông VRAM của card (hàng trăm GB/s), không phải cáp (vài GB/s). Thử nghiệm của kênh Alex Ziskind với cùng một card 16GB gắn qua OCuLink và cắm khe PCIe 5.0 x8 cho tốc độ sinh chữ chênh lệch trong sai số đo với mô hình dense.
Tuy vậy, kết quả không phải lúc nào cũng đẹp như lý thuyết. Thử nghiệm năm 2024 của Jan với TensorRT-LLM trên RTX 4090 qua Thunderbolt 3 đo được tốc độ thấp hơn 38,5% so với khe PCIe 4.0 x16, và nhóm thử nghiệm chưa giải thích được hoàn toàn. Phần mềm khác nhau có thể trao đổi dữ liệu với CPU nhiều hơn mức cần thiết. Với eGPU, llama.cpp và các phần mềm dựa trên nó (Ollama, LM Studio) là lựa chọn đã được kiểm chứng nhiều nhất.
Khi mô hình lớn hơn VRAM: băng thông bắt đầu quan trọng
Khi mô hình không vừa VRAM, llama.cpp cho phép để một phần mô hình ở RAM hệ thống và CPU tự tính phần đó. Hai giai đoạn chịu ảnh hưởng khác nhau:
- Sinh chữ: CPU tính phần mô hình nằm ở RAM, rồi chỉ gửi kết quả trung gian nhỏ qua cáp. Tốc độ lúc này bị giới hạn chủ yếu bởi băng thông RAM hệ thống và CPU, cáp eGPU ảnh hưởng không nhiều. Nhưng dù card cắm máy bàn hay eGPU, tốc độ đều giảm mạnh so với khi chạy trọn trong VRAM.
- Đọc câu lệnh: đây là chỗ eGPU chịu thiệt. Với câu lệnh dài (từ 32 token trở lên theo mặc định), llama.cpp chép phần trọng số đang nằm ở RAM sang card để tính cho nhanh. Mỗi lần như vậy, hàng GB dữ liệu phải đi qua cáp. Với cáp chậm, thời gian chép có thể lâu hơn cả thời gian tính.
Điều này đặc biệt đúng với mô hình MoE cỡ lớn — kiểu mô hình mà người dùng hay để phần "chuyên gia" ở RAM và chỉ giữ phần chung trong VRAM. Hướng dẫn tối ưu MoE cho llama.cpp trên Hugging Face lưu ý: nếu băng thông PCIe tới card thấp, nên nâng ngưỡng kích hoạt việc chép này lên (biến môi trường GGML_OP_OFFLOAD_MIN_BATCH), để câu lệnh ngắn được CPU và card cùng xử lý thay vì chờ chép trọng số qua cáp.
Nói gọn: nếu bạn định chạy mô hình lớn hơn VRAM thường xuyên, OCuLink giúp thời gian chờ chữ đầu tiên ngắn hơn rõ so với Thunderbolt 3/4 — nhanh hơn gấp đôi ở phần chép dữ liệu.
Ghép nhiều eGPU: tuỳ cách chia mô hình
Muốn chạy mô hình 70B bằng hai card 24GB, có hai cách chia:
- Chia theo lớp (mặc định của llama.cpp): card thứ nhất giữ nửa đầu mô hình, card thứ hai giữ nửa sau. Giữa hai card chỉ chuyển kết quả trung gian nhỏ ở mỗi bước, nên cách này chạy được qua eGPU. Đổi lại, hai card làm việc lần lượt chứ không cùng lúc, nên tốc độ không tăng gấp đôi.
- Chia theo tensor (tensor parallel, như vLLM hoặc chế độ chia theo hàng của llama.cpp): hai card cùng tính một lớp rồi liên tục trao đổi kết quả. Cách này nhanh hơn trên máy bàn có khe x16, nhưng rất "kén" băng thông — qua cáp eGPU 4 làn, lợi ích thường mất đi phần lớn.
Với eGPU, ghép nhiều card hợp lý nhất khi mục tiêu là đủ VRAM để chạy mô hình lớn, không phải để tăng tốc.
AI tạo ảnh và fine-tune
- Tạo ảnh (Stable Diffusion, Flux): nếu đủ VRAM, mô hình nằm yên trong card và cáp gần như không ảnh hưởng. Nhưng khi VRAM thiếu, ComfyUI và các giao diện tương tự tự động đẩy qua lại từng phần mô hình (bộ mã hoá chữ, mô hình chính, bộ giải mã ảnh) giữa RAM và VRAM trong mỗi lần tạo ảnh. Lúc đó cáp nhanh giúp mỗi ảnh xong sớm hơn vài giây.
- Fine-tune mô hình nhỏ (LoRA): dữ liệu huấn luyện thường nhỏ và nằm sẵn trong VRAM, nên eGPU chạy ổn. Các kỹ thuật đẩy một phần trạng thái huấn luyện sang RAM hệ thống để tiết kiệm VRAM thì ngược lại, dùng cáp rất nhiều và chậm rõ trên eGPU.
Chọn kết nối theo cách dùng AI
| Cách dùng | TB3 / TB4 / USB4 | Thunderbolt 5 / OCuLink |
|---|---|---|
| Chat, trợ lý lập trình với một mô hình vừa VRAM | Ổn | Ổn, tải mô hình nhanh hơn |
| Hay đổi qua lại nhiều mô hình | Chấp nhận được, chờ lâu hơn vài giây mỗi lần | Tốt hơn |
| Mô hình lớn hơn VRAM, MoE chia với RAM | Chậm khi đọc câu lệnh dài | Nên dùng, ưu tiên OCuLink |
| Tạo ảnh với card ít VRAM | Chậm hơn mỗi ảnh | Tốt hơn |
| Ghép nhiều card | Chỉ nên chia theo lớp | Chia theo lớp; chia theo tensor vẫn hạn chế |
Cách kiểm tra eGPU đang chạy ở băng thông nào
- GPU-Z (Windows): dòng Bus Interface hiện số làn và đời PCIe đang dùng, ví dụ "PCIe x4 4.0". Card thường hạ tốc độ khi nhàn rỗi để tiết kiệm điện, nên hãy xem khi card đang chạy tải.
- nvidia-smi: lệnh
nvidia-smi -qhiển thị mục PCIe Generation và Link Width hiện tại, tối đa của card NVIDIA. - llama-bench: công cụ đo đi kèm llama.cpp, cho hai con số pp (tốc độ đọc câu lệnh) và tg (tốc độ sinh chữ). Chạy trên máy của bạn là cách chính xác nhất để biết cáp có đang làm chậm hay không.
Nếu thấy eGPU OCuLink chỉ chạy PCIe 3.0 hoặc ít làn hơn mong đợi, nguyên nhân thường nằm ở cáp — xem bài chọn cáp OCuLink.
Câu hỏi thường gặp
Thunderbolt 4 có đủ để chạy AI qua eGPU không?
Đủ, nếu mô hình nằm trọn trong VRAM. Bạn chỉ chờ lâu hơn vài giây lúc tải mô hình. Thunderbolt 4 yếu hơn rõ khi chạy mô hình lớn hơn VRAM hoặc tạo ảnh với card ít VRAM.
OCuLink nhanh hơn Thunderbolt bao nhiêu khi chạy AI?
Về băng thông, OCuLink nhanh hơn Thunderbolt 3/4 hơn gấp đôi. Khi mô hình vừa VRAM, tốc độ sinh chữ gần như bằng nhau; khác biệt nằm ở thời gian tải mô hình và đọc câu lệnh khi mô hình tràn ra RAM.
Vì sao token/giây của eGPU gần bằng máy bàn nhưng chờ chữ đầu tiên lại lâu hơn?
Vì tốc độ sinh chữ phụ thuộc VRAM, còn thời gian chờ chữ đầu tiên phụ thuộc bước đọc câu lệnh — bước này chậm hơn trên eGPU nếu một phần mô hình nằm ở RAM hệ thống.
Hai eGPU có chạy nhanh gấp đôi một eGPU không?
Không. Qua eGPU, cách ghép phù hợp là chia theo lớp — giúp chạy được mô hình lớn hơn, nhưng tốc độ không tăng gấp đôi.
Đọc thêm
- Dùng eGPU chạy AI trên máy: có đáng không?
- Cần bao nhiêu VRAM để chạy AI trên máy? Bảng tra theo mô hình
- OCuLink vs Thunderbolt 5 vs USB4: chuẩn nào cho eGPU?
- Làn PCIe và eGPU: x4, 8i, 16i khác nhau thế nào?
Nguồn tham khảo
- Hướng dẫn tối ưu mô hình MoE chia CPU + GPU trong llama.cpp: Hugging Face
- Thử nghiệm TensorRT-LLM trên eGPU Thunderbolt 3: Jan
- Tóm tắt thử nghiệm OCuLink và PCIe với LLM của Alex Ziskind: Lilys
