Bạn có thể tự host model AI nào với bao nhiêu RAM?

Điều gì quyết định các model AI bạn có thể tự host

Bạn có thể tự host model AI nào phụ thuộc vào một con số: dung lượng RAM trên máy. Họ model và framework ít quan trọng hơn nhiều so với việc các weight có vừa trong bộ nhớ mà vẫn còn đủ dung lượng dự phòng hay không. Bài viết này trình bày phép tính để xác định điều đó. Cài runtime là một công việc riêng, được trình bày trong hướng dẫn chạy Ollama trên VPS.

Có hai loại chi phí quyết định kết quả. Weight là chi phí cố định, phụ thuộc vào số lượng parameter và quantisation. Context window là chi phí phát sinh khi chạy, và đây là phần mọi người thường quên cho đến khi một model đã load được hôm qua lại không thể load hôm nay.

Phép tính dung lượng: số bit trên mỗi tham số

Một file model gần như chỉ chứa weight. Mỗi weight được lưu bằng một số bit nhất định. Quantisation là lưu weight bằng ít bit hơn precision khi model được train. Cách này làm giảm một phần nhỏ độ chính xác nhưng tiết kiệm rất nhiều bộ nhớ. Dung lượng được tính trực tiếp như sau:

weights in GB = (parameters in billions x bits per weight) / 8

Model được release ở mức 16 bit, tương đương 2 GB cho mỗi tỷ tham số. Vì vậy, hầu như không ai chạy ở release precision trên VPS. Đây là các mức quantisation bạn sẽ thường gặp, cùng số bit trung bình thực tế trên mỗi weight:

• Q8_0 lưu khoảng 8.5 bit trên mỗi weight, tương đương khoảng 1.1 GB cho mỗi tỷ tham số.
• Q6_K lưu khoảng 6.6 bit, tương đương khoảng 0.83 GB cho mỗi tỷ tham số.
• Q5_K_M lưu khoảng 5.7 bit, tương đương khoảng 0.71 GB cho mỗi tỷ tham số.
• Q4_K_M lưu khoảng 4.8 bit, tương đương khoảng 0.6 GB cho mỗi tỷ tham số.

Hãy dùng 0.6 GB cho mỗi tỷ tham số làm con số ước tính khi vận hành. Q4_K_M là lựa chọn mặc định hợp lý trên máy bị giới hạn bộ nhớ: mức suy giảm chất lượng so với 8 bit nhỏ trong hầu hết tác vụ, còn file chỉ gần bằng một nửa. Dưới 4 bit, chất lượng giảm nhanh. Vì vậy, model 70B bị nén xuống 2 bit thường trả lời kém hơn model 32B ở 4 bit trong cùng thế hệ. Khi bộ nhớ hạn chế, hãy giảm một cấp kích thước trước khi giảm xuống dưới 4 bit.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Cột weight ở trên áp dụng quy tắc 0.6 GB cho mỗi tỷ tham số. File GGUF thực tế thường nằm trong phạm vi chênh lệch vài phần trăm so với con số này, vì các layer embedding và output được giữ ở precision cao hơn phần còn lại. Model 3B ở 4 bit có dung lượng khoảng 1.8 GB. Model 8B là 4.8 GB. Model 32B là 19.2 GB, còn model 70B là 42 GB.

Tại sao độ dài context ngốn nhiều RAM hơn weights

KV cache (key value cache, tức trạng thái attention mà model giữ cho từng token hiện có trong cuộc trò chuyện) là khoản chi phí thứ hai. Cache này được cấp phát khi model load, có kích thước theo độ dài context bạn yêu cầu và tăng tuyến tính theo độ dài đó.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Với context mặc định của Ollama, model 8B này dùng nửa gigabyte cho cache. Ở 8192 token, nó dùng 1 GB. Ở context 128k mà model card công bố, nó dùng 16 GB, nhiều hơn 3 lần dung lượng weights. Model 70B thì ngược lại: cache của nó ở 128k là 40 GB, ít hơn chính dung lượng weights, vì grouped query attention giữ cho chi phí trên mỗi token không tăng gần nhanh như số lượng parameter.

Độ dài context mặc định của Ollama là 4096 token trên server chỉ dùng CPU. Khi có GPU, Ollama chọn giá trị mặc định dựa trên VRAM: 32k với 24 đến 48 GiB và 256k với 48 GiB trở lên. Tăng giá trị này bằng biến OLLAMA_CONTEXT_LENGTH trên server, rồi kiểm tra model đang chạy thực tế nhận được bao nhiêu trong cột CONTEXT của ollama ps. Phần bài viết về num_ctx và độ dài context trình bày chi tiết cách tính bộ nhớ phía sau thiết lập này.

Có 2 cách giảm dung lượng cache. Yêu cầu độ dài context bạn thực sự cần thay vì độ dài context mà model card công bố, vì hầu hết tác vụ chat và coding đều phù hợp trong khoảng 8k đến 32k. Hoặc quantise chính cache này xuống 8 bit để giảm một nửa dung lượng, nhưng sẽ ảnh hưởng phần nào đến khả năng nhớ lại thông tin trong context dài.

Model thường trú sẽ giữ RAM cho đến khi có tiến trình unload nó

Ollama giữ model trong memory 5 phút sau request cuối cùng, sau đó unload model. Giá trị mặc định này phù hợp với laptop nhưng không phù hợp với server, vì request đầu tiên sau mỗi khoảng idle lại phải chờ thời gian load model.

ollama ps
ollama stop qwen3:4b

ollama ps liệt kê các model đang thường trú, với cột SIZE cho biết lượng memory model đang giữ và cột UNTIL cho biết thời điểm model hết hạn. Để ghim model vĩnh viễn, đặt OLLAMA_KEEP_ALIVE=-1 trên service. Giá trị 0 sẽ unload model ngay khi mỗi response hoàn tất.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Gửi một prompt, sau đó chạy lại ollama ps sau 10 phút. Model vẫn được liệt kê. Đây chính là mục đích: model vẫn giữ lượng RAM đó dù có ai đang sử dụng hay không. Model đã ghim không phải là capacity dự phòng. Trên VPS 16 GB, model 8B với context 8k giữ khoảng 6 GB trong suốt thời gian service chạy. Vì vậy, hãy chọn cấu hình máy dựa trên model cộng với application của bạn, không chỉ dựa trên riêng model. Ghim model trong memory trình bày sự đánh đổi với độ trễ cold start.

Chạy gì trên VPS 4 GB

Dành khoảng 1 GB cho hệ điều hành và model server, còn lại khoảng 3 GB. Mức này phù hợp với model 1B đến 4B ở 4 bit, dùng context 4096 token mặc định. Tính đến tháng 8 năm 2026, nhóm này gồm Llama 3.2 3B, Qwen 3 1.7B và 4B, cùng các bản phát hành Gemma và Phi cỡ nhỏ. Hãy xem đây là các ví dụ về kích thước, không phải khuyến nghị. Tên model thay đổi sau vài tháng, nhưng phép tính này không thay đổi.

Tốc độ dự kiến khoảng 6 đến 14 token mỗi giây. Các model nhỏ như vậy xử lý tốt những tác vụ hẹp: phân loại, trích xuất tag, tóm tắt ngắn, viết lại một đoạn theo style của tổ chức. Chúng yếu ở suy luận nhiều bước và xử lý code trải trên nhiều file. Không có cách prompt nào khắc phục được hạn chế đó.

Swap là nguyên nhân gây lỗi phổ biến ở mức này. Nếu model không vừa bộ nhớ, Linux không từ chối load model. Thay vào đó, Linux đưa một phần bộ nhớ ra disk. Vì mỗi token được tạo ra cần đọc toàn bộ weight một lần, tốc độ generation giảm xuống còn vài giây cho mỗi token. Hãy theo dõi free -h cùng các cột si và so của vmstat 1 trong lúc model trả lời. Nếu swap in và swap out khác 0 trong quá trình generation, model quá lớn so với gói VPS.

Chạy được gì trên VPS 8 đến 16 GB

Đây là mức mà một model self-hosted bắt đầu hữu ích cho nhiều tác vụ. Với 8 GB, bạn có thể chạy model 7B hoặc 8B ở mức 4 bit, chiếm khoảng 4.8 GB cho weights, với context 8k. Với 16 GB, bạn có thể chạy model 13B hoặc 14B ở mức 4 bit, chiếm khoảng 8.4 GB, hoặc giữ model 8B ở mức 8 bit nếu muốn dùng memory cho độ chính xác thay vì tăng số lượng parameter.

Tốc độ là điểm hạn chế. Model 8B trên CPU tạo được khoảng 3 đến 7 token mỗi giây, còn model 14B đạt khoảng 1.5 đến 3.5 token mỗi giây. Một người đọc khoảng 5 đến 10 token mỗi giây, nên model 8B chạy trên CPU VPS có cảm giác như đang nhìn một người gõ rất chậm. Tốc độ này phù hợp với background job nhưng gây mệt khi chat tương tác. Các lần chạy Qwen 3 được đo với model 8B và lớn hơn trên VPS cho thấy thực tế sẽ như thế nào.

Các mô hình chạy được trên VPS 32 đến 64 GB

Mô hình 32B ở mức 4 bit chiếm khoảng 19.2 GB, nên phù hợp với gói 32 GB nếu dùng context ngắn và chạy thoải mái trên máy 48 GB hoặc 64 GB. Mô hình 70B ở mức 4 bit chiếm khoảng 42 GB, nên cần 64 GB trước khi tính thêm bất kỳ cache nào.

Tiếp theo, hãy đánh giá tốc độ một cách thực tế. Mô hình 32B chạy trên CPU đạt khoảng 0.6 đến 1.5 token mỗi giây, còn mô hình 70B đạt 0.2 đến 0.5. Một câu trả lời 500 token từ mô hình 70B mất khoảng 20 phút. Đây là các công cụ phù hợp để xử lý theo batch. Bạn có thể đưa một hàng đợi tài liệu vào xử lý qua đêm, khi đó tốc độ không quan trọng. Nhưng nếu đưa chúng vào một giao diện chat thì tốc độ ảnh hưởng rất lớn.

Cơ chế định tuyến của mô hình mixture of experts thay đổi cách tính này. Đây là chi tiết kiến trúc đáng học nhất. Mô hình MoE chỉ đưa mỗi token qua một phần nhỏ trong tổng số weights. Một mô hình có tổng cộng 30B parameter và 3B parameter active cho mỗi token cần lượng memory tương đương mô hình 30B, nhưng tạo token gần bằng tốc độ của mô hình dense 3B, vì mỗi token chỉ đọc các expert đang active. Trên máy 32 GB, MoE có cấu hình như vậy dễ sử dụng hơn nhiều so với mô hình dense 30B. Quy tắc cần nhớ: tổng số parameter quyết định memory, còn số parameter active quyết định tốc độ.

CPU inference thực tế nhanh đến mức nào?

Để tạo 1 token, hệ thống phải đọc toàn bộ weight đang hoạt động từ memory một lần. Không có cách nào tránh việc này. Vì vậy, tốc độ tạo token trên CPU phụ thuộc vào memory bandwidth, không phụ thuộc vào số core. Giới hạn tối đa được tính bằng memory bandwidth khả dụng chia cho kích thước weight tính theo byte. Một shared VPS nhỏ thường đạt thực tế 10 đến 25 GB mỗi giây trên toàn bộ vCPU, nên model 4.8 GB có tốc độ tối đa khoảng 2 đến 5 token mỗi giây.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Đây là các khoảng thường được báo cáo trên phần cứng VPS thông thường, không phải benchmark của một máy cụ thể. Kết quả của bạn phụ thuộc vào thế hệ memory, số channel trên host và số máy lân cận đang tranh chấp tài nguyên. Hãy tự đo bằng bất kỳ model tag nào bạn đã có:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Phần summary được in sau khi câu trả lời kết thúc bằng một dòng có nội dung eval rate: ... tokens/s. Đây là tốc độ tạo token của bạn. Bỏ qua lần chạy đầu tiên trong một session, vì load duration trong cùng summary bao gồm cả thời gian đọc weight từ disk. Đo token mỗi giây đúng cách giải thích cách lấy một con số có thể dùng để so sánh.

Có 2 kết quả thường khiến mọi người bất ngờ. Việc thêm vCPU nhanh chóng không còn giúp ích, vì sau khoảng 8 core, các core bổ sung phải chờ memory thay vì thực hiện phép tính. Trên shared plan, cùng một command cũng có thể trả về các con số khác nhau tùy từng giờ. Đây là CPU steal time do máy lân cận gây tải chứ không phải lỗi trong cấu hình của bạn.

Đọc prompt là một tác vụ khác với tạo câu trả lời. Xử lý prompt bị giới hạn bởi năng lực tính toán, nên có thể tăng tốc theo số core. Đây cũng là khâu mà GPU vượt trội nhất. CPU mất vài phút để đọc một tài liệu dài, còn GPU chỉ mất vài giây. Đây là rào cản đầu tiên khi trỏ coding agent vào model bạn tự host, vì mỗi lượt đều gửi lại context của file và các tool definition trước khi có một token nào của câu trả lời được trả về.

Điều gì thay đổi khi thêm GPU

Phép tính không thay đổi, chỉ có phạm vi áp dụng thay đổi. VRAM là giới hạn cứng, vì vậy hãy tính xem cấu hình nào phù hợp trước khi thuê:

• 8 GB VRAM chứa được model 7B hoặc 8B ở 4 bit với context ngắn.
• 16 GB chứa được model 14B ở 4 bit với context thực tế, hoặc model 8B ở 8 bit.
• 24 GB chứa được model 32B ở 4 bit khi giữ context ngắn.
• 48 GB trở lên chứa được model 70B ở 4 bit, vẫn còn chỗ cho cache và concurrency.

Khi model không vừa, Ollama sẽ chia model: một số layer chạy trên GPU, phần còn lại chạy trên CPU. ollama ps báo cáo cách chia này trong cột PROCESSOR, với giá trị dạng 78%/22% CPU/GPU. Hãy xem đây là cảnh báo, không phải tính năng. Phần chạy trên CPU quyết định tốc độ, vì mỗi token vẫn phải chờ các layer đó. Do đó, model có một phần tư số layer chạy trên CPU sẽ có tốc độ gần với CPU hơn nhiều so với GPU. Nếu thấy cách chia mà bạn không chủ định, hãy giảm context length trước. Thường chính cache là phần khiến model vượt quá giới hạn.

Concurrency là lý do khác để chọn cấu hình lớn hơn. Các weight được dùng chung giữa những request đồng thời, nhưng mỗi request đang hoạt động cần KV cache riêng. Vì vậy, 10 người dùng đồng thời chạy model 8B ở context 8k cần lượng cache gấp 10 lần 1 GB, ngoài phần weight. Phục vụ người dùng đồng thời từ một model tự host giải thích giới hạn này nằm ở đâu.

GPU có đáng thuê hay không cũng là một bài toán số liệu. Câu trả lời phụ thuộc vào số token bạn thực sự tạo mỗi tháng. Điểm hòa vốn giữa GPU VPS và token API có các số liệu đó.

Những gì bạn không thể tự host

Có hai giới hạn khác nhau ở đây. Biết mình đang gặp giới hạn nào sẽ giúp bạn chọn đúng hướng xử lý.

Giới hạn đầu tiên là closed weights. Các model thương mại frontier không được phân phối, nên không có file để tải xuống. Dù có thêm bao nhiêu RAM cũng không thay đổi được điều đó. Bạn có thể tự host mọi thành phần xung quanh chúng: giao diện, retrieval layer, agent loop và log. Riêng model vẫn phải chạy qua remote API. Bạn có thể tự host Claude hay không trình bày đầy đủ vấn đề này.

Giới hạn thứ hai là open weights nhưng model quá lớn. Các bản release open lớn nhất sử dụng kiến trúc mixture of experts với tổng số parameter lên đến hàng trăm tỷ. Quy tắc tương tự cũng áp dụng: model có tổng cộng 400B parameter ở mức 4 bit cần khoảng 240 GB chỉ cho weights, chưa tính cache. Đây là loại workload cần phần cứng chuyên dụng. Chi phí thuê phần cứng theo tháng cao hơn rất nhiều so với số tiền hầu hết mọi người chi cho API token trong một năm. Cần gì để tự host một model cấp Kimi trình bày yêu cầu thực tế.

Ranh giới thực tế giữa hai trường hợp là: hãy tự host khi tải ổn định và dữ liệu không nên rời khỏi server của bạn. Hãy mua token khi tải tăng đột biến hoặc khi chất lượng câu trả lời của frontier model mới là thứ bạn thực sự cần.

Kiểm tra tài nguyên hiện có trước khi chọn

free -h
nproc
lscpu | grep 'Model name'

Hãy lập kế hoạch dựa trên cột available của free -h, không phải cột total, vì total bao gồm cả bộ nhớ hệ thống đang sử dụng. Trừ khoảng 1 GB cho hệ điều hành và model server. Lấy phần còn lại chia cho 0.6 để tính số tham số tối đa, tính theo đơn vị tỷ, có thể chạy ở 4 bit. Sau đó trừ phần KV cache dành cho context thực tế bạn muốn dùng. Phần còn lại chính là đáp án. Khác với danh sách tên model, cách tính này không bị lỗi thời.

FAQ

Tôi cần bao nhiêu RAM để chạy model 8B?

Cần khoảng 4.8 GB cho weights ở mức lượng tử hóa 4 bit, cộng với KV cache theo độ dài context, và khoảng 1 GB cho hệ điều hành cùng model server. Với context 8192 token, cache tăng thêm khoảng 1 GB, vì vậy plan 8 GB chạy được còn plan 4 GB thì không. Nếu muốn dùng đầy đủ context 128k mà model card công bố, riêng cache đã cần 16 GB, nên bạn sẽ cần plan 32 GB.

Vì sao model chậm dù VPS có nhiều vCPU?

Vì tốc độ sinh token bị giới hạn bởi băng thông bộ nhớ, không phải số core. Mỗi token đều cần đọc toàn bộ tập weights đang hoạt động từ RAM, nên khi vài core đã làm bão hòa các memory channel, những core còn lại chỉ phải chờ. Swap là nguyên nhân phổ biến khác. Nếu vmstat 1 hiển thị giá trị khác 0 ở si và so trong khi model đang trả lời, weights không vừa trong RAM và một phần của mỗi token phải được đọc từ disk. Chi phí này cao hơn rất nhiều so với dự kiến.

Context window dài hơn có thực sự cần nhiều memory hơn không?

Có, và mức tăng tuyến tính theo số token. Một model 8B điển hình dùng khoảng 128 KiB KV cache cho mỗi token, nên 8192 token cần 1 GB còn 131072 token cần 16 GB. Cache được cấp phát khi model load, không phải khi conversation tăng lên. Vì vậy, yêu cầu context 128k sẽ reserve lượng memory đó ngay lập tức, ngay cả khi mọi prompt bạn gửi chỉ dài 200 token.

Tôi nên chạy model lớn ở 2 bit hay model nhỏ hơn ở 4 bit?

Hãy chọn model nhỏ hơn ở 4 bit. Chất lượng giảm chậm từ 8 bit xuống 4 bit và giảm nhanh khi thấp hơn 4 bit. Vì vậy, model 70B bị nén xuống 2 bit thường cho câu trả lời kém hơn model 32B ở 4 bit trong cùng một thế hệ model. Quantization quá mạnh thường biểu hiện bằng việc lặp lại và bỏ qua instruction, không phải bằng error message, nên bạn dễ đổ lỗi cho prompt. Hãy xem 4 bit là mức tối thiểu và thay đổi số lượng parameter thay vì giảm bit thêm.

Tôi có thể self-host model có năng lực tương đương các model thương mại lớn không?

Không trên một VPS thông thường. Các model open weight mạnh nhất có đến hàng trăm tỷ parameter. Ở mức 4 bit, riêng weights đã cần hơn 200 GB RAM, chưa tính KV cache. Các model thương mại mạnh nhất thì hoàn toàn không được phân phối. Phần cứng thông thường phù hợp để chạy model 8B đến 32B cho một tác vụ cụ thể. Trong trường hợp này, một model nhỏ có prompt rõ ràng và phạm vi hẹp thường có thể đạt kết quả tương đương model tổng quát. Nếu cần chất lượng cấp frontier, hãy so sánh chi phí API với chi phí phần cứng trước khi mua một trong hai.