Chuyển dữ liệu lên máy chủ GPU ở khu vực khác: hướng dẫn thực tế

Khi thuê GPU theo quốc gia, dữ liệu và GPU của bạn thường nằm ở hai nơi khác nhau. Bộ dữ liệu ở laptop tại Hà Nội, GPU ở Đức, còn kết quả lại cần mang về một chỗ khác nữa. Biết cách chuyển dữ liệu lên máy chủ GPU cho hiệu quả giúp tiết kiệm cả thời gian lẫn tiền, vì GPU ngồi chờ upload vẫn bị tính phí. Bài viết đi qua các công cụ, những thói quen giúp truyền file lớn ổn định, và cách tính phí băng thông trên Cloudj.

Cách lọc GPU theo vị trí được giải thích trong hướng dẫn thuê GPU theo vị trí.

Nguyên tắc số một: cái gì tải được thì đừng upload

Cách tiết kiệm lớn nhất là không phải gửi dữ liệu. Trọng số model công khai và bộ dữ liệu công khai nên được tải ngay trên máy GPU từ nguồn gốc. Đường mạng của máy chủ thường nhanh hơn rất nhiều so với đường lên của nhà bạn, nhất là đường quốc tế từ Việt Nam vốn hay chập chờn mỗi mùa sự cố cáp.

Với model trên Hugging Face:

pip install -U "huggingface_hub[cli]"
huggingface-cli login
huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /workspace/models/qwen2.5-7b

Lệnh login chỉ cần với repo bị giới hạn hoặc repo riêng. Quá trình tải tự nối lại nếu bị ngắt. Hướng dẫn tải từ Hugging Face Hub giải thích cách lọc file và vị trí cache. Với các link trực tiếp khác, dùng wget -c hoặc curl -C - để rớt mạng thì tải tiếp chứ không phải làm lại từ đầu.

Chỉ dữ liệu của riêng bạn (bộ dữ liệu nội bộ, checkpoint đã fine-tune, file dự án) mới cần đi từ máy bạn lên.

Nắm rõ thông tin kết nối

Mọi instance GPU của Cloudj đều truy cập qua SSH bằng key. Tab Connection hiển thị host và port, thường không phải 22. Mọi công cụ bên dưới đều cần port đó:

• ssh -p PORT
• scp -P PORT (chữ P viết hoa)
• rsync -e "ssh -p PORT"

Nếu chưa quen với key và port, hãy đọc bài SSH vào instance GPU trước.

Dùng rsync cho mọi thứ dung lượng lớn

rsync nên là lựa chọn mặc định. Nó hiển thị tiến độ, bỏ qua file đã gửi và nối tiếp được file đang dở:

rsync -avP -e "ssh -p <port>" ./dataset/ root@<host>:/workspace/dataset/

Tùy chọn -P giữ lại phần file đang dở và hiển thị tiến độ. Nếu mạng rớt, chạy lại đúng lệnh đó là nó chạy tiếp. scp dùng được cho một file nhỏ, nhưng không nối tiếp được.

Nén và gộp file nhỏ

Hàng nghìn file nhỏ truyền rất chậm vì file nào cũng tốn thêm chi phí khởi tạo. Hãy gộp lại thành một file trước:

tar -czf dataset.tar.gz dataset/
rsync -avP -e "ssh -p <port>" dataset.tar.gz root@<host>:/workspace/
ssh -p <port> root@<host> "cd /workspace && tar -xzf dataset.tar.gz"

Nén có tác dụng với văn bản, CSV, JSON và log. Với JPEG, PNG, MP4 hay trọng số model vốn đã nén sẵn thì gần như không giúp gì; khi đó dùng tar -cf không có -z để đỡ tốn CPU.

Với việc xử lý video, hãy upload video gốc rồi tách khung hình trên máy chủ, đừng upload từng khung hình.

Kiểm tra dữ liệu đã đến nơi

Với dữ liệu quan trọng, so sánh checksum ở hai đầu:

sha256sum dataset.tar.gz
ssh -p <port> root@<host> "sha256sum /workspace/dataset.tar.gz"

Hai mã băm phải trùng nhau. Bước này bắt được những lần truyền hiếm hoi bị lỗi, trước khi bạn phí hàng giờ GPU huấn luyện trên dữ liệu hỏng.

Tăng tốc khi truyền đường xa

Trên đường quốc tế dài, một luồng TCP có thể không dùng hết băng thông. Vài cách xử lý:

• Chia nhỏ và chạy song song. Upload nhiều phần của file nén bằng các tiến trình rsync riêng.
• Upload một lần lên VPS gần đó, rồi chép giữa hai máy chủ. Một VPS của Cloudj ở gần GPU (ví dụ Singapore hay Frankfurt) có thể làm điểm trung chuyển. Chép giữa hai trung tâm dữ liệu thường nhanh hơn nhiều so với upload từ nhà.
• Upload file lớn vào ban đêm, khi mạng gia đình vắng hơn.
• Chỉ khởi động GPU khi dữ liệu đã ở gần. Chuẩn bị dữ liệu trên máy trung chuyển, triển khai GPU, rồi kéo từ máy trung chuyển về.

Để chép từ instance hoặc máy chủ này sang máy khác, tạo key trên máy nguồn, thêm public key vào ~/.ssh/authorized_keys của máy đích, rồi chạy rsync giữa hai bên. Bài chuyển website sang VPS mới dùng đúng cách chép giữa hai máy chủ này trong bối cảnh khác.

Phí băng thông

Trên Cloudj, mỗi máy ghi giá băng thông riêng theo TB cho chiều tải xuống và tải lên, và bạn bị tính theo GB với giá của chính máy đó. Cả hai chiều đều tính: kéo dữ liệu vào instance và gửi kết quả ra ngoài.

Hệ quả thực tế:

• Khi so sánh máy cho job nặng dữ liệu, hãy nhìn cả giá băng thông chứ không chỉ giá chạy theo giờ.
• Tải model lớn từ nguồn về instance cũng tính là lưu lượng tải xuống; dù vậy đây vẫn thường là cách đỡ mất thời gian hơn cả.
• Chỉ mang về thứ bạn cần: checkpoint cuối và kết quả, không phải cache.

Khoản cọc giữ lại lúc triển khai có một phần dự phòng băng thông; phần chưa dùng được trả lại sau khi bạn hủy instance, có thể mất tới 72 giờ trong lúc chờ quyết toán phí băng thông cuối. Bài tính chi phí thuê GPU cloud hướng dẫn đưa phần truyền dữ liệu vào ngân sách.

Lấy kết quả về trước ngày hết hạn

Mỗi máy có ngày "available until". Qua ngày đó, instance và ổ đĩa bị xóa. Máy là host độc lập, không có SLA phần cứng. Vì vậy:

rsync -avP -e "ssh -p <port>" root@<host>:/workspace/outputs/ ./outputs/

Hãy chạy lệnh này định kỳ trong suốt job dài, đừng đợi đến cuối. Khi mọi thứ đã an toàn thì hủy instance.

Câu hỏi thường gặp

Vì sao rsync báo connection refused?

Thường là sai port. Dùng port trong tab Connection với -e "ssh -p PORT".

Có nên nén trọng số model trước khi upload không?

Hiếm khi đáng; trọng số vốn đã đặc. Tốt hơn nữa là tải chúng ngay trên máy.

Upload vào instance có bị tính phí không?

Băng thông được tính theo GB ở cả hai chiều với giá ghi trên máy. Hãy xem giá trước khi chuyển dữ liệu lớn.

Upload cứ thất bại hoài thì làm sao?

Dùng rsync -P để nối tiếp, chia nhỏ file nén, hoặc trung chuyển qua một VPS ở gần.

Lên kế hoạch cho lần truyền tới

Khi chọn máy trên trang triển khai, hãy xem cả tốc độ tải xuống và giá băng thông bên cạnh GPU. Giá trực tiếp theo từng mẫu có trên GPU cloud.