I did some testing this morning, and I was surprised to find that Muse Glimmer actually comfortably fits on a single RTX 3090 with full context + DFlash + mmproj at Q4_K_XL, unlike Qwen3.6-27B and Gemma-4-31B.

Muse Glimmer supports up to 256k context according to Unsloth. Here is my command:

llama-server \
  --model Muse-Glimmer-30B-UD-Q4_K_XL.gguf \
  --mmproj Muse-Glimmer-30B-mmproj-kquant.gguf \
  --spec-draft-model Muse-Glimmer-30B-DFlash-kquant.gguf \
  --spec-draft-ngl 999 \
  --spec-draft-n-max 15 \
  --spec-type draft-dflash \
  -c 262144 \
  --override-kv muse-glimmer.context_length=int:262144,dflash.context_length=int:262144 \
  -ngl 999 \
  -fit off \
  --parallel 1 \
  --flash-attn on \
  --no-warmup \
  --cache-type-k f16 \
  --cache-type-v f16 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 64 \
  --reasoning-preserve \
  --jinja \
  --host 127.0.0.1 \
  --port 8080

This fits in about 22GB to 23GB of VRAM, actually leaving a reasonable amount of unused memory.

On this RTX 3090, for Qwen3.6-27B and Gemma-4-31B, this is what I've been able to achieve using their Q4_K_XL models with MTP + mmproj, right at the limits of the RTX 3090's VRAM:

Model	F16 KV cache	Q8 KV cache
Qwen3.6-27B	70,000 tokens	125,000 tokens
Gemma-4-31B	52,000 tokens	81,000 tokens

Those small contexts have been borderline unusable on f16, and I don't enjoy using Q8 KV unless absolutely necessary, so I mostly use my slower DGX Spark to run these models at the full context.

On Muse Glimmer, there seems to be little reason to use my DGX Spark since it fits so nicely on the RTX 3090. Maybe I could run a bunch of parallel agents with full KV on the Spark.

Muse Glimmer also runs at between 64 tok/s and 124 tok/s in my testing under DFlash, depending on whether it is outputting prose or code. Either way, a pretty solid speed. I've seen about 1400 tok/s of prompt processing.

I also ran a two needle haystack test at about 150k tokens with one needle at the beginning and the other at the end, and the model retrieved them perfectly on the first try, so this is definitely not soft-capped to 128k context.

I downgraded from ChatGPT Pro to Plus, and immediately after the next billing cycle, I have lost access to Codex for the next 6 days because OpenAI applies the lower Plus weekly limit right away, while still counting the usage I made yesterday under the higher Pro limit during the same rolling weekly window. According to support, I will only get 3 weeks of Codex access for this month that I paid for.

Support confirmed this is “expected behavior.” In other words, when you downgrade, the limit changes immediately, but the prior usage does not reset or remain tied to the old Pro allowance. So you can pay for a fresh month of Plus and still be locked out of Codex for most of the first week because of usage that happened before the Plus subscription started.

That makes no sense. Weekly usage has two parts: the usage and the limit. If the usage carries over, the limit should carry over too. If the limit changes immediately, the usage should reset against that new limit.

Otherwise, OpenAI is effectively selling a month of Plus while withholding part of the included Codex access. Support refused to reset the quota or provide a partial refund.

This policy is not clearly disclosed, and it is anti-consumer. People should know how OpenAI handles plan changes before switching tiers.

Bigger ubatch made gpt-oss-120b prompt processing much faster on my RTX 3090

I was tuning gpt-oss-120b-F16.gguf with llama.cpp on a 24 GB RTX 3090 and found that increasing the physical micro-batch size (-ub) can massively improve prompt processing throughput, as long as you also raise --n-cpu-moe enough to keep the run inside VRAM.

The llama.cpp defaults are -b 2048 and -ub 512; I included that default run as its own point in the chart.

Here are the informal llama-bench results I charted:

ubatch	n-cpu-moe	prefill	generation
256	25	240.03 tok/s	33.14 tok/s
512 (default)	26	380.27 tok/s	32.29 tok/s
2048	25	1112.54 tok/s	32.96 tok/s
4096	26	1682.47 tok/s	32.38 tok/s
8192	28	2090.68 tok/s	30.05 tok/s

Compared with the llama.cpp default -ub 512, prompt processing went from about 380 tok/s to about 2091 tok/s, roughly a 5.5x gain. Compared with the smaller -ub 256 run, it was about an 8.7x gain. Token generation dropped from about 32.3 tok/s at default settings to 30.1 tok/s at -ub 8192, about a 7% reduction.

The catch is that the larger ubatch needs more GPU compute workspace. On my machine, -ub 4096 needed --n-cpu-moe 26, and -ub 8192 needed --n-cpu-moe 28. So this is a throughput trade: move a few more MoE layers to CPU to make enough room for the bigger batch, and prompt-heavy workloads get dramatically faster while generation gets a little slower.

https://preview.redd.it/s750judj7m0h1.png?width=2250&format=png&auto=webp&s=c696d26db310933120b9b99c310b2662e2d4f390

Note: the first four prefill points are pp4096; the 8192 ubatch point is from a pp8192 run, so treat this as an informal tuning result rather than a perfectly controlled benchmark.

-----

One of the reasons I bought a DGX Spark was to have better prompt processing speeds. If I had known about this trick, I might not have done that in retrospect, even though it is a very nice machine, and still gets slightly better prompt processing performance and like double the token generation speed for gpt-oss-120b. Higher ubatch drastically closes the gap.

I ran into a surprising rsync bottleneck when pushing backups to a Ubiquiti UNAS Pro over a 10Gb link. The link was fine, rsync -W helped some, but SSH was still the next ceiling.

The fix was forcing SSH to use AES-GCM instead of the default negotiated cipher:

rsync -aWh --info=progress2 \
  -e 'ssh -T -c aes128-gcm@openssh.com -o Compression=no' \
  --rsync-path="/path/to/rsync" \
  /source/path/ \
  root@UNAS_IP:/destination/path/

On my UNAS Pro, OpenSSH was defaulting to:

chacha20-poly1305@openssh.com

Switching to:

aes128-gcm@openssh.com

basically doubled throughput from 1Gbps to 2Gbps. The UNAS Pro CPU has AES acceleration, so AES-GCM is much faster than ChaCha20 in this workload. 2Gbps is not incredible, but... it's a step up?

To make it the default for SSH clients, add this to ~/.ssh/config on the machine running rsync:

Host *
    Ciphers ^aes128-gcm@openssh.com

The ^ is important: it moves AES-GCM to the front of the default list without removing fallback ciphers.

You can verify what SSH negotiates with:

ssh -vv root@UNAS_IP true 2>&1 | grep 'cipher:'

Also, for fast LAN transfers, consider rsync -W / --whole-file. The rsync delta algorithm can be slower than just sending the changed file when you’re on a 10Gb network, especially with how weak the UNAS Pro's CPU is.