Tileward / Evals
Evals

See what Tileward changes before you deploy it.

Every test we have run, with its result in one line. The tables come first. The cards under them show the detail, and each one links to its write-up.

Tileward Models Each build, its size, and what held.

ModelBuildFile sizeWhat held
Tileward 35B-A3BTWX4871.9 → 24.1 GB66% smaller (3.0×)Level with the publisher’s own FP8 build on MMLU, 82.8% against 82.9%, and 36% smaller than that build (1.55×).
Tileward 35B-A3Bagainst NVIDIA’s NVFP4 buildTWX4871.9 → 24.1 GB66% smaller (3.0×)Closer to the original than NVIDIA’s NVFP4 build, and level with it on MMLU, 82.9% against 82.6%. NVIDIA’s build is 2.8% smaller (1.03×), decodes faster for 1 and 16 callers (ours for 64) and caches 12% more tokens at our hosted setting.
Tileward Qwen3.8-27BTWFP455.6 → 20.1 GB64% smaller (2.8×)Level with NVIDIA’s NVFP4 build on MMLU, 82.4% against 82.1%, and 8.5% smaller than that build.
Tileward Qwen3.8-27Bthe earlier buildTWX4855.6 → 31.0 GBIn an agent loop it finished 43.7% of 142 tasks against 45.1% for the uncompressed model, a gap inside the test’s margin.
Tileward PersonaPlex 7BTWX416.7 → 6.3 GB62% smaller (2.7×)On one laptop it makes each 80 ms frame in 20 ms against about 40, and chooses the original’s next word 96% of the time.
Tileward VoiceChat 11BTWX444.4 → 11.5 GB74% smaller (3.9×)Picks the right tool as often as the original, 55 of 80 against 52. On the card it runs at the original’s speed.
Whisper large-v3TWX43.09 → 0.98 GB68% smaller (3.2×)At most 0.3 points more error than the original on nine of ten test sets, and 1.06 on Danish. 152 live calls on one 20 GB card, against 140.
Whisper large-v3-turboTWX41.62 → 0.56 GB65% smaller (2.9×)Level with turbo on six of ten test sets and behind on four, by 0.09 to 0.68 points. 331 live calls on one 20 GB card, against 301.

Tileward Context How much less was sent, and what happened to the answers.

WorkloadSent to the modelWhat held
Long conversationsLOCOMO95% less context (18.9×)55% of questions answered, against 63–67% with the whole transcript.
One long conversation, asked back97–99% fewer tokens (38–82×)20 of 20 questions answered, the same as resending the whole transcript.
An agent with a long backlogAgentBench, 104 tasks68% less context (3.2×)37 tasks solved against 24 with full history. The lead moves by 14–19 tasks between identical runs.
Agents in sequence7 agents49% fewer tokens (2.0×)86% of the material each step needed was delivered.
Agents in parallel8 agents78% fewer tokens (4.5×)66% of the material each agent needed was delivered.
A recall upgradeLongMemEval-S, our own run on a 150-question sample, self-judged47.9% → 57.9% right14 answers fixed and none broken, on the 140 questions scored.

Tileward Governance A locked tile, tested by trying to get past it.

TestResultWhat held
Requests written to get past a lock2,201 of 2,251 stoppedStopped before the model saw them. 50 got through.
Ordinary requests45 of 50 allowed5 were blocked that should not have been.
Workload
Benchmark
Measurement

Tileward Models Smaller builds, measured against the original.

Model compressionMMLUQuality

Level with the publisher’s build, and 36% smaller (1.55×) Tileward 35B-A3B on MMLU

The publisher’s own FP8 build37.5 GB · 82.9% MMLU
Tileward 35B-A3BTWX4824.1 GB · 82.8% MMLU
Community GPTQ build24.4 GB · 83.3% MMLU
Community AWQ build25.5 GB · 83.2% MMLU
36%
Smaller than the FP8 build (1.55×)
±0.3
Points either way on each score

Level with FP8. Both community 4-bit builds score 0.4 to 0.5 points higher, a direction rather than a size.

  • Five-shot, 14,042 questions, lm-evaluation-harness, no sampling. The four bars are one run, one machine, same base model.
  • Quoted to the tenth: our own build, run twice in one session, scores 82.8 and 82.9, and 181 of 14,042 answers change between the runs.
  • Bars are weights on disk; serving VRAM is 25.6 GB against FP8's 39.1 GB. MMLU is multiple choice and we lead on two of its four categories; matching FP8 is consistent with the builds behaving alike, not proof.
Report: A smaller model should not become a different model →
Model compressionMMLUQuality

Closer to the original than NVIDIA’s build, and level on MMLU Tileward 35B-A3B against NVIDIA’s NVFP4 build, whose file is 2.8% smaller (1.03×)

NVIDIA NVFP423.4 GB · 82.6% MMLU
Tileward 35B-A3BTWX4824.1 GB · 82.9% MMLU
0.023
Distance from the original model, NVIDIA’s 0.040: lower is closer
82.9%
MMLU score, NVIDIA’s 82.6%: level
2.3%
Facts it made up, NVIDIA’s 2.1%
238 of 240
Tool calls right, NVIDIA’s 240
179
Tokens a second for one caller, NVIDIA’s 197; ours leads at 64
508,031
Tokens cached at our hosted setting, NVIDIA’s 571,026

Closer to the original model, and level on MMLU and fabrication. Its next-word probabilities sit nearer the original’s than NVIDIA’s do (a KL distance of 0.023 against 0.040), MMLU is 82.9% against 82.6% (p = 0.08), and fabrication 2.3% against 2.1% of facts (p = 0.82). It leads on MMLU-Redux, 90.7% against 90.0%, mostly on questions NVIDIA’s build did not finish within the 12,288-token limit. NVIDIA’s file is 2.8% smaller (1.03×). NVIDIA’s build decodes faster for 1 and 16 callers while ours is faster for 64, has room for 12% more cached tokens at our hosted memory setting, and missed none of the 240 tool calls where ours missed two.

  • Closeness: teacher-forced on 300 corpus chunks (87,955 positions), one request at a time. The mean KL divergence of each build’s next-word probabilities (its top 20) from the BF16 original’s is 0.023 for ours and 0.040 for NVFP4. Run twice in the same boot on 40 of the chunks, ours moves 0.003 from itself and NVFP4 0.008, so the gap is larger than either build’s own noise.
  • MMLU: five-shot, 14,042 questions, lm-evaluation-harness, no sampling. The two bars are one session on one machine, same base model. The paired test counts the answers that differ: 416 right only for ours, 366 only for NVFP4 (p = 0.08).
  • MMLU-Redux: 5,700 questions, answers generated with thinking on and capped at 12,288 tokens, the same session: 126 right only for ours and 86 only for NVFP4 (p = 0.007). NVFP4 reached the cap on 107 questions and ours on 78; on the 5,569 both finished, 92.0% against 91.8% (p = 0.37).
  • Speed: output tokens a second without speculative decoding, random 1,024-token prompts and 256-token replies, 1, 16 and 64 simultaneous callers: 179, 1,625 and 3,442 for ours against 197, 1,682 and 3,316. With 8,192-token prompts the two are within 1% at 4 and 16 callers.
  • Memory: at our hosted service’s memory setting and its full 262,144-token window, the cache holds 508,031 tokens for ours and 571,026 for NVFP4. At the engine’s default setting the two are within 1.3%.
  • Fabrication: each build reads passages from Tileward’s own document set and writes out the facts they state; every fact is matched back to its passage, and one that no passage supports counts as fabricated. Ours wrote 1,683 facts and 38 were unsupported; NVFP4 wrote 1,819 and 38 were (p = 0.82, treating facts as independent).
  • Tool calls: six cases (one call, two calls in one turn, nested arguments, a tool that must not be called, the right tool out of twenty, a two-turn loop), 20 trials each, scored mechanically on tool name, call count and argument shape, once with thinking off and once on: 240 calls. Ours missed two, both in the one-call case with thinking off, where it answered in text instead of calling the tool; NVFP4 missed none (p = 0.50).
  • Bars are weights on disk (24.10 against 23.42 GB); loaded on the card, 21.0 against 20.4 GiB. NVIDIA’s build is its public NVFP4 checkpoint of the same base. Every figure on this card is from one 80 GB Hopper-generation card.
All write-ups →
Model compressionMMLUQuality

Level with NVIDIA’s build, and 8.5% smaller Tileward Qwen3.8-27B against NVIDIA’s NVFP4 build

NVIDIA NVFP421.9 GB · 82.1% MMLU
Tileward Qwen3.8-27BTWFP420.1 GB · 82.4% MMLU
8.5%
Smaller than NVIDIA’s build
82.4%
MMLU score, NVIDIA’s 82.1%: level
4.0%
Facts it made up, NVIDIA’s 4.8%
238 of 240
Tool calls right, NVIDIA’s 240

Smaller, and level on MMLU, MMLU-Redux, fabrication and speed. MMLU-Redux 89.4% against 89.4% (p = 0.85), fabrication 4.0% against 4.8% of facts (p = 0.31), and decode speed within about 2% at 1, 16 and 64 callers. NVIDIA’s build stays closer to the original model on next-word agreement, 89.0% against 87.8%, and missed none of the 240 tool calls where ours missed two.

  • MMLU: five-shot, 14,042 questions, lm-evaluation-harness, no sampling. The two bars are one session on one machine, same base model. The paired test counts the answers that differ: 484 right only for ours, 432 only for NVFP4 (p = 0.09).
  • MMLU-Redux: 5,700 questions, answers generated with thinking on; the same session, 133 right only for ours and 129 only for NVFP4.
  • Speed: output tokens a second with speculative decoding (3 draft tokens, about half accepted by both builds), natural-text prompts, 1, 16 and 64 simultaneous callers: 109, 843 and 1,390 for ours against 110, 826 and 1,381.
  • Fabrication: each build reads passages from Tileward’s own document set and writes out the facts they state; every fact is matched back to its passage, and one that no passage supports counts as fabricated. Ours wrote 1,637 facts and 66 were unsupported; NVFP4 wrote 1,702 and 81 were (p = 0.31, treating facts as independent). In a second session ours scored 64 of 1,642; NVFP4 was not run there.
  • Tool calls: six cases (one call, two calls in one turn, nested arguments, a tool that must not be called, the right tool out of twenty, a two-turn loop), 20 trials each, scored mechanically on tool name, call count and argument shape, once with thinking off and once on: 240 calls. Ours missed two (a call to a tool that did not apply, with thinking off; a nested case that returned no call, with thinking on) and NVFP4 missed none (p = 0.50). In a second session, on a different server setting, ours made all 240; NVFP4 was not run there.
  • Agreement: teacher-forced on 300 corpus chunks (87,955 positions), top-1 agreement with the BF16 original; the mean KL to it is 0.050 for ours and 0.042 for NVFP4.
  • Bars are weights on disk (20.05 against 21.92 GB); loaded on the card, 18.0 against 19.8 GiB. NVIDIA’s build is its public NVFP4 checkpoint of the same base.
All write-ups →
Model compressionAgent workflowsAgentBenchQuality

In an agent loop, level with the uncompressed model four builds of Qwen3.8-27B on 142 tasks

Qwen3.8-27B, uncompressed64 + 64 of 142 · 45.1%
Tileward Qwen3.8-27B, TWX4861 + 63 of 142 · 43.7%
The publisher’s own FP8 build60 + 65 of 142 · 44.0%
Bonsai 2 27B, a ternary build57 + 64 of 142 · 42.6%
43.7%
Tasks finished, uncompressed 45.1%
142
Tasks, each run twice per build

A tie on finished tasks: all three compressed builds finish within noise of the base. The ternary build is the smallest file and works hardest for it. Paired by task over two runs, the TWX48 build of Tileward-Qwen3.8-27b wins 10 and loses 13 against the BF16 base, a gap smaller than the test can see. The publisher’s FP8 build finishes 1.1 points fewer (11 won, 16 lost) and the ternary build 2.5 fewer (13 won, 19 lost); neither gap is one this test can call. Every compressed build spent more prompt tokens than the base to get there: ours 7% more, the ternary build 28% more.

  • AgentBench OS: Linux tasks in a real container, pass or fail decided by the environment; the 142 tasks every arm got a turn on. Greedy decoding, thinking off, 32k context, one NVIDIA 80 GB GPU, the same tasks and settings for all four.
  • An agent loop does not repeat itself exactly, so 142 tasks resolve a gap of about ten points; every gap on this card is smaller than that, a direction rather than a size.
  • The three Qwen-format builds ran on vLLM; the ternary build ran on its publisher’s own server, the only one that loads it, with reasoning off like the others, so its publisher’s thinking-on figures do not compare to this row. On this Hopper-generation card the FP8 build ran its native 8-bit path.
All write-ups →
Model compressionQuality

62% smaller, and half the time for each frame Tileward PersonaPlex 7B on one laptop

PersonaPlex as published16.7 GB · 37 to 42 ms a frame
Standard 8-bit conversion8.2 GB · 23 ms a frame
Tileward TWX46.3 GB · 20 ms a frame
62%
Smaller file
20 ms
To make each 80 ms frame
96%
Same next word as the original

Smaller and faster than both, and behind the 8-bit conversion on agreement. The standard 8-bit conversion picks the original’s next word 98.1% of the time; a standard conversion at our size, 92.8%.

  • One laptop, every build in the same runtime. Compute is the model alone for one conversation; the audio codec is not counted.
  • Agreement is over 375 word moments in four conversations recorded from the published model, so a point either way is within chance.
  • In 20 unscripted conversations a build, a speech recogniser followed the TWX4 build as well as the original.
Report: We shrank PersonaPlex by 62% to run at 20ms a frame →
Model compressionQuality

74% smaller, and it still picks the right tool Tileward VoiceChat 11B against VoiceChat as published

VoiceChat as published44.4 GB · right tool 52 of 80
The same weights, stored in 16 bits24.2 GB · identical to the original
Tileward TWX411.5 GB · right tool 55 of 80
74%
Smaller file than as published
55 of 80
Right tool, the original 52
95%
Same next word as the original

A quarter of the file and no loss this test can see; on the card it keeps the original’s size and speed. The file is 53% smaller than the lossless form. The build is at 71 ms of each 80 ms frame, as the original is, and 24 GiB in memory.

  • 100 spoken requests in six synthetic voices on a clean line, scored on the first tool call. A gap of three or four calls in 80 is within chance, so the two builds are level.
  • One NVIDIA 96 GB card, one conversation at a time. Across 100 answers offline and 20 through the streaming path, an answer repeated itself twice for the original and once for the build.
  • VoiceChat is NVIDIA’s model under the OpenMDW License Agreement, version 1.1 (OpenMDW-1.1); the build is a modified version of it under the same agreement.
Report: We compressed VoiceChat by 74% and made it run in real time on one card →
Model compressionQuality

68% smaller, and at most 0.3 points more error on nine of ten sets Whisper large-v3 and large-v3-turbo, each in TWX4, on one 20 GB card

Whisper large-v3 as published3.09 GB · 140 live calls
Whisper large-v3-turbo as published1.62 GB · 301 live calls
Tileward TWX4 of large-v30.98 GB · 152 live calls
Tileward TWX4 of turbo0.56 GB · 331 live calls
68%
Smaller file than large-v3 (3.2×)
0.3 pts
Most error added on nine of ten sets
1.06 pts
Error added on Danish, the tenth
8%
More live calls than large-v3 on one 20 GB card
4 of 10
Sets where the turbo build trails turbo, by 0.09 to 0.68 pts

Smaller than turbo, and level with it or ahead on every set. The large-v3 build is 40% smaller than large-v3-turbo (1.7×); its error rate is lower than turbo’s on four sets and level on six. Turbo carries about twice the live calls.

  • One 20 GB card, every build on vLLM at 90% of the card’s memory. Word error rate, or character error rate for Mandarin and Japanese, with a paired bootstrap 95% range for each change.
  • Ten sets: LibriSpeech test-clean and test-other, FLEURS in seven languages, and 384 synthetic call-centre clips. Japanese turns on one clip where the original repeats itself.
  • A live call is one second of audio transcribed per second, with 512 windows of 28 seconds sent at once. Large-v3 fills this card’s memory, so a larger card holds more.
Report: We shrank Whisper large-v3 by 68%, below the size of turbo →

Tileward Context Less sent to the model, and what happened to the answers.

Conversation memoryLOCOMOToken costQuality

Most of the answers, on 95% less context (19×) LOCOMO long conversations, judged by a separate model

95%
Less context than the whole transcript (18.9×)
55%
Questions answered with Tileward Context
63–67%
Answered with the whole transcript

Tileward sent 1,499 tokens per question against 28,365 for the full transcript. This keeps most, not all, of the answer rate; a separate model judged every answer.

Report: Keep most of the answer rate on 95% less context (19×) →
Conversation memoryToken costQuality

Every question answered, on 97–99% fewer tokens (38–82×) one 142-turn conversation, asked back

The whole transcript, resent3,122 tokens a question
With Tileward Context38–83 tokens a question
97–99%
Fewer tokens (38–82×)
20 of 20
Questions answered, either way
0 of 20
Answered with no conversation at all

12 facts mentioned once each, 20 questions, 8 needing two or three facts at once. Qwen3.5-9B, exact substring match.

All write-ups →
Agent workflowsAgentBenchToken costQuality

More tasks solved, on 68% less context (3.2×) 104 AgentBench tasks with earlier work in history

68%
Less context than full history (3.2×)
37 against 24
Tasks solved, with Context and with full history
14–19
Tasks that change between identical runs

Tileward sent 523,028 context tokens against 1,651,372 for full histories. The context reduction is stable; the 13-task lead is not, so the repeated ordering matters more than the margin.

Report: Give agents useful context, not the whole backlog →
Agent workflowsToken costQuality

Agents in sequence, on half the tokens seven agents handing work down a line

planner → builder-migration → builder-api → validator → tester → reviewer → release
Without Tileward80,031 tokens/run
Routing set up by hand35,226 tokens/run
With Tileward Context40,486 tokens/run
49%
Fewer tokens (2.0×)
39.5M
Tokens saved per 1,000 runs
86%
Of what each step needed, delivered

11,667 tokens of shared state over 21 artifacts. Tileward delivered 86% of the material each step declared it needed; hand-configured routing, which is a person tagging artifacts per problem, delivered 95%. This flow was graded twice, four hours apart: Tileward 0.881 then 0.952, the uncompressed control 0.952 then 1.000. The scores move further between runs than between arms, so treat the token figures as the reliable half. The fuller run.

Write-up: Compression was the easy part →
Agent workflowsToken costQuality

Agents in parallel, on 78% fewer tokens (4.5×) eight agents gathering at once

five parallel gatherers → synthesizer → critic → editor
Without Tileward364,306 tokens/run
Routing set up by hand65,513 tokens/run
With Tileward Context81,388 tokens/run
78%
Fewer tokens (4.5×)
283M
Tokens saved per 1,000 runs
66%
Of what each agent needed, delivered

This is the flow we do worst on, and the saving is the largest. 45,712 tokens of shared state over 32 artifacts. Hand-configured routing delivered every artifact each agent declared it needed; Tileward delivered 66%. Answers were not graded on this flow, but a later run judged them on a blind panel and Tileward came last of four. The whole result.

Write-up: Compression was the easy part, including this loss →
Conversation memoryLongMemEvalQuality

A recall upgrade fixed 14 answers and broke none LongMemEval-S, our own run on a 150-question sample, self-judged

Before the upgrade67 of 140 · 47.9%
After the upgrade81 of 140 · 57.9%
+10.0
Points gained, same questions before and after
14 and 0
Answers fixed, answers broken
9→16
LongMemEval-S temporal-reasoning, of 40

The arms differ by one upgrade to how Tileward Context recalls conversations; store, questions, model and judge are identical. No question that was right before went wrong after. Paired 95% interval on the overall gain: +5.0 to +15.0 points. The upgrade spends a little of the recall budget on itself, so the after arm sometimes carries slightly less material and still wins.

  • Our own harness run of LongMemEval-S on Tileward’s recall path at default settings: a single run of a 150-question sample, 140 scored identically in both arms.
  • Tileward 35B-A3B wrote and judged every answer.
Report: Improve recall without losing correct answers →

Tileward Governance A locked tile, tested by trying to get past it.

GovernanceQuality

2,201 of 2,251 attempts to get past a lock, stopped the same locked request, reworded every way we could

Requests written to get past a lock2,251 tested
Stopped before the model saw them2,201
Got through50
2,251
Requests tested
50
Got through
45 of 50
Ordinary requests allowed
Report: Put policy in front of the model—not inside the prompt →

Agent flows measured on a 120B open-weight model, tokens counted by the serving model rather than estimated. A provider that discounts a repeated prefix narrows what the saving is worth.

Bring your own workload. Point the harness at something you actually run. Talk to an engineer.