Research · Benchmarks

Turn smart-glasses and local-AI claims into reproducible evidence

Name: CyanBridge Local LLM Benchmark — Qwen vs Gemma cold/warm latency (2026-08-29 sample)
Creator: CyanBridge
License: https://creativecommons.org/licenses/by/4.0/

A generic summary of smart glasses is not enough. CyanBridge's research section is built around first-hand measurements, compatibility traces, failure cases, and reproducible configurations that other users can verify — from local LLM latency to Ray-Ban Meta privacy boundaries and smart-glasses-for-blind task tests.

First dataset — Qwen vs Gemma local LLM sample (replace with measured run)

Reproducibility template: same prompt set (10 coding-agent update prompts + 10 accessibility OCR prompts), quantization per README, temperature 0.2, phone Pixel 8 / Android 15 vs desktop RTX 4080 / Ubuntu 24.04 / Ollama 0.5.x. Report cold-start (first token after load), warm-start (subsequent), tokens/sec and peak RAM. Sample placeholder numbers below illustrate the table shape — replace with actual measured values before claiming “benchmark published”.

Model	Quant	Context	Cold start	Warm start	Tokens/sec	Peak RAM	Tool-call pass
Qwen 7B	Q4_K_M	4k	— ms*	— ms*	—	— MB*	— /10
Gemma 4 9B	Q4_K_M	4k	— ms*	— ms*	—	— MB*	— /10

* Replace placeholders with first measured run. Do not publish as “benchmark results” until cold/warm are actually timed on the named hardware with the shared prompt set archived alongside the table.

Benchmark tracks

Local LLMs: cold/warm latency, memory, context scaling and structured tool-call pass rate for Qwen and Gemma-family candidates.
Smart-glasses bridges: connection reliability, media-transfer latency, firmware-specific failures and recovery behavior.
Privacy: document which data crosses the glasses, phone, local network and optional cloud boundaries for each workflow.
Accessibility: OCR/text-reading accuracy, scene-description failure modes, end-to-end spoken latency and conservative handling of uncertainty.
Battery and thermals: sustained-use measurements rather than one-shot demos when a workflow runs on mobile hardware.

Publication standard

Name the exact glasses model and firmware version.
Name the phone/desktop hardware, operating system, model build and quantization.
Publish the prompt/task set or enough detail to reproduce it.
Report failures and ambiguous outcomes instead of keeping only successful demos.
Distinguish vendor-supported APIs from reverse-engineered or experimental community paths.

Next research topics

Qwen vs Gemma on real CyanBridge workloadsCompare models using end-to-end assistant tasks, not leaderboard scores alone.HeyCyan bridge behaviorDocument media and connection paths with exact firmware-level observations.MYVU custom/local AISeparate vendor-exposed controls from experimental or reverse-engineered paths.Visual accessibility benchmarksMeasure reading, identification and latency while publishing the important safety boundaries.

Why clear evidence matters

Original measurements, clear terminology, stable URLs, descriptive headings, and consistent compatibility data make the same work easier for people to understand and verify.

Track what changes

Compatibility and model behavior can move quickly, so CyanBridge keeps dated public updates instead of silently rewriting claims.

Continue