AI model nào có thể self-host theo RAM VPS?

Yếu tố quyết định những AI model nào bạn có thể self-host

Chỉ một con số quyết định những AI model nào bạn có thể self-host: 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 weights có vừa vào memory 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 để bạn tự xác định điều đó. Cài runtime là một công việc riêng, được hướng dẫn trong hướng dẫn chạy Ollama trên VPS.

Có 2 loại chi phí quyết định kết quả. Weights 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. Đây là phần mọi người thường quên, cho đến khi model đã load được hôm qua nhưng hôm nay lại không thể load.

Số học khi ước tính: số bit trên mỗi parameter

Một model file gần như chỉ chứa weights. Mỗi weight được lưu bằng một số bit nhất định. Quantisation là lưu weights 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 memory. Kích thước được tính trực tiếp như sau:

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

Models được release ở 16 bit, tương đương 2 GB cho mỗi 1 tỷ parameters. Vì vậy, gần như không ai chạy model ở release precision trên VPS. Đây là những mức quantisation bạn sẽ thực tế 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 1 tỷ parameters.
• Q6_K lưu khoảng 6.6 bit, tương đương khoảng 0.83 GB cho mỗi 1 tỷ parameters.
• Q5_K_M lưu khoảng 5.7 bit, tương đương khoảng 0.71 GB cho mỗi 1 tỷ parameters.
• Q4_K_M lưu khoảng 4.8 bit, tương đương khoảng 0.6 GB cho mỗi 1 tỷ parameters.

Dùng 0.6 GB cho mỗi 1 tỷ parameters làm con số ước tính khi làm việc. Q4_K_M là lựa chọn mặc định hợp lý trên máy bị giới hạn memory: chất lượng giảm không nhiều so với 8 bit trong hầu hết tác vụ, còn file có kích thước 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 memory không đủ, hãy giảm xuống một size class trước khi giảm 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 1 tỷ parameters. Các GGUF file thực tế thường chỉ chênh vài phần trăm so với con số này, vì embedding layer và output layer được giữ ở precision cao hơn phần còn lại. Model 3B ở 4 bit có kích thước khoảng 1.8 GB. Model 8B là 4.8 GB. Model 32B là 19.2 GB, còn model 70B là 42 GB.

Vì sao độ dài context tốn nhiều RAM hơn weights

KV cache (key value cache, tức trạng thái attention mà model lưu cho từng token hiện có trong cuộc hội thoại) là khoản chi phí thứ hai. KV cache đượ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 đó dùng nửa gigabyte cho cache. Ở 8192 token, nó dùng 1 GB. Với context 128k mà model card công bố, nó dùng 16 GB, nhiều hơn 3 lần so với weights. Model 70B thì ngược lại: cache của nó ở 128k là 40 GB, ít hơn chính phần weights, vì grouped query attention khiến chi phí cho mỗi token không tăng nhanh gần bằng 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 khi có từ 24 đến 48 GiB, và 256k khi có từ 48 GiB trở lên. Tăng giá trị này bằng biến OLLAMA_CONTEXT_LENGTH trên server, sau đó 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 phép tính bộ nhớ phía sau thiết lập này.

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

Model lưu trong RAM sẽ giữ phần RAM đó cho đến khi có tác vụ unload

Ollama giữ model trong memory 5 phút sau request cuối cùng rồi mới unload. 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 resident, trong đó 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. Để giữ một model trong memory vĩnh viễn, hãy đặt OLLAMA_KEEP_ALIVE=-1 cho service. Giá trị 0 sẽ unload model ngay sau khi hoàn tất mỗi response.

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, rồi 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ữ phần RAM đó, dù không có ai đang sử dụng. Model được pin không phải là capacity còn dư. 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 model. Giữ model trong memory trình bày đánh đổi giữa việc pin model và latency khi cold start.

Một VPS 4 GB chạy được gì

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 mặc định 4096 token. 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 nhỏ. Hãy xem đây là ví dụ về kích thước, không phải khuyến nghị. Tên model thay đổi vài tháng một lần, còn phép tính thì không.

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 và viết lại một đoạn theo style của tổ chức. Chúng xử lý kém việc suy luận nhiều bước và code trải trên nhiều file. Không thể khắc phục các giới hạn này chỉ bằng prompt.

Vấn đề thường gặp ở mức này là swap. Nếu model không vừa bộ nhớ, Linux không từ chối load model. Thay vào đó, Linux đẩy một phần memory ra disk. Vì mỗi token được tạo ra đều phải đọc toàn bộ weight một lần, tốc độ generation sẽ 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 khi model trả lời. Nếu swap in và swap out khác 0 trong lúc generation, model quá lớn so với gói VPS này.

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

Đây là mức mà một model tự host 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, sử dụng 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, sử dụng khoảng 8.4 GB, hoặc giữ model 8B ở mức 8 bit nếu bạn muốn dùng bộ nhớ cho độ chính xác thay vì tăng số lượng parameter.

Tốc độ là điểm hạn chế. Model 8B chạy trên CPU tạo khoảng 3 đến 7 token mỗi giây, còn model 14B tạo 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 trên CPU VPS có cảm giác như đang nhìn một người gõ rất chậm. Mứ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 trên VPS ở mức 8B và lớn hơn cho thấy tình hình thực tế.

Chạy gì trên VPS 32 đến 64 GB

Model 32B ở mức 4 bit chiếm khoảng 19.2 GB, nên có thể chạy trên gói 32 GB với context ngắn và chạy thoải mái trên 48 GB hoặc 64 GB. Model 70B ở mức 4 bit chiếm khoảng 42 GB, nên cần 64 GB ngay cả khi chưa tính cache.

Sau đó, hãy đánh giá tốc độ một cách thực tế. Model 32B chạy trên CPU đạt khoảng 0.6 đến 1.5 token mỗi giây, còn model 70B đạt 0.2 đến 0.5. Một câu trả lời dài 500 token từ model 70B mất khoảng 20 phút. Với tốc độ đó, request thường bị ngắt trước khi model hoàn tất vì timeout của client hoặc proxy phía trước Ollama hết hạn trước. Đây là nguyên nhân của lỗi context deadline exceeded. Đây là các công cụ xử lý theo batch. Bạn có thể đưa cho chúng một queue tài liệu để xử lý qua đêm, khi đó tốc độ không quan trọng. Nhưng nếu đặt chúng sau một giao diện chat, tốc độ lại ảnh hưởng rất nhiều.

Cơ chế định tuyến mixture of experts thay đổi cách tính này. Đây là chi tiết kiến trúc đáng tìm hiểu nhất. Model MoE đưa mỗi token đi qua chỉ một phần nhỏ trong tổng số weights. Một model có tổng cộng 30B parameter nhưng chỉ kích hoạt 3B parameter cho mỗi token cần lượng memory tương đương model 30B và tạo token với tốc độ gần bằng model dense 3B, vì mỗi token chỉ đọc các expert đang active. Trên máy 32 GB, một model MoE có cấu hình như vậy dễ sử dụng hơn nhiều so với model dense 30B. Quy tắc cần nhớ: tổng số parameter quyết định lượng 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 lý thuyết được tính bằng memory bandwidth có thể sử dụng chia cho kích thước weight tính bằng byte. Một shared VPS nhỏ thường cung cấp thực tế 10 đến 25 GB mỗi giây trên toàn bộ vCPU, nên model 4.8 GB đạt 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 ghi nhận 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ố lượng máy khác đang tranh chấp tài nguyên đó. Hãy đo trên hệ thống của bạn 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ó giá trị để so sánh.

Có 2 kết quả thường khiến người dùng bất ngờ. Thêm vCPU nhanh chóng không còn giúp cải thiện tốc độ, 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ó thể trả về các con số khác nhau theo từng giờ. Nguyên nhân là CPU steal time từ noisy neighbour, không phải do bạn cấu hình sai.

Đọc prompt là một công việc khác với tạo câu trả lời. Xử lý prompt phụ thuộc vào năng lực tính toán, nên tốc độ có tăng theo số core. Đây cũng là phần mà GPU vượt CPU nhiều nhất. CPU cần vài phút để đọc một tài liệu dài, trong khi GPU chỉ cần vài giây. Đây là giới hạn đầu tiên bạn gặp khi trỏ một coding agent vào model bạn host, vì mỗi lượt đều gửi lại context của file và định nghĩa tool trước khi token đầu tiên 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ó pool áp dụng phép tính đó thay đổi. VRAM là giới hạn cứng, vì vậy hãy tính trước model nào có thể chạy được 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 nếu giữ context ngắn.
• Từ 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 phần chia này trong cột PROCESSOR, với giá trị chẳng hạn như 78%/22% CPU/GPU. Hãy xem đó 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 một phần chia mà bạn không chủ ý cấu hình, trước tiên hãy giảm context length. Thường chính cache là nguyên nhân khiến model vượt giới hạn.

Concurrency là một 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 chạy đồng thời, nhưng mỗi request đang hoạt động cần KV cache riêng. Vì vậy, 10 user đồng thời dùng model 8B với context 8k cần lượng cache gấp 10 lần 1 GB, ngoài phần dành cho weight. Phục vụ user đồng thời từ một model tự host cho biết giới hạn đó nằm ở đâu.

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

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

Có 2 rào cản khác nhau ở đây. Bạn cần biết mình đang gặp rào cản nào.

Rào cản đầu tiên là model có weight đóng. 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. Thêm 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, lớp retrieval, 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 giải thích đầy đủ vấn đề này.

Rào cản thứ 2 là các model có weight mở nhưng 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 cho chúng: model có tổng cộng 400B parameter ở mức 4 bit cần khoảng 240 GB chỉ cho weight, chưa tính cache. Đây là loại workload cần hardware chuyên dụng. Chi phí thuê hardware theo tháng cao hơn nhiều so với số tiền mà phần lớn người dùng chi cho API token trong cả 1 năm. Cần gì để tự host model cấp Kimi trình bày yêu cầu thực tế. Sự phân chia tương tự cũng xuất hiện trong thư viện của Ollama: GLM 5.2 chỉ được liệt kê dưới dạng cloud model và một model nhỏ hơn cùng dòng mới là model thực sự được tải xuống VPS.

Ranh giới thực tế giữa 2 lựa chọn là: hãy tự host khi tải ổn định và dữ liệu không được 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 ở mức frontier mới là điều 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ả phần memory 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ố lượng parameter tối đa, tính theo đơn vị tỷ, mà bạn có thể chạy ở mức 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 là đáp án. Không giống danh sách tên model, đáp án này không nhanh chóng 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 quantisation 4 bit, cộng thêm KV cache theo độ dài context, và khoảng 1 GB cho operating system cùng model server. Với context 8192 token, cache thêm khoảng 1 GB, nên gói 8 GB chạy được còn gói 4 GB thì không. Nếu muốn dùng đầy đủ context 128k mà model card quảng cáo, riêng cache đã chiếm 16 GB, vì vậy bạn sẽ cần gói 32 GB.

Vì sao model của tôi chạy chậm dù VPS có nhiều vCPU?

Vì tốc độ generation bị giới hạn bởi memory bandwidth, không phải số core. Mỗi token cần đọc toàn bộ weight đang hoạt động từ RAM, nên khi một 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 dữ liệu của mỗi token phải được đọc từ disk. Chi phí này cao hơn nhiều so với mức bạn có thể dự đoán.

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

Có. Mức tăng tỷ lệ 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 và 131072 token cần 16 GB. Cache được cấp phát khi model load, không phải khi cuộc hội thoại dài thêm. Vì vậy, yêu cầu context 128k sẽ reserve lượng memory đó ngay lập tức, dù 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, nhưng 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 thuộc cùng một thế hệ model. Quantisation mạnh thường gây lặp lại và bỏ qua instruction thay vì hiển thị error message, nên bạn dễ quy lỗi cho prompt. Hãy xem 4 bit là mức thấp nhất và thay đổi số parameter thay vì giảm thêm số bit.

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 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 trước khi tính KV cache, còn các model thương mại mạnh nhất hoàn toàn không được phân phối. Phần cứng thông thường có thể chạy tốt model 8B đến 32B cho một tác vụ cụ thể. Với phạm vi hẹp và prompt được viết tốt, model nhỏ thường có thể đạt kết quả tương đương model tổng quát. Nếu cần chất lượng 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.