XeStrata xe0.1.43.1 was published on October 12 at 20:19 UTC, early on October 13 Korean time. It is a hotfix that returns Qwen3.8-Flash-Next prefill on Intel GPUs to its original path.

Prefill is the stage where the model reads in the whole prompt. According to the maintainer, xe0.1.43 ran this stage on Intel Arc GPUs through the slow DP4a path instead of the matrix engines (XMX), making it about a third slower at 32K on the Arc Pro B70.

On an Arc Pro B70 with IQ3_XXS quantization at 32K, 1,590 tok/s in xe0.1.43 became 2,415 tok/s in xe0.1.43.1, with the same answers as before xe0.1.43. This is the maintainer's regression comparison, not an independent reproduction or a figure for every supported GPU.

The machine-code swap in packages, fixed earlier

xe0.1.42, released on October 11 UTC, fixed a different kind of defect. A bug in the compiler that builds the packages (intel/llvm) put another GPU's machine code under some GPU targets.

The cases named were AMD gfx1030, gfx1101, gfx1201 and others, and NVIDIA sm_80, sm_86 and sm_89 being swapped. Names like these are the target labels a compiler uses when producing machine code for a particular GPU generation.

On such a GPU the engine could stop (ILLEGAL_INSTRUCTION on an RX 9070 XT), run slowly or give wrong answers. The project says packages built with the fixed compiler were checked to carry each GPU's own machine code.

How a packaging defect differs from a path-selection defect

xe0.1.42 was about whether code matching the device went into the package, while xe0.1.43.1 was about which of several paths was selected at run time.

A correct binary can still pick a slow path, and turning on an accelerated path does not fix a package built for the wrong target.

So a report with only a version number and a tok/s figure, without GPU and backend details, can hardly tell the two defects apart.

Matrix acceleration hardware differs by vendor

According to the project documentation, XeStrata targets one Intel Arc, AMD Radeon (RDNA2 or later) or NVIDIA GPU on Linux. Matrix products run on XMX on Intel, WMMA on AMD (RDNA3 or later) and tensor cores on NVIDIA, and a GPU without matrix engines uses integer dot-product instructions such as DP4a.

On AMD, prefill's dense matrix products run in the distribution's ROCm rocBLAS and hipBLASLt. ROCm is AMD's runtime and library stack for its GPUs, and the documentation says only the RX 9060 XT (gfx1200) has been checked for that table.

In other words these are not one accelerator under vendor-specific names but different hardware features. That is why news of a restored Intel path is hard to carry over to performance expectations for other vendors' cards.

Caveats: conditions for quoting the numbers and saved-conversation compatibility

In the hotfix's comparison against upstream, the RTX 4070 and RX 9060 XT are still listed as being measured. The 1,590 to 2,415 tok/s regression comparison is also a separate experiment from the upstream Strata comparison in the same release.

Because the version changed, conversations saved with --conversation-save by an earlier version are not read.

The release notes' install procedure checks the downloaded package against its checksums and then checks the setup.

sha256sum -c SHA256SUMS --ignore-missing
xestrata --setup

If a GPU library or the render group is missing, xestrata --setup prints the command that installs it and stops; run that command, then run setup again.

Records to keep before updating

Recording the current package version, model file, GPU architecture and runtime libraries first makes it easier to tell what changed after the update.

Keeping the previous configuration and a few representative prompts also allows comparing whether answers changed.

A comparison that separates prefill from generation

A path regression like this one only shows up when prefill and generation speed are measured separately with the same model and input length. A single number mixing the two cannot show which stage slowed down.

This article is based on reading the release notes and project documentation; it did not run XeStrata or verify GPU combinations.

XeStrata's two fixes address different layers, whether the package carries the right machine code and whether the matrix-engine path is selected at run time, and a speed figure alone reveals neither.