Chạy Meta Muse Glimmer 30B trên VPS cần bao nhiêu RAM?

Muse Glimmer cần gì trên VPS

Muse Glimmer chạy trên một Linux VPS thông thường, không cần GPU. Tag bạn pull quyết định model có vừa trong bộ nhớ hay không. Meta Superintelligence Labs phát hành model này vào ngày 10 August 2026 theo giấy phép Apache 2.0: 30 billion parameter, context window 128K và một perception encoder chuyên dụng có 1.8B parameter để model có thể đọc ảnh cùng với văn bản. Meta định hướng model này cho các local agent chạy liên tục thay vì chat, với mức reasoning do bạn đặt cho từng request.

Các tag Ollama được công bố và đọc vào ngày 16 August 2026 có dung lượng từ 17 GB đến 59 GB. Khoảng này là toàn bộ bài toán sizing. Tag mặc định được liệt kê ở mức khoảng 18 GB, vì vậy VPS nhỏ nhất có thể dùng được rõ ràng phải có nhiều hơn 18 GB RAM trống. Dung lượng disk để tải model và bộ nhớ cho context window cần được tính thêm.

Nên pull tag muse-glimmer nào?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama liệt kê 11 tag cho model này không phải bản dành cho Apple. Các tag này chứa cùng 30 tỷ weight, được lưu ở những độ chính xác số khác nhau. Kích thước hiển thị là dung lượng bạn phải download, đồng thời cũng gần bằng lượng memory bạn phải có trước khi cộng thêm context.

Hai bản 4-bit là các bản nhỏ: 30b-nvfp4 ở mức 17 GB và 30b-q4_K_M ở mức 18 GB. Tag mặc định 30b có cùng kích thước với bản q4_K_M. Hai bản 8-bit, 30b-q8_0 và 30b-mxfp8, có kích thước gần 31 GB. 30b-bf16 là bản phát hành 16-bit chưa quantise, có kích thước 57 GB. Mức này cần nhiều RAM hơn hầu hết server thuê có thể cung cấp với mức giá phù hợp cho một side project.

Các tag -dflash là những bản build tương tự nhưng có hỗ trợ DFlash, và mỗi bản đều lớn hơn bản không có DFlash tương ứng. Ollama mô tả DFlash là một tính năng tăng tốc, đồng thời minh họa tính năng này trên Apple Silicon và GPU desktop. Trên VPS chỉ có CPU, bạn sẽ phải dùng thêm dung lượng đó trong memory thực cho một tính năng được đo trên phần cứng khác. Vì vậy, hãy bắt đầu với tag không có DFlash và chỉ thay đổi một yếu tố mỗi lần.

Hãy bắt đầu với 4-bit, trừ khi bạn có lý do cụ thể để không dùng. Chuyển từ 4-bit sang 8-bit gần như làm tăng gấp đôi số byte CPU phải đọc cho mỗi token được sinh ra, khiến throughput giảm trong khi memory use tăng. Chi phí thực tế của quantisation q4, q8 và fp16 giải thích trade-off này. Trên một máy chỉ có CPU, câu trả lời ngắn gọn là bản 4-bit là lựa chọn duy nhất đáng dùng để bắt đầu.

Vì sao các tag MLX không làm gì trên Linux server

MLX là framework mảng của Apple, còn engine MLX của Ollama là backend dành cho Apple Silicon. Mọi tag có mlx trong tên đều được build cho engine và phần cứng đó. Trên VPS Linux x86, đó là hàng chục gigabyte dữ liệu tải xuống mà bạn không thể chạy, và chúng chỉ chiếm chỗ trên disk. Các số liệu tốc độ trong thông báo được đo trên máy Mac chỉ áp dụng cho những tag đó, nên cũng không mô tả server của bạn. Khi đọc danh sách tag trên trang model, trước tiên hãy loại mọi tên có mlx, sau đó chọn kích thước từ các tag còn lại.

Cần bao nhiêu RAM và dung lượng đĩa?

Có hai thành phần chiếm bộ nhớ, và chỉ một trong số đó phụ thuộc vào kích thước tag. Dung lượng weights được cố định theo tag bạn pull. KV cache, tức trạng thái theo từng token mà model giữ cho cuộc hội thoại, tăng theo độ dài context bạn cấu hình. Tài liệu của Ollama lưu ý rằng việc phục vụ các request song song sẽ nhân context với số request đang xử lý. Vì vậy, một máy trả lời đồng thời cho 2 agent cần nhiều bộ nhớ hơn cùng máy đó khi chỉ trả lời 1 agent.

Không nên lấy một con số RAM từ bất kỳ hướng dẫn nào, kể cả hướng dẫn này. Hãy pull tag, gửi cho model 1 prompt, rồi chạy 2 lệnh sau trong khi model vẫn đang nằm trong memory.

ollama ps
free -h

ollama ps cho biết hiện đang load những gì và công việc được chia giữa CPU và GPU như thế nào. free -h cho biết còn lại bao nhiêu tài nguyên. Hai output này trên chính máy của bạn đáng tin hơn mọi bảng công bố, vì chúng đã bao gồm context setting, quantisation và mọi tiến trình khác đang chạy trên server.

Dữ liệu trên disk là phần dễ tính hơn. Ollama lưu model trong /usr/share/ollama/.ollama/models trên Linux. Trên hầu hết image VPS, đường dẫn này nằm trên root filesystem. Một root volume 40GB không đủ chứa bản build bf16 có dung lượng 57 GB, và cũng không đủ chứa 2 tag 8-bit cạnh nhau. Hãy chuyển store sang một volume đã mount trước khi pull bất kỳ thứ gì.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

User ollama phải sở hữu directory đó, vì service chạy dưới user ollama và service tự ghi các blob vào đó. Nếu pull lỗi do permission, journalctl -u ollama -n 50 sẽ chứa nguyên nhân.

Về swap, cần nói rõ một điều: swap không giúp bạn chạy tag lớn hơn. Quá trình generation truy cập weights cho từng token được tạo ra. Vì vậy, nếu weights nằm trong swap, hệ thống phải đọc chúng từ disk lặp đi lặp lại. vmstat 1 sẽ cho thấy các cột si và so hoạt động liên tục, còn tốc độ output giảm xuống còn vài giây cho mỗi token. Hãy giữ một swap file nhỏ để dự phòng trường hợp bị out of memory killer. Cấp đủ RAM cho tag mà bạn thực sự muốn chạy.

Cài đặt Ollama và ghim tag cụ thể

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

Script cài đặt thiết lập một systemd service, nên server sẽ khởi động lại service sau khi reboot. Nếu bạn không muốn chạy Ollama dưới dạng system service do root quản lý, chạy Ollama rootless dưới Podman trình bày cách này. Sau đó, hãy pull một tag cụ thể.

ollama pull muse-glimmer:30b
ollama list

Tự đọc cột kích thước trong ollama list và so sánh với danh sách tag hiện tại trên trang model. Các tag đã publish có thể được thêm, đổi tên hoặc xóa. Kích thước trong một hướng dẫn chỉ là ảnh chụp tại một thời điểm.

Không bao giờ dùng ollama pull muse-glimmer trên server mà bạn phụ thuộc vào. Tên model không có tag sẽ trỏ đến tag latest, còn latest là một pointer mà publisher có thể chuyển sang build khác. Một lần pull định kỳ có thể thay model đang chạy bên dưới agent của bạn, làm thay đổi nhu cầu bộ nhớ và hành vi, nhưng log không thông báo điều đó. Hãy ghi rõ tag trong script, unit file và cấu hình agent. Tự host LLM bằng Ollama trên VPS trình bày các bước còn lại để thiết lập server.

Bạn có thể chạy Muse Glimmer mà không cần GPU không?

Có, nhưng cần nói rõ giới hạn hiệu năng. Việc tạo một token yêu cầu đọc trọng số model từ memory, nên tốc độ phụ thuộc vào memory bandwidth chứ không phụ thuộc vào số vCPU mà gói dịch vụ quảng cáo. Sau một số lượng core nhất định, thêm core hầu như không cải thiện gì. Trên shared VPS, bandwidth này được chia sẻ với mọi tenant khác trên host, nên model 30B ở mức 4-bit chỉ tạo được một số token mỗi giây.

Đừng mặc định tin bất kỳ con số nào về việc này, kể cả con số của tôi. Đo số token mỗi giây trên chính máy của bạn rồi quyết định dựa trên kết quả thực tế.

Kết quả là model này phù hợp rõ rệt với hai kiểu workload khác nhau. Chat tương tác rất khó chịu, vì bạn đọc nhanh hơn tốc độ server ghi ra và mỗi câu trả lời đều bắt đầu bằng một khoảng chờ dài. Tác vụ agent chạy nền thì phù hợp, vì một task chạy không cần giám sát trong 10 phút không bị ảnh hưởng bởi tốc độ chậm. Đây chính xác là workload mà Meta mô tả cho model này.

Nếu cần tốc độ tương tác, có 2 lựa chọn thực tế: GPU hoặc hosted API. Tính điểm hòa vốn giữa GPU VPS và token API trước khi thuê bất kỳ dịch vụ nào, và GPU VPS thực sự cung cấp cho bạn những gì giải thích những gì bạn đang mua. Để trả lời câu hỏi rộng hơn về khả năng chạy của một máy cụ thể, hãy bắt đầu với những model bạn có thể tự host, còn chạy một model Qwen có kích thước tương tự trên VPS là phép so sánh gần nhất trong nhóm kích thước này.

Vì sao nó quên thông tin từ lâu trước khi đạt 128K token?

Vì cửa sổ context mặc định của Ollama là 4096 token, bất kể model hỗ trợ bao nhiêu. Tính đến tháng 8 năm 2026, Ollama vẫn ghi giá trị mặc định này trong FAQ của mình. Tag quảng cáo 128K, nhưng server chỉ cấp cho model 4096 token cho đến khi bạn đặt giá trị khác. Vì vậy, transcript dài của agent sẽ mất các lượt trao đổi ban đầu và model trông như bị mất trí nhớ.

Tăng giá trị này trên server cho mọi request:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Trong một session tương tác, /set parameter num_ctx 32768 chỉ thay đổi giá trị cho session đó. Khi dùng API, gửi num_ctx trong request options.

Mỗi token context bổ sung đều tiêu tốn thêm memory ngoài phần weights. Nếu yêu cầu đủ 128K trên một máy chỉ được cấu hình đủ cho weights, quá trình load sẽ fail hoặc chuyển sang một chế độ chậm hơn. Hãy tăng theo từng bước và chạy ollama ps sau mỗi bước. Cách num_ctx và độ dài context hoạt động trong Ollama giải thích phần tính toán này.

Mức độ suy luận: low, medium, high và xhigh

Meta tài liệu hóa 4 mức độ suy luận cho Muse Glimmer, từ low đến xhigh, và khuyến nghị 2 mức cao hơn cho các tác vụ coding và agent phức tạp. Trong Ollama, thiết lập này dùng tham số think. Dùng --think= trên command line hoặc gửi think trong phần body của API.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

Trong một phiên tương tác, /set think và /set nothink dùng để bật hoặc tắt thiết lập này. Tài liệu Ollama cho biết hầu hết model chấp nhận boolean hoặc một mức như low, medium hay high; một số model chấp nhận max cho mức cao nhất hiện có. Các chuỗi chính xác mà model này chấp nhận được ghi trên trang của model. Hãy đọc trang đó thay vì đoán, rồi thử thủ công một giá trị trước khi tích hợp vào agent.

Trên máy chỉ có CPU, thiết lập này ảnh hưởng rõ đến thời gian phản hồi. Mức cao hơn tạo ra nhiều thinking token hơn trước khi từ đầu tiên của câu trả lời xuất hiện, và mỗi thinking token chiếm cùng thời gian thực như một answer token. Với công việc thông thường, hãy giữ mức low.

Giữ model đã load cho agent luôn chạy

Theo mặc định, Ollama unload model khi model không hoạt động trong năm phút. Với agent chạy mỗi mười phút, điều đó có nghĩa là mỗi lần chạy đều phải load đầy đủ 18 GB từ disk. Trên VPS sử dụng network attached storage, quá trình này không nhanh. Thay vào đó, hãy giữ model trong memory.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Giá trị âm sẽ giữ model resident cho đến khi có thao tác unload. keep_alive trong một API request sẽ ghi đè giá trị mặc định của server cho lần gọi đó. Cái giá phải trả là rõ ràng: RAM vẫn bị chiếm dụng khi không có tác vụ nào chạy. Vì vậy, chỉ nên dùng thiết lập này trên máy dành riêng cho agent. Giữ model Ollama đã load trình bày các biến thể.

Kết nối coding agent

Ollama cung cấp API tương thích với OpenAI tại http://127.0.0.1:11434/v1, vì vậy hầu hết công cụ agent chỉ cần kết nối bằng base URL và một API key không rỗng. Trang Muse Glimmer của Ollama cũng ghi lại shortcut khởi chạy để kết nối một agent được hỗ trợ với model cục bộ bằng một lệnh, đồng thời bạn nên cố định tag tại đó.

ollama launch claude --model muse-glimmer:30b

Agent gửi các prompt lớn. Nội dung file, output của tool và transcript ngày càng dài đều được gửi dưới dạng input token. Trên máy chỉ có CPU, xử lý prompt là phần gây tải trước cả khi quá trình sinh nội dung bắt đầu. Giữ thiết lập context ở mức nhỏ nhất mà tác vụ cho phép. Kết nối coding agent với Ollama trình bày phần client, chạy coding agent trên VPS trình bày máy chủ nơi agent chạy, còn kiểm soát chi phí agent trên VPS trình bày những gì xảy ra khi agent chạy cả ngày.

Input hình ảnh cũng hoạt động tương tự. Ollama API nhận hình ảnh trong trường images của message, vì vậy client chỉ hỗ trợ văn bản sẽ không bao giờ gửi hình ảnh, dù perception encoder có khả năng đến đâu.

Không mở cổng 11434

Ollama API không có cơ chế xác thực. Đặt OLLAMA_HOST=0.0.0.0:11434 để truy cập từ laptop sẽ đưa một model runner không yêu cầu xác thực lên public Internet. Bất kỳ ai tìm thấy endpoint này đều có thể tải model vào disk của bạn và đọc mọi dữ liệu mà agent gửi qua đó. Hãy để API chỉ bind vào localhost và dùng tunnel thay thế.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Bảo vệ endpoint Ollama API trình bày các tùy chọn phù hợp, bao gồm reverse proxy yêu cầu thông tin xác thực.

Các lỗi thường gặp và dấu hiệu nhận biết

Quá trình pull dừng giữa chừng. Nguyên nhân là dung lượng đĩa. Chạy df -h trong thư mục model. Một bản build bf16 57 GB không thể vừa trên root volume 40GB, và hai tag 8-bit đặt cạnh nhau cũng không vừa.

Model tải xong rồi process bị dừng. Nguyên nhân là hết bộ nhớ. dmesg -T ghi lại việc kernel out of memory killer chọn một process, còn journalctl -u ollama -n 100 hiển thị cùng sự kiện đó ở phía service. Cách xử lý là dùng tag nhỏ hơn hoặc num_ctx nhỏ hơn. Tăng swap không giải quyết được vấn đề.

Model chạy với tốc độ vài giây cho mỗi token. Chạy vmstat 1 và theo dõi các cột si và so. Hoạt động swap liên tục nghĩa là weights không vừa trong RAM, nên máy phải đọc chúng lại từ disk trong khi chạy.

Một tag đã chạy được tuần trước nhưng hiện không còn. Danh sách tag có thể thay đổi. Đọc lại trang model, pin tag hiện tại và ghi tên tag ở nơi bạn có thể tìm lại.

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

Muse Glimmer cần bao nhiêu RAM trên VPS?

Bắt đầu từ kích thước tag rồi cộng thêm context window. Tag mặc định có kích thước khoảng 18 GB vào ngày 16 August 2026, nên máy 16GB hoàn toàn không chứa được tag này, còn máy 24GB chỉ còn rất ít chỗ cho context. Hãy xem đó là điểm bắt đầu, không phải câu trả lời cuối cùng. Pull tag, load tag một lần, rồi chạy ollama ps và free -h trên chính máy của bạn để đọc số liệu thực tế. Context dài hơn và các request chạy song song đều làm tăng mức dùng memory ngoài phần weights.

Có thể chạy Muse Glimmer mà không cần GPU không?

Có. Muse Glimmer có thể load và trả lời chỉ bằng CPU trên VPS. Tốc độ sinh token bị giới hạn chủ yếu bởi memory bandwidth, không phải số lượng core. Trên shared host, bandwidth này còn bị chia sẻ, vì vậy ở mức 4-bit, hãy chỉ kỳ vọng vài token mỗi giây. Mức này dùng được cho tác vụ agent chạy nền không cần giám sát, nhưng sẽ khó chịu khi chat tương tác. Chạy ollama ps trong lúc đang xử lý request rồi đọc cột processor để xác nhận tác vụ đang chạy ở đâu.

Các tag MLX có dùng được trên Linux VPS không?

Không. Mọi tag có mlx trong tên đều được build cho MLX engine của Ollama, tức backend dành cho Apple Silicon. Trên server Linux x86, các tag này chỉ là những file tải xuống rất lớn nhưng không thể chạy được. Hãy dùng tag 30b không có hậu tố, hoặc một tag khác không phải MLX, và bỏ qua các benchmark phần cứng Apple đi kèm những bản build MLX.

Tại sao model quên thông tin từ rất lâu trước khi đạt 128K token?

Vì context window mặc định của Ollama là 4096 token, bất kể model hỗ trợ bao nhiêu token. Do đó server sẽ cắt bớt các cuộc hội thoại dài trước khi model nhìn thấy chúng. Đặt OLLAMA_CONTEXT_LENGTH trên server, hoặc dùng /set parameter num_ctx cho một session, hoặc gửi num_ctx trong options của API request. Mức dùng memory sẽ tăng theo, vì vậy hãy tăng từng bước và kiểm tra ollama ps sau mỗi lần thay đổi.

Nên cố định tag hay cứ dùng latest?

Hãy cố định tag. muse-glimmer không có tag sẽ resolve thành latest. Đây là một pointer mà publisher có thể chuyển sang build khác bất kỳ lúc nào, nên một lần pull thông thường cũng có thể làm thay đổi model mà agent của bạn chạy. Ghi muse-glimmer:30b trong script, unit file và cấu hình agent. Kiểm tra danh sách tag trên trang model trước khi cố định, vì các tag đã publish có thể thay đổi.