When 27B Feels Bigger: A Local Qwen3.8 Agent Field Guide

Deployment facts

The runtime under test, frozen with the packet. One model checkpoint, one runtime, one GPU pair; the only variable across the four measurements below is the speculative-decoding configuration.

Provenance: this page is materialized exclusively from the operator-issued frozen measured packet (Phase 2 bounded data handoff). No local evidence or web source was opened for this artifact. All values are measured campaign evidence.

Four variants, one model

Same checkpoint, same runtime, same 131,072-token ceiling. Parent runs without speculative decoding; the three MTP variants enable multi-token prediction at depths 1–3. Note for the deep variants: MTP-2 and MTP-3 repeatedly run the model's single MTP layer — they do not load multiple distinct draft models.

Context and decode: near-empty vs full

Decode speed at the two frozen context endpoints: near-empty context and full 131,072-token context, each a 256-token completion over 36 successful requests per variant. The gap between the two bars of a variant is its endpoint loss.

Compare any two variants at either endpoint

Pick an endpoint and two variants. Deltas are computed live from the frozen values and labeled as such; nothing here is estimated or interpolated.

Keyboard: Tab / Shift+Tab move between the controls, ←/→ switch the endpoint radio pair and change a <select>, and the chart updates live. All controls are standard form elements with visible focus rings.

MTP draft acceptance

How often the main model accepts the layer's drafted tokens, at each endpoint. The parent has no MTP layer, so no acceptance applies. Remember: MTP-2 and MTP-3 repeatedly run the same single MTP layer — deeper depth is repeated use, not a different draft model.

Thermals and VRAM

Peak values across each variant's run. The MTP variants peak a little above the parent on memory and a little on temperature, while power stays essentially flat — and software power-cap samples occurred, so every peak below is inside the capped envelope. No thermal slowdown of either kind was sampled.

Slowdown accounting (frozen): software power-cap samples — occurred; hardware thermal slowdown samples — 0; software thermal slowdown samples — 0.

Hermes operational lessons

What the frozen packet says about running a Hermes agent against this deployment. Each point traces directly to a field in data.json; derived arithmetic is labeled as derived.

1. Compaction sits before the ceiling, by design. Hermes is configured for 80% compaction (hermes_compaction_threshold) against a 131,072-token server context. Derived: 0.80 × 131,072 = 104,857.6 — compaction engages around 104,858 tokens, well before the server stops taking context.
2. Judge a variant at both endpoints, not one. MTP-2 posts the fastest near-empty rate (69.9185759 t/s) yet the largest endpoint loss (19.0850201%); MTP-1 degrades least (2.6889170%) with a 58.4112987 t/s near-empty rate; the parent loses 11.0454406%. The "fastest variant" depends on where your conversation lives.
3. Uplift is flat across depth; acceptance is not. Full-context uplift over the parent runs 32.3821558% (MTP-1), 31.7624877% (MTP-2), 34.5128842% (MTP-3) — within a few points — while acceptance falls with depth, from MTP-1's 0.6037736 / 0.7162162 to MTP-3's 0.4086957 / 0.4081633 (near / full).
4. Deeper MTP is not a bigger draft model. MTP-2 and MTP-3 repeatedly run the model's single MTP layer (frozen packet note). Compare depths as repeated use of one layer, not as different draft checkpoints.
5. The power cap is doing work; the thermals are not. Software power-cap samples occurred in the logged runs while hardware and software thermal slowdowns were both zero. Peaks (VRAM 22,407–23,503 MiB, 63–64 °C, 349.01–349.56 W) belong to a capped envelope. Derived: the MTP variants peak 1,064–1,096 MiB above the parent's 22,407 MiB.
6. Plan sessions against the context ceiling, not the KV pool. The deployment reports a KV pool of 257,960 tokens against a 131,072-token max model context (both server-reported deployment facts). The 131,072 figure is the operational ceiling; the pool size is not a second, larger window.

Limitations, stated plainly

• Two endpoints only. The packet freezes near-empty and full-context decode rates. The protocol records 12 anchors × 3 repetitions (36/36 successful per variant), but per-anchor values are not part of this artifact.
• 256-token completions. Every rate is a measured decode rate for 256-token completions. No longer completions, no wall-clock latency, no token counts beyond the frozen fields, no energy totals.
• Endpoint labels as given. "Near-empty" and "full" are used as frozen in the packet; the exact contents of the anchor prompts are not part of this artifact.
• Single MTP layer. MTP-2 and MTP-3 repeatedly run the model's single MTP layer; the three MTP variants are not three distinct draft models.
• Frozen-packet provenance. Values were materialized from the operator-issued packet without opening local evidence or web sources; this page does not re-audit them.
• Server-reported figures. The 257,960-token KV pool and the 131,072-token max context are server-reported deployment facts, not independent measurements in this artifact.
• Capped power. Because software power-cap samples occurred, peak power values describe a capped envelope; behavior outside it is out of scope.
• No variance or failure data. The packet carries no per-request min/max/variance and no failed requests (36/36 successful, as frozen); none is displayed here.

Frozen packet notes, verbatim

All values are measured campaign evidence as frozen by the operator for the Phase 2 handoff.

Endpoint loss / endpoint uplift values reproduce arithmetically from the given near-empty and full-context decode rates (verified at materialization).

MTP-2 and MTP-3 repeatedly run the model's single MTP layer; they do not load multiple distinct draft models.