Bởi Chạy Qwen 3.8 27B trên VPS với Ollama
Qwen 3.8 27B cần tag qwen3.8:27b và khoảng 18 GB tải xuống. Xem RAM thực tế, tốc độ CPU, cùng giới hạn VPS 8 đến 64 GB.
Bạn có thể chạy Qwen 3.8 27B trên VPS không có GPU không?
Để chạy Qwen 3.8 27B trên VPS, bạn cần tag qwen3.8:27b. Tính đến ngày 17 October 2026, Ollama library có tag này để pull trực tiếp về máy: model có 27.3 billion parameters, quantisation Q4_K_M, giấy phép Apache 2.0, context window 256K và dung lượng download 18 GB, trong đó có vision projector khoảng 0.9 GB. Ollama bổ sung hỗ trợ Qwen 3.8 27B trong v0.32.12, phát hành ngày 14 August 2026, vì vậy bản cài đặt cũ cần được upgrade trước. Tính đến ngày 17 October 2026, bản stable mới nhất là v0.40.5, phát hành ngày 14 October 2026.
Câu trả lời ngắn là có, trên VPS từ 32 GB trở lên, nhưng tốc độ sẽ chậm. Model dense 27B ở Q4 cần khoảng 17 GB RAM chỉ cho weights, trước khi lưu một token nào trong context. Vì vậy, các gói 8 GB và 16 GB hoàn toàn không phù hợp. Trên VPS DDR4 two-channel phổ biến, mức trần là khoảng 3 tokens mỗi giây, chậm hơn tốc độ đọc của hầu hết mọi người.
Các tag 27B cũ hơn vẫn có trong library: qwen3.6:27b và qwen3.5:27b đều là các bản build Q4_K_M có kích thước tương tự. Qwen3.8-27B giữ nguyên architecture của Qwen3.6-27B, và các file config chính thức của hai model có cùng cách bố trí layer, nên phần tính toán bộ nhớ dưới đây áp dụng cho cả hai. Hãy kiểm tra danh sách hiện tại trước khi sao chép bất kỳ command nào tại trang tag qwen3.8 của Ollama. Phép tính ở đây phụ thuộc vào số lượng parameter, số bit trên mỗi weight và cách bố trí attention, không phụ thuộc vào version number.
Cần pull tag Ollama nào và cách kiểm tra
Pull một tag không tồn tại sẽ trả về lỗi rõ ràng, nên bạn có thể nhanh chóng xác định ngay trên máy. Một tag tồn tại vẫn có thể không chạy được locally. Đây là nguyên nhân khiến nhiều người gặp vấn đề với GLM 5.2, có trong library nhưng chỉ được serve từ cloud của Ollama.
ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27bollama show in ra architecture, số parameter, context length và quantisation của tag bạn thực sự đang có. Nếu dòng parameter hiển thị 27.3B và dòng quantisation hiển thị Q4_K_M, bạn đang dùng build mà hướng dẫn này dựa trên. Library cũng có qwen3.8:27b-q8_0 và qwen3.8:27b-bf16 cho cùng bộ weight ở precision cao hơn, các biến thể 27b-mtp, cùng các tag 27b-nvfp4, 27b-mxfp8, 27b-mlx và 27b-mlx-bf16 mà trang tags ghi là MLX. Đây là format dành cho Apple Silicon, không phải Linux VPS. Không giống qwen3.6, mục qwen3.8 không có tag 35b-a3b. Các model MoE (mixture of experts) đó vẫn nằm dưới qwen3.6 và hoạt động rất khác trên CPU. Phần dưới sẽ nói thêm về chúng.
Số lượng parameter nhân số byte trên mỗi weight
Dữ liệu đằng sau biểu đồ này
[
{
"label": "Q4_K_M",
"size_gb": 17,
"bits_per_weight": 4.98,
"notes": "published tag qwen3.8:27b, language model file"
},
{
"label": "Q5_K_M",
"size_gb": 19.5,
"bits_per_weight": 5.7,
"notes": "computed, no library tag exists"
},
{
"label": "NVFP4",
"size_gb": 18,
"bits_per_weight": 5.27,
"notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
},
{
"label": "Q8_0",
"size_gb": 29,
"bits_per_weight": 8.5,
"notes": "published tag 27b-q8_0, language model file"
},
{
"label": "BF16",
"size_gb": 55,
"bits_per_weight": 16.1,
"notes": "published tag 27b-bf16, language model file"
}
]Công thức chỉ có một dòng. Số byte của weights = số parameter * số bit trên mỗi weight / 8. Ở mức chính xác 4 bit, 27.3 tỷ parameter sẽ chiếm 13.7 GB. File language model trong tag Q4_K_M đã phát hành có kích thước 17 GB, tương đương 4.98 bit trên mỗi weight trong thực tế.
Chênh lệch đó không phải lỗi. Các format K-quant không lưu mọi tensor ở cùng độ rộng danh nghĩa. Những tensor suy giảm chất lượng nhiều nhất khi nén sẽ được cấp nhiều bit hơn: danh sách tensor của Ollama cho file qwen3.8:27b đã phát hành cho thấy output layer, các phép chiếu attention QKV và một số phép chiếu down của feed-forward dùng Q6_K; các tensor normalisation nhỏ dùng độ chính xác đầy đủ 32-bit; còn token embedding vẫn dùng Q4_K như phần lớn model. Tên của format biểu thị giá trị trung bình, và giá trị trung bình này gần 5. Hiệu ứng tương tự cũng xuất hiện ở đầu kia của thang đo: 55 GB của BF16 tương đương 16.1 bit trên mỗi weight, thay vì cố định ở 16. Ở đó, token embedding dùng BF16 như mọi thành phần khác. Phần vượt thêm một ít đến từ metadata của file, các tensor normalisation được giữ ở 32-bit và việc kích thước được liệt kê đã được làm tròn đến GB gần nhất.
Hãy tính cả tag, không chỉ file language model. Mỗi tag GGUF của qwen3.8:27b cũng phát hành một vision projector khoảng 0.9 GB. Vì vậy tag Q4_K_M được liệt kê là 18 GB.
Model này không có tag Q5_K_M được công bố, nên dòng 19.5 GB được tính theo mức thông thường 5.7 bit trên mỗi weight của format đó, thay vì được đo thực tế. Q8_0 gần như tăng gấp đôi dung lượng so với Q4, lên 29 GB. Trên máy chỉ dùng CPU, mức tăng gấp đôi đó khiến lưu lượng bộ nhớ trên mỗi token cũng tăng gấp đôi, nên tốc độ token mỗi giây cũng giảm khoảng một nửa. Chỉ riêng lý do đó đã đủ để chọn Q4_K_M làm mặc định ở đây. Nếu bạn muốn đánh giá khía cạnh chất lượng thay vì bộ nhớ, so sánh chi tiết hơn giữa Q4, Q8 và fp16 cho thấy đầu ra bắt đầu suy giảm ở đâu.
Chi phí của KV cache khi context tăng
Dung lượng weights là chi phí cố định. KV cache (key và value cache, tức trạng thái attention mà model giữ cho mọi token đã đọc) tăng tuyến tính theo độ dài context. Đây là nơi hầu hết người dùng thực sự hết RAM.
Dữ liệu đằng sau biểu đồ này
[
{
"label": "4k tokens",
"kv_f16_gb": 0.25,
"kv_q8_gb": 0.13
},
{
"label": "8k tokens",
"kv_f16_gb": 0.5,
"kv_q8_gb": 0.25
},
{
"label": "16k tokens",
"kv_f16_gb": 1,
"kv_q8_gb": 0.5
},
{
"label": "32k tokens",
"kv_f16_gb": 2,
"kv_q8_gb": 1
},
{
"label": "64k tokens",
"kv_f16_gb": 4,
"kv_q8_gb": 2
},
{
"label": "128k tokens",
"kv_f16_gb": 8,
"kv_q8_gb": 4
}
]Các con số này lấy từ file config của model. Qwen3.8-27B, giống Qwen3.6-27B, là model dùng hybrid attention. Chỉ 16 trong tổng số 64 layer dùng full attention và giữ cache tăng theo từng token. Các layer này có 4 key/value head theo GQA (grouped-query attention) và head dimension là 256. 48 layer còn lại dùng linear attention (Gated DeltaNet) và giữ một state có kích thước cố định. Theo phép tính của tôi, state này vào khoảng 150 MB cho mỗi conversation slot, bất kể context dài đến đâu. Như vậy, ở f16, dung lượng là 64 KiB cho mỗi token: 2 GB ở 32k token và 8 GB ở 128k token. Đừng chỉ dựa vào phép tính này trên máy của bạn. Hãy load model và đọc cột SIZE của ollama ps. Cột này báo tổng weights, cache và overhead trong một con số.
Context 256K trên model card có thể đạt được với kiến trúc này, nhưng không miễn phí. Khi lấp đầy context ở f16, cache cần khoảng 16 GB ngoài phần weights, trong khi máy đã dùng 17 GB cho weights. Ollama mặc định không cấp toàn bộ context window cho bạn. Nó load một window nhỏ hơn nhiều. Ollama FAQ ghi giá trị này là 4096 token. Bạn phải chủ động tăng nó bằng OLLAMA_CONTEXT_LENGTH. Biến áp dụng trên toàn server này không phải là tùy chọn duy nhất. Đặt num_ctx trên từng request cho phép bạn giữ giá trị mặc định tiết kiệm cho các request khác, trong khi một job dài được cấp window lớn hơn. Hãy tăng từng bước và kiểm tra ollama ps sau mỗi lần thay đổi.
Hai thiết lập giúp giữ cache ở mức thấp. OLLAMA_KV_CACHE_TYPE=q8_0 lưu cache ở 8 bit thay vì 16 bit, giảm dung lượng cần dùng cho 32k token từ 2 GB xuống còn 1 GB. Thiết lập này cần flash attention, vì vậy hãy đặt cả OLLAMA_FLASH_ATTENTION=1 và xác nhận mức giảm trong ollama ps thay vì mặc định rằng thiết lập đã được áp dụng. Nếu trước đây bạn chưa thay đổi kiểu cache, hướng dẫn so sánh q8_0 với f16 cho KV cache của Ollama trình bày cách đặt cả hai biến và đọc các số liệu trước và sau. OLLAMA_NUM_PARALLEL=1 cũng quan trọng không kém. Ollama có thể xử lý nhiều request cùng lúc, và mỗi slot nhận một phần context riêng. Vì vậy, tăng parallelism sẽ âm thầm nhân dung lượng cache mà bạn đã dự trù. Giá trị mặc định hiện tại vốn đã là 1, và phần override bên dưới giữ cố định giá trị đó. Nếu có nhiều hơn một người dùng máy này, chính sự nhân lên đó sẽ gây vấn đề. số người dùng đồng thời mà một model tự host có thể phục vụ được quyết định bởi số cache slot và độ sâu hàng đợi từ rất lâu trước khi số core trở thành yếu tố quyết định.
RAM 8, 16, 32 và 64 GB chứa được gì
Dữ liệu đằng sau biểu đồ này
[
{
"label": "8 GB",
"q4_max_ctx_ktok": 0,
"q8_max_ctx_ktok": 0,
"notes": "Weights alone exceed the box. Use a 4b or 8b model."
},
{
"label": "16 GB",
"q4_max_ctx_ktok": 0,
"q8_max_ctx_ktok": 0,
"notes": "17 GB of weights does not fit in 16 GB of RAM."
},
{
"label": "32 GB",
"q4_max_ctx_ktok": 128,
"q8_max_ctx_ktok": 0,
"notes": "Q4 fits with room for long context. Q8 weights do not fit."
},
{
"label": "64 GB",
"q4_max_ctx_ktok": 256,
"q8_max_ctx_ktok": 256,
"notes": "Both fit with the full 256K window."
}
]Đọc 2 con số này là số nghìn token context có thể chứa cùng với weights và vision projector, khi dùng cache f16, trên một Linux VPS không có giao diện đồ họa, còn khoảng 1.5 GB cho hệ điều hành và một phần dự phòng nhỏ. Số 0 nghĩa là bản thân weights không vừa, nên không thể chứa context nào.
8 GB và 16 GB đều không đủ sát ngưỡng để dùng được. 17 GB weights không thể nằm trong 16 GB RAM, và không có thiết lập context nào thay đổi được điều đó. Thêm swap cũng không giải quyết được. Ollama memory-map file GGUF, nên khi các page resident vượt quá RAM, kernel bắt đầu evict rồi đọc lại chúng. Mỗi token khi đó phải đọc hàng GB dữ liệu từ disk. Máy sẽ ở trạng thái iowait cao và tạo ra chưa đến 1 token mỗi giây.
32 GB là mức bắt đầu dùng được. Weights chiếm 17 GB, vision projector dùng thêm khoảng 0.9 GB, còn lại khoảng 12.5 GB, đủ cho khoảng 128k token context f16 với một phần dự phòng. Weights Q8_0 ở mức 29 GB hoàn toàn không vừa ở tier này.
64 GB là mức thoải mái. Q4 còn đủ chỗ cho toàn bộ context window 256k, và weights Q8_0 cũng vừa khi vẫn giữ được toàn bộ 256k context phía sau. Trước khi trả tiền cho 64 GB để dùng Q8, cần hiểu rõ bạn đang mua gì: output tốt hơn một chút nhưng tốc độ giảm một nửa, trên một máy vốn đã chậm. Q4 đã đạt 128k token trên gói 32 GB, và đó là lựa chọn cân bằng tốt hơn với gần như mọi người.
Tốc độ inference trên CPU trên một VPS là bao nhiêu?
Sinh một token từ model dense nghĩa là đọc toàn bộ weight từ memory một lần. Không phải một phần. Mà là toàn bộ. Vì vậy, giới hạn tốc độ không nằm ở số core, mà là băng thông memory chia cho kích thước của các weight. Ở Q4, mỗi token tạo ra 17 GB lưu lượng memory.
Dữ liệu đằng sau biểu đồ này
[
{
"label": "DDR4-2666, 2 channel",
"mem_bandwidth_gb_s": 42.6,
"ceiling_tok_s": 2.5
},
{
"label": "DDR4-3200, 2 channel",
"mem_bandwidth_gb_s": 51.2,
"ceiling_tok_s": 3
},
{
"label": "DDR5-4800, 2 channel",
"mem_bandwidth_gb_s": 76.8,
"ceiling_tok_s": 4.5
},
{
"label": "DDR4-3200, 8 channel",
"mem_bandwidth_gb_s": 204.8,
"ceiling_tok_s": 12
},
{
"label": "DDR5-4800, 12 channel",
"mem_bandwidth_gb_s": 460.8,
"ceiling_tok_s": 27.1
}
]Đây là mức trần, không phải số đo thực tế. Tốc độ output thực tế thường chỉ đạt khoảng 50 đến 70 phần trăm con số trên, vì độ trễ memory và việc prefetch không hoàn hảo khiến bạn không bao giờ đạt đỉnh lý thuyết. Một VPS DDR4-3200 hai kênh có mức trần 3 token mỗi giây, nên hãy kỳ vọng khoảng 2. Một máy DDR5-4800 hai kênh có mức trần 4.5, nên hãy kỳ vọng khoảng 3.
Các dòng server lớn cần được hiểu kèm một cảnh báo. Một platform EPYC mười hai kênh có 460.8 GB/s và mức trần 27.1 token mỗi giây, nhưng bạn không thuê toàn bộ một máy EPYC. Băng thông memory là tài nguyên dùng chung của toàn bộ host, được chia cho mọi tenant trên máy đó. Vì vậy, một slice 8 vCPU không đi kèm mười hai kênh băng thông độc quyền. Các hướng dẫn tập trung vào GPU thường bỏ qua điểm này. Đây là lý do hai gói VPS có cùng số vCPU có thể khác nhau 3 lần trên cùng một model.
Tăng thêm vCPU cũng sớm không còn giúp ích vì cùng một lý do. Khi các core yêu cầu dữ liệu nhanh hơn tốc độ memory controller có thể cung cấp, các thread bổ sung chỉ tạo thêm overhead cho việc scheduling. Ollama không có environment variable cấp server để đặt số thread, nên hãy đặt num_thread trong request options theo số core vật lý, đo tốc độ, rồi thử một nửa con số đó. Trên nhiều gói shared, mức thấp hơn lại nhanh hơn.
Xử lý prompt hoạt động khác. Prefill, tức lượt xử lý input trước khi token đầu tiên xuất hiện, bị giới hạn bởi năng lực tính toán thay vì băng thông. Vì vậy, tốc độ của nó tăng theo số core. Hiệu ứng thực tế là có một khoảng chờ dài trước khi output bắt đầu với prompt lớn, sau đó là tốc độ ổn định nhưng chậm như trên. Hãy đo riêng hai giai đoạn bằng --verbose. Lệnh này in ra một prompt eval rate và một eval rate cho mỗi request.
Nếu model dense 27B quá chậm, hãy kiểm tra các tag qwen3.6:35b-a3b trước khi từ bỏ việc chạy trên CPU. Các tag này chỉ kích hoạt khoảng 3 tỷ parameter cho mỗi token thay vì toàn bộ 27.3 tỷ parameter. Vì vậy, lưu lượng memory trên mỗi token giảm gần một bậc độ lớn, dù file trên disk lớn hơn. Bạn đánh đổi dung lượng RAM để lấy tốc độ. Lựa chọn runtime cũng quan trọng ở đây. Ollama và llama.cpp cung cấp các tùy chọn tuning CPU khác nhau trên cùng một code inference nền tảng.
Khi nào nên thuê GPU theo giờ
Dữ liệu đằng sau biểu đồ này
[
{
"label": "L40S, 48 GB",
"mem_bandwidth_gb_s": 864,
"ceiling_tok_s": 51
},
{
"label": "RTX 4090, 24 GB",
"mem_bandwidth_gb_s": 1008,
"ceiling_tok_s": 59
},
{
"label": "A100, 80 GB",
"mem_bandwidth_gb_s": 2039,
"ceiling_tok_s": 120
},
{
"label": "H100 SXM, 80 GB",
"mem_bandwidth_gb_s": 3350,
"ceiling_tok_s": 197
}
]Cùng công thức đó, khi áp dụng cho băng thông bộ nhớ GPU được công bố, sẽ cho ra một nhóm kết luận khác. Một card dành cho người dùng phổ thông có 24 GB bộ nhớ có giới hạn 59 token mỗi giây với các weight này. Một card data centre hiện tại đạt 197. Bạn không thể thu hẹp khoảng cách này chỉ bằng cách tinh chỉnh số lượng thread. Card này chạy bộ nhớ ở mức 1008 GB/s, trong khi VPS của bạn chỉ đạt vài chục GB/s.
Vì vậy, hãy phân định theo workload thay vì theo sở thích. CPU inference phù hợp khi công việc chạy bất đồng bộ và không có ai phải chờ kết quả: tóm tắt một loạt tài liệu qua đêm hoặc chạy job phân loại hằng đêm trong lúc bạn ngủ. Hãy thuê GPU ngay khi có người đang chờ output hoặc khi request đến nhanh hơn tốc độ máy xử lý xong chúng. CPU runtime không bị giới hạn ở một request mỗi lần: tài liệu của llama.cpp server mô tả parallel decoding và continuous batching trên cả CPU lẫn GPU, còn Ollama cũng có thể phục vụ các request song song, nhưng sẽ tốn thêm cache. Yếu tố quyết định là serving rate đo được so với arrival rate, vì vậy hãy đo thời gian xử lý một batch thực tế trên chính máy của bạn. Khi request đến nhanh hơn tốc độ đó, queue sẽ tăng.
So sánh chi phí không đơn giản như vẻ ngoài. VPS 64 GB tính phí cho mọi giờ trong tháng, bất kể model có được load hay không, trong khi GPU instance chỉ tính phí cho số giờ bạn để nó chạy. Nếu mức sử dụng thực tế của bạn là 2 giờ mỗi ngày, GPU thuê có thể vừa nhanh hơn vừa rẻ hơn. Trước tiên, hãy tính duty cycle rồi mới tính chi phí. Chọn VPS có GPU trình bày những điểm cần kiểm tra trên chính instance, còn vLLM vượt Ollama khi phục vụ các request đồng thời trên GPU vì nó batching chúng đúng cách.
Có một lựa chọn thứ ba mà nhiều người bỏ qua. Giữ model 27B trên CPU để chạy batch work và dùng model API hosted cho interactive path. Không có yêu cầu nào bắt buộc một model phải phục vụ cả hai.
Cài Ollama và đo máy của bạn
Script cài đặt là script chính thức. Script này thiết lập một systemd service chạy bằng user chuyên dụng ollama.
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -gollama --version phải in ra 0.32.12 hoặc mới hơn. Đây là bản phát hành đầu tiên hỗ trợ Qwen 3.8 27B. Kiểm tra free -g trước khi pull bất kỳ thứ gì. Nếu cột total trên dòng Mem nhỏ hơn 32, hãy dừng tại đây và chọn model nhỏ hơn. Pull 18 GB mà không thể chạy sẽ lãng phí một giờ và rất nhiều dung lượng disk.
Đặt các tùy chọn runtime trong systemd override thay vì trong shell. Model chạy bên trong service nên không nhìn thấy môi trường tương tác của bạn.
sudo systemctl edit ollama[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"sudo systemctl restart ollama
ollama pull qwen3.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."Output của --verbose là số đo bạn cần. eval rate là số token mỗi giây trong quá trình generation. prompt eval rate là tốc độ prefill. load duration là thời gian đọc weights từ disk. Vì vậy, OLLAMA_KEEP_ALIVE=60m được đặt như vậy: trên CPU, việc nạp lại 17 GB từ disk trong mỗi request tốn nhiều thời gian hơn chính request đó. Timeout idle mặc định là năm phút. Khoảng thời gian này đủ ngắn để batch queue có khoảng trống giữa các item phải trả chi phí load đó nhiều lần. Các tùy chọn giữ model trong memory bao gồm cả field keep_alive cho từng request và cách giữ thiết lập này sau khi reboot.
Trong khi model đang được load, hãy kiểm tra mức sử dụng memory từ terminal thứ hai.
ollama psCột SIZE là footprint memory thực tế, bao gồm cả KV cache. Giá trị này phải gần bằng tổng weights, vision projector và dòng tương ứng với context length của bạn trong biểu đồ KV. Ở 8192 token với cache 8-bit, phần cache tăng dần chỉ khoảng một phần tư gigabyte, so với 0.5 GB nếu cache vẫn dùng f16, chưa tính fixed linear-attention state. Cột PROCESSOR phải hiển thị 100% CPU. Nếu hiển thị giá trị khác, một thành phần nào đó đã chiếm GPU và các số đo tốc độ trong hướng dẫn này không mô tả đúng máy của bạn.
Các tình huống lỗi và chuỗi chính xác bạn sẽ thấy
Model không tải được. Ollama in một dòng chứa tên của cả hai con số, theo dạng model requires more system memory (18.6 GiB) than is available (15.2 GiB). Đây là dạng lỗi tốt, vì Ollama đã kiểm tra trước khi cấp phát, thay vì để kernel tự xử lý. Giảm context length, chuyển sang tag nhỏ hơn hoặc dùng plan lớn hơn.
Process biến mất giữa chừng khi đang trả lời. Client không hiển thị thông tin hữu ích nào, còn journalctl -u ollama -n 50 cho thấy service đang restart. Chạy dmesg -T | tail. Nếu thấy một dòng có nội dung Out of memory: Killed process ... (ollama), nghĩa là kernel OOM killer đã dừng process. Trường hợp này xảy ra khi kiểm tra trước lúc load đã thành công, nhưng cache tăng vượt estimate trong một cuộc hội thoại dài. Giảm context length.
Pull thất bại ngay lập tức. Error: pull model manifest: file does not exist nghĩa là tag không có trong library. Version number chưa được release cũng gây đúng lỗi này, và typo trong tag cũng vậy. qwen3.8:27b là tag có thật, nên nếu chính xác tag đó vẫn lỗi, hãy kiểm tra typo trước. Xác nhận tag trên trang library trước khi đổ lỗi cho network. Nếu một tag có thật pull được nhưng không chạy, kiểm tra ollama --version với 0.32.12.
Mọi thứ đều hoạt động nhưng tốc độ chậm không chịu nổi. Tốc độ dưới 1 token mỗi giây trên máy có đủ RAM cho thấy vấn đề nằm ở paging, không phải compute. Chạy vmstat 1 trong lúc generate. Cột si hoặc so khác 0 nghĩa là kernel đang swap. Cách xử lý là giảm context hoặc giảm số model được load. wa cao và ổn định nhưng không có hoạt động swap nghĩa là các weight được memory-map đang bị đọc lại từ disk, tức là chúng thực sự không vừa trong RAM.
Token đầu tiên mất 30 giây, sau đó output nhanh hơn. Đó là prefill và là hành vi bình thường. Mỗi request không trúng cache đều phải xử lý lại system prompt dài, vì vậy hãy rút ngắn system prompt trước khi tối ưu các phần khác.
CPU-only 27B thực sự phù hợp với việc gì
Hãy đặt kỳ vọng dựa trên số liệu, không dựa trên hy vọng. Với tốc độ 2 đến 4 token mỗi giây, một câu trả lời 500 token mất từ 2 đến 4 phút. Tốc độ này không dùng được cho chat nhưng hoàn toàn phù hợp với một queue. Model cần suy nghĩ trước khi trả lời sẽ còn chậm hơn, vì các token suy luận ẩn cũng được tạo ở cùng tốc độ chậm như phần trả lời. Vì vậy, điều chỉnh mức độ suy luận theo công việc là một trong số ít cách rút ngắn câu trả lời mà không phải đổi model. Tóm tắt tài liệu, gắn tag hàng loạt, trích xuất trường từ một backlog file và code review không cần giám sát đều chấp nhận được tốc độ này vì không có ai phải chờ câu trả lời. Hỗ trợ lập trình nằm đúng ở ranh giới đó. Vì vậy, giao cho coding agent một model bạn tự host có ích cho các job chạy nền như tạo commit message và khung test, nhưng không phù hợp với các gợi ý inline mà bạn phải ngồi chờ.
Lợi ích về quyền riêng tư mới là lý do chính. Model chạy trên phần cứng bạn thuê và kiểm soát. Không có request nào rời khỏi máy. Bạn cũng không phải trả phí theo token. Điều này rất đáng giá với dữ liệu chịu quy định, ngay cả khi tốc độ chỉ là 3 token mỗi giây. Hãy so sánh trung thực với phương án khác: tự host một model quy mô frontier cần nhiều phần cứng hơn một bậc độ lớn. 27B chạy trên CPU là điểm rẻ nhất trên đường cong đó mà output vẫn đáng để đọc.
Để benchmark các trường hợp trên, bạn cần input có cấu trúc thực tế. Hầu hết public data API yêu cầu tạo account trước khi cho bạn đo throughput. Demo endpoint của Strasmore (do chúng tôi vận hành) trả về SQL chỉ đọc trên dữ liệu cổ phiếu và options của Mỹ, không cần key và không cần signup. Gửi GET đến https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 sẽ trả về JSON mà bạn có thể pipe thẳng vào một prompt loop, kèm theo câu SQL chính xác đã tạo ra dữ liệu đó. Nhờ vậy, model có nội dung để tóm tắt và bạn có thể kiểm tra độc lập. Demo giới hạn ở 500 row và 20 giây cho mỗi lần gọi, với dữ liệu lịch sử từ 1 January 2025 trở đi. Mức này thoải mái vượt quá lượng dữ liệu mà một máy chạy 2 token mỗi giây có thể xử lý. Danh sách đầy đủ các column có tại https://ai.strasmore.com/api/demo/schema.
Nếu đây là lần đầu bạn cài Ollama, hướng dẫn đầy đủ để chạy Ollama trên VPS trình bày cách thiết lập service, HTTP API và các firewall rule mà hướng dẫn này giả định bạn đã có sẵn. Không expose port 11434 ra Internet. Ollama không có authentication tích hợp, nên bất kỳ ai truy cập được port này đều có thể dùng model của bạn và đọc prompt của bạn.
FAQ
Có model Qwen 3.8 27B trên Ollama không?
Có. Tính đến ngày 17 October 2026, Ollama library có entry qwen3.8, còn qwen3.8:27b (cũng được tag là latest) là bản build Q4_K_M 18 GB của model dense có 27.3 billion parameters, kèm vision projector và context window 256K. Model chạy local và cần Ollama v0.32.12 trở lên. Các tag qwen3.6:27b và qwen3.5:27b cũ hơn vẫn được liệt kê. Hãy kiểm tra https://ollama.com/library/qwen3.8/tags để xem danh sách hiện tại. Tag không tồn tại sẽ fail với Error: pull model manifest: file does not exist.
Tôi cần bao nhiêu RAM để chạy model Qwen 27B trên VPS?
32 GB là mức tối thiểu thực tế cho Q4_K_M. Weights cần 17 GB, vision projector thêm khoảng 0.9 GB, operating system cần khoảng 1.5 GB, còn KV cache thêm khoảng 1 GB cho mỗi 16,000 token context ở f16, vì chỉ 16 trong tổng số 64 layer của model giữ cache tăng dần. Gói 16 GB không thể chứa weights, còn swap không giúp được vì file được memory-map và kernel chỉ đọc lại file từ disk ở mỗi token. 64 GB cho đủ chỗ để dùng đầy đủ window 256K, kể cả khi dùng weights Q8_0 ở mức 29 GB.
Model 27B chạy trên CPU đạt bao nhiêu token mỗi giây?
Lấy memory bandwidth chia cho kích thước weights, sau đó lấy 50 đến 70 phần trăm kết quả. VPS DDR4-3200 two-channel có mức trần gần 3 tokens mỗi giây và đạt khoảng 2. Máy DDR5-4800 two-channel có mức trần gần 4.5 và đạt khoảng 3. Các server platform có nhiều channel hơn trông tốt hơn trên lý thuyết, nhưng memory bandwidth được chia sẻ cho mọi tenant trên host. Vì vậy, hãy tự đo bằng ollama run qwen3.8:27b --verbose và đọc dòng eval rate.
Tôi nên dùng Q4 hay Q8 trên VPS chỉ có CPU?
Trong gần như mọi trường hợp, hãy dùng Q4_K_M. Q8_0 cần 29 GB so với 17 GB, nên cần gói 64 GB và di chuyển gần gấp đôi lượng memory cho mỗi token, khiến tốc độ tokens mỗi giây giảm khoảng một nửa. Khác biệt về chất lượng giữa Q4_K_M và Q8_0 trên model 27B là nhỏ đối với hầu hết tác vụ. Thay vì dùng RAM cho Q8, hãy dùng phần RAM đó cho context dài hơn, vì context dài thay đổi những gì model có thể làm chứ không chỉ cách model diễn đạt.
Khi nào thuê GPU rẻ hơn VPS có nhiều RAM?
Khi duty cycle thấp hoặc có người đang chờ kết quả. GPU có 24 GB memory đạt khoảng 59 tokens mỗi giây với các weights này, so với 2 hoặc 3 trên VPS thông thường, và chỉ tính phí cho số giờ GPU chạy. VPS 64 GB tính phí cả tháng, dù model có được load hay không. Hãy tính số giờ mỗi ngày bạn thực sự generate token. Nếu dưới 2 hoặc 3 giờ, thuê GPU theo giờ thường thắng cả về tốc độ lẫn chi phí. Công việc batch ưu tiên thấp chạy liên tục là trường hợp VPS always-on có lợi thế.