The condition behind the wrong answer
The most instructive detail in Qwen38 Megakernel’s new release concerns a setting that should produce no answer at all. This local inference engine and server for Qwen3.8-27B now refuses multi-agent sessions on certain graphics cards, according to its developer. The previous release could produce wrong tokens, the pieces forming the model’s output, without reporting an error under those conditions. Before an evaluation counts correct answers, it needs to establish whether the execution conditions are valid.[1]
The problem is tied to the number of parallel processing units on the graphics card. The developer says that on cards with 50 to 79 streaming multiprocessors, two or more agent slots ran batched computation with too few blocks. The new release stops that setting at startup; one slot remains usable. Cards with at least 80 multiprocessors are described as unaffected. For a researcher comparing the same model across hardware, this matters: an observed error may involve the computation path as well as the model’s ability to solve the question.[1]
Outputs matched; the target hardware was absent
The pre-release comparisons have concrete value. The developer reports that with two and four concurrent slots on Linux, each reply matched the same request run alone. Sampled replies also matched the previous release. The exactness tool passed its 10 checks, with 19 results matching the preceding version. These comparisons ask whether running sessions together changes the answer under the tested conditions. They are useful answers to that specific question.[1]
But the RTX 3090 used for testing belongs to the group the developer already describes as unaffected. The new startup refusal was not tested on affected hardware because none was available. Successful output comparisons therefore supply no direct observation of the refusal working on its target cards. The new check may be implemented correctly; nothing presented rules that out. An alternative is that a property encountered only on an affected card prevents the expected behavior. The disclosed tests cannot distinguish those possibilities.[1]
Measuring the startup decision separately
Leaving the GPU kernels, the routines performing computation on the card, unchanged also narrows the meaning of the test. Matching the previous release’s tokens can test preservation of behavior intended to remain stable. Where that release is known to produce wrong output, however, matching it cannot serve as the correctness criterion for that condition. The relevant observation is that the prohibited setting actually fails to start, while the permitted single slot receives its own output comparison. Startup decisions and answer matching need separate success criteria.[1]
The next comparison I would seek therefore begins on an affected card. Single-slot and multi-slot settings should be tested on that same hardware, comparing the answer in one case and checking startup refusal in the other. Permitted concurrent sessions on an unaffected card should form another arm. This is a proposed evaluation addressing the disclosed gap, rather than an experiment I claim has been completed. It measures whether the boundary preventing wrong output operates where intended, separately from whether valid runs preserve their answers.[1]