Devotd Github
NewInference & serving

wallawalla47/infernix 68cb699 — CPU assist for 122B prompts up to 575 columns

infernix's 2026-11-05 commit widens the CPU assist range for prompts on 122B models from 255 columns to 575 columns, reducing the throughput cliff that had appeared beyond 256 columns.

Repositorywallawalla47/infernix ↗

infernix's 2026-11-05 commit widens the CPU assist range for prompts on 122B models from 255 columns to 575 columns, reducing the throughput cliff that had appeared beyond 256 columns.

GitHub description: C++/CUDA single-GPU inference engine for Qwen3.8 (incl. Qwen3.8-Flash-Next with offloaded experts) on the RTX 5090; grew from NInfer

stars
★ 118
Forks
18
Language
C++
License
Apache-2.0
Latest release
windows-2026.10.11
Read original source ↗View on GitHub ↗

infernix is a C++/CUDA single-GPU inference engine that runs the Qwen3.8 family on a single RTX 5090. It also includes Qwen3.8-Flash-Next, which offloads experts, and the project originated from NInfer. The 2026-11-05 commit 68cb699 widens the CPU assist limit for prompt calls on 122B models here from 255 columns to 575 columns, and changes it so that from 576 columns onward it hands over to streaming. This path applies only when the NVFP4 W4A16 expert bank uses the same CPU arithmetic path.

The goal is to close the throughput cliff that arose on prompts exceeding 256 columns. The commit message records, before the change, 279.5 tok/s at 255 columns and 228.1 tok/s at 256 columns. Using a commit from the same repository as the baseline, with a single process running a -p list, 4 alternating repetitions per arm, and INT8 KV conditions, the measured figures are +4.0% at prompt 128 columns, +14.5% at 192 columns, +13.1% at 255 columns, +40.5% at 256 columns, +33.9% at 320 columns, +26.0% at 384 columns, +17.0% at 448 columns, +9.7% at 512 columns, and +4.2% at 575 columns, and it states that it led in every repetition. The streaming region at 576, 768, and 1023 columns is -0.2%, -0.1%, and -0.1%, effectively a tie, and the commit adds that this region was -3.3%, -2.5%, and -1.2% before the modification. The cause was that the side which split off the streaming pass also inherited the link occupancy share of the assist calls and was therefore 1.2~3.3% slower; this time that share was cut off at 0. It is a batch-level change that only differs in which device computes the expert, and the commit writes that the reproducible expert id at a 450-token prompt was the same as 42edfebe. The limit and the occupancy-share ramp are determined by assist_max_columns and assist_link_share in ExpertOffload.

However, all the evidence is produced by the repository on its own basis. The comparison target is the immediately preceding commit of the same repository, and the measurement conditions are fixed at a single process, 4 repetitions, and INT8 KV. The link occupancy share values (77/256 at 64 columns, 104/256 at 255 columns, 149/256 at 575 columns) are values re-measured with the same CPU kernel in Flash-Next's FP4-Local and carried over, not values re-measured on 122B. The region beyond 575 columns is streaming, so there is no improvement, and this path applies only to configurations using the NVFP4 W4A16 bank, while other expert banks still stop at 255 columns. There is no license or star count in the given material. If you are running 122B with CPU offloading on an RTX 5090, it is worth checking, but what to expect under other conditions is still too early to judge.