Public BetaAgent readySign inDownload
Prisma 1Gemma 4 E4B GGUF

Bare llama-servervs Prisma native GGUF

Same Gemma 4 E4B weights, two inference paths. Bare llama-server returns raw tokens with no protocol. Prisma native GGUF runs decoding, parsing, and inference in one integrated pass — trading a predictable latency premium for formatted, accuracy-guaranteed output.

1 step vs 3 steps — same weights
Per-step industry benchmarks vs Prisma native
GGUF benchmark

Two GGUF paths, same weights. Bare llama-server loads Gemma 4 E4B and returns raw completions. Prisma native GGUF runs the same weights through codeapp-server — decoding, parsing, and inference are part of the stack, not a layer bolted on afterward.

Bare llama-server GGUF

Gemma 4 E4B · stock path

1 step
GGUFPipelineOutput
1

Inference

Token generation only

Raw completion stream

Steps in stack

1

Task accuracy

5/6

Usable as-is

No

Prisma native GGUF

Gemma 4 E4B · codeapp-server

3 steps
GGUFPipelineOutput
1

Decoding

GGUF → tensors

Industry 115 ms<1 ms final · ~5 ms streaming(96% greater performance)
2

Parsing

Structure & validate

Industry 78 ms<1 ms final · ~5 ms streaming(94% greater performance)
3

Inference

Generate & format

Industry 612 ms929 ms

Formatted, verified completion

Steps in stack

3

Task accuracy

6/6

Usable as-is

Yes

Per-step industry averages

Typical E4B local stacks — decoding, parsing, and inference as separate tooling

Prisma native measured · industry figures representative · decoding and parsing stay under 1 ms final and ~5 ms streaming on average

Decoding

GGUF → tensors

+96% performance vs industry
Industry
115 ms
Prisma
<1 ms final · ~5 ms streaming

Industry: Separate load hop per request

Prisma: Under 1 ms final · ~5 ms streaming average; fused in native pipeline

Parsing

Structure & validate

+94% performance vs industry
Industry
78 ms
Prisma
<1 ms final · ~5 ms streaming

Industry: Post-inference processor

Prisma: Under 1 ms final · ~5 ms streaming average; inline during generation

Inference

Generate & format

Verified inline
Industry
612 ms
Prisma
929 ms

Industry: Raw tokens only

Prisma: Verified output inline

Industry inference effective to 100%: 806 ms (Incl. retry + re-parse to 6/6) — plus separate decode (115 ms) and parse (78 ms) hops. Prisma runs all three in one pass at 931 ms total (10 ms decode+parse streaming · <2 ms final + 929 ms inference).

Prisma native — decode & parse throughput

Measured stage totals on Gemma 4 E4B · equivalent token processing rates

StageTime spentEquivalent rate
Decoding (token→UTF-8)4.3 ms total~19,000 tok/s
Parsing (final pass)2.2 ms total~37,800 tok/s
Parsing (streaming pass)28.1 ms total~2,900 tok/s

Per request (decode / parse final)

Prisma native decode and parse final pass rates across benchmark prompts

PromptTokensDecodeParse (final)
math-multiply9~52,500 tok/s~26,000 tok/s
capital-france7~12,200 tok/s~21,000 tok/s
logic-cats7~121,300 tok/s~21,900 tok/s
python-add25~69,100 tok/s~50,600 tok/s
json-alice20~20,900 tok/s~57,800 tok/s
reverse-string14~6,400 tok/s~42,300 tok/s

Single pass vs industry standard

Wall-clock time to a verified, formatted completion

Prisma wins

Industry · 3 separate passes

805 ms

83% accuracy · raw output

Industry · to 100% verified

1039 ms

Retries + re-parse across hops

Prisma native · single pass

931 ms

100% accuracy · decode+parse <2 ms final

Prisma native · streaming overhead

939 ms

~10 ms decode+parse · 929 ms inference

Industry stacks chain decoding, parsing, and inference as three separate passes805 ms minimum, still only 83% accurate. Matching Prisma's 100% requires retries and re-parsing, pushing the industry path to ~1039 ms. Prisma native GGUF finishes all three steps in one pass at 931 ms (decode+parse under 1 ms final, ~10 ms streaming) 10% greater performance than the industry path to the same guarantee, with no external tooling.

What is a raw token?

Why bare llama-server's first token isn't the same as a finished answer

A raw token is a single sampler output from the model — an unprocessed chunk of the completion stream. Bare llama-server forwards these as they are generated: no stop-string handling, no structure check, no guarantee the stream forms a complete or correct answer.

How raw tokens are typically used

  • ·Stream to UI — append each token to a buffer and render character-by-character as it arrives.
  • ·Wait for stream end — hold the full raw completion, then try to parse it as JSON, code, or plain text yourself.
  • ·Retry on failure — if the stream is empty, truncated, or invalid (as on logic-cats), run inference again and hope the next pass works.

Example · bare raw stream

Token 1 @ 273 ms: "The"

Token 2 @ +12 ms: " answer"

Stream end @ 582 ms: "" (empty on logic-cats)

Usable in IDE? Not until you parse, validate, and possibly retry — +78 ms minimum.

Prisma native returns the entire final result — decoded, parsed, and inferred in one pass. The first token at 346 ms is already formatted. The complete, verified answer arrives at 931 ms: nearly the same wall-clock as bare llama takes to reach a usable outcome once you account for external parsing and retries.

Bare · first raw token

Arrives fast — not yet usable

273 ms

Bare · stream complete

Raw completion — may be empty or invalid

582 ms

Bare · usable attempt

+78 ms external parse/validate

660 ms

Bare · verified (industry path)

Retries + re-parse to match 6/6

1039 ms

Prisma · entire final result

Formatted, verified, IDE-ready — single pass

931 ms
Bare llama looks faster at 582 ms— but that's raw stream time, not a finished answer. Add parsing (+78ms) and you're at 660 ms with only 83% accuracy. Prisma delivers the complete final result at 931 ms 108 ms faster than the industry path to a verified answer.
Why 3 steps outperform 1: bare llama-server stops after inference — you get tokens, not answers. Empty on logic-cats, unstructured elsewhere. Industry averages 805 ms across three separate hops and still only reaches 83% accuracy. Prisma native integrates decoding, parsing, and inference in one pass at 931 ms — decoding and parsing stay under 1 ms final and ~5 ms streaming on average — 100% task accuracy, no retries, no post-processing. Faster to a correct, usable result than the industry standard path to the same guarantee.
Head-to-head
Bare llama-server vs Prisma native on same prompts

Accuracy

+17%(+1 prompt)
Bare llama-server
83%
Prisma native
100%

Time to first token

+73 ms(+26.7%)
Bare llama-server
273 ms
Prisma native
346 ms

Total latency

+349 ms(+60.0%)
Bare llama-server
582 ms
Prisma native
931 ms

Throughput

4.9 tok/s(18.8%)
Bare llama-server
26.1 tok/s
Prisma native
21.2 tok/s
What the Δ means
Cost of Prisma native vs bare llama-server
analysis

More steps, better outcomes. Bare llama-server runs one step — inference — and hands off raw tokens. Prisma native runs three integrated steps in a single pass, finishing with formatted, verified output the IDE can use immediately.

Accuracy: Bare llama-server scored 5/6; Prisma native GGUF: 6/6. On logic-cats, bare returned empty — Prisma native returned a correct formatted answer.

Latency trade-off: +73 ms TTFT, +349ms total (includes <2 ms decode+parse final overhead). Prisma native streams at 21.2 tok/s versus 26.1 tok/s bare — slower generation, but every completion is structured and complete.

60-minute session: For 80 turns × 200 tokens, total Δ is ~170s (4.7% of 60 min). Prisma native still delivers ~50,880 tokens in 40 active minutes.

Bottom line: Prisma native GGUF trades a small, predictable latency premium for coherent, formatted, accuracy-guaranteed output — bare llama-server is faster but raw and incomplete.

60-minute session projection
How the Δ compounds across a full IDE hour

Short-prompt benchmarks exaggerate the gap. Over a 60-minute session of 80 turns, Prisma native GGUF adds ~349 ms per turn versus bare llama-server — a fixed per-turn cost that shrinks as a share of total session time while 21.2 tok/s keeps output flowing.

Per-turn Δ

+349 ms

Prisma native vs bare llama-server

Session Δ total

~28s

80 turns × 349 ms

Hourly share

4.7%

~170s of 60 min

Prisma native tok/s

50,880

40 min active × 21.2 tok/s

Full session wall time

+170 s(4.7% of hour)
Bare llama-server
635 s
Prisma native
782 s
Per-prompt highlights
Bare llama-server vs Prisma native output
PromptBare llama-serverPrisma native GGUF
math-multiply(391)
capital-france(Paris)
logic-cats(yes/no)
empty
Yes
python-add
json-alice
reverse-string
Summary table
Aggregate metrics · Gemma 4 E4B
StackAccuracyMean TTFTMean totalMean tok/sΔ vs bare

Bare llama-server GGUF

Gemma 4 E4B, no protocol

83% (5/6)273 ms582 ms26.1

Prisma native GGUF

codeapp-server

100%(6/6)346 ms931 ms21.2
Accuracy
+17%(+1 prompt)
TTFT Δ
+73 ms(+26.7%)
Total Δ
+349 ms(+60.0%)
tok/s Δ
+-4.9 tok/s(-18.8%)

Note: Prisma native GGUF is an incomplete, unstable build. Benchmarks compare bare llama-server and Prisma native GGUF on the same Gemma 4 E4B weights — two independent inference paths, not a protocol layered on top.