TẤT CẢ HỆ THỐNG HOẠT ĐỘNG BÌNH THƯỜNG 14 KHU VỰC · LÁ CHẮN 1.2 TBPS NẠP TIỀN BẰNG BTC · XMR · LTC · ETH · USDT +3 COIN

GPU & AI

Cách tự vận hành một LLM trên server GPU riêng tư

9 phút đọc

Cách tự vận hành một LLM trên server GPU riêng tư

Chạy một mô hình ngôn ngữ trên phần cứng bạn thuê là cách duy nhất để chắc chắn rằng prompt của bạn không bị ghi log, lưu giữ, hay đọc bởi bất kỳ ai khác ngoài bạn. Mọi API dạng hosted — dù chính sách quyền riêng tư của nó có tốt đến đâu — đều nhận được mọi token bạn gửi đi, và chính sách đó có thể thay đổi mà không cần bạn đồng ý. Tự vận hành dịch chuyển ranh giới đó: trọng số nằm trên một ổ đĩa do bạn kiểm soát, suy luận diễn ra trong VRAM bạn thuê theo giờ, và không có gì rời khỏi máy trừ khi bạn tự gửi nó đi đâu đó. Về mặt phần mềm, mọi thứ giờ đây thực sự dễ dàng. Điều vẫn khiến nhiều người mắc bẫy là tính toán dung lượng card trước khi đặt mua, và nhớ rằng một cổng suy luận (inference port) để mở thì vẫn cứ là một cổng để mở.

Tự vận hành thực sự mang lại điều gì — và không mang lại điều gì

Hãy nói rõ ràng về lợi ích thực sự, vì cụm từ "AI riêng tư" đang bị dùng một cách tùy tiện. Một model chạy trên GPU của riêng bạn thay đổi hoàn toàn một số thứ, và không thay đổi chút nào những thứ khác.

  • Prompt và kết quả đầu ra của bạn ở lại trên máy — không có việc ghi log phía nhà cung cấp, không có khoảng thời gian lưu giữ, không có dataset nào được xây dựng từ những gì bạn hỏi.
  • Không tài khoản, không giới hạn tốc độ theo từng key, và không có lớp chính sách nào chen giữa bạn và trọng số. Model bạn triển khai chính là model bạn nhận được.
  • Chi phí có thể dự đoán được ở quy mô lớn. Vượt qua vài triệu token mỗi ngày, một card đi thuê rẻ hơn hẳn so với tính giá theo từng token, và mức giá đó không đổi dù nhà cung cấp có điều chỉnh lại bảng giá của họ.
  • Nó không biến một model yếu thành một model mạnh. Một model có trọng số mở (open-weights) chạy trên phần cứng của riêng bạn thì vẫn là chính model đó — tự vận hành mang lại quyền kiểm soát, chứ không mang lại năng lực hàng đầu (frontier capability).
  • Nó không giấu được điều gì khỏi nhà cung cấp host. Bất kỳ ai có quyền truy cập vật lý vào một cỗ máy đang chạy đều về nguyên tắc có thể đọc được bộ nhớ của nó, và đó là vấn đề của nhà cung cấp host, chứ không phải của model.

VRAM là yếu tố quyết định tất cả: chọn đúng card cho từng model

Gần như mọi lần thử đầu tiên thất bại đều bắt nguồn từ một phép tính VRAM sai. Trọng số, KV cache và không gian làm việc đều phải vừa trong card cùng một lúc, và không hề có chuyện xuống cấp từ từ — bạn sẽ nhận một lỗi hết bộ nhớ (out-of-memory) chỉ vài giây sau khi bắt đầu tải. Quy tắc kinh nghiệm khá dễ áp dụng: ở độ chính xác 16-bit, một model cần khoảng 2 GB VRAM cho mỗi tỷ tham số, khoảng 1 GB ở 8-bit, và khoảng 0.6 GB ở 4-bit. Sau đó cộng thêm KV cache, phần tăng theo độ dài ngữ cảnh và theo số yêu cầu đồng thời — và đây chính là thứ thực sự gây rắc rối khi lên production, chứ không phải lúc kiểm thử.

  • Model 7B đến 8B: khoảng 16 GB ở FP16, hoặc dễ dàng dưới 8 GB ở 4-bit. Đây là nhóm vừa vặn với RTX A4000 16 GB và vẫn còn dư chỗ.
  • Model 13B đến 14B: khoảng 28 GB ở FP16, khoảng 9 GB ở 4-bit. RTX 4090 24 GB chạy tốt phiên bản đã lượng tử hóa với nhiều ngữ cảnh dư dả.
  • Model 30B đến 34B: khoảng 68 GB ở FP16, gần 20 GB ở 4-bit — nơi phù hợp nhất là RTX 5090 32 GB.
  • Model 70B: khoảng 140 GB ở FP16, khoảng 40 GB ở 4-bit. Điều đó đồng nghĩa với một A100 hoặc H100 80 GB, và ở độ chính xác đầy đủ thì cần nhiều hơn một card.
  • Ngữ cảnh dài làm tăng KV cache, chứ không phải trọng số. Một cửa sổ 128k token trên một model lớn có thể tự nó đòi hỏi thêm hàng chục gigabyte — hãy tính toán việc này trước khi đặt mua, đừng để đến sau.
Lượng tử hóa (quantisation) là quyết định có đòn bẩy lớn nhất mà bạn sẽ đưa ra. Chuyển từ FP16 sang một phép lượng tử hóa 4-bit tốt sẽ cắt giảm VRAM khoảng ba phần tư, đổi lại mức giảm chất lượng mà hầu hết tác vụ không bao giờ nhận ra — đây chính là thứ biến một model "cần một H100" thành một model "chạy tốt trên 4090". Hãy tự đo trên chính prompt của bạn thay vì tin vào một bảng benchmark có sẵn.

Chọn GPU: từ A4000 đến H100, và khi nào tính theo giờ tốt hơn theo tháng

Mọi gói trong dòng server GPU đều là một card vật lý trọn vẹn với toàn bộ VRAM của nó — không phân vùng MIG, không chia sẻ thời gian sử dụng — nên con số ghi trên thông số kỹ thuật chính là con số bạn thực sự có thể lấp đầy. Hãy chọn card khớp với model bạn định phục vụ thực sự, chứ không phải model mà một ngày nào đó bạn có thể muốn thử.

  • RTX A4000 16 GB giá $89/mo — 8 vCPU và 64 GB RAM. Đủ cho một trợ lý 7B đến 13B đã lượng tử hóa, một dịch vụ embeddings, hoặc một pipeline phân loại chạy suốt cả ngày.
  • RTX 4090 24 GB giá $189/mo — 16 vCPU, 128 GB và 2 TB NVMe. Mức giá trên mỗi token tốt nhất cho các model 13B đến 34B ở 4-bit, và là lựa chọn phổ biến cho một endpoint production quy mô nhỏ.
  • RTX 5090 32 GB giá $279/mo — 24 vCPU và 192 GB. 8 GB dôi ra đó thường chính là khác biệt giữa một model 34B vừa đủ chỗ với ngữ cảnh thực và một model thì không.
  • A100 80 GB giá $690/mo — 32 vCPU, 256 GB và 4 TB NVMe. Băng thông HBM2e và đủ bộ nhớ cho một model 70B ở 4-bit với cửa sổ ngữ cảnh dài, hoặc để phục vụ với mức batching cao.
  • H100 80 GB giá $1190/mo — 48 vCPU, 384 GB, 8 TB NVMe và một cổng 10 Gbps. Hỗ trợ FP8 cùng băng thông HBM3 khiến đây là lựa chọn hợp lý duy nhất nếu bạn cần throughput thực sự lớn hoặc cần huấn luyện.

Việc tính phí là theo giờ hoặc theo tháng, từ cùng một số dư trả trước, và điều đó thay đổi bài toán chi phí nhiều hơn người ta thường nghĩ. Một đợt đánh giá kéo dài hai buổi chiều trên một H100 chỉ tốn đúng số giờ nó đã chạy, chứ không phải nguyên một tháng. Một endpoint chat cần trả lời được vào lúc ba giờ sáng thì lại cần một cỗ máy tính theo tháng. Nếu bạn cần nhiều card trong cùng một máy, hoặc một GPU đặt cạnh thật nhiều dung lượng lưu trữ cục bộ, một máy chủ dedicated sẽ là lựa chọn phù hợp hơn — và trường hợp tổng quát cho việc thanh toán bằng crypto được trình bày trong thuê server GPU bằng tiền mã hóa.

Từng bước: từ nạp tiền bằng crypto đến một endpoint đang chạy

  1. 01Tạo tài khoản bằng một email dùng một lầnChỉ cần một email và một mật khẩu. Không tên, không số điện thoại, không giấy tờ tùy thân, nên phía chúng tôi không có gì liên kết model bạn chạy với bạn.
  2. 02Nạp số dư bằng cryptoNạp số dư trả trước bằng Bitcoin, Monero hoặc bất kỳ đồng nào trong số 8 coin được hỗ trợ. Số dư không bao giờ hết hạn và không bao giờ bị đóng băng.
  3. 03Triển khai một instance GPU trên image CUDAChọn card, khu vực và một image đã cài sẵn CUDA cùng driver mới và PyTorch. Máy sẽ sẵn sàng chỉ trong vài phút.
  4. 04Xác nhận card đã hiển thị trước khi tải bất cứ thứ gìChỉ một lệnh nvidia-smi sẽ báo cáo GPU, phiên bản driver và dung lượng VRAM còn trống. Đây là một bước kiểm tra mười giây giúp bạn tiết kiệm cả giờ đồng hồ bối rối.
  5. 05Tải trọng số về NVMe cục bộLấy model về ổ đĩa riêng của instance thay vì một network mount. Trọng số có thể lên tới hàng chục gigabyte và bạn sẽ phải tải chúng nhiều hơn một lần.
  6. 06Khởi động server chỉ bind vào localhostChạy vLLM hoặc Ollama trên 127.0.0.1, xác nhận một lượt hoàn thành ngay tại máy, và chỉ sau đó mới quyết định cách bạn sẽ truy cập nó từ bên ngoài.

vLLM, Ollama hay llama.cpp: chọn stack phục vụ

Ba stack này bao phủ gần như mọi trường hợp, và lựa chọn đúng phụ thuộc vào việc endpoint sẽ nhận bao nhiêu yêu cầu, chứ không phải cái nào ấn tượng nhất về mặt kỹ thuật.

  • Ollama — con đường ngắn nhất từ con số không đến một endpoint hoạt động được. Một lệnh duy nhất tải về một model đã lượng tử hóa và phục vụ nó phía sau một API tương thích OpenAI. Lý tưởng cho một người dùng, một bản prototype, hoặc một trợ lý riêng tư.
  • vLLM — câu trả lời cho production. Continuous batching và paged attention cho phép một card duy nhất phục vụ nhiều yêu cầu đồng thời với throughput gấp nhiều lần một vòng lặp đơn giản. Đó là khác biệt giữa một endpoint cho riêng bạn và một endpoint cho một ứng dụng thực sự.
  • llama.cpp — kẻ thực dụng. Lượng tử hóa GGUF xuống tới 4-bit và thấp hơn, đẩy các layer không vừa sang CPU, và mức bộ nhớ tối thiểu thấp nhất trong ba stack. Đây là thứ giúp một model quá khổ vẫn có thể chạy được trên một card quá nhỏ.
  • TGI, SGLang và TensorRT-LLM còn nhanh hơn nữa trong những tình huống cụ thể. Chỉ nên dùng đến chúng sau khi bạn đã đo được nút thắt cổ chai thực sự, không phải trước đó.

Cả ba đều cung cấp một route chat-completions tương thích OpenAI, nên code ứng dụng vốn được viết cho một API thương mại thường chỉ cần đổi một base URL và không cần thay đổi gì thêm. Chính sự tương thích đó là lý do thực tế khiến việc tự vận hành không còn là một dự án lớn mà trở thành một lựa chọn cấu hình đơn giản.

Giữ endpoint ở chế độ riêng tư: không bao giờ để lộ cổng suy luận

Một server suy luận không có xác thực chính là phiên bản hiện đại của một cơ sở dữ liệu để mở. Các scanner tìm ra IP mới chỉ trong vài giờ, và một endpoint bị lộ nghĩa là ai đó khác đang tiêu tốn giờ GPU của bạn — hoặc đọc bất cứ thứ gì ứng dụng của bạn gửi qua nó.

Hãy bind server vào 127.0.0.1, không bao giờ vào 0.0.0.0. Truy cập nó qua một đường hầm WireGuard do chính bạn kiểm soát hoặc một đường hầm SSH, và đặt một reverse proxy có token thật ở phía trước nếu một ứng dụng cần quyền truy cập. Ollama trên cổng 11434 và vLLM trên cổng 8000 đều liên tục bị quét tìm, và cả hai đều không xác thực theo mặc định.

Nếu endpoint thực sự cần công khai — một sản phẩm chứ không phải một trợ lý riêng tư — hãy kết thúc TLS tại một reverse proxy, yêu cầu một bearer token mà bạn xoay vòng định kỳ, và giới hạn tốc độ theo từng key. Đặt reverse proxy đó trên một VPS nhỏ riêng biệt và chỉ để máy GPU có thể truy cập được qua đường hầm là cách sắp xếp gọn gàng hơn. Đây cũng chính là logic tương tự như dựng một website mà không cần KYC: cỗ máy đối mặt trực tiếp với internet nên chứa càng ít thứ càng tốt.

Tinh chỉnh (fine-tuning): khi một buổi chiều trên card đi thuê còn tốt hơn một hóa đơn hàng tháng

Tinh chỉnh là lý lẽ mạnh mẽ nhất để đi thuê thay vì đăng ký thuê bao dài hạn. Một lượt chạy LoRA hay QLoRA trên một model 7B đến 13B — vài nghìn ví dụ, một số ít epoch — hoàn tất trong vài giờ trên một 4090 và chỉ tốn đúng số giờ nó đã chạy. Adapter tạo ra chỉ nặng vài trăm megabyte, nên bạn có thể giữ lại checkpoint, hủy instance, rồi sau đó nạp adapter đó lên một card nhỏ hơn để phục vụ. Fine-tune toàn phần cho một model 70B là một ngân sách hoàn toàn khác và cần một A100 hay H100 có đủ chỗ cho trạng thái optimizer, nhưng ngay cả vậy thời gian vẫn được tính bằng ngày chứ không phải bằng một bản hợp đồng dài hạn.

Quy trình mà việc tính phí theo giờ mở ra rất đơn giản: triển khai, huấn luyện, sao chép adapter ra khỏi máy, rồi hủy nó. Bạn chỉ trả tiền cho phần compute mình đã dùng và không có card nào nằm không giữa chừng. Giữ dataset trên NVMe của instance trong lúc làm việc và lấy nó ra lại khi xong — không thứ gì bạn để lại trên một cỗ máy đi thuê nên là bản sao duy nhất.

Sự đánh đổi quyền riêng tư thẳng thắn của một GPU bạn không sở hữu

Tự vận hành loại bỏ rò rỉ lớn nhất và cụ thể nhất: một bên thứ ba nhận được mọi prompt, giữ nó trong một khoảng thời gian lưu giữ nào đó, và tự quyết định sẽ làm gì với nó. Trên một card đi thuê, model và dữ liệu của bạn sống bên trong một cỗ máy chỉ trả lời cho đúng key của bạn. Thứ mà việc đi thuê không thể loại bỏ chính là bản thân nhà cung cấp host. Bất kỳ ai có quyền truy cập vật lý vào một server đang chạy đều về nguyên tắc có thể đọc được bộ nhớ của nó, và mã hóa toàn ổ đĩa trên một server từ xa chỉ bảo vệ bạn trước một ổ đĩa bị đánh cắp, chứ không phải một ổ đĩa đang chạy.

Vậy nên câu hỏi thực sự đáng quan tâm không phải là "host có nhìn thấy nó không" mà là "host có biết tôi là ai không". Hosting không KYC trả lời đúng câu đó: chỉ cần một email và một mật khẩu, không xác minh, không có gì được lưu lại để bị rò rỉ hay bị yêu cầu cung cấp. Thanh toán từ số dư crypto loại bỏ luôn sự hiện diện của ngân hàng. Bạn muốn đẩy khía cạnh thanh toán đi xa đến đâu là một lựa chọn thuộc về threat model (mô hình rủi ro) của riêng bạn — Bitcoin mang tính danh tính giả, không ẩn danh, nên các đồng coin truy ngược về một sàn giao dịch đã xác minh danh tính vẫn dẫn tới đâu đó, trong khi nạp tiền bằng Monero khép lại khoảng hở đó ở cấp độ giao thức.

Những sai lầm âm thầm lãng phí giờ GPU

  • Chỉ tính dung lượng dựa trên trọng số mà quên mất KV cache, khiến model tải lên trơn tru rồi sụp đổ ngay ở yêu cầu dài đầu tiên.
  • Phục vụ ở FP16 trên một card lẽ ra có thể chạy cùng model đó ở 4-bit với ngữ cảnh gấp ba lần, chỉ vì một nỗi lo về chất lượng mà chẳng ai thực sự đo đạc.
  • Tải bốn mươi gigabyte trọng số về một network mount, rồi thắc mắc tại sao mỗi lần khởi động lại đều mất tới hai mươi phút.
  • Để server bind vào 0.0.0.0 "chỉ để test từ laptop của mình", và trên một IP công khai thì điều đó bị phát hiện ngay trong ngày.
  • Trả tiền theo tháng cho một card nằm không hai mươi giờ mỗi ngày, trong khi khối lượng công việc từ đầu vốn chỉ là một tác vụ theo lô.
  • Benchmark từng yêu cầu một, kết luận rằng vLLM không đáng công sức, rồi bỏ lỡ mất rằng toàn bộ lợi thế của nó chỉ hiện ra khi có tính đồng thời.

Không có sai lầm nào trong số này là kỳ lạ hay hiếm gặp. Đó là những gì xảy ra khi card được chọn trước cả khi model được chọn. Hãy quyết định model và mức lượng tử hóa trước, tính toán VRAM một cách trung thực, giữ cổng luôn đóng, và một LLM tự vận hành sẽ là một trong những thứ ít đòi hỏi chăm sóc nhất mà bạn có thể để chạy liên tục.

Sẵn sàng dùng thử?Triển khai Máy chủ GPU từ $89/tháng — không KYC, thanh toán bằng crypto. Bắt đầu