expXa vs PXA 4 on Qwen3.6-35B-A3B Q6_K

Matched depth-one MTP

Three scored runs per engine and input length, with exactly 128 generated tokens. Request time includes the whole HTTP request; native prefill and decode rates describe the engine’s timed phases.

Matched runs with MTP disabled

What MTP changes

The following compares median total request time with MTP off and on within each engine. Positive percentages mean a shorter request with MTP. Draft and acceptance counts for each request are included in the download.

Correctness and recovery checks

Natural-stop arithmetic, grounding, extraction and negation checks passed 48/48 cases. Chat-formatted retrieval checks placed three edited facts throughout a roughly 65K-token archive and passed 8/8 cases. Following-request checks after cancellation passed 12/12 launch groups. These are bounded functional checks, not a general model-quality benchmark.

Method

• Identical Q6_K weights and CPU-resident vision projector, both GPUs, equal layer split, all model layers on GPU. Context allocation 262,144; Q8_0 key/value cache; 10 generation and 10 batch threads; batch 4,096 and microbatch 1,024; one slot; 64 context checkpoints.
• expXa uses its qualified 4×8 attention and two-token Q6_K MTP profile. PXA uses its own implementation with the same explicit depth-one MTP setting. MTP-off arms disable speculation explicitly. This measures complete builds; it does not isolate one attention kernel.
• Matched token arrays at 512, 4,096, 16,384 and 65,536 tokens. Temperature zero, seed 42, prompt caching disabled. All five model end-of-generation tokens are suppressed for speed requests only. Natural-stop checks clear that bias.
• Three rounds rotate the four engine/MTP configurations and prompt-length order. Every launch has an unscored 512-token warmup. Loading is excluded. The schedule is rotated, but three rounds do not fully counterbalance four configurations.
• Every scored response must report the complete input length, no truncation and exactly 128 generated tokens. Request wall time and time to first content are measured by the same local client.
• Other inference was fenced throughout the scored window. Other models remained loaded, so this is the same shared-memory layout for both engines. Resource reserves and unrelated process identities were monitored. The original serving configuration was restored and verified afterward.

Excluded attempts

An initial launch was refused by the runtime lock before scoring. A subsequent attempt stopped after a 4,096-token request ended at 93 output tokens despite the generic ignore-EOS option. Its entire partial arm, including the preceding 512-token run, was excluded. The final study explicitly suppressed all five end-of-generation tokens for both engines and reran the comparison.

Limits

• One dual-V100 host, one quantization and three repetitions per configuration. Shared-host CPU and storage activity can still introduce noise.
• Synthetic, repetitive prompts with forced output length can favor different speculative acceptance rates than conversation. Natural stopping and real workloads may change the ranking.
• The 262K context was allocated; the longest speed prompt evaluated here was 65,536 tokens. This is not a 262K retrieval or throughput qualification.
• Output hashes were stable across repeats within each configuration. They differed across configurations at 512 and 4,096 input tokens, and matched across all four configurations at 16,384 and 65,536 tokens. Short-input decode rates therefore include differences in the generated token sequence. Passing the short functional checks does not establish broad equivalence or language quality.

Related study: the 30B Q4_K_M comparison with CPU expert offload. Its placement and model differ, so the absolute times are not a controlled model-to-model comparison.