RUNTIME BENCHMARK / LIQUID AI
Latency traces ↗
LFM3-VL-2B / GALAXY S26 ULTRA
Native Hexagon VL decode.
Liquid’s published llama.cpp reference.
melange_hexagon_rewrite + CPU lm_head split. Three reported rounds: 78.00 / 78.20 / 76.00 tok/s. Same named S26 Ultra device; different prompt lengths, precision and decoding protocols.
Inspect latency deltas ↓PROTOCOLS DIFFER. Liquid official: 1,024 text tokens, 256 generated tokens. Reproduced HTP: 272 prompt tokens, 255 generated tokens. ZETIC: 256 image + 19 text rows, 256 teacher-forced tokens. All include image input; precision differs. Rate ratios are not controlled speedups.
01 / BENCHMARK MATRIX
The official llama.cpp CPU4 result appears alongside our native runtime and reproduced baselines. Galaxy S26 Ultra throughout; each source keeps its own input, precision and decoding protocol.
LFM3-VL-2B · DECODE THROUGHPUT
Liquid official CPU4: one 512 × 512 image + 1,024 text tokens, 256 generated tokens, Q4_0 LM / F16 projector. ZETIC: 256 image + 19 text rows, 256 teacher-forced tokens, W8A16 encoder / native W4 decode. Reproduced HTP: 272 prompt tokens and 255 generated tokens. These are different protocols, not a controlled speedup. Official CPU4 and reproduced OpenCL both report 46.7 tok/s; they are distinct measurements.
llama.cpp CPU4 · Q4_0 LM / F16 projector · 512 × 512 image + 1,024 text tokens · 256 generated tokens. Prefill throughput is not TTFT; no comparable ZETIC memory figure is supplied.
Purple = Liquid's published reference; blue = ZETIC's reproduced llama.cpp baselines; mint = ZETIC's native path. The source configurations differ. A published rate ratio does not establish controlled speedup or equal task quality.
LFM3-1.7B / TEXT DECODE
HIGHER IS BETTER ↑Liquid official: no Galaxy S26 Ultra text result in the cited release.
1,024 input / 256 output tokens, context 2,048. Interleaved device-farm runs. Different quantization; quality parity is not established.
LFM3-VL-2B / REPORTED TTFT
LOWER IS BETTER ↓Liquid official: TTFT not published. Its 169 tok/s prefill throughput is not a TTFT measurement.
Reported encoder + prefill component sums: 297 vs 730 ms. Prompt representation, precision and timer boundaries differ.
02 / LATENCY DELTAS
Liquid's published CPU4 rate, our reproduced HTP rate and our native VL rate on one time scale. These durations are derived from throughput; the original protocols differ.
256 ÷ 46.7 vs. 256 ÷ 50.95 vs. 256 ÷ 78.0 tok/s. A common output-count projection, not measured completion times. Liquid: 1,024 text tokens; reproduced HTP: 272 prompt tokens and 255 generated output tokens in the source; ZETIC: 256 image + 19 text rows and teacher-forced output. Different inputs, precision and decoding protocols.
256 ÷ 45.18 vs. 256 ÷ 75.54 tok/s. Decode only; excludes prefill and changing-context effects. No official Liquid S26 Ultra text result is published.
Reproduced HTP comparison. Liquid's official TTFT is not published; its 169 tok/s prefill rate is not TTFT. Prompt representation, precision and timer boundaries differ; see measurement scope ↗.
Three reported rates. One clock. Select a workload and output length.
0 / 256 tokens
Teacher-forced · 256 image + 19 text rows
0 / 256 tokens
Generated · 1,024 text tokens
0 / 256 tokens
Generated · 272 prompt / 255 output tokens
Derived simulation, not live inference or a recorded model response. Duration = selected output length ÷ reported decode rate. Vision protocols differ: ZETIC uses teacher-forced tokens, while Liquid's published CPU4 reference and reproduced HTP use generated tokens; prompts and precision also differ. This is not a controlled speedup or quality comparison. Prefill, tokenization, sampling and changing-context effects are excluded. Output lengths beyond 256 tokens are extrapolations.
03 / RUNTIME IMPLEMENTATION
The optimized QNN graph approached 62 tok/s on Xiaomi 17 Ultra. Native decode changes weight DMA, KV staging, CPU/DSP work placement and VTCM lifecycle.
The reported QNN graph still carried roughly 1,100 non-weight operations. ZETIC moved the full decode step into melange_hexagon_rewrite, coordinating weight DMA and compute instead of dispatching individual graph operations.
SCHEMATIC · ONE NATIVE DECODE STEP
Reported Xiaomi 17 Ultra component timings. These are DSP execution intervals, not end-to-end token latency.
Partial KV staging avoids an all-or-nothing DDR fallback at longer context. CPU lm_head work also keeps memory clocks active. The report attributes the broader DSP gain to the DDR governor vote, not just parallel CPU arithmetic.
SCHEMATIC · MEMORY STATE IS PART OF EXECUTION
v81 partial-KV result on Xiaomi 17 Ultra. CPU work affects DDR behavior; this does not establish lower power consumption.
QNN prefill and native decode share DSP resources inside one process. ZETIC added suspend / resume and reset handoff counters so prefill can run again and CPU workers resume correctly.
↶ SUSPEND / RESUME + RESET FOR THE NEXT TURN
Xiaomi 17 Ultra: TTFT 295–300 ms; PPL 9.00 on a small 257-token check. Repetition does not establish task-quality parity.
THE MEMORY-TRANSFER LIMIT
922.8 MB of weights per token, divided by the reported 73–75 GB/s DMA ceiling, implies a 12.3–12.6 ms lower bound.
Component timings on Xiaomi 17 Ultra. The lower bound is analytical. These bars are not end-to-end latency or whole-chip utilization.
UPCOMING / TTFT OVERHEAD REDUCTION
The current engine returns VTCM to QNN for prefill. Moving prefill into melange_hexagon_rewrite targets that transition cost. This integration is still pending.
CURRENT EXECUTION→NEXT INTEGRATION
UPCOMING ENGINEERINGCURRENT HANDOFF COST / EACH TURN
Founder engineering estimate.
VTCM handoff to QNN prefill.
Return shared DSP memory
to QNN prefill
Existing W8A16
prefill execution
melange_hexagon_rewrite
This ruler isolates the handoff cost. Its overlap with the reported TTFT timer is not established; no projected saving is subtracted from the measured results.
TARGET THE TRANSITION / MEASURE THE RESULT
Native prefill integration is pending.
No post-integration timing yet.
melange_hexagon_rewriteMove prefill into
the native runtime
Retain the implemented
decode path
The goal is to reduce the transition into QNN prefill. Prefill and decode have not yet been optimized together in the native runtime. The resulting TTFT must be measured after integration.
Pending engineering bandwidthDeferred while other engineering work takes priority.
Source: founder engineering update, October 28, 2026. Approximately 50 ms is the reported current handoff-overhead estimate. It is not a verified future saving, and it is not subtracted from measured headline results. Diagram widths are schematic; only the current-overhead ruler uses a time scale.
04 / IMPLEMENTATION HISTORY
Reported Xiaomi 17 Ultra progression, LFM3-1.7B. Graph optimizations first. A custom decode runtime next. A working integrated engine at the end.
QNN W8A16 → native engine
34.7 → 72.3 tok/s2.08× across ZETIC's implementation stages.
This is not the Qualcomm HTP comparison.
Supporting engineering progression across builds, not a controlled per-change ablation. The Xiaomi HTP reference is 49.3 tok/s using tg200@d1024; ZETIC uses 256 output tokens. The main S26 text comparison above uses 256 on both sides.
05 / REPRODUCIBILITY
The model, runtime, hardware and measurement scope belong beside the numbers. Here is exactly what this brief does and does not establish.
SM-S948U1 · SM8850 · Android 16
Input / output tokens · context 2,048
Every text pass · hottest zone · screen off
Text ZETIC: 3 rounds, each median of 3
ZETIC: QNN W8A16 prefill + melange_hexagon_rewrite W4 decode, fp16 KV, CPU lm_head split. ZETIC decode rounds: 75.54 / 75.27 / 75.70 tok/s. The headline uses their median, 75.54. The llama.cpp b11946 HTP QAD-Q4_0 reference is 45.18 tok/s, with a reported remeasurement of 45.05. Configurations were alternated within the same farm run.
ZETIC TTFT rounds: 267.7 / 276.9 / 273.5 ms. Baseline text TTFT is a prefill-time proxy: 1,024 ÷ reported prefill tok/s. It excludes tokenization and sampling. The chart keeps this limitation visible and does not claim a matched application TTFT measurement.
LFM3-VL-2B, cats.png at 512 × 512, prompt “Describe the image in detail.” ZETIC uses a QNN W8A16 vision encoder and prefill plus melange_hexagon_rewrite decode. The HTP reference uses QAD-Q4_0 language-model weights and an F16 multimodal projector.
| Runtime | Round 1 | Round 2 | Round 3 | Median |
|---|---|---|---|---|
| ZETIC | 294 | 302 | 297 | 297 |
| llama.cpp HTP | 742 | 718 | Not reported | 730 |
TTFT is reported as encoder + prefill / prompt evaluation. ZETIC processes 275 rows (256 image + 19 text), while llama.cpp reports 272 tokens. ZETIC decode uses 256 teacher-forced tokens; llama.cpp uses 255 generated tokens with ignore-eos. VL decode is therefore a configuration comparison, not matched free-generation performance. CPU4 reaches 52.6 tok/s, above HTP's roughly 51 tok/s in this short context.
The official LFM3 release ↗ reports 46.7 tok/s decode, 169 tok/s prefill and 1.94 GB memory for LFM3-VL-2B on Galaxy S26 Ultra. The embedded chart identifies llama.cpp on four CPU threads. The published chart and model card ↗ specify Q4_0 language-model weights, an F16 multimodal projector, one 512 × 512 image, 1,024 text tokens and 256 generated tokens at batch size 1.
ZETIC's corresponding VL decode median is 78.0 tok/s (78.0 / 78.2 / 76.0), using QNN W8A16 vision encoding and prefill plus native W4 decode: 256 image rows + 19 text rows, then 256 teacher-forced tokens. 78.0 ÷ 46.7 = 1.67× (+67.0%) is a published rate comparison across different protocols and precision configurations, not a controlled speedup or quality-parity result. The official text chart supplies no S26 Ultra result. Official prefill throughput is not TTFT.
The S26 text run reports ZETIC PPL 9.004 on a 257-token wiki window; no HTP PPL is reported in that farm run. Separate Xiaomi measurements report 9.00 for ZETIC vs 8.88 for llama.cpp. This is a small text diagnostic, not an equivalent-quality or downstream-accuracy claim.
The native decode path uses fp16 KV instead of the 8-bit native-KV graph configuration. The supplied report records 9.80 PPL for the latter on Xiaomi. Vision teacher-forced wiki-token perplexity is not an image understanding quality score.
ZETIC measurements, reproduced baselines and implementation descriptions come from the founder-supplied LFM3 engineering report ↗, accessed October 28, 2026 PDT. The S26 text run completed October 28 at 10:12 PDT (October 29, 02:12 KST); the VL section reports October 28 at 11:08 PDT (October 29, 03:08 KST).
The source's later S26 VL section supersedes its earlier “VL end-to-end not measured” text. Its VL submission/completion timestamps are inconsistent; chronology remains CONFIRM. Raw device logs and linked private pull requests were not independently re-run or audited for this brief.
“Qualcomm HTP baseline” means the supplied llama.cpp b11946 HTP results, which the founder identified as the intended comparison. It is not a claim about every Qualcomm implementation or an independently supplied internal-team benchmark. The results do not establish energy efficiency, long-duration thermal stability, universal device coverage or production acceptance.
ZETIC × LIQUID AI
75.54 tok/s text decode. 297 ms vision TTFT.
Configurations, repeated rounds and source measurements below.