№ 0352GitHub
Muse Glimmer on Tenstorrent p150
A correctness-first bring-up of Muse Glimmer 30B on a single Tenstorrent p150 card, with paged KV cache, native DFlash speculative decoding and an OpenAI-compatible server.
Muse Glimmer 30B
This bring-up supports the correctness-first production path only:
- batch size 1 on one TT device;
- 2,048-token chunked causal prefill into a 64-token paged KV cache;
- the checkpoint's native DFlash assistant;
- a native 16-token DFlash block in a 32-token physical target verify tile;
- greedy decoding through the OpenAI-compatible server;
- Muse's native addressed-message and ATEM tool-call protocol.
Production weights use BFP8 for attention/LM-head projections and BFP4 for
all target and DFlash MLP projections. Norms and KV caches remain BF16.
Packed verification writes only its real rows with one page-level fill per
touched page; physical padding rows never enter the target cache. Prompt-only
alignment and long-context tails may use all 32 physical rows, while native
speculative decode remains 16 tokens. A persistent
single-session prompt snapshot reuses an exact chat prefix on the next turn;
only the newly serialized assistant, tool, and user suffix is appended.
On the local single-device Blackhole server, synchronized prefill of an exactly
128,000-token prompt measured 1,549.38 prompt tok/s; all 128,000 tokens used
the chunked paged path. A cached 64-token tool-call suffix at that position
measured 184.30 prefill tok/s and 56.01 true AR tok/s. The following 145-token
tool-response suffix (128 chunked plus a 17-token packed tail) measured 246.77
prefill tok/s and 20.13 true AR tok/s. The complete tool call and response were
parsed correctly and remained coherent. At short context, the sustained
256-token workload produced 255 true AR tokens in 2.121 seconds: 119.99 AR
tok/s, with 240 accepted drafts across 18 packed verifies.
tokens_per_second is deliberately the end-to-end completion rate: completion
tokens divided by the entire request latency. It must not be interpreted as
prefill throughput. ar_decode_tokens_per_second (also exposed under the
backward-compatible decode_tokens_per_second name) counts only tokens produced
after the captured AR replay loop starts. It excludes tokenization, cold or
cached prefill, cache snapshots, tool-call parsing, tool-response prompt tokens,
and the first bonus token already computed by the final prefill logits. Its
denominator includes trace-input refreshes, DFlash replay, on-device greedy
sampling, packed target verification, the tiny ID readback, and anchor-commit
replay. DF




