Uno for vLLM v0.4.4 on AMD Radeon

Uno for vLLM v0.4.4 on AMD Radeon

Uno for vLLM v0.4.4 now runs on AMD Radeon AI PRO R9700 (RDNA4, gfx1201) with ROCm, in a container built from the
stock vLLM v0.30.0 ROCm image: ghcr.io/brntech/vllm-uno:0.4.4-rocm. On BroadNet's production traffic on one R9700,
Gemma 4 26B A4B with the recommended settings (UNO_RECOMMENDED=1) and the v0.4.4 adapter serves 310 tokens per
second with eight requests in flight (stock DFlash K8 in vLLM 0.30.0 ROCm: 298) and 241 with four (stock
DFlash K8 in vLLM 0.30.0 ROCm: 197). One request at a time it takes 25.0 % less time per token than
stock DFlash K8 in vLLM 0.30.0 ROCm, and on 14k and 28k-token documents 60.0 % and
68.4 % less than stock DFlash K8 in vLLM 0.30.0 ROCm. The output is the model's own.

The adapter is the v0.4.4 one, on Hugging Face (main).
The code that proposes, accepts and samples tokens is the v0.4.4 release's; what the ROCm image adds is below.

What is in the image

• Uno v0.4.4 on vLLM v0.30.0. The v0.4.4 patches (0001 to 0005 in this repository) are ported onto vLLM v0.30.0,
  the version vLLM publishes a ROCm image for, as one diff (patch/rocm-0.4.4/vllm-v0.30.0-rocm.diff); Python only, no
  compiled library changes. The build refuses any other base: every file the diff changes must have v0.30.0's bytes.
• gfx1201 admitted. Uno, its 4-expert drafts (UNO_DRAFT_MOE_TOPK=4) and the AWQ MoE path check the GPU before
  they start. Each check keeps its CUDA condition first; on ROCm, only gfx1201 (Radeon AI PRO R9700) is admitted, and
  every other ROCm GPU keeps the refusal. On ROCm the AWQ experts run vLLM's Triton kernel, so the 4-expert drafts use
  it there.
• Tuned for the R9700, on by default. A fused-MoE config for Gemma 4 26B A4B's AWQ experts (the launcher points
  VLLM_TUNED_CONFIG_FOLDER at it on gfx12), a dispatch table for the dense 4-bit layers (which kernel and tile serve
  each row count), the adapter's LoRA kernel configs (read under the GPU name ROCm reports), and larger attention tiles
  for prefill-shaped launches (patched into the container's vLLM at start; decode and verify launches keep vLLM's
  tiles). On gfx12 the adapter also runs on the main stream: inside HIP graphs the dual-stream LoRA path leaves the GPU
  idle at every cross-stream fork and join.
• The same switch. UNO_RECOMMENDED=1 sets UNO_K=5, UNO_PLOOKUP_L=2, UNO_PLOOKUP_MAX_CTX=4096,
  UNO_DRAFT_MOE_TOPK=4 and UNO_GEMMA_SPLITKV_MULTI=1, as in the CUDA release. R9700_PREFILL_TILES=0 skips the tile
  patch; VLLM_LORA_ENABLE_DUAL_STREAM=1 restores dual stream; VLLM_TUNED_CONFIG_FOLDER= (empty) drops the MoE config.

Measured

One Radeon AI PRO R9700 (32 GB), ROCm 7.2, Gemma 4 26B A4B AWQ 4-bit, the v0.4.4 adapter. v0.4.4 = the
0.4.4-rocm container with UNO_RECOMMENDED=1; DFlash K8 and plain decoding on the stock vllm/vllm-openai-rocm:v0.30.0
image as published, with nothing added; the same serve flags for all. One session, three rounds per arm with the arm
order rotated, every server started fresh for its workload and sent two warmup requests (the first two production
requests) before the timed ones. Production traffic = 72 real requests, completion tokens only. Documents = open-data
texts, 4 sets x 2 tasks, up to 384 output tokens, one at a time, on the one-at-a-time servers after the production
requests. Production figures are the median of the three rounds, with the range of the three rounds in brackets for
v0.4.4's and DFlash K8's tokens per second; document figures are the median of all 24 requests of the three rounds
pooled; speed-ups over plain are ratios of these medians. Per-round numbers and the tables derived from them are in the
release's evidence files; v0.4.4's figures here are rounded so that none is better than measured.

production traffic	Uno v0.4.4	DFlash K8, vLLM 0.30.0 ROCm	plain
eight at a time: tokens per second, whole batch	310 (307-310)	298 (297-299)	202
eight at a time: speed-up over plain	1.53x	1.48x	1.00x
four at a time: tokens per second, whole batch	241 (237-241)	197 (197-197)	167
four at a time: speed-up over plain	1.44x	—	1.00x
one at a time: ms per token, rounds 1 / 2 / 3	8.920 / 8.995 / 8.951	11.920 / 11.948 / 11.966	—

documents, one at a time: ms per token	Uno v0.4.4	DFlash K8, vLLM 0.30.0 ROCm
2k-token prompts	10.11	16.12
14k-token prompts	13.52	33.84
28k-token prompts	17.56	55.56

• Eight at a time, v0.4.4 took 3.1 %, 4.2 % and 3.7 % less time per token than
  stock DFlash K8 in vLLM 0.30.0 ROCm (rounds 1, 2 and 3); four at a time, 17.0 %, 18.3 % and
  18.4 % less; one at a time, 25.1 %, 24.7 % and 25.1 % less. On 2k-token
  documents 36.0 %, 37.3 % and 37.2 % less, on 14k 59.5 %,
  59.5 % and 60.8 %, on 28k 68.2 %, 68.9 % and
  68.9 %.
• A comparison is called when every round of both arms agrees on the direction by more than the larger round spread.
• KV cache at 32k context: 215,042 tokens on every v0.4.4 server with the recommended settings.

Speed-up over plain decoding

v0.4.4 decodes 1.40x faster one request at a time than plain decoding in vLLM 0.30.0 ROCm, and 1.25x, 1.23x and
1.18x faster on 2k, 14k and 28k-token documents.

workload	Uno v0.4.4	plain decoding, vLLM 0.30.0 ROCm	speed-up over plain decoding in vLLM 0.30.0 ROCm
one at a time: ms per token	8.874	12.446	1.40x
2k-token documents: ms per token	10.23	12.85	1.25x
14k-token documents: ms per token	13.62	16.87	1.23x
28k-token documents: ms per token	17.42	20.56	1.18x

These four come from a second session on the same card, image, model, settings and workloads: four rounds per arm with
the arm order balanced, every server's decode speed checked before its timed requests. v0.4.4's own times in it are
within 1.2 % of the session above on every workload. One-at-a-time figures are the median of the four rounds,
document figures the median of all 32 requests pooled; each speed-up is the ratio of the two figures beside it. All four
are called: in every round v0.4.4 takes less time per token than plain decoding in vLLM 0.30.0 ROCm by more than the
larger round spread. Per-round numbers are in evidence/release-0.4.4-rocm/plain-rerun/.

Lossless

The ROCm image runs the v0.4.4 release's proposal, acceptance and sampling code: every candidate still goes through
vLLM's own rejection sampler against the draft distribution it was drawn from, so the output distribution is the
model's. What differs on ROCm is numerics (vLLM's ROCm kernels, the tuned configs, the prefill tiles), which can move
the last bits of a probability the same way a different GPU does, never which distribution is sampled. The v0.4.4 CPU
tests, with the v0.4.3 exactness suites (vLLM's rejection kernels at the served shapes, position by position against
the model's distribution), run on the ROCm image with three test-side lines changed (the image's version string, and a
field vLLM v0.30.0 reads on a test double): 174 CPU tests pass, rc 0 in every group, the same 174 as on the CUDA
release image (evidence/release-0.4.4-rocm/cpu/).

Run

docker pull ghcr.io/brntech/vllm-uno:0.4.4-rocm
hf download Broadnet/gemma-4-26B-A4B-uno-adapter --local-dir /path/to/adapter
docker run --rm --device /dev/kfd --device /dev/dri --group-add video --group-add render \
  --security-opt seccomp=unconfined --ipc=host --shm-size 8g -p 127.0.0.1:8000:8000 \
  -v /path/to/hf-cache:/root/.cache/huggingface -v /path/to/adapter:/adapter:ro \
  -e UNO_PROFILE=gemma4 -e UNO_RECOMMENDED=1 \
  ghcr.io/brntech/vllm-uno:0.4.4-rocm cyankiwi/gemma-4-26B-A4B-it-AWQ-4bit /adapter \
  -- --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4

The flags after -- turn on Gemma 4's tool-call and reasoning parsers, as on the measured servers. Uno starts only on
gfx1201 in this image; the CUDA image ghcr.io/brntech/vllm-uno:0.4.4 is unchanged. Build it yourself from the
repository root with docker build -f patch/rocm-0.4.4/Dockerfile ..

Uno for vLLM v0.4.4

Uno for vLLM v0.4.4

Uno for vLLM v0.4.4 makes Uno fast with several requests in flight, turns the recommended Gemma 4 settings on
with one switch, UNO_RECOMMENDED=1, and comes with a new Gemma 4 adapter whose last training stage drafts as many
tokens as those settings serve. On BroadNet's production traffic on one RTX 3090, Gemma 4 26B A4B with the recommended
settings and the new adapter serves 721 tokens per second with eight requests in flight (stock DFlash K8 in vLLM
0.30.0: 679) and 523 with four (stock DFlash K8 in vLLM 0.30.0: 497). One request at a time it
decodes 1.69x faster than plain decoding and takes 7.6 % less time per token than stock DFlash K8 in vLLM
0.30.0. The output is the model's own.

The adapter is on Hugging Face (main); the v0.4.3
adapter stays there at revision s5. The code that proposes, accepts and samples tokens is unchanged; what changes is
which attention kernel computes a decode step with several requests in flight (below).

What changed

• Split-KV attention for steps with several requests (UNO_GEMMA_SPLITKV_MULTI=1). Uno's split-KV attention
  kernel, used for its draft and verify passes, ran only when one request was in the step; with two or more, every
  attention call fell back to vLLM's general kernel. v0.4.4 admits a step to the split-KV kernel when every request in
  it has the same number of query rows, and keeps one launch for the whole step. The kernel itself is unchanged: each
  request's attention is computed exactly as when it runs alone (a GPU test checks the outputs are bit for bit equal
  for steps of 2, 4 and 8 requests, and for steps of 2, 4 and 7 requests plus one padded request from a CUDA graph
  with prompt-chunk rows among them, both Gemma 4 attention layouts, widths 5, 6 and 8). Against the general kernel
  v0.4.3 used for these steps, the split-KV kernel adds up each request's attention in a different order, so in steps
  with several requests the attention output can differ from v0.4.3's in the last bits (bfloat16), and with it the
  draft and target probabilities of that step. Steps whose requests have different widths keep the general kernel, as
  before; with the recommended settings that includes steps that mix requests above and below the 4,096-token length
  gate (6 and 8 rows).
• CUDA graphs for 6 to 8 requests in flight. With the recommended settings each request verifies 8 rows per step,
  so 6, 7 and 8 requests need graph sizes 48, 56 and 64; the profile's capture sizes ended at 40, and those steps ran
  without a CUDA graph. With UNO_GEMMA_SPLITKV_MULTI=1 the launcher adds capture sizes 48, 56 and 64. The two come
  together: with the general attention kernel the larger sizes would also take memory from the KV cache at startup;
  with the multi-request kernel the KV cache holds 75,731 to 75,768 tokens at 32k context on a 24 GB RTX 3090.
• One switch for the recommended settings (UNO_RECOMMENDED=1, Gemma 4 profile). It sets UNO_K=5,
  UNO_PLOOKUP_L=2, UNO_PLOOKUP_MAX_CTX=4096, UNO_DRAFT_MOE_TOPK=4 and UNO_GEMMA_SPLITKV_MULTI=1. A variable you
  set yourself wins. Set to empty, UNO_PLOOKUP_L= turns prompt lookup off, UNO_DRAFT_MOE_TOPK= drafts with all 8
  experts and UNO_GEMMA_SPLITKV_MULTI= turns the multi-request path off; an empty UNO_K=, or an empty
  UNO_PLOOKUP_MAX_CTX= while lookup is on, is refused at startup. The launcher prints the settings it used at startup
  (Uno settings: ...). It refuses UNO_GEMMA_SPLITKV_MULTI=1 without split-KV attention, on the Qwen3 profile, or
  with more than 9 verify rows per request (UNO_K + UNO_PLOOKUP_L + 1), which the split-KV kernel does not take;
  and it refuses UNO_RECOMMENDED=1 with the Qwen3 profile.
• Startup checks at the new capture sizes. The v0.4.3 check for UNO_DRAFT_MOE_TOPK=4 (every draft batch the
  server can be asked for must have a captured graph) now finds graphs for up to 8 requests with the recommended
  settings; --max-num-seqs above 8 still stops at startup. Only UNO_K=5 with UNO_PLOOKUP_L=2 was measured.
  Without UNO_GEMMA_SPLITKV_MULTI the capture sizes and the check are those of v0.4.3.
• A new adapter. Every earlier Gemma 4 adapter was trained with four-row draft blocks; since v0.4.3 the recommended
  settings draft five tokens per block (UNO_K=5). The new adapter continues the v0.4.3 adapter for 2,000 updates with
  five-row draft blocks and with the draft passes routed as they are served (4 of the 8 experts, the 64k draft
  vocabulary). It has the same rank, the same configuration file and the same file layout, so it is a drop-in
  replacement. The v0.4.3 adapter stays on Hugging Face at revision s5.
• Nothing else moves: the image is the v0.4.3 release image plus two attention files and the launcher; same vLLM
  build, profile defaults, draft vocabulary and LoRA kernel configs. With neither new variable set, a v0.4.4 server
  runs the v0.4.3 path.

Measured

One RTX 3090, Gemma 4 26B A4B AWQ 4-bit, the new adapter. v0.4.4 = the v0.4.4 container with UNO_RECOMMENDED=1;
DFlash K8 on the stock vllm/vllm-openai:v0.30.0 image; plain decoding on the v0.4.4 container; the same serve flags
for all. One session, three rounds per arm with the arm order rotated, every server started fresh for its workload and
sent two warmup requests (the first two production requests) before the timed ones. Production traffic = 72 real
requests, completion tokens only. Documents = open-data texts, 4 sets x 2 tasks, up to 384 output tokens, one at a time,
on the one-at-a-time servers after the production requests. Production figures are the median of the three rounds, with
the range of the three rounds in brackets for tokens per second; document figures are the median of all 24 requests of
the three rounds pooled; speed-ups over plain are ratios of these medians. Per-round numbers and the tables derived
from them are in the release's evidence files; v0.4.4's figures here are rounded so that none is better than measured.

production traffic	Uno v0.4.4	DFlash K8, vLLM 0.30.0	plain
eight at a time: tokens per second, whole batch	721 (721-723)	679 (673-679)	520 (517-524)
eight at a time: speed-up over plain	1.38x	1.31x	1.00x
four at a time: tokens per second, whole batch	523 (521-528)	497 (487-504)	354 (353-356)
four at a time: speed-up over plain	1.48x	1.41x	1.00x
one at a time: ms per token	4.420	4.786	7.471
one at a time: speed-up over plain	1.69x	1.56x	1.00x

documents, one at a time: ms per token (speed-up over plain)	Uno v0.4.4	DFlash K8, vLLM 0.30.0	plain
2k-token prompts	4.84 (1.53x)	6.33 (1.17x)	7.43
14k-token prompts	6.28 (1.37x)	10.24 (0.84x)	8.60
28k-token prompts	7.30 (1.31x)	14.07 (0.68x)	9.63

• Eight at a time, v0.4.4 took 5.8 %, 5.8 % and 7.0 % less time per token than
  stock DFlash K8 in vLLM 0.30.0 (rounds 1, 2 and 3); four at a time, 6.7 %, 6.0 % and 3.7 % less; one
  at a time, 4.0 %, 7.8 % and 8.3 % less. On 14k-token documents,
  34.8 %, 43.8 % and 38.0 % less; on 28k, 48.1 %,
  45.5 % and 47.5 % less.
• v0.4.3, whose capture sizes end at 40, runs steps with 6 to 8 requests without a CUDA graph. In an earlier session
  with the v0.4.3 adapter (v0.4.3-comparison/ in the evidence), v0.4.3 with its recommended settings served
  364 tokens per second with eight requests in flight, less than plain decoding (513), and
  v0.4.4 served 714, 1.96x as much.
• KV cache at 32k context: 75,731 to 75,768 tokens for v0.4.4 with the recommended settings.

Lossless

v0.4.4 changes which attention kernel computes the target's and the drafter's attention when several requests share a
step, and the adapter, which only proposes tokens; the code that proposes, accepts and samples candidates is unchanged.
Every candidate still goes through vLLM's own rejection sampler against the draft distribution it was drawn from, so the
output distribution is the model's. The new path computes each request's attention with the same kernel and the same
per-request split as the one-request path: a GPU test on the release image checks that the outputs are identical, bit
for bit, to running each request alone, for both Gemma 4 attention layouts, query widths 5, 6 and 8, and 2, 4 and 8
requests at contexts from 300 to 6,000 tokens, plus steps of 2, 4 and 7 requests with one padded request (as a larger
captured CUDA graph runs them) and requests whose rows are a prompt chunk (36 of 36 cases equal); the release's CPU tests
check the same equality in Triton's interpreter and check which steps the new path admits. The v0.4.3 CPU exactness
tests (vLLM's rejection kernels at the served shapes, position by position against the model's distribution) run
unchanged on the v0.4.4 image, and every statistic they print is identical to the v0.4.3 release run. 174 CPU tests pass
(rc 0 in every group), including the launcher's and the startup checks' own tests; the per-test numbers are in the
validation evidence.

Upgrade and rollback

docker pull ghcr.io/brntech/vllm-uno:0.4.4
hf download Broadnet/gemma-4-26B-A4B-uno-adapter --local-dir /path/to/adapter
docker run ... -v /path/to/adapter:/adapter:ro -e UNO_PROFILE=gemma4 -e UNO_RECOMMENDED=1 \
  ghcr.io/brntech/vllm-uno:0.4.4 cyankiwi/gemma-4-26B-A4B-it-AWQ-4bit /adapter \
  -- --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4

The flags after -- turn on Gemma 4's tool-call and reasoning parsers, as on the measured servers.
UNO_DRAFT_MOE_TOPK=4 (part of the recommended settings) runs on compute-capability-8.6 GPUs (RTX 30-series class)
only and refuses to start elsewhere; there, add -e UNO_DRAFT_MOE_TOPK=.

Rollback: the v0.4.3 adapter with `hf download Broadnet/gemma-4-26B-A4B-uno...

Uno for vLLM v0.4.3

Uno for vLLM v0.4.3

Uno for vLLM v0.4.3 adds prompt lookup to the Gemma 4 profile: after Uno's drafted tokens, two more candidates
are copied from the request itself, and the model checks them all in the same pass. With the recommended settings (five
Uno drafts, two lookup tokens, draft passes through 4 of the 8 experts), on BroadNet's production traffic, one request
at a time on an RTX 3090, Gemma 4 26B A4B decodes 1.68x faster than plain decoding and takes 6.3 % less time per
token than DFlash in vLLM 0.30.0; on 14k and 28k-token documents it is 1.41x and 1.28x plain, where DFlash is
slower than plain. The output is the model's own.

The new settings are off by default: an unconfigured v0.4.3 server runs exactly the v0.4.2 path. Four environment
variables turn the recommended settings on (below). The release also points the Gemma 4 instructions at a new adapter, trained on 38,560
open prompts (Hugging Face, revision s5; the v0.4.2 adapter stays at
revision s3).

What changed

• Prompt lookup after Uno's drafts (UNO_PLOOKUP_L=L, 1 to 8). Each proposal is K Uno drafts followed by L tokens
  copied from the request: the tokens that followed the most recent earlier occurrence of the longest matching suffix
  (up to 4 tokens) of the prompt, the answer so far and this step's drafts. The serve script sets
  num_speculative_tokens = K + L, so verification covers all K + L candidates in one target pass.
• A per-request length gate (UNO_PLOOKUP_MAX_CTX=N). A request whose context (prompt plus output) is above N
  tokens verifies only Uno's K drafts. The choice depends on the request's length alone, never on token values, and is
  made before the step runs. Lookup paid on short production requests and cost time on long prompts; the gate keeps the
  first and drops the second. The target model also captures full CUDA graphs at the gated width, so a gated step does
  not fall back to piecewise execution.
• Uno's static-width verify attention path now covers up to 9 rows (K + L + 1), so the wider verify keeps the
  attention kernel Uno's verify already used.
• Recommended settings documented: UNO_K=5 (one more Uno draft than the profile default of 4) and
  UNO_DRAFT_MOE_TOPK=4 (the draft pass routes each token through 4 of Gemma 4's 8 experts; verification keeps all 8).
  Both switches already exist in v0.4.1; v0.4.3 measures and recommends them with lookup. UNO_DRAFT_MOE_TOPK=4 is for
  compute-capability-8.6 GPUs (RTX 30-series class) only and refuses to start elsewhere.
• Startup checks for UNO_DRAFT_MOE_TOPK=4. The 4-expert draft runs only inside captured CUDA graphs. The server
  now refuses to start when it will capture no draft graph (--enforce-eager, a CUDA graph mode without full decode
  graphs, or capture sizes too small for one request's drafts), and checks at startup that every draft batch it can be
  asked for (up to max_num_seqs x UNO_K rows) has a captured graph, refusing with a message naming the missing
  batch sizes if one does not. Before, such a server started and stopped at its first request, or once that many
  requests were in flight. Under the profile defaults (up to 8 requests, capture sizes up to 40) UNO_K of 5 or less
  starts; UNO_K=6 or more, or --max-num-seqs above 8 at UNO_K=5, is refused. The checks run once at startup and
  change nothing in drafting, verification or sampling.
• Nothing else moves: same base image and vLLM build as v0.4.1 (the image is the v0.4.1 release image plus these
  files), same profile defaults, same draft vocabulary, same LoRA kernel configs.

Measured

One RTX 3090, the v0.4.3 container, Gemma 4 26B A4B AWQ 4-bit, the new adapter, the recommended settings (UNO_K=5,
UNO_PLOOKUP_L=2, UNO_PLOOKUP_MAX_CTX=4096, UNO_DRAFT_MOE_TOPK=4). DFlash K8 ran on the stock
vllm/vllm-openai:v0.30.0 image with the same serve flags. One session, two rounds per arm in balanced order.
Production traffic = 72 real requests, completion tokens only. Documents = open-data texts, 4 sets x 2 tasks, up to
384 output tokens, one at a time; median decode time per token, both rounds pooled. Per-arm numbers and the tables
derived from them are in the release's evidence files.

workload	Uno v0.4.3	DFlash K8, vLLM 0.30.0	plain
production traffic, one at a time: ms per token (two rounds)	4.401 / 4.473	4.763 / 4.712	7.450 / 7.466
tokens per second per request	227.2 / 223.5	209.9 / 212.2	134.2 / 133.9
speed-up over plain	1.68x	1.57x	1.00x
production traffic, four at a time: tokens per second, whole batch	501 / 490	505 / 506	358 / 360
speed-up over plain	1.38x	1.41x	1.00x
documents, 2k-token prompts: ms per token (speed-up)	5.07 (1.46x)	6.10 (1.22x)	7.41
documents, 14k-token prompts	6.08 (1.41x)	9.92 (0.86x)	8.55
documents, 28k-token prompts	7.51 (1.28x)	14.49 (0.66x)	9.58

• One at a time, Uno took 7.6 % and 5.1 % less time per token than DFlash (round 1, round 2). On 14k documents, 41 %
  and 33 % less; on 28k documents, 48 % less in both rounds.
• Lookup on vs off (a separate session, the previous adapter, K=4; lookup-ablation.json): with the gate at 4,096,
  3.0 % less time per token on production traffic than lookup off. Without the gate, lookup was 4.7 % and 4.3 % slower
  than lookup off on 14k and 28k-token documents; with the gate, 0.5 % faster at 14k and 2.9 % slower at 28k.
• KV cache at 32k context on a 24 GB RTX 3090: 74,161 tokens with the recommended settings; 79,022 for v0.4.2 as
  published (the 0.4.1 container with the 28.6k-prompt adapter, default settings), measured in the same session. Most
  of the difference comes with prompt lookup and its gate, which capture CUDA graphs at more decode widths: in the
  lookup session, 74,036 tokens with lookup and the gate, 77,227 with lookup alone, 79,022 with lookup off.

Lossless

Every candidate, drafted or copied, goes through vLLM's own rejection sampler, checked against the draft distribution
it was drawn from (so 4-expert drafts change only what is proposed, never what is accepted); a copied token is a fixed (point-mass)
proposal, which the sampler accepts with exactly the model's probability for it, so the output distribution is the
model's. The release's CPU tests run vLLM's real rejection kernels in Triton's interpreter on the served shapes (K=4
and K=5 drafts, L=2 lookup tokens, vocabularies above 8,192 tokens) and check the emitted tokens position by position against
the model's distribution: greedy, temperature 1, temperature 0.7 with top-p 0.9, and batches that mix gated and
ungated requests. Deliberately broken lookup rows are caught by the same tests. 96 CPU tests pass (rc 0 in
every group), including the startup check's own tests; the per-test numbers are in the validation evidence.

Upgrade and rollback

docker pull ghcr.io/brntech/vllm-uno:0.4.3
docker run ... -e UNO_PROFILE=gemma4 -e UNO_K=5 -e UNO_PLOOKUP_L=2 -e UNO_PLOOKUP_MAX_CTX=4096 -e UNO_DRAFT_MOE_TOPK=4 \
  ghcr.io/brntech/vllm-uno:0.4.3 cyankiwi/gemma-4-26B-A4B-it-AWQ-4bit /adapter \
  -- --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4

The flags after -- turn on Gemma 4's tool-call and reasoning parsers, as on the measured servers.

Rollback: unset the four settings (the v0.4.2 path in the same image), or run ghcr.io/brntech/vllm-uno:0.4.1 with the
s3 adapter revision. Prompt lookup was built and measured on the Gemma 4 profile only; the Qwen3-8B
profile's defaults are unchanged.

Uno for vLLM v0.4.2

Uno for vLLM v0.4.2

Uno for vLLM v0.4.2 ships a new Gemma 4 26B A4B adapter, trained on 28,560 open prompts, nearly three times the
10,000 of the previous one. With it the Gemma 4 profile runs BroadNet's production traffic 1.57x faster than plain
decoding, matching the DFlash drafter (K=8, 1.56x in the same session), and decodes long prompts from 2k to 28k
tokens 1.31x to 1.49x faster than plain and 1.29x to 1.98x faster than DFlash. The output is the model's own.

On a single RTX 3090 at 32k context that is 216 tokens per second per request on production traffic (DFlash 215,
plain 137) and 137 tokens per second on a 28k-token prompt (DFlash 69, plain 105).

The image does not change: v0.4.2 runs on ghcr.io/brntech/vllm-uno:0.4.1
(sha256:f679879cada7b90d658246305801f2e9316e6f21f75cb7c3d7cd8fa37642ca34), with the same patch series, profile and
64k draft vocabulary.

What changed

• New adapter at Broadnet/gemma-4-26B-A4B-uno-adapter
  (Hub commit 90e7186d225d7d0c5746e6f84ba5280e6d3077a0). The previous 10k-prompt adapter, then three more stages of
  new open rows (5,000, 5,000 and 8,560), each continuing from the one before; the published checkpoint is the last
  stage's step 17,120. Same rank-16 shape and the same adapter_config.json, so it drops in where the old one was.
  adapter_model.safetensors sha256 abfdde5cfefad7bbbd8525ca38da4da2464b07aa0724beb65dca1fa7f592f2ee (75,627,016
  bytes).
• Tokens per cycle keep rising with more open prompts: 3.71 with 10,000, 3.76 with 20,000 and 3.78 with 28,560, same
  card, same recipe.

Measured

One RTX 3090, the v0.4.1 image, K=4; plain decoding, the previous adapter and DFlash K=8 in the same session on the same
image, two servers each. Production traffic: 72 real requests, one at a time, milliseconds per output token on the HTTP
clock.

	v0.4.2 adapter	10k-prompt adapter	DFlash K=8	plain
ms per output token (two servers)	4.657 / 4.619	4.719 / 4.705	4.663 / 4.649	7.276 / 7.281
speed-up over plain	1.569x	1.545x	1.563x	1.00x
tokens per cycle (τ)	3.76 / 3.80	3.70 / 3.72	3.25 / 3.25	1

Long prompts (open documents, median decode time per output token; Uno 16 requests per length over two servers, plain
and DFlash K=8 8 each, same session and card):

prompt tokens	2k	6k	10k	14k	20k	28k
Uno over plain	1.49x	1.42x	1.41x	1.36x	1.32x	1.31x
DFlash over plain	1.15x	0.96x	0.94x	0.75x	0.72x	0.66x
Uno over DFlash	1.29x	1.47x	1.50x	1.81x	1.83x	1.98x

Lossless: Uno-versus-plain distances are the same size as plain-versus-plain ones (24 short production prompts, 96
samples each, two Uno and three plain servers: mean total variation 0.057 over the six Uno-versus-plain pairs against
0.056 over the three plain-versus-plain pairs; ranges 0.048 to 0.068 and 0.053 to 0.059). Details and raw files in
docs/validation.md and evidence/release-0.4.2/.

Upgrade

Keep ghcr.io/brntech/vllm-uno:0.4.1 and download the adapter again; the run command is unchanged. Since v0.4.3 the
Hub's main branch holds a newer adapter; this release's adapter is at revision s3:

hf download Broadnet/gemma-4-26B-A4B-uno-adapter --revision s3 --local-dir /path/to/uno-adapter

The previous 10k-prompt adapter stays available at revision p10k:

hf download Broadnet/gemma-4-26B-A4B-uno-adapter --revision p10k --local-dir /path/to/p10k-adapter

then mount the downloaded directory as /adapter.

Uno for vLLM v0.4.1

Uno for vLLM v0.4.1

Uno for vLLM v0.4.1 makes Gemma 4 26B A4B decode about 1 % faster on the RTX 3090, and the output is the model's own. The
Gemma 4 profile now ships tuned kernel configs for the adapter's LoRA layers. In the release session the profile runs
BroadNet's production traffic 1.53x faster than plain decoding (1.51x with the tuned configs turned off, same image,
same session).

Everything else is v0.4.0: the same patch series, the same reconstructed release tree
(4aa655488f2c8d86fcc3692b037e03a991dcc9ba), the same digest-pinned base image and the same
P10K adapter. The vLLM package inside the image is
byte-identical to v0.4.0's.

What changed

• Tuned LoRA kernel configs for the RTX 3090. Uno's draft pass runs the adapter through vLLM's LoRA shrink and
  expand Triton kernels, which used vLLM's generic default configs. v0.4.1 ships configs tuned for the shapes the
  Gemma 4 draft pass launches with the rank-16 adapter (shrink over 2,112 to 8,192 inputs, expand to 2,112 to 8,192
  outputs, 4 to 40 rows), chosen by timing each candidate under CUDA graphs, as served, and checking every winner
  against a reference product. At one request (four draft rows) the adapter's kernel time per layer falls from about
  35 to about 24.5 microseconds.
• The profile sets VLLM_TUNED_CONFIG_FOLDER=/opt/uno-kit/release/lora-configs. vLLM matches the files by GPU name, so
  any other GPU keeps its default configs. VLLM_TUNED_CONFIG_FOLDER= (empty) turns the tuned configs off.

Measured

Production traffic (72 requests, one at a time, HTTP clock), one RTX 3090, P10K adapter, two servers per arm in
balanced order:

session	tuned configs	configs off	change	τ (tuned / off)
release image (v0.4.1 candidate)	4.970 / 4.921 ms per token	4.970 / 5.002	-0.8 %	3.70 / 3.71
v0.4.0 image + the same config files	4.882 / 4.875	4.942 / 4.923	-1.1 %	3.70 / 3.70

Tokens per cycle do not move: only the draft pass runs these kernels, and verification skips the adapter branch, so
the emitted distribution is the model's own. The release session's short-prompt distribution check matches plain
decoding as closely as v0.4.0's did (details and receipts in docs/validation.md).

Upgrade

docker pull ghcr.io/brntech/vllm-uno:0.4.1 and run it exactly as v0.4.0. On a GPU other than the RTX 3090 the image
behaves as v0.4.0. The tuning script used for these files is in the release evidence (tune_lora.py), for anyone who
wants to generate configs for another card.

Uno for vLLM v0.4.0

Uno for vLLM v0.4.0

Uno for vLLM v0.4.0 makes Gemma 4 26B A4B, the model BroadNet runs in production for its clients in English and
Arabic, the fastest Gemma 4 26B on long prompts we have measured: 1.3x to 1.8x faster than DFlash, the fastest
Gemma 4 drafter we found, at every length from 2k to 28k tokens, and 1.52x faster than plain decoding on our
production traffic, on a single 24 GB RTX 3090 with the new
P10K adapter. The output is the model's own. The
drafter now runs on Gemma 4's own hybrid KV layout, scores a 64k-token draft vocabulary while verification keeps the
full one, and the verify pass skips the adapter branch.

Why Gemma 4 26B A4B. It is the model behind BroadNet's production agent workloads: email triage and drafting,
service-health monitoring and incident triage, multi-agent coordination, code review, in English and Arabic. The
Gemma 4 family leads the open models in our published Arabic benchmark, on the strength of dialect-authentic
generation, and this model is the base of our Arabic-tuned models. Every speed number here is measured on 72 real
requests from that traffic, replayed on our own hardware, not on a synthetic benchmark; the adapter itself is trained
on open data only.

The package is v0.3.0 plus one patch (0003-uno-hybrid-kv-draft-vocab.patch: three vLLM files and their tests) on the same digest-pinned
vLLM 00972dfd72988942138a7a6089eaee08580210b8 CI image; the reconstructed release tree is
4aa655488f2c8d86fcc3692b037e03a991dcc9ba.

What changed

• Hybrid-KV drafting. v0.3.0 refused any KV layout other than one full-attention group, so Gemma 4 ran with
  --disable-hybrid-kv-cache-manager, stored every layer's cache for the whole context and could not start at 32k on a
  24 GB card. The drafter now accepts several KV groups when every layer spec is full attention or a plain sliding
  window, and one Triton launch writes the draft rows' slot mappings for the extra groups. Chunked, circular and
  compressed layouts, and specs whose tokens_per_state is not 1, are still refused by name at startup.
• Draft vocabulary (UNO_DRAFT_VOCAB). Given a JSON list of token ids, the draft pass scores only those rows of the
  tied LM head and samples from a full-vocabulary buffer that is minus infinity elsewhere; that buffer is also the
  proposal distribution handed to verification, which scores the full vocabulary, so rejection sampling stays exact.
  The release ships a 65,536-id Gemma 4 list ranked on open data and turns it on in the Gemma 4 profile.
• Inactive-adapter bypass. When no token in a batch carries an adapter (every verify pass), the dual-stream LoRA
  path runs the base layer alone instead of launching and zero-filling the auxiliary branch.
• Gemma 4 profile: split-KV draft attention on by default (UNO_GEMMA_SPLITKV=0 turns it off), 32k context
  (UNO_MAX_MODEL_LEN overrides), hybrid KV cache manager on, max_num_seqs=8,
  gpu_memory_utilization=0.90, CUDA graphs covering 32 draft rows and 40-row verify batches. At 32k the Gemma 4 profile holds 79k tokens of KV
  (plain 101k, the DFlash drafter 68k with the same serving flags).

Fixed, and a known issue in v0.3.0

With prefix caching on (the default in both profiles since v0.3.0), a new request whose cached prefix left exactly one
prompt token to compute could come back as <pad> tokens: an exact repeat of a prompt whose length is one more than a
multiple of the KV block size (a retry, n > 1, a benchmark loop). vLLM's scheduler padded that one-token prefill like
a resumed decode, with placeholder draft tokens, and Uno's probabilistic verification accepted them. Ordinary chat
traffic rarely meets the condition. v0.4.0 fixes it in the scheduler, with a regression test; on v0.3.0, upgrade or add
--no-enable-prefix-caching.

What this release validates

docs/validation.md carries the runs; the short version, one RTX 3090, P10K adapter, K=4. "Final" rows ran on the
release image; "first" rows on the first release image, which lacks only the two fixes above:

check	result
Production traffic (72 real requests, one at a time), final	4.934 / 4.905 ms per token vs plain 7.489: 1.52x
Long prompts, 2k / 6k / 10k / 14k / 20k / 28k tokens, first (median decode time; Uno 16 requests per length over two servers, plain and DFlash 8)	1.47x / 1.35x / 1.36x / 1.33x / 1.28x / 1.26x plain (DFlash 1.14x / 0.94x / 0.86x / 0.75x / 0.74x / 0.69x)
Greedy replays vs plain servers (72 requests), first	61 and 57 diverge; plain vs plain 60
Sampled distributions, short prompts, prefix caching on (mean TV), final Uno vs first-image plain servers	0.056 to 0.067; plain vs plain 0.048 to 0.062, two halves of one server 0.060 to 0.073
Sampled distributions, 3k-14k documents (mean TV), first	0.222 to 0.246; plain vs plain 0.233 to 0.245

Scope

One GPU type (RTX 3090, AMD64). The production number is one request at a time; with several users sending long
prompts at once, prompt processing dominated and plain decoding kept pace with Uno and DFlash in our concurrent
long-prompt test. The Qwen3-8B
profile is unchanged from v0.3.0.

Credits

Uno is the work of IFM and the Uno authors. Gemma 4 is by Google; the AWQ checkpoint
is by cyankiwi; the DFlash comparator is by z-lab. This implementation and its measurements are by the BroadNet Research
Team.

Uno for vLLM 0.3.0

Uno for vLLM v0.3.0

Uno for vLLM v0.3.0 adds Gemma 4 26B A4B to the Model Runner V2 implementation
at cf87916880b051e8782521dfe2afa12e0627e172 on vLLM
00972dfd72988942138a7a6089eaee08580210b8. The package builds from vLLM's
digest-pinned per-commit CI image, overlays only verified Python source, and
preserves the base image's compiled CUDA libraries.

Release status. Both profiles are certified on this image. The Qwen3-8B profile
passes its full gate set. The Gemma 4 profile is certified: Uno is as close to plain as plain is to itself across sessions on this hardware, under greedy and sampled decoding alike. The numbers behind that sentence are in
docs/validation.md, which also carries the gate outcomes.

What changed

• Gemma 4 26B A4B support on the Model Runner V2 Uno path: MoE drafting,
  sliding-window attention, and language-only admission for a multimodal
  checkpoint, served as a second profile (UNO_PROFILE=gemma4) beside the
  unchanged Qwen3-8B default.
• Fail-closed draft-scope admission: language-only targets, one KV cache group
  covering every draft layer, no KV transfer or encoder-cache consumer, and
  SM86 for the draft MoE top-k variant, each refused by name at startup.
• An opt-in split-KV draft attention path (UNO_GEMMA_SPLITKV=1) covering the
  checkpoint's two head-size families, logging the engaged width, head size,
  query and KV head counts and segment count per family.
• An opt-in draft MoE top-k variant (UNO_DRAFT_MOE_TOPK=4) that captures and
  replays the drafters' routers at top-4 while the verifier keeps its own
  routing, restores every router on a partial capture, and refuses an
  uncaptured serving shape by dispatch key, environment variable and variant
  name instead of falling back to eager routing.
• A draft-graph coverage receipt and a dispatch-key diagnostic, so a
  captured-versus-dispatched disagreement is visible in the log.
• A floor-matched distributional gate (gates/lossless_floor.py), the profile
  evaluation's own instrument, shipped beside the permutation comparator, with a
  chunk contract that records every pass's request chunking and refuses a
  comparison, or a floor, recorded at a different chunk.
• An ordered two-layer patch series and a corrected release tree: the
  reconstruction now records the squashed head's own tree,
  0149f03eb8287bdfdcc916752b3851405695d350.

What this release validates

The released-image run on an RTX 3090 (24 GiB) re-passes the v0.2.0 gate set
for Qwen3-8B BF16 at K=8: health, functional greedy and sampled generation, SSE
streaming, cold shared-prefix requests, C=8, a queued C=32 capacity check, and
both distributional gates at n=256 with 32 tests, 5,000 permutations, no red
test, and zero in-serving JIT-compilation warnings. A deliberately wrong adapter
revision failed through the same candidate launcher.

For Gemma 4 26B A4B AWQ at K=4 the same runner passes greedy decoding, the live
API and capacity checks, the config-time vision refusal that names
Uno requires a language-only model, and the draft MoE top-k variant boot. The
port evaluation measured Uno at 166.713 tokens/s and plain decoding at 143.694
tokens/s over five 384-token greedy requests, a 1.16× speedup. This measurement
establishes throughput for the stated workload; the certification evidence is
reported separately in docs/validation.md.

The Gemma 4 profile is certified: Uno is as close to plain as plain is to itself across sessions on this hardware, under greedy and sampled decoding alike. The certification interprets the sampled comparisons alongside the
cross-session same-arm controls. The kit's permutation test stays the instrument
for profiles whose plain arm is reproducible, as Qwen3-8B is on this image.

Launch the certified profile with UNO_PROFILE=gemma4 bash release/serve.sh cyankiwi/gemma-4-26B-A4B-it-AWQ-4bit <adapter directory>; the adapter it uses is
published at https://huggingface.co/Broadnet/gemma-4-26B-A4B-uno-pilot-adapter.

G2 preparation/KV, G3 attention, and broader G4/G7 qualification remain
CUDA_UNVERIFIED; the available receipts support only the bounded scenarios
exercised.

Platform

v0.3.0 is Linux AMD64 only; the pinned base image is published for linux/amd64
alone. An ARM64 image follows when vLLM tags a release image containing the
pinned base.

See README.md, docs/configuration.md, and
docs/validation.md for the exact profiles, source
identity, validation record, and artifact checksums.

Uno for vLLM v0.2.0

Uno for vLLM v0.2.0

Uno for vLLM v0.2.0 packages the Model Runner V2 implementation at
5da193919b44335ddf14eac193dfc9e8d5e59df5 on vLLM
b87339888d29329c42c42573e34cc2beebdcc48b. It builds from vLLM's
digest-pinned per-commit CI image, overlays only verified Python source, and
preserves the base image's compiled CUDA libraries.

What changed

• Replaces the Model Runner V1 release implementation with native MRV2 Uno.
• Uses the MRV2 speculative configuration: adapter path, mask-token bound, and
  deterministic noise seed, with eight speculative tokens per step.
• Uses the PR's measured production shape: BF16 Qwen3-8B, async scheduling,
  prefix caching, FlashAttention 2, max_num_seqs=16,
  max_num_batched_tokens=2048, an explicit 2 GiB KV cache, and nine CUDA
  graph capture sizes through 144.
• Includes a reproducible patch, manifest, source-overlay build, offline
  serving validation, and deterministic source bundle.

What this release validates

The released-image run on an RTX 3090 passed health, functional greedy and
sampled generation, SSE streaming, cold shared-prefix requests, C=8, and a
queued C=32 capacity check. The G2v2 sampled and mixed chunk-8 gates passed at
n=256 with 32 tests and 5,000 permutations each. Uno engagement, full startup
warm-up, graph replay, eight real-request nvidia-smi residency samples, and
zero in-serving JIT-compilation warnings were recorded. A deliberately wrong
adapter revision failed through the same candidate launcher as expected.

The implementation is the one carried by upstream
PR #55947, as part of
RFC #55267; the measured
tables and receipts are in the PR description.

Platform

v0.2.0 is Linux AMD64 only. An ARM64 image follows when vLLM tags a release
image containing the pinned base.

See README.md, docs/configuration.md,
and docs/validation.md for the exact profile, source
identity, validation record, and artifact checksums.

Uno for vLLM 0.1.0

Uno for vLLM 0.1.0

Run IFM's Uno diffusion adapter through vLLM's OpenAI-compatible server. This release brings native two-pass Uno decoding to Linux AMD64 and ARM64, with asynchronous scheduling, draft-only LoRA routing, prefix caching, private draft graph replay and seed-row reuse.

Get started

Docker selects the right image for your CPU architecture. Use a Linux host with an NVIDIA GPU, a compatible NVIDIA driver and the NVIDIA Container Toolkit.

docker pull ghcr.io/brntech/vllm-uno:0.1.0
docker run --rm --name vllm-uno --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v vllm-uno-hf-cache:/root/.cache/huggingface \
  ghcr.io/brntech/vllm-uno:0.1.0 \
  Qwen/Qwen3-8B s-sahoo/uno-qwen3-8B -- \
  --attention-config '{"flash_attn_version":2}'

This starts Qwen3-8B BF16 with its original Uno adapter, K=8, on one NVIDIA GPU. The FlashAttention 2 setting above covers the tested Ampere and Blackwell GB10 configurations. First startup downloads the pinned model and adapter, then warms up the runtime; subsequent starts reuse the named download cache. The API is available at http://127.0.0.1:8000/v1 once /health is ready.

See the configuration guide for memory settings, model revisions and source builds.

Tested on hardware

Both native images passed on RTX 3090 (Ampere, AMD64) and GB10 (Blackwell, ARM64):

• Model and adapter loading, health and model endpoints.
• Greedy replies, sampling and streamed responses.
• Shared-prefix requests and batches of 8 and 32 concurrent requests.
• Active Uno drafting and acceptance, private graph replay and seed-row reuse.

Each image also passed 16 package and HTTP-gate tests, matched the source package and retained all 17 checked compiled libraries from its pinned upstream base. The shared source passed 368 focused CPU tests.

The attached validation record identifies the images, source, configuration and test results. The validation guide includes matched plain/Uno comparison procedures for other configurations. Performance measurements and methodology are in the paper and companion evidence.

Source and downloads

The source archive, validation record and SHA-256 checksums are attached. The same source tag supports local builds for either CPU architecture. BroadNet's code and release tools are licensed under Apache-2.0; model and adapter weights download from their original repositories.

• Source tag: v0.1.0, commit 5d9078c83b6082be73cddc430b07fb516612076a.
• Container: ghcr.io/brntech/vllm-uno:0.1.0 (also available as latest). No registry login is required.
• Immutable image index: sha256:2780aa2d0b4c69e4ff8ac397b4c055aef5cf1a1464288d73a5a27bff10bb1224.
• Source archive SHA-256: eb4a1550a1b95c8b83a44da5b85459cfa390a448c62f4bf1336e475f28223eb2.

Attribution

An independent community implementation by BroadNet Research Team. The Uno method and trained adapters are the work of IFM and the Uno authors.

• Uno paper
• IFM's Uno implementation
• Original Qwen3-8B Uno adapter
• BroadNet paper and evidence
• Attribution and notices

Uno for vLLM 0.1.0rc1

Uno for vLLM 0.1.0rc1

The first public research release of BroadNet's native Uno integration for vLLM.
Run IFM's Uno diffusion adapter through vLLM's OpenAI-compatible server, with
draft-only LoRA routing, asynchronous scheduling, private draft graph replay,
prefix caching and seed-row reuse.

The release includes a consolidated patch against a pinned vLLM revision,
reproducible source and Docker build tools, a serving recipe, and matched
plain-reference/Uno validation tools. BroadNet's code and release tools are
licensed under Apache-2.0. The Uno method and trained adapters remain the work
of IFM and the Uno authors.

Get started

Pull the prebuilt container below. The source archive and v0.1.0rc1 tag are
also available for local development and custom builds.
The documented profile is Qwen3-8B BF16, the original Uno adapter, K=8,
one NVIDIA GPU and Linux AMD64. Ampere uses the documented FlashAttention 2
override. Model and adapter downloads are pinned to their original repositories.

This is a research prerelease with a prebuilt Linux AMD64 container and the
source/build recipe. Follow the current repository's
container instructions
for prerequisites and the Ampere FlashAttention 2 override.

docker pull ghcr.io/brntech/vllm-uno:0.1.0rc1
docker run --rm --name vllm-uno --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v vllm-uno-hf-cache:/root/.cache/huggingface \
  ghcr.io/brntech/vllm-uno:0.1.0rc1

First startup downloads the pinned model and adapter into the named cache.
The recorded Ampere integration used an RTX 3090 with 24 GB VRAM; smaller-memory
configurations have not been validated. The container verification attachment
records the checks of the exact image.

Published Linux AMD64 image digest:
ghcr.io/brntech/vllm-uno@sha256:569209545da6898a0de3601a8d15b22d24a9019f38fd139de793d0120fd76f2a.
The image and all 41 layer blobs were accessible anonymously, and an unsigned
Docker pull passed. No registry login is required.

Validation

• 368 focused source CPU tests passed, with no skips, under Python 3.12.
• 16 package and HTTP-gate regression tests passed in the final built image.
• The Linux AMD64 build preserved all 17 checked compiled libraries.
• All 31 package files matched between the committed source, source archive
  and built image.
• A prior bounded RTX 3090 run of the equivalent runtime implementation loaded
  the model and adapter, completed a 256-token request, and demonstrated active
  Uno drafting, private graph replay and seed-row reuse.

The current public image was not rerun on a GPU. Full matched sampled-distribution
and strict greedy comparison passes are not claimed for this version. The
validation guide
records the evidence and provides the reference/candidate procedure. Historical
H100 measurements are documented separately in the paper.

Downloads and source identity

• vllm-uno-0.1.0rc1.tar.gz: the complete 31-file source kit.

• validation.json: source identity, recorded checks and per-file SHA-256 hashes.

• SHA256SUMS: checksums for the source kit and validation record.

• container-verification.json: published image identity and container checks.

• CONTAINER-SHA256SUMS: checksum for the container verification record.

• Source commit: 2b90eafe36921dc9f8136aa1ad3c93241da9650a

• Upstream vLLM: e962733e08d10f7ca65dac4df99e116460b8b174

• Reconstructed vLLM tree: 5676f765c94d7afaf1c03cd9e7fbdf3dbcaf8ef7

Research and attribution

• BroadNet paper and companion evidence
• Uno: Unlocking Lossless Speedups in LLMs via Discrete Diffusion
• IFM's Uno implementation
• Original Qwen3-8B Uno adapter
• Upstream attribution and notices

An independent community implementation by BroadNet Research Team.