Bởi Chạy Qwen 27B trên VPS với Ollama: cần bao nhiêu RAM?
Không có Qwen 3.8 trên Ollama. Xem cách chạy tag 27B hiện có trên VPS chỉ dùng CPU, vì sao VPS 8 và 16 GB không đủ, và mức RAM 32 đế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, trước hết bạn cần một model tag thực sự tồn tại. Tính đến ngày 4 tháng 8 năm 2026, Ollama library hoàn toàn không có entry qwen3.8. Tag 27B đã được phát hành gần nhất là qwen3.6:27b: 27.8 tỷ tham số, quantisation Q4_K_M, giấy phép Apache 2.0. Mọi command và mọi con số bên dưới đều dùng tag đó trên Ollama v0.32.5, được phát hành ngày 27 tháng 7 năm 2026.
Câu trả lời ngắn là có, nếu VPS có 32 GB RAM trở lên, nhưng tốc độ sẽ chậm. Một model dense 27B ở Q4 cần khoảng 17 GB RAM chỉ cho weights, trước khi lưu một token context nào. Vì vậy, các gói 8 GB và 16 GB hoàn toàn không phù hợp. Trên một VPS DDR4 hai kênh phổ biến, tốc độ tối đa khoảng 3 token mỗi giây, chậm hơn tốc độ đọc của hầu hết mọi người.
Con số 3.8 xuất phát từ đâu? Nhiều khả năng là từ số lượng tham số. Trang Ollama của qwen3.6:27b ghi model có 27.8B tham số, và 27.8 rất dễ được nhớ nhầm thành 3.8. Ngoài ra còn có qwen3.5:27b, cùng bản build Q4_K_M từ bản phát hành trước. Hãy kiểm tra danh sách hiện tại trước khi copy bất kỳ command nào tại trang tag qwen3.6 của Ollama. Nếu một qwen3.8 thực sự được phát hành sau này, phép tính ở đây vẫn áp dụng vì nó phụ thuộc vào số lượng tham số và số bit trên mỗi weight, không phụ thuộc vào số phiên bản.
Nê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 có tồn tại vẫn có thể không chạy được locally. Đây là điểm khiến nhiều người gặp lỗi với GLM 5.2, được liệt kê trong library nhưng chỉ được phục vụ từ cloud của Ollama.
ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist
ollama pull qwen3.6:27b
ollama show qwen3.6: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 là 27.8B và dòng quantisation là Q4_K_M, bạn đang dùng đúng build mà hướng dẫn này dựa trên. Library cũng có qwen3.6:27b-q8_0 và qwen3.6:27b-bf16 cho cùng bộ weight ở precision cao hơn, cùng một nhóm tag 35b-a3b là các model MoE (mixture of experts) và hoạt động trên CPU rất khác. Phần dưới sẽ nói thêm về các tag này.
Số lượng parameter nhân với số byte trên mỗi weight
The data behind this chart
[
{
"label": "Q4_K_M",
"size_gb": 17,
"bits_per_weight": 4.89,
"notes": "published tag qwen3.6:27b"
},
{
"label": "Q5_K_M",
"size_gb": 19.8,
"bits_per_weight": 5.7,
"notes": "computed, no library tag exists"
},
{
"label": "NVFP4",
"size_gb": 20,
"bits_per_weight": 5.76,
"notes": "published tag 27b-nvfp4"
},
{
"label": "Q8_0",
"size_gb": 30,
"bits_per_weight": 8.63,
"notes": "published tag 27b-q8_0"
},
{
"label": "BF16",
"size_gb": 56,
"bits_per_weight": 16.1,
"notes": "published tag 27b-bf16"
}
]Công thức chỉ có một dòng. Số byte của weight = số parameter * số bit trên mỗi weight / 8. Với đúng 4 bit, 27.8 tỷ parameter sẽ chiếm 13.9 GB. Tag Q4_K_M được phát hành có kích thước 17 GB, tương đương 4.89 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 ở đúng độ rộng danh nghĩa. Những tensor bị giảm chất lượng nhiều nhất khi nén sẽ được giữ ở 5 hoặc 6 bit, còn các layer token embedding và output thường được giữ ở Q6_K hoặc Q8_0. Tên format thể hiện giá trị trung bình, và giá trị trung bình thực tế gần 4.9. Hiệu ứng tương tự cũng xuất hiện ở đầu còn lại của thang: 56 GB với BF16 tương đương 16.1 bit trên mỗi weight thay vì cố định ở 16, vì file còn chứa metadata và một bảng embedding full-precision.
Q5_K_M chưa có tag được công bố cho model này, nên dòng 19.8 GB được tính theo mức 5.7 bit trên mỗi weight thường dùng cho format đó thay vì đo thực tế. Q8_0 gần như tăng gấp đôi so với Q4, lên 30 GB. Trên máy chỉ chạy CPU, mức tăng gấp đôi này khiến memory traffic trên mỗi token tăng gấp đôi, nên tốc độ cũng giảm khoảng một nửa, tính theo tokens per second. Vì riêng lý do đó, Q4_K_M là lựa chọn mặc định phù hợp ở đây. Nếu bạn muốn xem khía cạnh chất lượng thay vì khía cạnh bộ nhớ, so sánh chi tiết hơn giữa Q4, Q8 và fp16 sẽ cho thấy output thực sự bắt đầu suy giảm ở đâu.
Chi phí của KV cache khi context tă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 đã xử lý) 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.
The data behind this chart
[
{
"label": "4k tokens",
"kv_f16_gb": 1,
"kv_q8_gb": 0.5
},
{
"label": "8k tokens",
"kv_f16_gb": 2,
"kv_q8_gb": 1
},
{
"label": "16k tokens",
"kv_f16_gb": 4,
"kv_q8_gb": 2
},
{
"label": "32k tokens",
"kv_f16_gb": 8,
"kv_q8_gb": 4
},
{
"label": "64k tokens",
"kv_f16_gb": 16,
"kv_q8_gb": 8
},
{
"label": "128k tokens",
"kv_f16_gb": 32,
"kv_q8_gb": 16
}
]Các con số này giả định cấu hình Qwen đã dùng trong những dense model gần đây cùng nhóm kích thước: 64 layer, 8 key/value head với GQA (grouped-query attention) và head dimension là 128. Cấu hình đó tương đương 256 KiB cho mỗi token ở f16, tức 8 GB tại 32k token và 32 GB tại 128k. Đừng áp dụng máy móc phép tính này cho máy của bạn. Hãy load model rồi đọc cột SIZE của ollama ps. Cột này hiển thị tổng weights, cache và overhead trong một giá trị duy nhất.
Đây là lý do context 256K trên model card chỉ là con số nổi bật, không phải cấu hình nên dùng ngay. Nếu lấp đầy context này ở f16, cache sẽ chiếm 64 GB ngoài phần weights, trong khi máy đã dùng 17 GB cho weights. Ollama không cấp toàn bộ window theo mặc định. Nó load một window nhỏ hơn nhiều, và bạn tăng kích thước này một cách có chủ đích bằng OLLAMA_CONTEXT_LENGTH. Biến cấp server này không phải là cần gạt duy nhất. Đặt num_ctx trong từng request cho phép bạn giữ default tiết kiệm cho mọi 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 setting có thể giảm một nửa hoặc hơn lượng cache. OLLAMA_KV_CACHE_TYPE=q8_0 lưu cache ở 8 bit thay vì 16 bit, giảm cache của 32k token từ 8 GB xuống 4 GB. Tính năng này cần flash attention, nên hãy đặt OLLAMA_FLASH_ATTENTION=1, đồng thời xác nhận mức giảm trong ollama ps thay vì mặc định cho rằng setting đã được áp dụng. OLLAMA_NUM_PARALLEL=1 cũng quan trọng tương tự. Ollama có thể phục vụ nhiều request cùng lúc, và mỗi slot có một phần context riêng. Vì vậy, nếu giữ parallelism ở giá trị mặc định, tổng cache cần dự trù sẽ âm thầm tăng theo cấp số nhân. Nếu có nhiều hơn một người dùng máy này, sự nhân lên đó là nơi vấn đề bắt đầu. 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 queue từ rất lâu trước khi số core trở thành yếu tố quyết định.
8, 16, 32 và 64 GB RAM chứa được gì
The data behind this chart
[
{
"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": 32,
"q8_max_ctx_ktok": 0,
"notes": "Q4 fits with room to spare. Q8 weights do not fit."
},
{
"label": "64 GB",
"q4_max_ctx_ktok": 128,
"q8_max_ctx_ktok": 64,
"notes": "Both fit. Q8 leaves much less room for context."
}
]Đọc 2 con số này là số nghìn token context có thể dùng cùng với weights, khi dùng f16 cache, trên một Linux VPS headless còn khoảng 1.5 GB cho hệ điều hành và một phần dung lượng dự phòng nhỏ. Số 0 nghĩa là bản thân weights không vừa, nên không chứa được context nào.
8 GB và 16 GB không phải các mức sát giới hạn. 17 GB weights không thể vừa 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. Khi các page resident vượt quá RAM, kernel bắt đầu evict rồi đọc lại chúng. Khi đó, mỗi token phải đọc hàng GB từ disk. Máy sẽ ở trạng thái iowait cao và tạo ra thấp hơn 1 token mỗi giây.
32 GB là mức bắt đầu dùng được. Weights chiếm 17 GB, còn lại khoảng 13 GB. Dung lượng này đủ cho khoảng 32k token context f16 với một phần dự phòng. Q8_0 weights ở mức 30 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 khoảng 128k token context, còn Q8_0 weights vẫn vừa với khoảng 64k token phía sau. Trước khi trả tiền cho 64 GB để dùng Q8, hãy xác định 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. Với gần như mọi người, Q4 cùng context dài hơn là lựa chọn cân bằng tốt hơn.
Suy luận CPU trên VPS nhanh đến mức nào?
Sinh một token từ dense model nghĩa là đọc mọi weight từ memory một lần. Không phải chỉ 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, lượng traffic memory cho mỗi token là 17 GB.
The data behind this chart
[
{
"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à các 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ố hiển thị, vì độ trễ memory và prefetching không hoàn hảo khiến bạn không bao giờ đạt đỉnh lý thuyết. VPS dùng DDR4-3200 hai channel có mức trần 3 token mỗi giây, nên hãy kỳ vọng khoảng 2. Máy dùng DDR5-4800 hai channel có mức trần 4.5, nên hãy kỳ vọng khoảng 3.
Các dòng server lớn đi kèm một cảnh báo. Nền tảng EPYC 12 channel 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 cấp host, được mọi tenant trên máy đó dùng chung. Vì vậy, một slice 8 vCPU không đi kèm 12 channel 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ể chênh nhau 3 lần khi chạy cùng một model.
Thêm vCPU cũng sớm không còn giúp ích vì cùng nguyên nhân. Khi các core yêu cầu dữ liệu nhanh hơn tốc độ memory controller có thể cung cấp, thêm thread chỉ làm tăng overhead lập lịch và không đem lại lợi ích nào khác. Đặt OLLAMA_NUM_THREAD bằng số core vật lý, đo tốc độ, rồi thử giảm xuống một nửa. 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 quá trình 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, nên tốc độ có tăng theo số core. Trên thực tế, với prompt lớn, hệ thống sẽ tạm dừng lâu trước khi bắt đầu output, sau đó duy trì tốc độ ổn định chậm như trên. Đo riêng hai phần bằng --verbose. Lệnh này in ra prompt eval rate và eval rate cho mỗi request.
Nếu dense model 27B quá chậm, hãy xem các tag qwen3.6:35b-a3b trước khi từ bỏ 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.8 tỷ parameter. Vì vậy, traffic 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 inference code nền tảng.
Khi nào nên thuê GPU theo giờ
The data behind this chart
[
{
"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 memory của GPU được công bố sẽ cho ra một kết luận khác. Một card consumer 24 GB có mức trần 59 token/giây với các weight này. Một card data centre hiện nay đạt 197. Không thể thu hẹp khoảng cách này bằng cách tinh chỉnh số lượng thread. Card này chạy memory ở 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 chồng 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 phải chờ output, hoặc khi request đến nhanh hơn 1 request mỗi 30 giây, vì máy chỉ chạy CPU không có đủ headroom để batching và queue sẽ cứ dài thêm.
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, còn GPU instance chỉ tính phí trong thời gian bạn bật nó. Nếu usage 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, sau đó 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ụ request đồng thời trên GPU vì vLLM batching các request đó đúng cách.
Có một lựa chọn thứ ba thường bị bỏ qua. Giữ model 27B trên CPU để xử lý batch, đồng thời đặt một model hosted API phía trước interactive path. Không có yêu cầu nào buộc một model phải phục vụ cả hai loại workload.
Cài đặt Ollama và đo trên máy của bạn
Script cài đặt là script chính thức và 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.5 hoặc mới hơn. 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 17 GB mà máy không thể chạy sẽ lãng phí một giờ và rất nhiều dung lượng đĩa.
Đặ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 environment 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.6:27b
ollama run qwen3.6: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ừ đĩa, vì vậy OLLAMA_KEEP_ALIVE=60m được đặt: trên CPU, việc đọc lại 17 GB từ đĩa 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 nghỉ 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 footprint từ terminal thứ hai.
ollama psCột SIZE là footprint memory thực tế, bao gồm cả KV cache. Giá trị này thường gần bằng dung lượng weights cộng với dòng tương ứng với context length của bạn trong biểu đồ KV. Ở 8192 token với cache 8-bit, hãy dự kiến thêm khoảng một gigabyte trên dung lượng weights. Nếu cache vẫn ở f16, con số tương ứng là 2 GB. 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 con số 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à chính xác chuỗi bạn sẽ thấy
Model từ chối load. 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à 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 câu 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) thì kernel OOM killer đã kill process. Trường hợp này xảy ra khi kiểm tra trước khi load đã thành công nhưng cache tăng vượt quá mức ước tính trong một cuộc hội thoại dài. Giảm context length.
Pull fail ngay lập tức. Error: pull model manifest: file does not exist có nghĩa là tag không tồn tại trong library. Gõ qwen3.8:27b cũng cho đúng lỗi này, tương tự mọi lỗi gõ sai version. Xác nhận tag trên trang library trước khi cho rằng mạng có vấn đề.
Mọi thứ đều hoạt động nhưng tốc độ chậm không thể chịu được. 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 có nghĩa là kernel đang swap. Cách xử lý là giảm context hoặc giảm số model được load. Nếu wa duy trì ở mức cao nhưng không có hoạt động swap, các weight được memory-map đang bị đọc lại từ disk. Điều đó có nghĩa là chúng thực sự không vừa trong bộ nhớ.
Token đầu tiên mất 30 giây, sau đó output nhanh hơn. Đó là prefill và hoàn toàn bình thường. Mỗi request không dùng được 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 tinh chỉnh bất kỳ thứ gì khác.
CPU-only 27B thực sự phù hợp cho việc gì
Hãy đặt kỳ vọng dựa trên các con số, 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 dài 500 token mất từ 2 đến 4 phút. Tốc độ này không phù hợp cho chat nhưng hoàn toàn dùng được cho hàng đợi xử lý. Model suy nghĩ trước khi trả lời còn làm phép tính này tệ hơn, vì các token suy luận ẩn được tạo ở cùng tốc độ chậm như phần trả lời. Vì vậy, chọn mức độ suy luận phù hợp với công việc là một trong số ít cách rút ngắn thời gian 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 dữ liệu từ một backlog file và review code không cần giám sát đều chịu được tốc độ này, vì không có ai phải chờ câu trả lời. Hỗ trợ coding nằm ngay ở ranh giới đó. Vì vậy, trỏ một coding agent vào model bạn tự host có ích cho các job chạy nền như tạo commit message và dựng 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ề privacy 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, và không có chi phí tính theo token. Điều này rất đáng giá với dữ liệu thuộc diện quản lý nghiêm ngặt, ngay cả khi tốc độ chỉ là 3 token mỗi giây. Hãy so sánh một cách thực tế với phương án khác: self-host một model quy mô frontier cần nhiều phần cứng hơn một bậc độ lớn, còn 27B chạy trên CPU là điểm rẻ nhất trên đường cong này mà output vẫn đáng đọc.
Để benchmark các trường hợp đó, 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 bạn có thể đo throughput. Demo endpoint của Strasmore (do chúng tôi vận hành) thực thi SQL chỉ đọc trên dữ liệu thị trường Mỹ trong 22 năm, không cần key và không cần signup. Một GET tới https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 trả về JSON mà bạn có thể pipe thẳng vào một prompt loop, cùng với 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. Giới hạn là 500 row và 20 giây cho mỗi lần gọi, cao hơn đáng kể so với lượng dữ liệu mà một máy chạy ở tốc độ 2 token mỗi giây có thể tiêu thụ. Danh sách đầy đủ các column có tại https://api.strasmore.com/v1/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 rule của firewall mà hướng dẫn này giả định bạn đã có. 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ể sử 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?
Không. Tính đến ngày 4 tháng 8 năm 2026, thư viện Ollama không có namespace qwen3.8. Các tag 27B hiện có là qwen3.5:27b và qwen3.6:27b, cả hai đều là bản build Q4_K_M của model dense có 27.8 tỷ parameter. Số 3.8 trong từ khóa tìm kiếm gần như chắc chắn là số parameter 27.8B bị nhớ nhầm thành số phiên bản. Kiểm tra https://ollama.com/library/qwen3.6/tags để xem danh sách hiện tại và pull qwen3.6:27b nếu bạn muốn bản 27B mới nhất đã được release. 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 chiếm 17 GB, hệ điều hành cần khoảng 1.5 GB, còn KV cache thêm khoảng 1 GB cho mỗi 4000 token context ở f16. Gói 16 GB không đủ chứa weights, và swap không giúp được vì file được memory-map, nên kernel chỉ đọc lại file từ disk cho mỗi token. 64 GB cho bạn đủ chỗ để dùng context dài hoặc weights Q8_0 ở mức 30 GB.
Model 27B sẽ tạo được bao nhiêu token mỗi giây trên CPU?
Lấy memory bandwidth chia cho kích thước weights, rồi lấy 50 đến 70 phần trăm kết quả đó. VPS DDR4-3200 hai kênh có giới hạn gần 3 token mỗi giây và đạt khoảng 2. Máy DDR5-4800 hai kênh có giới hạ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.6: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 là 30 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 độ token mỗi giây giảm khoảng một nửa. Với hầu hết tác vụ, chênh lệch chất lượng giữa Q4_K_M và Q8_0 trên model 27B là nhỏ. Thay vào đó, hãy dùng RAM để tăng context, vì context 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ờ. GPU có 24 GB memory đạt khoảng 59 token 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 xem thực tế mỗi ngày bạn generate token trong bao nhiêu giờ. 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 liên tục nhưng ưu tiên thấp là trường hợp VPS luôn bật có lợi hơn.