Downloads · 30 days
28
26% of all-time downloads
GotoAI-Inc/Muse-Glimmer-30B-W8A16
Muse-Glimmer-30B-W8A16 is a image-text-to-text model from GotoAI-Inc. Use it for the image-text-to-text task on the model card, and read the license before you ship it in a product. It is set up for transformers. The card lists the license as apache-2.0.
Int8 weight-only quantization of meta-models/Muse-Glimmer-30B, in compressed-tensors format for vLLM. 34.78 GB, down from 59.55 GB — the model fits a 48 GB card, or a 40 GB card comfortably (its KV cache is tiny); tex…
Downloads · 30 days
28
26% of all-time downloads
All-time downloads
109
Public
Parameters
29.8B
34.8 GB on disk
Likes
0
Public
Click a slice to open those files.
.safetensors34.8 GB · 100%
How the weights are stored.
I3225.2B · 85%
From the Hugging Face model README
Int8 weight-only quantization of meta-models/Muse-Glimmer-30B, in compressed-tensors format for vLLM. 34.78 GB, down from 59.55 GB — the model fits a 48 GB card, or a 40 GB card comfortably (its KV cache is tiny); text-only it is 30.94 GB.
This is the fidelity-first build. Int8 round-to-nearest stays far closer to the bfloat16 weights than int4 does, at ~1.6x the footprint of the int4 W4A16 sibling (22.20 GB). If you are targeting a 24 GB card, use that one; use this one when you have the VRAM and want the least quality loss quantization can give without calibration.
Unofficial and unaffiliated with Meta. All model capabilities, evaluations and limitations belong to the original model card — see the base model for those.
Meta publishes 4-bit builds of this model as llama.cpp K-quants and an ExecuTorch
.pte, neither of which vLLM can load. This repository fills that gap: the same weights
in the compressed-tensors format vLLM serves natively.
Weights were quantized from bfloat16 to int8, group size 128, symmetric, weight-only
(activations stay 16-bit) using llmcompressor.model_free_ptq. No calibration data was
used and the model was never loaded — the quantizer operates directly on the safetensors.
Architecture, tokenizer, chat template and processor config are the vendor's, unmodified.
| component | precision | size |
|---|---|---|
| language-model linears (52 layers) | int8 g128 | 25.56 GB (73.5%) |
embed_tokens + lm_head (untied) | bfloat16 | 5.38 GB (15.5%) |
| vision tower, adapter, projection | bfloat16 | 3.84 GB (11.1%) |
| total | 34.78 GB |
The vision tower is deliberately untouched: vLLM builds Muse Glimmer's vision encoder
with quant_config=None, so a checkpoint carrying quantized vision weights fails to load.
lm_head is left at full precision as well — it is untied in this model, and it is the
layer that decides the probabilities of the framing tokens that tool-call and reasoning
parsing depend on.
Requires vLLM >= 0.28 (Muse Glimmer support landed after the 0.27.1 release) and transformers >= 5.15.
At the time of writing, 0.28 is not yet on PyPI, so vLLM must come from the nightly index.
Note that nightly wheels self-report a lower version than the last release
(0.26.1rc1.devNNNN+g<sha> vs 0.27.1), so pip install -U --pre vllm will silently keep
0.27.1 and the model will fail with invalid tool call parser: muse_glimmer. Pin the
nightly explicitly:
pip install --force-reinstall --pre --extra-index-url https://wheels.vllm.ai/nightly \
"vllm==0.26.1rc1.dev1059+g2740c817f" # any main build after 2026-08-14 works
python -c "from vllm.model_executor.models.registry import ModelRegistry as R; \
print('MuseGlimmerForConditionalGeneration' in R.get_supported_archs())"
vllm serve GotoAI-Inc/Muse-Glimmer-30B-W8A16 \
--max-model-len 65536 \
--gpu-memory-utilization 0.90 \
--enable-auto-tool-choice --tool-call-parser muse_glimmer \
--reasoning-parser muse_glimmer
Do not pass --quantization; compressed-tensors is detected from config.json. The int8
W8A16 scheme uses Marlin kernels and runs on compute capability 7.5 and above.
--tool-call-parser muse_glimmer is not optional for agentic use: the model frames
tool-call arguments in ATEM markup, and without the parser the named/required
tool_choice path returns tool_calls: null.--reasoning-parser muse_glimmer splits thinking into reasoning_content.--language-model-only skips the vision tower and frees ~3.84 GB (a 30.94 GB
text-only checkpoint), at the cost of image and video input.--speculative-config '{"method": "dflash", "model": "meta-models/Muse-Glimmer-30B-assistant", "num_speculative_tokens": 16}'Fitting the card. --gpu-memory-utilization must cover weights and KV cache. 0.90
of a 48 GB card is 43.2 GB — comfortable over the 34.78 GB of weights. 0.90 of a 40 GB
card is 36 GB, which still clears the weights because long context is cheap here: 2 KV
heads and a 2048 sliding window on 39 of 52 layers put a 32k sequence at roughly 0.5 GB,
against a model maximum of 131072. On a 32 GB card use --language-model-only to drop to
the 30.94 GB text-only footprint.
Built with llm-quantizer:
./llmq.py run --profile muse-glimmer-30b
W8A16 is the profile's default scheme, so no --scheme flag is needed. The run re-shards
the source (it ships as a single 49.95 GB safetensors file, which no consumer GPU can
hold) into 4 GB pieces, then:
# llmcompressor==0.13.1a20260814, compressed-tensors==0.18.1a20260818,
# transformers==5.15.1, torch==2.13.0
from llmcompressor import model_free_ptq
model_free_ptq(
model_stub="Muse-Glimmer-30B-resharded",
save_directory="Muse-Glimmer-30B-W8A16",
scheme="W8A16",
ignore=["re:.*vision.*", "lm_head", "re:.*embed_tokens.*"],
device="cuda:0",
)
Because a job holds one shard at a time, the peak device footprint is a few GB rather than the model size — this build ran on a 16 GB GPU.
No benchmarks have been run. Treat the published Muse Glimmer numbers as describing the bfloat16 model, not this one: data-free round-to-nearest quantization degrades quality more than a calibrated (GPTQ/AWQ) or QAT build, and how much, for your task, is unmeasured here. Int8 degrades far less than the int4 sibling — that is the reason this build exists — but "less" is not "none".
What has been checked is that it works in practice. The checkpoint has been served on a
single 48 GB GPU under vLLM and used to drive the Goose
agent harness through normal sessions, with --tool-call-parser muse_glimmer and
--reasoning-parser muse_glimmer. Multi-step tool calling and reasoning extraction behave
as expected — no malformed tool calls or leaked framing tokens observed.
That is a functional smoke test, not a quality measurement, but it exercises the part most sensitive to weight quantization: structured emission (tool-call markup and reasoning delimiters) degrades before fluency does, so an agent harness running cleanly is more informative here than a perplexity number would be.
Apache 2.0, inherited from the base model — the vendor's LICENSE is included. The base
model's USAGE_POLICY.md is also included and applies to this derivative; please read
it before use. "Muse Glimmer" is Meta's; this repository is not endorsed by or affiliated
with Meta.