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

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 tồn tại. Tính đến ngày 4 tháng 8 năm 2026, thư viện Ollama hoàn toàn không có entry qwen3.8. Tag 27B đã phát hành gần nhất là qwen3.6:27b: 27.8 tỷ parameter, 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ó từ 32 GB RAM trở lên, nhưng tốc độ sẽ chậm. Model dense 27B ở Q4 cần khoảng 17 GB RAM chỉ cho weights, chưa tính 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à do nhầm với số lượng parameter. Trang Ollama của qwen3.6:27b ghi model có 27.8B parameter, và 27.8 rất dễ bị nhớ nhầm thành 3.8 về sau. Ngoài ra còn có qwen3.5:27b, cùng bản build Q4_K_M của bản phát hành trước. Hãy kiểm tra danh sách hiện tại trước khi sao chép command, 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, cách tính trong bài vẫn áp dụng, vì nó phụ thuộc vào số lượng parameter 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 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 kiến trúc, số lượng parameter, độ dài context và quantisation của tag bạn thực sự đã có. Nếu dòng parameter hiển thị 27.8B và dòng quantisation hiển thị 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 ở độ 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 parameter nhân số byte trên mỗi weight

[
  {
    "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ế.

Khoảng chênh lệch này 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 giảm chất lượng nhiều nhất khi nén đượ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 phản ánh 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 đo: 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 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 weight của format đó thay vì đo thực tế. Q8_0 gần như gấp đô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 độ token mỗi giây cũng giảm gần một nửa. Chỉ riêng vì lý do đó, Q4_K_M là lựa chọn mặc định phù hợp ở đâ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 lưu 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 con số trên giả định cấu trúc mà Qwen đã dùng trong các 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 trúc này cần 256 KiB cho mỗi token ở f16. Vì vậy, 32k token cần 8 GB và 128k token cần 32 GB. Không nên á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à 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, riêng cache sẽ cần 64 GB, ngoài số 17 GB mà máy đã dùng cho weights. Ollama không mặc định cấp toàn bộ window. 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 nhu cầu 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 đồng thời và 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 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, nếu giữ parallelism ở giá trị mặc định, cache thực tế sẽ âm thầm tăng theo hệ số mà bạn không đưa vào dự toán.

8, 16, 32 và 64 GB RAM chứa được gì

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

Hãy đọc hai con số này là hàng nghìn token context có thể chứa cùng với weights, 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 dung lượng dự phòng nhỏ. Giá trị 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 là trường hợp sát giới hạn. 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 đẩy chúng ra rồi đọc lại. Mỗi token sau đó phải đọc hàng GB dữ liệu 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 sử dụng được. Weights chiếm 17 GB và bạn còn khoảng 13 GB, đủ cho khoảng 32k token context f16 khi vẫn có phần dự phòng. Weights Q8_0 ở mức 30 GB hoàn toàn không vừa với mức RAM này.

64 GB cho dư dả hơn. Q4 còn chỗ cho khoảng 128k token context, còn weights Q8_0 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ì: đầu ra 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ừ 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à nằm ở memory bandwidth chia cho kích thước của weight. Ở Q4, lượng memory traffic 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 độ output thực tế thường chỉ đạt khoảng 50 đến 70 phần trăm con số trên, vì memory latency và cơ chế prefetch không hoàn hảo khiến bạn không bao giờ đạt peak 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 máy chủ lớn đi kèm một cảnh báo. Một 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. Memory bandwidth 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 bandwidth độ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 vẫn có thể khác nhau gấp 3 lần khi chạy cùng một model.

Tăng thêm vCPU cũng sớm không còn giúp ích vì cùng 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 scheduling overhead. Chúng không đem lại lợi ích nào khác. Đặt OLLAMA_NUM_THREAD bằng số core vật lý của bạn, đo lại, rồi thử giảm còn 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 lượt xử lý toàn bộ 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ì bandwidth, nên tốc độ có tăng theo số core. Trong thực tế, bạn sẽ thấy một khoảng dừng dài trước khi output bắt đầu nếu prompt lớn, sau đó là tốc độ ổn định chậm như trên. Đo riêng 2 phầ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 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, memory traffic 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 RAM footprint để 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 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
  }
]

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 kết luận khác. Một card dành cho người dùng phổ thông có 24 GB bộ nhớ chỉ đạt tối đa 59 token mỗi giây với các weight này. Một card dành cho data centre hiện nay đạt 197. 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 đó 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 là lựa chọn 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 đố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ỉ dùng CPU không có đủ headroom để batching và queue sẽ tiếp tục tăng.

So sánh chi phí không đơn giản như nhìn bề ngoài. VPS 64 GB tính phí cho từng giờ trong tháng, bất kể model có đang được load hay không, còn GPU instance chỉ tính phí trong 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 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ì vLLM thực hiện batching đú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 API được host phía trước luồng 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 loại workload.

Cài đặt Ollama và đo trên chính máy của bạn

Script cài đặt là script chính thức và sẽ 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 -g

ollama --version phải hiển thị 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, vì pull 17 GB mà máy không thể chạy sẽ làm 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 môi trường interactive 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 lúc 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 cho 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 memory footprint từ một terminal thứ hai.

ollama ps

Cột SIZE là memory footprint 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. Ở 8192 token với cache 8-bit, hãy dự kiến thêm khoảng 1 gigabyte ngoài dung lượng weights, so với 2 GB nếu cache vẫn ở f16. 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ố liệu tốc độ trong hướng dẫn này không mô tả đúng máy của bạn.

Các dạng lỗi và chuỗi chính xác bạn sẽ thấy

Model không tải được. Ollama in ra 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) thì kernel OOM killer đã dừng 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.

Lệnh 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 sẽ tạo ra đúng lỗi này, và lỗi gõ sai version number cũng vậy. Xác nhận tag trên trang library trước khi quy lỗi cho network.

Mọi thứ đều hoạt động nhưng tốc độ chậm đến mức không thể sử dụng. Tốc độ dưới 1 token mỗi giây trên một máy có đủ RAM thường cho thấy hệ thống đang paging, không phải compute bị chậm. 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 luôn 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 memory.

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 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 với 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 dùng được cho chat, nhưng hoàn toàn phù hợp với việc xử lý qua queue. Tóm tắt tài liệu, gắn nhãn hàng loạt, trích xuất trường từ mộ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.

Lý do chính là quyền riêng tư. 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à bạn không phải trả phí theo token. Điều đó rất có giá trị 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ế: self-host model quy mô frontier cần nhiều phần cứng hơn một bậc độ lớn, còn model 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 bao gồm thiết lập service, HTTP API và các rule 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

Ollama có model Qwen 3.8 27B 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, đều là bản build Q4_K_M của model dense có 27.8 tỷ tham số. Số 3.8 trong cụm tìm kiếm gần như chắc chắn là số lượng tham số 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à dùng pull qwen3.6:27b nếu bạn muốn bản 27B mới nhất đã phát hành. Tag không tồn tại sẽ lỗi 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. Weight 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 weight, và swap không giúp được vì file được memory-map; kernel sẽ phải đọc lại file từ disk cho mỗi token. 64 GB cho bạn đủ chỗ để dùng context dài hoặc weight Q8_0 có dung lượng 30 GB.

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

Lấy memory bandwidth chia cho dung lượng weight, sau đó 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 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.

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ó 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à phải 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ành RAM cho context dài hơn. Context dài thay đổi khả năng của model, 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 token mỗi giây với các weight này, so với 2 hoặc 3 trên VPS thông thường, và chỉ tính phí trong 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ự cần generate token. 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 luôn bật có lợi thế.