The same weights, 1600 points apart: serving Jevlar through Flide

The first post ended with Jevlar at 3604 over 100 games, second on Opper's JevMan leaderboard behind the greedy rule it learned from, and with one finding that was really about plumbing: the same weights scored 700 points more at 54 ms an answer than at 193 ms, because the escape answers arrived in time. This post is what happened when we kept pulling on that thread. Not one weight changed. The engine did, the answer went from 54 ms to 16 ms, and the 100-game score went from 3604 to 5183 ± 455, above the greedy rule.

The engine

Jevlar had been served the way it was built: a transformers forward pass per question, in a container next to the game, with the fast kernels for Qwen3.5's linear-attention layers installed. On an H100 that answered in 54 to 58 ms. For a 500-token prompt through a 4-billion-parameter model the arithmetic itself takes a few milliseconds; the rest is the hundreds of small GPU launches a layer-by-layer forward makes, and the Python between them.

Flide is an inference engine built for exactly this kind of model: a decision model that reads one prompt and answers at one position, no generation. It captures the whole forward as CUDA graphs at start, so a request is one replay instead of hundreds of launches; it runs fused kernels for Qwen3.5's layers; and it packs every question of a request into one forward, sharing the part of the prompt the questions have in common. It serves the same System One API the benchmark speaks.

Plugging Jevlar in meant teaching Flide Jevlar's prompt and readout, about 150 lines: render each question exactly as before, system turn and all, read the logits of the four direction words at the answer position, add the position bias, draw the pick at the same temperature. Exactness was the whole point, so the rendering was moved into one module shared by both engines and checked byte for byte on 550 requests recorded from real games, and the tokens Flide feeds the model were checked against the whole-prompt tokenization on every one of them. The edited weights, which live in a small file applied at load, were written once into a full checkpoint for Flide to read. From a cold container the model loads in 9 s and the graphs capture in 5 s; the server answers 46 s after start.

The sharing of prompt text between questions, Flide's headline feature, buys Jevlar little: the game's two questions differ already in the system turn, so only the first 113 of about 500 tokens are shared. The gain here is almost all launch overhead. Two smoke runs of two games confirmed the path worked and answered in 15 to 16 ms; then the 24 games, then the 100.

The numbers

Both rows are the same file of weights, the same prompt, the same H100, the same benchmark settings. The first is the run from the previous post.

The 24-game run played first gave 4908 ± 873, inside the 100-game figure's spread. The best game scored 12210; the median was 4720; three games reached level 3. Error bars are two standard errors over the games, the submission checker's convention, and the checker replays every recording before it counts: both folders pass.

Why

The mechanism is the one the first post found, carried further. When a ghost comes down the corridor the benchmark asks "keep going or turn back?" and re-asks as the situation changes; an answer that lands after its question was replaced is logged as stale and never used. At 193 ms Jevlar used 6 escape answers a game and 16 arrived stale. At 54 ms it used 33 and 12 arrived stale. At 16 ms it uses 83 a game and 2 arrive stale.

escape answers a game, used in time and arrived stale · the hc1 weights at four answer times, 24 to 100 games each

That last number is the surprise. The first post concluded that speed only pays below about 100 ms, from the step between 119 ms and 58 ms. It turns out 54 ms was still leaving a quarter of the escape answers on the floor, and the benchmark asks more of them the longer Pac-Man lives: 305 calls a game at 16 ms against 182 at 54 ms, because the games run half as long again and into levels where the ghosts are faster.

The deaths tell the same story. Over the 100 games at 54 ms, 225 deaths came at junctions, 57 with a ghost ahead in a corridor and 18 while waiting for an answer. At 16 ms: 191 at junctions, 97 in corridors, 12 waiting. The corridor deaths went up, not down, which looked wrong until the levels were counted: 52 games reach level 2, where corridors are where the faster ghosts catch you. Jevlar is not escaping worse; it is living long enough to meet harder ghosts.

What this says about the leaderboard

Jevlar's 5183 is above the greedy rule's 4450, the hand-written search that plays the practice games it learned from. That figure is the benchmark's own, from its fallback over 8 games, so the comparison is not like for like, and the rule is still the better player of a single position: Jevlar agrees with it on 90% of held-out positions and never more. What Jevlar has over it is not judgement but time. The rule's answers are instant; the model's used to be late, and now they are not.

It also says something uncomfortable about the previous table. Every entry on the board that is a model has a serving stack behind it, and the stack is worth more points than any edit we made. The whole climb of the first post, from 1327 to 3604, was 2300 points of weight-space programming; the engine swap is 1600 points for no weights at all. A leaderboard of decision models under a real-time game is, to a first approximation, a leaderboard of latency, and should probably say so next to each score.

A patch back to Flide

One thing went back the other way. Reading Flide's own family for the Open-Jev models on the way in, we found it tokenizing a request's context serially and then copying the result into every branch to scan it again. By the time the patch was ready, Flide 0.1.12 had done the first part itself; the rest, comparing only the branches' own tokens, is now a pull request on Flide: planning a 25-branch request on a long context 40% faster, with the plans unchanged on 300 random requests.

Where it stands

The entry keeps the benchmark's "trained" label: the read-outs were fitted on simulator positions, and nothing about the engine changes that. The 0.8B has not been run through Flide; the first post found its deaths were decisions, not late answers, and that is worth checking again now that 16 ms is on the table. The edits, the family, the checkpoint tool, the bench logs and all 124 recordings are published with the entry.