Measured · 21 to 23 September 2026 · 54 runs
Long context on the HP ZBook Ultra G1a
halogen-flash-server 0.12.1 and 0.13.1 from 32,000 to 990,000 tokens
Authors
Machine
HP ZBook Ultra G1a
- SoC
- Ryzen AI Max+ PRO 395
- GPU
- Radeon 8060S, gfx1151
- Memory
- 128 GiB LPDDR5X-8000, soldered – shared by CPU and GPU as unified memory
- SSD
- Samsung 990 PRO, 4 TB, NVMe on PCIe 4.0 x4
- OS
- Ubuntu 24.04,
140 W power supply,
platform_profile=performance
Model
Qwen3.8-Flash-Next
- Size
- about 180B – measured at 176.9 billion parameters
- Build
- “512×56B”, 48 blocks, 512 experts, 10 of them active per token
- Context
- native up to 262,144 tokens, beyond that YaRN with factor 4
Engine
halogen-flash-server
- Version
- image
0.12.1and0.13.1, Podman – byte-identical tokens - Weights
w4b.hgn+ quality overlay, 5.53 bpw- Flags
HALOGEN_CTXper length up to 1,048,576,HALOGEN_ROPE_YARN=4beyond 262k- Budget
- 3,072 output tokens per task, temperature 0, a fresh container per run
Tasks
Eight questions about a weather log
- Text
- 651 lines of weather-station readings, the same at every length
- Length
- padded with an unrelated maintenance journal
- Kind
- look up, compare, count, sum
- Scored
- six; the two arithmetic tasks test sums, not context
1,194tokens/s
Prompt processing on the first question about a text
27seconds
Reading the whole text once, on the first question
1.8seconds
Reading a follow-up the text itself is already processed
47.2tokens/s
Output when answering follow-up questions
100.1GiB
Memory held of 125.1 GiB; left afterwards: 13.2 GiB
768tokens/s
Prompt processing on the first question about a text
21.5minutes
Reading the whole text once, on the first question
2.3seconds
Reading a follow-up the text itself is already processed
40.9tokens/s
Output when answering follow-up questions
109.3GiB
Memory held of 125.1 GiB; left afterwards: 4.1 GiB
Medians over all runs at the given length. On the first question about a text the machine reads all of it. On every follow-up question it is already processed, and only the new question is added. Chapter 02 shows the lengths in between.
01 · Setup
The same task at every length
To find out whether a model understands a long context, you have to change the length and hold the task still. So the questions always concern the same weather log: 651 lines of weather-station readings, about 32,000 tokens, with eight questions that each have one unambiguous answer. An unrelated maintenance journal before and after it brings the text to each length, with 957,999 tokens at 990k. If the result changes, it can only be the length.
Up to 245k three versions of the weather log with different random values ran per step, one beyond: 21 runs for understanding. For speed, all 54 scored runs of those days count, including those with other documents of the same length; how fast the machine reads and answers depends on the number of tokens, not on their content. Discarded are warm-up runs, repeats of the same document and pilot runs with other settings. Which run is missing and why is in the evaluation in the repository.
02 · Speed
Read once, then it answers in seconds
On the first question about a text the machine reads 1,194 tokens per second at 32k and 768 at 990k. Every follow-up on the same text then takes at most 2.3 seconds, at every length.
For work on a long document this means: you wait once, 3.9 minutes at 245k, and then keep asking in conversation. An agent that extends its history pays for reading only what is new.
03 · Memory
The pool sets the memory, not the prompt
At startup halogen reserves a pool for a fixed number of positions and holds all of it, however long the text turns out to be. Up to 262k every run used the same pool: 100.1 GiB, whether the prompt had 32,000 or 245,000 tokens. For 990k it is 109.3 GiB of 125.1 GiB.
Beyond 262k halogen ran with a generation budget of 16,384 instead of 32,768 tokens. That lowers the working memory from 21.4 to 12.5 GiB, which is why the pool for 396k holds less than the native one.
At 990k it gets tight. After startup the machine had 4.1 to 5.6 GiB left for everything else, and while reserving the pool the kernel already had to compact memory 534 times; with the smaller pools not once. Next to a pool this size nothing large should run on the notebook.
04 · Understanding
Understanding holds up to 262k and slips beyond
Up to 245k the model solves 106 of 108 scorable tasks.
Within the native limit, length is no obstacle for this model. The first version of the weather log solves all eight tasks at every step up to 245k, the two arithmetic tasks included; across all 18 runs 2 answers are missing, spread over 64k and 245k, not piled up at the top end.
05 · Beyond 262k
The first thing to fail is the look-up
Beyond the native limit it is the length. The same weather log gives 6 of 8 correct answers at 396k, 4 of 8 at 594k and 5 of 8 at 990k.
The pattern is not an even decline. The model names a real sensor ID from the same log, only from the wrong row; at 245k it still picks that row reliably. So it does not lose the text but the exact place in it.
Reading also gets more expensive beyond the limit: at 990k every token costs 35 percent more time than at 245k. Output is almost untouched by it.
06 · YaRN
At equal length, YaRN does not change the result
Beyond 262,144 tokens the model only gets there with YaRN, a stretch of the position encoding. The suspicion that it causes the drop is obvious. The measurement refutes it.
Two independent cross-checks stand behind this: a block of four runs in alternating order on a long weather log of 4,993 lines, and one run with the short weather log inside the maintenance journal that joins the native series exactly. The wording of the answers changes with YaRN, the solution does not.
YaRN is what makes lengths beyond 262k possible, but it does not cause the model to look up worse there. That is the length itself.
07 · Every figure
Results per length step
Understanding: the weather log inside the maintenance journal, the six scorable tasks across all runs of the step. Speed: medians across all scored runs of the step. Every chart in this report is computed from these values; the values per run are in docs/kontext-werte.json.
| Length | Scaling | Runs | correct |
|---|---|---|---|
| 32k | native | 3 | 18 / 18 |
| 64k | native | 3 | 17 / 18 |
| 96k | native | 3 | 18 / 18 |
| 128k | native | 3 | 18 / 18 |
| 192k | native | 3 | 18 / 18 |
| 245k | native | 3 | 17 / 18 |
| 396k | YaRN 4 | 1 | 5 / 6 |
| 594k | YaRN 4 | 1 | 4 / 6 |
| 990k | YaRN 4 | 1 | 4 / 6 |
| Length | Runs | Reading (s) | Reading (t/s) | Output (t/s) | Follow-up (s) |
|---|---|---|---|---|---|
| 32k | 4 | 27.0 | 1,194 | 47.2 | 1.8 |
| 64k | 6 | 57.3 | 1,120 | 45.6 | 1.7 |
| 80k | 3 | 73.9 | 1,084 | 40.9 | 1.8 |
| 96k | 6 | 86.7 | 1,109 | 43.6 | 2.0 |
| 112k | 3 | 104.2 | 1,076 | 45.5 | 1.5 |
| 128k | 6 | 119.9 | 1,069 | 44.4 | 1.9 |
| 144k | 3 | 138.9 | 1,037 | 36.5 | 1.9 |
| 160k | 3 | 156.0 | 1,026 | 37.0 | 2.0 |
| 176k | 3 | 177.5 | 996 | 43.3 | 1.8 |
| 192k | 6 | 184.1 | 1,044 | 42.3 | 2.1 |
| 229k | 1 | 229.1 | 1,000 | 44.1 | 1.9 |
| 245k | 4 | 236.4 | 1,037 | 41.9 | 1.8 |
| 396k | 2 | 444.9 | 891 | 44.1 | 1.8 |
| 594k | 2 | 709.6 | 837 | 42.5 | 2.1 |
| 990k | 2 | 1,289.0 | 768 | 40.9 | 2.3 |
| Pool | Budget | Starts | Weights | KV-Pool | Working | total | left |
|---|---|---|---|---|---|---|---|
| 393,216 | 32,768 | 9 | 68.0 | 10.8 | 21.4 | 100.1 | 13.2–13.7 |
| 425,984 | 16,384 | 2 | 68.0 | 11.7 | 12.5 | 92.1 | 21.1–21.7 |
| 622,592 | 16,384 | 2 | 68.0 | 17.1 | 12.5 | 97.6 | 15.3–16.3 |
| 1,048,576 | 16,384 | 2 | 68.0 | 28.8 | 12.5 | 109.3 | 4.1–5.6 |
08 · Limits
What this work does not show
One version beyond 262k. Above the native limit one version of the weather log ran per length. At temperature 0 the same document repeats the same answer; the spread lies between documents and is not measured there. That 990k solves one task more than 594k belongs to this. What holds is the gap: the same version is error-free up to 245k and no longer from 396k.
One pool for every length up to 262k. Up to 262k every run used the everyday pool of 393,216 positions. How much memory a smaller pool would save for short texts is not measured.
The smaller arena. From 396k halogen works with a generation budget of 16,384 instead of 32,768 tokens. That changes together with the length and is not measured separately.
One kind of document. The tasks ask about a tabular measurement log. For source code, prose or conversations the limit may lie elsewhere.
One engine, one machine. What is measured is halogen 0.12.1 and 0.13.1 on the HP ZBook Ultra G1a. The speed holds for this stack; whether llama.cpp understands the same at the same lengths is not measured here.