Ternary Bonsai 2 27B: a 27B reasoning model in 6 GB that keeps 98% on Prism ML's tests
Prism ML fit Qwen3.8-27B into a 5.95 GB file of three-value weights. On one RTX 4090 it wrote about 104 tokens/s using about 12 GB of the card's memory.
Qwen3.8-27B, the open reasoning and vision model from Alibaba's Qwen team, takes about 54 GB in its original, full-detail form, according to Prism ML's model card. The version we ran on a single gaming graphics card is a file of 5.95 GB. We asked it to read a menu from a photo, solve a seating puzzle with three valid answers and find one code hidden in a document of about 25,000 words. Each question was asked once or twice, and every answer was right.
By Prism ML's tests, Ternary Bonsai 2 27B keeps 98.2% of the original's quality. A conventional shrink to almost the same size keeps 84.1%. Prism ML released it in September under the Apache 2.0 license (free to use commercially). It is Prism ML's second attempt at this three-value format on a 27-billion-parameter model, and it scores higher than the first. To run it, you need Prism ML's modified version of the usual free tools, because the standard ones cannot read the file. Here is what you take away:
| What | Result |
|---|---|
| Model | Ternary Bonsai 2 27B by Prism ML: Qwen3.8-27B (27B parameters, reads text and images) stored so that almost every internal number is just -1, 0 or +1 |
| File size | 5.95 GB (smallest version) or 7.21 GB, against about 54 GB for the original |
| Quality, Prism ML's model card | 84.78 against 86.32 for the original over 14 reasoning tests (98.2%). The conventional way of shrinking it to a similar size: 72.59 |
| GPU we used | one NVIDIA RTX 4090, a 24 GB gaming card, rented on RunPod |
| Memory used while serving | about 12 GB of the card's 24, with a 65,536-token working memory shared by up to 4 users at once |
| Speed for one user | about 104 tokens a second (a token is roughly three quarters of a word) |
| Four users at once | about 159 tokens a second in total, once we raised one setting |
| From asking for the model to ready (GPU machine already set up) | 55 seconds, mostly downloads |
| The catch | needs Prism ML's modified version of llama.cpp to run |
A mixing desk with switches instead of faders
A language model is, physically, a very long list of numbers called weights. In the original Qwen3.8-27B each one is stored with 16 bits, which is like a mixing desk where every one of 27 billion faders can sit at any of 65,536 positions.
Prism ML replaced almost every fader with a three-position switch: down, off, up (-1, 0, +1). Then, for each group of 128 switches, it kept one ordinary fader that sets the volume of the whole group. Each switch plus its share of the group fader costs under 2 bits, against 16 in the original, which is why the file is about nine times smaller. Prism ML ships two versions of the file, 5.95 GB and 7.21 GB. The bigger one is faster on some graphics cards.
Before turning the faders into switches, Prism ML also re-wired the desk in a fixed pattern. Whatever plays through it has to go through the same re-wiring, or the sound comes out scrambled. Reading images needs a separate, optional 0.63 GB file.
Easy questions hide the damage
On a hard math competition Bonsai scores 95.83 and on a coding test 90.07, by the model card. The usual way to shrink the model to about the same size (7.27 GB) falls to 57.5 and 56.4 on those same tests, even though it scores 88.93 on an easy general-knowledge quiz, close to the original. The model card's phrase for it: "why casual testing misses the collapse".
So when someone tells you a small model "works fine", the useful question is: on what? Averaged over the 14 tests on Prism ML's model card, all with the model allowed to think before answering:
| Version | Size | Average | Share of the original |
|---|---|---|---|
| Qwen3.8-27B, original | about 54 GB | 86.32 | 100% |
| Standard 4-bit version (by Unsloth, a team that publishes shrunken models) | 17.6 GB | 85.18 | 98.7% |
| Standard 2-bit version | 7.27 GB | 72.59 | 84.1% |
| Ternary Bonsai 2 27B | 5.95 GB | 84.78 | 98.2% |
Math and coding come through almost untouched. The losses are in general knowledge and reasoning (79.86 against 85.55) and in reading images (66.19 against 71.36).
Two footnotes from Prism ML's whitepaper. On long, multi-step coding work, fixing real bugs in real code, it keeps only about three quarters of the original (60.8 against 80.6). And in the whitepaper, the 98.2% is measured with maximum thinking (a setting called xhigh). At medium thinking Bonsai scores 79.3, against 83.9 at maximum thinking, and the original scores 82.6 at medium.
Stock llama.cpp cannot read the file
llama.cpp is the open-source program that runs model files like this one on your own machine. The model card says it plainly: "Stock llama.cpp will not run these files." It rejects both Bonsai formats as unknown. The known issues page adds that the popular desktop apps for running models cannot load them either. Older versions of the standard program could even open a related Bonsai file and answer with nonsense, because they skip the re-wiring described above. We did not test the standard program ourselves.
The fix is Prism ML's modified copy of llama.cpp (a fork), with ready-made builds for Linux, Windows, macOS and more. The latest came out on 14 October. On Linux, Prism ML's known issues page says to pick the download built for NVIDIA's older toolkit version (12.8), because the newest one crashes on some machines. That page dates from September, before the October release, so we do not know if the crash still happens. We used 12.8 and had no crash.
The model also thinks a lot before it answers, and that thinking counts against the length limit you set. Ask for at most 256 tokens and you may get an empty answer, because the model used them all thinking. The card recommends a limit of 16,384 tokens.
How fast it should be
On the RTX 4090, the card says the smaller file writes about 91 tokens a second for one user, around 68 words a second. Which file is faster depends on the graphics card, and the For engineers section lists them.
The bigger difference is size: the usual 4-bit version of the original, by Unsloth, is 17.6 GB, three times the 5.95 GB Bonsai file. We have not measured the original model's speed with the same software on the same card.
Running it on InferenceKey
The GPU and the software
We ran it on one RTX 4090 with 24 GB, rented on RunPod.
InferenceKey starts models through small adapters we call backends. The built-in one for llama.cpp installs the official version, which cannot read this file, so we wrote our own: a custom backend package of about 6 KB that InferenceKey runs on the GPU machine. It downloads Prism ML's fork, the 5.95 GB model and the image-reading file, and starts the fork's server. One surprise on the way: the fork's download expects two NVIDIA libraries to already be on the machine and does not include them, so the backend installs them from NVIDIA's Python packages.
The backend also deals with the model's habits. It asks for medium thinking by default, gives every answer room for 16,384 tokens so thinking does not eat the reply, and swaps the "high" thinking setting, which the known issues page says returns an error, for maximum thinking. The card says medium is meant for shorter answers. In our two samples it did not give shorter answers than maximum thinking, and on Prism ML's tests it scores lower (79.3 against 83.9).
The steps
Our SDK example does it in two scripts. publish.py uploads the custom backend to your account once. main.py tells InferenceKey to run the model on your GPU machine, waits until it is ready, asks a question (and optionally one about an image), saves the answer and shuts the model down. The heart of it:
spec = WorkloadSpec(
name="Ternary Bonsai 2 27B",
slug="ternary-bonsai-2-27b",
model="prism-ml/Ternary-Bonsai-2-27B-gguf",
backend="ternary-bonsai-2-27b", # the custom backend from publish.py
task_type="text2text",
worker_id=os.environ["IK_WORKER_ID"],
execution_policy=ExecutionPolicy.FIXED,
execution_policy_config={"replicas": 1},
)
ref = mgmt.ensure(spec)
mgmt.wait_until_ready(ref.workload_slug, timeout=1800)
On the GPU, the backend starts the fork's server with the model card's recommended settings and room for 65,536 tokens of conversation. For anyone reproducing the run, the command is:
llama-server -m Ternary-Bonsai-2-27B-PTQ1_0.gguf --mmproj Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf \
-ngl 99 -fa on -c 65536 --jinja \
--temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.05
Then you talk to it through the same chat address format as OpenAI's service. We ran everything from a private copy of InferenceKey on our development machine, never the live service.
What we measured
Ready in 55 seconds. From the moment the script asked for the model to the moment it answered "ready", on a freshly rented machine where InferenceKey's small agent program was already installed (that took 122 s beforehand): 16.7 s to set up the backend's Python environment, 31.5 s to download 6.6 GB of model and the 208 MB fork, and 4.1 s for the server to load it.
About 12 GB of memory. While serving, with a 65,536-token working memory shared by up to four users and image reading switched on, the GPU never used more than about 12 GB of its 24, even with a 34,000-token document and four requests running together. The download is about nine times smaller than the original, but the memory used while serving is roughly double the file, because the conversation's working memory and the image part live there too.
About 104 tokens a second per user. Across 12 real requests through InferenceKey, one at a time, every answer came out at 101 to 104 tokens a second, about 78 words a second. That is a little faster than the model card's figure for this GPU, 91.1. We do not know why. The whitepaper gives yet another figure for this card (96.7), so results seem to vary between machines and builds.
Long documents read fast. The model read the whole 25,000-word document (34,000 tokens) in about 12 seconds and found the hidden code. From question to answer it took 13.5 s.
Four users at once. Four questions sent at once all finished in 9.6 s, each user getting 68 to 78 tokens a second (about 159 in total). That needed one setting raised: by default the platform answered them one after another, and the last one waited 22.4 s.
What it answered
These are our own questions, one or two tries each, so they show behavior, not benchmark quality. Every one came back right:
- A warehouse robot question with a battery that drains per meter: 28%, correct both with medium thinking and with maximum thinking, the fastest answer in 3.75 s.
- A seating puzzle: exactly the three valid seatings, at both settings.
- A small coding task (merging overlapping intervals): correct code.
- A two-sentence summary in Spanish with thinking switched off: right, in 1.9 s.
- A photo of a menu: all four items and prices read exactly.
- Counting apples in a picture: seven, correct.
- The code hidden in the middle of the 34,000-token document: found.
Of the 17 requests we timed, none looped, came back empty or was cut off. A hard question still spends several seconds thinking first: the seating puzzle took 14.7 s at medium. We did not test the model calling outside tools (search, a calculator, your own API), which the known issues page says sometimes goes wrong, nor very long maximum thinking.
The demo video
The video shows the model running on the RTX 4090 in the InferenceKey dashboard, then a terminal asking the robot question (215 tokens at 103.2 tokens a second, 3.0 s) and the menu photo (429 tokens at 103.1 tokens a second, 6.0 s).
What went wrong
The model itself gave us no trouble. Most of what broke was ours, in the platform, and it shows up because this was a custom backend rather than one of our built-in ones.
- No streaming for custom backends. Asking for the answer word by word returned an error inside an otherwise normal response. Only the built-in backends support it today. Our dashboard's chat tester always streams, so it could not be used for this model, which is why the video uses a terminal.
- The answer arrives wrapped. A custom backend's reply arrives as a block of raw data inside the chat message instead of clean text, and the usage counter reads zero. Our example cleans it up, but a standard chat app would show the raw block.
- One request at a time by default. A model tied to one machine starts out taking one request at a time, the same bug we hit in our AstaBrief-8B test. One settings call fixes it.
- Settings do not reach custom backends. Settings you give the model in InferenceKey's dashboard never reach a custom backend, so ours keeps them in its own code.
- A five-minute ceiling. InferenceKey gives a custom backend 300 seconds per answer. At about 100 tokens a second that is roughly 29,000 tokens of thinking plus answer. We never got near it (the longest answer was 1,447 tokens), but very long maximum thinking could.
- Outside the platform: RunPod's shared RTX 4090 pool had none available, so we used its dedicated tier.
Who did what
The Qwen team at Alibaba trained Qwen3.8-27B and released it under Apache 2.0. Prism ML built Ternary Bonsai 2 27B from it. They designed the format, borrowed the re-wiring idea from Meta's SpinQuant research (Liu et al.), wrote the code in their llama.cpp fork that reads the switches on the fly, and published ready-made builds, a demo, a whitepaper and a detailed known issues page. Mobius Labs' compression method shrank the image part. Unsloth made the 4-bit comparison build. The llama.cpp project is the base the fork builds on. We spotted the release in an AI Search video.
Our part was the custom backend that brings Prism ML's fork into InferenceKey, the SDK example, running it end to end on one RTX 4090, and measuring speed, memory and start-up time.
What to take away
The usual 4-bit version of Qwen3.8-27B (17.6 GB) also fits a 24 GB card like this one, and on Prism ML's tests it keeps slightly more quality (98.7% against 98.2%). What the 6 GB file gives you is headroom: room for a second model or a longer conversation on the same card, and a chance at smaller cards. We did not test any card under 24 GB, so that last part is open. On the RTX 4090 it wrote about 100 tokens a second. The limits: the quality numbers are Prism ML's, our own checks were about 20 requests with one or two tries per question, long, multi-step coding work (fixing real bugs) keeps only about three quarters of the original, and today you depend on Prism ML's fork to run it at all.
While it served, about half of that RTX 4090 sat free, a little over 12 GB. That is room for a second, smaller model on the same card, for example the one that powers search over your company's documents. What would you put next to it?
For engineers
Model (model card, KNOWN_ISSUES, whitepaper, Bonsai-demo, base model). Repo prism-ml/Ternary-Bonsai-2-27B-gguf, sha b072e1d3, created 2026-09-16, last modified 2026-09-25, Apache-2.0, not gated. Files (all prefixed Ternary-Bonsai-2-27B-): PTQ1_0.gguf 5,946,648,928 B, PQ2_0.gguf 7,206,168,928 B, F16.gguf 53,808,408,928 B, mmproj-Q8_0.gguf 629,246,976 B, mmproj-BF16.gguf 931,145,856 B. No Q2_0 file. The "about 54 GB" in the narrative is the card's FP16 row (the whitepaper says 53.80 GB). 27.36B parameters: 24.35B language backbone (64 blocks), 2.54B embedding/LM head, 0.46B vision tower (27 blocks). Architecture unchanged from Qwen3.8-27B (Qwen3_5ForConditionalGeneration): hybrid attention, every 4th layer full attention (16 full, 48 Gated DeltaNet), 24 Q / 4 KV heads, head_dim 256, SwiGLU, RoPE, RMSNorm, 262,144 native context.
Format. Ternary g128: weights in {-1, 0, +1}, one FP16 scale per 128 weights, log2(3) + 16/128 = about 1.71 bpw on ternary tensors, 1.72 for the whole model. Weights stored in a Hadamard-rotated basis (block 1024, fixed sign vector; the whitepaper's R = (1/sqrt n) H_n S follows SpinQuant, arXiv:2405.16406) folded in offline; the runtime applies the matching transform to activations or refuses the file. Low-bit coverage: embeddings, attention and MLP projections, LM head. 26.2M params (0.0976% of the LM: linear-attention recurrent state path and norms) stay in higher precision. The rotation is a Hadamard transform of the SpinQuant kind. Vision projector: Q8_0 container 0.63 GB (whitepaper: HQQ 4-bit) or BF16 0.93 GB. Card memory table: FP16 16.0 bpw ~54 GB; ideal 1.72 bpw 5.8 GB (~9.3x); PTQ1_0 dense trits 1.75 bpw 5.95 GB (~9.0x); PQ2_0 one trit per 2-bit slot 2.13 bpw 7.21 GB (~7.5x). The whitepaper gives slightly different figures (PTQ1_0 1.76 bpw 5.93 GB, PQ2_0 2.16 bpw 7.25 GB, FP16 53.80 GB). We use the card's, which match the file sizes on Hugging Face.
Quality (card). EvalScope + vLLM on H100, thinking mode, 14 benchmarks: FP16 86.32, UD-Q4_K_XL by Unsloth (5.2 bpw, 17.6 GB) 85.18, IQ2_XXS (2.16 bpw, 7.27 GB) 72.59, Bonsai 84.78. IQ2_XXS: MMLU-Redux 88.93, AIME26 57.5, LiveCodeBench 56.4. Bonsai AIME26 95.83, LiveCodeBench 90.07. By category FP16 / Bonsai: knowledge and reasoning 85.55 / 79.86, math 97.06 / 96.57, coding 89.07 / 89.42, instruction following 81.25 / 82.66, BFCL v3 76.74 / 74.92, vision (MMMU-Pro, OCR Bench v2) 71.36 / 66.19. Card density (D = -log2(1 - score/100) / GB): Bonsai 2 0.457, previous Ternary Bonsai 27B 0.416 (80.98 at 5.75 GB), IQ2_XXS 0.257, UD-Q4_K_XL 0.157, FP16 0.053. Whitepaper (20 benchmarks, xhigh): Bonsai 83.9 vs FP16 85.4 (also 98.2%), IQ2_XXS 75.2. Terminal-Bench 2.1 52.8 vs 69.7, SWE-bench Verified 60.8 vs 80.6, tau2-Bench 80.2, BFCL v3 74.9, AA-LCR 77.0. Medium effort (Table 11): 79.3 vs 82.6, AIME25 74.58 vs 86.25, GPQA Diamond 75.56 vs 84.34. Our backend defaults to medium, so expect the Table 11 numbers unless you send reasoning_effort: "xhigh".
Speed (card, llama-bench, batch 1, no vision tower), tg128 PQ2_0 / PTQ1_0: RTX 5090 129.9 / 120.5, RTX PRO 6000 Blackwell 124.8 / 117.9, H100 SXM 113.9 / 86.9, RTX 6000 Ada 82.8 / 90.4, RTX 4090 81.2 / 91.1, L40S 74.4 / 81.8, A100 SXM 73.9 / 54.7, L4 29.8 / 32.1. RTX 4090 pp512: 3,124 / 1,645. PQ2_0 is faster decode on Hopper, Ampere data-center and Blackwell and faster prefill everywhere; PTQ1_0 moves 17% less weight data and wins decode on Ada and L4. The whitepaper's Table 5 (build of 2026-09-16) differs, for example RTX 5090 142.5 / 134.4, RTX 4090 90.9 / 96.7. KNOWN_ISSUES: prebuilt Linux binaries decode erratically on RTX 5090 (#199, build with -DCMAKE_CUDA_ARCHITECTURES=120a-real).
Runtime. Fork release prism-b10777-e3de715 (commit e3de7152), published 2026-10-14T15:26:33Z. Linux CUDA tarballs: 12.4 326,799,565 B, 12.8 208,198,074 B, 13.3 183,998,027 B, plus macOS, iOS, Android, CPU, Vulkan, ROCm 7.2, SYCL and Windows builds. Bonsai-demo setup.sh pins it (commit #262, 2026-10-15). Card: stock llama.cpp rejects PQ2_0 and PTQ1_0 and loads Q2_0 without warning, producing garbage (no Hadamard activation runtime). Bonsai-demo README: official Q2_0 works with current upstream llama.cpp that has Bonsai 2 support; PQ2_0 and PTQ1_0 still need the fork. MODEL-FORMATS.md: older builds could load Q2_0 without the transforms and produce gibberish. Ollama and LM Studio (GGUF) cannot load PQ2_0/PTQ1_0 either. KNOWN_ISSUES (last checked 2026-09-23, before b10777, so some items may be stale): CUDA 13.3 segfaults on some Linux systems (#222, use 12.8 on Linux, 12.4 on Windows); reasoning_effort: "high" returns HTTP 500 (template accepts low, medium, xhigh; low behaves close to xhigh); 500 when the system message is not first or there are two; thinking budget in chat_template_kwargs ignored; malformed or looping tool calls; looping on some prompts at xhigh; F16 GGUF loads in stock llama.cpp but output is garbled; self-quantized PQ2_0/PTQ1_0 lack prism.hadamard.* metadata and generate nonsense. The card's quickstart uses llama-cli -c 32768 -n 16384; KNOWN_ISSUES suggests -c 65536. Sampling, thinking mode: temperature 1.0, top_p 0.95, top_k 20, min_p 0.05. Bonsai-demo: FP16 KV cache 64 KiB/token, BONSAI_KV4=1 about 18 KiB/token.
Our setup. RunPod RTX 4090 24 GB, SECURE (COMMUNITY 4090 and L4 returned 409), driver 570.158.01 (CUDA 12.8), 450 W limit. Worker bootstrapped by a local InferenceKey manager over HTTP and TCP tunnels (ssh.direct after 27.4 s, 25,243,632 B worker binary over SFTP in 62 s, finished 122 s after the pod POST). Production never touched. Custom Python backend ternary-bonsai-2-27b 0.1.0 (5,957 B package): downloads the fork's linux-cuda-12.8 tarball, the PTQ1_0 GGUF and mmproj Q8_0, adds nvidia-cuda-runtime-cu12==12.8.* and nvidia-cublas-cu12==12.8.* (the tarball links libcudart.so.12 and libcublas.so.12 without shipping them) to LD_LIBRARY_PATH, runs llama-server as above on a loopback port. Defaults reasoning_effort to medium, maps high to xhigh, merges system messages into one leading message, max_tokens 16,384. SDK example commit 7a1d7883 on inferencekey-sdk main.
Time to ready. ensure() to ready 54.6 s on a pod whose worker was already bootstrapped: venv + requirements 16.7 s (1.1 GB), downloads 31.5 s (about 210 MB/s), server load 4.1 s, setup_s 35.6. PQ2_0 (7.21 GB) downloaded separately in 24 s.
Memory and power. While serving: llama-server 11,662 MiB; peak GPU total 11,672 MiB (11.4 GiB, about 12.2 GB) of 24,564 with -c 65536, n_slots = 4, n_ctx_slot = 65536, kv_unified = true, mmproj loaded, including the 33,840-token prompt and four parallel requests; 12,892 MiB free. With kv_unified the 65,536-token KV pool is shared by the 4 slots, not 65K each. The GPU total rose to 19,403 MiB only while llama-bench ran next to the server. Peak power 445.1 W during llama-bench.
llama-bench (build e3de71522 (10777), -ngl 99 -fa 1 -p 512 -n 128 -r 3): PTQ1_0 (5.53 GiB, 26.90 B) pp512 3,279 +- 427, tg128 105.78 +- 0.56; PQ2_0 (6.70 GiB) pp512 3,230 +- 433, tg128 94.50 +- 0.41. Both above the card's RTX 4090 row (91.1 and 81.2). PTQ1_0 was the faster decode on this Ada GPU, as the card says.
Per request (non-streaming /v1/chat/completions, system prompt "You are a helpful assistant", max_tokens 16,384, timings from llama-server):
| Case | Effort | Prompt tok | Out tok | Gen tok/s | Prompt tok/s | Round trip s |
|---|---|---|---|---|---|---|
| robot battery | medium | 77 | 371 | 103.9 | 186 | 5.31 |
| robot battery | xhigh | 115 | 250 | 103.4 | 413 | 3.75 |
| seating puzzle | medium | 74 | 1,447 | 104.2 | 255 | 14.73 |
| seating puzzle | xhigh | 74 | 670 | 103.7 | 256 | 7.62 |
| merge_intervals | medium | 52 | 756 | 104.2 | 274 | 8.42 |
| Spanish summary | none | 40 | 73 | 101.4 | 139 | 1.87 |
| menu OCR | medium | 617 | 230 | 103.2 | 1,189 | 4.34 |
| count apples | medium | 346 | 219 | 103.1 | 832 | 3.79 |
| describe ramen | none | 607 | 64 | 101.2 | 1,023 | 3.34 |
| needle, 33,840 tok | none | 33,840 | 11 | 68.0 | 2,843 | 13.53 |
Median generation 103.6 tok/s over 12 sequential requests (101.2 to 104.4). Platform overhead on short answers 0.3 to 0.6 s (round trip minus backend total, local manager over a tunnel). finish_reason: stop in all 17 bench requests. One sample each at temperature 1.0: the seating puzzle used 1,447 tokens at medium and 670 at xhigh, and the robot question 371 and 250. Two samples cannot say whether medium is usually longer or shorter.
Concurrency. Four parallel requests at the assignment's default max_in_flight 1: 22.4 s wall (round trips 6.7, 10.6, 13.9, 22.4 s). After PATCH /api/projects/<pid>/assignments/<workload>/<worker> {"max_in_flight": 8}: 9.6 s wall, 68.4 to 78.1 tok/s each, 1,524 tokens, about 159 tok/s aggregate.
Platform issues. (1) stream: true with a custom backend returns HTTP 200 with data: {"error":{"code":"unknown_backend",...}} then [DONE]: run_streaming_inference in crates/worker/src/jobs.rs only handles the Ollama and OpenAI-compatible built-ins. (2) custom_backend_process returns output.to_string() and chat_choice_from_out puts it in message.content as a JSON string, usage all zeros. (3) ensure() with a worker_id creates the assignment with max_in_flight 1. (4) The worker starts python -m inferencekey.backend.serve without --config-json, so ctx.config is empty. (5) Worker /process client timeout 300 s for custom backends. (6) Built-in llamacpp backend pulls ggml-org llama.cpp (asset_download_url hardcoded, default tag b9748). (7) SFTP of the 25 MB worker binary took 62 s. (8) Panel cosmetics: Access column "No access" with a working wildcard key, "GPU telemetry partial".
Cleanup. Workload and pod deleted (RunPod 404 afterwards), tunnels, NATS, database and MinIO objects removed.
Limits. About 20 requests of our own, one or two samples per question, temperature 1.0, most at medium effort. All quality benchmarks are Prism ML's. No tool calling, no very long xhigh reasoning, no PQ2_0 serving numbers through InferenceKey (llama-bench only), no stock llama.cpp test, one GPU model.
Sources: model card, KNOWN_ISSUES, whitepaper, Bonsai-demo, fork release prism-b10777, Qwen3.8-27B, SpinQuant, SDK example, demo video, AI Search video.