PROJECT 04 · EDGE AI · SEPTEMBER 2026

BENCHMARKING LOCAL
INFERENCE.

We compare four small models on consumer-level hardware.

Inside the ASUS mini PC used for the benchmark, showing its two memory modules and NVMe drive
THE ACTUAL TEST MACHINE / OPEN CHASSIS

01 / HARDWARE USED

Consumer mini PC

CPU
AMD Ryzen 3 5300U · 4 cores / 8 threads
MEMORY
16 GB DDR4-3200 · 2 × 8 GB
GRAPHICS
Integrated AMD Radeon · shared memory
STORAGE
WD Blue SN570 · 500 GB NVMe

No discrete GPU. Every model ran locally through llama.cpp.

02 / MODELS USED

Four model architectures

  • LFM2.5-8B-A1BHYBRID MoE

    8.3B total / 1.5B active; convolution and attention layers.

  • GRANITE 4.0 H TINYHYBRID MoE

    7B total; Mamba-2, attention, and routed experts.

  • QWEN3-8BDENSE

    8.2B dense Transformer rather than routed experts.

  • SMOLLM3-3BDENSE

    3B dense Transformer; the smallest model in the comparison.

SHARED DEPLOYMENT FORMAT GGUF · Q4_K_M

GGUF packages each model for llama.cpp; Q4_K_M is the common, mostly 4-bit K-quantization—not another model architecture.

All four also used the same 4,096-token context.

01 / THE QUESTION

EXPERIMENTAL QUESTION.

Beyond the model name, performance depends on quantization, runtime, context, hardware, prompts, tool schemas, and the validation around the response.

Our narrower question was: on this exact stack, which model fits which edge workload? Semantic success asks whether the decision is correct. Contract success asks whether software can safely consume it without interpretation.

02 / RESULTS

Scorecard

The benchmark is a comparison of complete configurations, not model names in the abstract. We fixed llama.cpp build b10964, Q4_K_M quantization, 4,096-token context, one parallel slot, temperature zero, seed 42, the harness, and the Ryzen 3 5300U. Only the loaded model changed.

MODELSEMANTICCONTRACTDECODEPEAK RAMNOTES
QWEN3-8B78.6%67.9%3.0 tok/s5.71 GB

More consistent exact outputs; dense architecture increased CPU decode cost.

LFM2.5-8B-A1B78.6%25.0%16.5 tok/s5.43 GB

Fast CPU decode; exact outputs often required normalization.

GRANITE 4.0 H TINY75.0%53.6%12.5 tok/s4.70 GB

Moderate memory use with comparatively consistent tool routing.

SMOLLM3-3B60.7%35.7%7.3 tok/s2.64 GB

Lower memory use; structured tool routing failed in this configuration.

READ THIS CAREFULLY “Semantic” gives credit for the correct decision inside extra prose. “Contract” requires the exact requested output or a real structured tool call. Tool-call-shaped text receives no credit.

Why Qwen decoded more slowly

Qwen3-8B is dense: its blocks do not route around inactive experts. On this memory-bandwidth-limited CPU, more model data had to move for every generated token. See the scorecard for the measured decode rate.

Why Liquid decoded more quickly

LFM2.5-8B-A1B is a hybrid MoE that activates only a subset of its parameters per token and uses convolution-heavy layers. Less active work plausibly explains the decode-rate difference in the scorecard; this run did not isolate kernel effects separately.

03 / USE-CASE RESULTS

Use-case results

USE CASEQWENLIQUIDGRANITESMOL
COMPRESSION
100%
100%
66.7%
66.7%
EDGE MATH
25%
75%
75%
50%
LOCAL EXTRACTION
75%
75%
50%
75%
OFFLINE GROUNDING
100%
100%
100%
100%
PRIVACY CONTROL
100%
50%
75%
50%
SENSOR DECISION
60%
80%
60%
80%
TOOL ROUTING
100%
75%
100%
0%

Why the Qwen result moves sharply It passed one of four edge-math tasks—the timestamp update—and missed temperature conversion, compound energy growth, and anomaly thresholding. With only four tasks, each result moves the score by 25 points; this is a failure pattern, not a broad claim about math ability.

How to read the buckets

What each bucket measures

Each bucket represents a failure surface in an edge system—not a school-subject score.

COMPRESSION
Measures: preserving the important cause, resolution, extrema, and trend while shortening local telemetry.
Why it matters: edge devices must reduce noisy data before storing it or sending a small upstream payload.
EDGE MATH
Measures: deterministic arithmetic, unit conversion, thresholds, anomaly calculations, and timestamp updates.
Why it matters: a numerically wrong answer can trigger the wrong actuator even when the prose sounds confident.
LOCAL EXTRACTION
Measures: turning logs, OCR, packets, and maintenance text into typed fields and normalized JSON.
Why it matters: sensors and field documents are messy; downstream software needs clean values without a cloud parser.
OFFLINE GROUNDING
Measures: answering only from supplied manuals, caches, and ordered logs—and abstaining when the fact is absent.
Why it matters: disconnected devices cannot verify guesses, so knowing when not to answer is a safety feature.
PRIVACY CONTROL
Measures: local-only policy compliance, remote-tool abstention, redaction, and safe local-cache selection.
Why it matters: data sovereignty is often the reason inference is moved to the edge in the first place.
SENSOR DECISION
Measures: mapping readings and multi-signal conditions to exact actions such as inspect, ventilate, or shut down.
Why it matters: edge inference often sits closest to real equipment, where false positives and misses have physical cost.
TOOL ROUTING
Measures: selecting the correct local function with valid arguments, while ignoring tempting remote or irrelevant tools.
Why it matters: an agent becomes operational only when its intent is emitted as an executable, bounded action.

04 / OUTPUT COMPLIANCE

Semantic vs. contract gap

Each gap subtracts exact contract success from semantic success. It shows how often an answer was substantively correct but not usable by the required machine interface because of formatting or tool-call compliance. The scorecard contains the underlying rates; a smaller gap implies less adapter and validation work.

Liquid semantic → contract gap−53.6pt
Qwen semantic → contract gap−10.7pt
Granite semantic → contract gap−21.4pt
False remote tool calls0

This is a system-design choice, not a model leaderboard: either pair a fast, semantically capable model with validation and a narrow adapter, or accept lower speed for a model whose native interface behavior better fits the control loop.

05 / MODEL COMPARISON

Model comparison

06 / METHOD AND LIMITS

Method and limits

  1. 01

    28 deterministic edge tasks
    Sensor decisions, local math and extraction, offline grounding, compression, tool routing, and privacy controls.

  2. 02

    112 task evaluations
    The same suite was executed once against each of four locally loaded Q4_K_M models.

  3. 03

    Two scoring layers
    Semantic correctness is separated from exact machine-contract compliance. Tools count only when emitted as executable structured calls.

  4. 04

    One pinned stack
    AMD Ryzen 3 5300U, llama.cpp build b10964, Q4_K_M weights, 4K context, one slot, temperature 0, seed 42, and the same prompts and tools.

  5. 05

    Comparable throughput run
    Three uncached 3,800-token prefills plus 128-token decodes per model. Inference requests were rejected unless addressed to localhost.

These results answer one bounded question: how these four Q4_K_M models behaved inside this harness on this machine. They do not predict another runtime or device. The next experiment should change one layer at a time—seed, quantization, context, or hardware—and add private workloads from the intended deployment.