Chạy Qwen 27B trên VPS với Ollama cần bao nhiêu RAM?

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 có tồn tại. Tính đến ngày 4 August 2026, thư viện Ollama hoàn toàn không có entry qwen3.8. Tag 27B gần nhất đã được release là qwen3.6:27b: 27.8 tỷ tham số, quantisation Q4_K_M, licence 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 July 2026.

Câu trả lời ngắn là có, nếu VPS có từ 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 two-channel 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 nhận 27.8B tham số, và 27.8 rất dễ bị nhớ nhầm thành 3.8. Ngoài ra còn có qwen3.5:27b, cùng một bản build Q4_K_M từ release 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 trong bài 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 Ollama tag 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 tag ngay trên máy.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show in ra architecture, số lượng parameter, độ dài context và quantisation của tag hiện có trên máy. Nếu dòng parameter là 27.8B và dòng quantisation là Q4_K_M, bạn đang dùng bản 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ộ weights với độ chính xác cao hơn, cùng một nhóm tag 35b-a3b là các model MoE (mixture of experts) và hoạt động rất khác trên CPU. Phần dưới sẽ nói thêm về các tag này.

Số lượng tham số nhân với số byte trên mỗi trọng số

[
  {
    "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 trọng số = số tham số * số bit trên mỗi trọng số / 8. Với đúng 4 bit, 27.8 tỷ tham số 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 trọng số trong thực tế.

Chênh lệch này không phải lỗi. Các format K-quant không lưu mọi tensor ở độ rộng danh nghĩa. Những tensor giảm chất lượng nhiều nhất khi nén sẽ được giữ ở 5 hoặc 6 bit. Các layer token embedding và output thường được giữ ở Q6_K hoặc Q8_0. Tên của format biểu thị một 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 kia của thang đo: 56 GB đối với BF16 tương đương 16.1 bit trên mỗi trọng số thay vì cố định ở 16, vì file còn chứa metadata và một bảng embedding full-precision.

Q5_K_M không có tag được công bố cho model này, nên dòng 19.8 GB được tính theo mức thông thường 5.7 bit trên mỗi trọng số của format đó thay vì đo thực tế. Q8_0 gần như tăng gấp đôi dung lượng so với Q4, lên 30 GB. Trên máy chỉ dùng CPU, mức tăng gấp đôi này khiến lưu lượng bộ nhớ trên mỗi token cũng tăng gấp đôi, nên tốc độ xử lý cũng giảm khoảng một nửa, tính theo token mỗi giây. Chỉ riêng lý do đó đã đủ để chọn Q4_K_M làm mặc định trong trường hợp này.

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.

[
  {
    "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 số liệu này giả định kiến trúc Qwen đã dùng trong những dense model gần đây cùng phân khúc 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 này tương đương 256 KiB cho mỗi token ở f16, tức 8 GB ở 32k token và 32 GB ở 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 báo 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à một 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, bạn sẽ tốn 64 GB cache ngoài số weights, trên một máy đã dùng 17 GB cho weights. Ollama không cấp toàn bộ context window theo mặc định. Nó load một window nhỏ hơn nhiều, và bạn phải chủ động tăng bằng OLLAMA_CONTEXT_LENGTH. 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 cache xuống còn một nửa hoặc thấp hơn. OLLAMA_KV_CACHE_TYPE=q8_0 lưu cache ở 8 bit thay vì 16 bit, giảm mức dùng cho 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, rồ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ể xử lý đồng thời nhiều request, và mỗi slot có một phần context riêng. Vì vậy, giữ parallelism ở giá trị mặc định sẽ âm thầm nhân số cache bạn đã dự trù. Nếu có nhiều hơn một người dùng máy này, phép nhâ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 cache slot và độ dài hàng đợi từ lâu trước khi số core trở thành yếu tố quyết định.

Dung lượng phù hợp với 8, 16, 32 và 64 GB RAM

[
  {
    "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, ở f16 cache, trên một Linux VPS không có giao diện đồ họa, với khoảng 1.5 GB dành cho hệ điều hành và một phần dự phòng nhỏ. Giá trị 0 nghĩa là bản thân weights không vừa, nên không có context nào dùng được.

8 GB và 16 GB không phải là 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, nên khi các page resident vượt quá RAM, kernel bắt đầu đẩy chúng ra và đọc lại liên tục. Mỗi token khi đó phải đọc hàng GB từ disk. Máy bị 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 khoảng 13 GB, đủ 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 context 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 còn một nửa, trên một máy vốn đã chậm. Với hầu hết mọi người, Q4 cùng context dài hơn là lựa chọn cân bằng hơn.

CPU inference trên VPS nhanh đến mức nào?

Sinh một token từ dense model có nghĩa là đọc toàn bộ weight từ memory một lần. Không phải chỉ một phần. Là toàn bộ. Vì vậy, giới hạn tốc độ không nằm ở số core mà nằm ở băng thông memory chia cho kích thước weight. Ở Q4, lượng dữ liệu truyền qua memory cho mỗi token là 17 GB.

[
  {
    "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
  }
]

Đó là mức trần, không phải số đo thực tế. Tốc độ đầu ra 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 peak lý thuyết. VPS DDR4-3200 hai kênh có mức trần 3 token mỗi giây, vì vậy hãy kỳ vọng khoảng 2. Máy DDR5-4800 hai kênh có mức trần 4.5, vì vậy 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 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 cấp host được chia sẻ cho mọi tenant trên máy đó, nên 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ều này. Đây là lý do hai gói VPS có cùng số vCPU có thể khác nhau gấp ba lần khi chạy cùng một model.

Thêm vCPU cũng sớm không còn giúp tăng tốc vì cùng lý do. Khi các core yêu cầu dữ liệu nhanh hơn khả năng cung cấp của memory controller, các thread bổ sung chỉ tạo thêm overhead lập lịch mà 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ử một nửa con số đó. Trên nhiều gói shared, thiết lập 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. Tác động thực tế là 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 chậm như trên. Dùng --verbose để đo riêng hai giai đoạn. Lệnh này in ra một prompt eval rate và một eval rate cho mỗi request.

Nếu dense 27B quá chậm, hãy xem các tag qwen3.6:35b-a3b trước khi bỏ cuộc với 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ỷ, nên lượng dữ liệu truyền qua memory cho 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, và Ollama và llama.cpp cung cấp các tùy chọn tuning CPU khác nhau trên cùng code inference nền tảng.

Khi nào nên thuê GPU theo giờ

[
  {
    "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
  }
]

Áp dụng cùng công thức cho băng thông bộ nhớ GPU được công bố sẽ cho một nhóm kết luận khác. Một card dành cho người dùng phổ thông 24 GB 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 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 đó chạy bộ nhớ ở 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 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 một request mỗi 30 giây, vì máy chỉ chạy CPU không có dư địa batching và queue sẽ cứ tăng lên.

So sánh chi phí không đơn giản như nhìn qua. VPS 64 GB tính phí cho mọi giờ trong tháng, dù model có được load hay không, còn GPU instance chỉ tính phí cho những 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, sau đó mới tính giá. Chọn VPS có GPU trình bày những điểm cần kiểm tra ngay trên instance, còn vLLM vượt Ollama khi bạn 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 mà nhiều người bỏ qua. Giữ model 27B trên CPU để xử lý batch và đặt một model API được host phía trước đường xử lý tương tác. Không có yêu cầu nào bắt buộc một model phải phục vụ cả hai mục đích.

Cài Ollama và đo hiệu năng trên 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 service systemd chạy bằng user chuyên dụng ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --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ỳ model nào. Nếu cột total trên dòng Mem có giá trị dưới 32, hãy dừng lại và chọn model nhỏ hơn. Pull 17 GB dữ liệu 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ố liệu bạn cần. eval rate là số token mỗi giây trong giai đoạn 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 thiết lập: trên CPU, việc nạp lại 17 GB từ đĩa trong mỗi request tốn nhiều thời gian hơn chính request đó.

Trong khi model đang được load, hãy kiểm tra mức sử dụng tài nguyên từ terminal thứ hai.

ollama ps

Cột SIZE là mức sử dụng bộ nhớ thực tế, bao gồm cả KV cache. Giá trị này phải 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. Với 8192 token và cache 8-bit, hãy dự kiến thêm khoảng một gigabyte ngoài dung lượng weights. Nếu cache vẫn ở f16 thì mức này là 2 GB. Cột PROCESSOR phải in ra 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ố liệu tốc độ trong hướng dẫn này không mô tả đúng máy của bạn.

Các trường hợp 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 giá trị, 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 nâng cấp lên plan lớn hơn.

Process biến mất giữa lúc trả lời. Client không hiển thị thông tin hữu ích, còn journalctl -u ollama -n 50 cho thấy service đang restart. Chạy dmesg -T | tail. Nếu có một dòng chứa Out of memory: Killed process ... (ollama) thì kernel OOM killer đã dừng process. Trường hợp này xảy ra khi kiểm tra trước khi tải đã 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 lỗi ngay lập tức. Error: pull model manifest: file does not exist có nghĩa là tag không có trong library. Gõ qwen3.8:27b cũng tạo ra chính xác lỗi này, và lỗi chính tả trong số phiên bản cũng vậy. Xác nhận tag trên trang library trước khi kiểm tra network.

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 hệ thống đang paging, không phải thiếu năng lực tính toán. Chạy vmstat 1 trong lúc model đang sinh output. 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 rồi output chạy nhanh hơn. Đó là prefill và là hành vi bình thường. Mỗi request không hit 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 yếu tố 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 sẽ 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 hàng đợi xử lý. Tóm tắt tài liệu, gắn nhãn hàng loạt, trích xuất trường dữ liệu từ backlog file và review code không cần giám sát đều có thể chấp nhận tốc độ này vì không có ai phải chờ phản hồi. Hỗ trợ lập trình nằm ngay ranh giới đó. Vì vậy, giao cho coding agent một model bạn tự host sẽ 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ập luận về quyền riêng tư mới là điểm quan trọng. Model chạy trên phần cứng do bạn thuê và kiểm soát, không có request nào rời khỏi máy, và bạn không phải trả phí theo token. Điều đó rất đáng giá đối với dữ liệu chịu quy định, ngay cả khi tốc độ chỉ là 3 token mỗi giây. Hãy đánh giá trung thực so với phương án thay thế: tự host một model có quy mô tương đương 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.

Nếu đây là lần đầu bạn cài Ollama, hướng dẫn đầy đủ để chạy Ollama trên VPS sẽ 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ó. Không expose port 11434 ra Internet. Ollama không có sẵn authentication, vì vậy bất kỳ ai truy cập được port này đều có thể sử dụng model của bạn và đọc cá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 August 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 27.8 billion 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ẽ lỗi với Error: pull model manifest: file does not exist.

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ó dung lượng 17 GB, hệ điều hành cần khoảng 1.5 GB, còn KV cache tăng 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 đủ dung lượng để dùng context dài hoặc weights Q8_0 có dung lượng 30 GB.

Model 27B sẽ cho bao nhiêu token mỗi giây trên CPU?

Lấy memory bandwidth chia cho dung lượng weights, rồi lấy 50 đến 70 phần trăm kết quả. VPS DDR4-3200 hai kênh có mức trần gần 3 token mỗi giây và đạt khoảng 2. Máy DDR5-4800 hai kênh có mức trần gần 4.5 và đạt khoảng 3. Các server platform nhiều kênh hơn trông tốt hơn trên lý thuyết, nhưng memory bandwidth được chia sẻ giữa 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.

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ó dung lượng 30 GB, so với 17 GB của Q4_K_M. Vì vậy, 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. Khác biệt 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ào đó, hãy dành RAM cho context dài hơn, vì context thay đổi khả năng của model chứ không chỉ cách model diễn đạt.

Khi nào thuê GPU rẻ hơn dùng VPS 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 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í trong những 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 có lợi hơn 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ế.