@yoheinakajima: glance-vlm speedlab is now open source! read: https://glance.yohei.me/speed/ try: https://github.com/yoheinakajima/glan…
Summary
The article presents an open-source study on optimizing latency for local vision-language models through benchmarking and techniques like native batching and MLX quantization, achieving significant speedups while maintaining decision accuracy on Apple hardware.
View Cached Full Text
Cached at: 09/24/26, 12:26 PM
glance-vlm speedlab is now open source!
read: https://glance.yohei.me/speed/ try: https://github.com/yoheinakajima/glance-speedlab…
turn any webcam into multiple live AI detectors (emotion, count, object), running locally
⚡ Recorded live on an Apple M5, one-question loop: PyTorch/MPS FP16: ~210 ms p50 MLX 8-bit: ~160 ms p50
🧪 Controlled nine-question, fresh-frame benchmark: 358.5 → 259.6 ms p50 27.6% lower latency 84/84 decisions matched
21 experiments, reproducible benchmarks, paper, and failures
Glance Speedlab — a local VLM latency study
Source: https://glance.yohei.me/speed/
Abstract
Live camera VLM systems are often described by model throughput, but their useful latency is a product of capture, transport, vision encoding, repeated text work, decoding and scheduling. We built a local-first lab around Glance and ran 21 preregistered experiments to separate those costs.
Native multi-question batching produced a 2.405× speedup. A smaller 2B model was 2.994× faster than the 4B reference but failed the quality guardrail. The accepted 8-bit MLX direct scorer reduced fresh-frame p50 from 358.5 to 259.6 ms (1.381×), matched 84/84 fixed-suite decisions and kept maximum probability drift to 0.039.
The main lesson is methodological: optimize realized model work, not configuration labels or proxy counts. Several attractive changes reduced nominal tokens or precision without producing a safe end-to-end win.
1. System and method
Glance answers typed questions about a frame by reading the probability of constrained answer tokens directly. It does not generate prose. The live system wraps that scorer with camera capture, a scheduler and a same-origin local gateway.
camera → crop / resize → local gateway → vision encoder
→ shared-prefix question batch → answer-token probabilities
→ scheduler / temporal policy → browser telemetry
Each experiment declared a hypothesis, primary metric, quality guardrail, hardware, version and stopping rule before implementation. Accepted speedups had to survive paired measurement and preserve decisions within the declared tolerance. The fixed suite used nine statements across reusable test images; raw frames and model weights are excluded from the public artifact.
**Apparatus.**Apple M5, 32 GB unified memory. Reference: Qwen3-VL-2B-Instruct via Glance, PyTorch MPS FP16. Candidate: Qwen3-VL-2B-Instruct via MLX, 8-bit.
2. Results
InterventionMeasured resultDecisionNative multi-question request2.405× faster; exact decisions within toleranceKeep8-bit MLX direct scoring358.5 → 259.6 ms p50; 84/84 decisions; max drift 0.039Ship experimentally2B instead of 4B2.994× faster; 83.3% agreementFast tier only4-bit MLX direct scoringSpeed held; maximum probability drift reached 0.361RejectFixed-shape suffix compilation0.6% p50 improvementBelow materialityUniform vision-token reductionUp to 15.6% faster; one decision changed, drift reached 0.411RejectUntrained early decoder exits6–22% faster; no tested depth passed both gatesRejectBrowser payload workBase64 and JSON cost at most 0.1 ms p95 at 320 pxDeprioritize The MLX result was not accepted on latency alone. It preserved every fixed-suite decision in the paired run, replicated at 1.334×, and was then integrated into Glance behind an explicit backend flag. PyTorch remains the compatibility default.
Native batching was the clearest architectural win: one shared visual prefix and one multi-question request avoided repeated setup. By contrast, browser serialization was measurable but too small to explain user-visible latency.
3. What did not work
- Quality fail**4-bit quantization.**It retained speed but moved probabilities too far for a dependable scorer.
- No material win**Compilation.**Fixed-shape suffix compilation improved p50 by only 0.6%.
- Quality fail**Uniform token cuts.**Lowering visual resolution removed useful evidence along with compute.
- Quality fail**Raw early exits.**Shallower decoder states were faster, but were not trained to be calibrated decision heads.
- Wrong bottleneck**Transport micro-optimization.**At the tested frame size, model compute dominated the browser-to-loopback path.
Keeping these results matters. They narrow the search space and expose a repeated failure mode: a cheaper representation is not automatically a cheaper or equivalent computation.
4. Interpretation
The successful changes reduced work the hardware actually performed: shared-prefix batching removed duplicate model passes, while MLX paired an Apple-native runtime with accepted 8-bit weights and direct answer-token scoring. The rejected changes mostly optimized a proxy—declared precision, token count or graph form—without securing both realized latency and decision stability.
The evidence points toward conditional compute rather than one globally smaller model:
cheap temporal gate
↓ changed enough
fast 2B / MLX scorer
↓ uncertain or fine-detail
full reference path
This cascade is still a hypothesis. The synthetic temporal gate reduced triggers by 95.1%, but requires labeled real-camera sequences before it can support a public efficiency claim.
5. Limitations
- The primary measurements come from one Apple M5 machine with 32 GB unified memory.
- The fixed suite is deliberately small and measures decision preservation, not broad semantic capability.
- Thermal state, other Apple chips and lower-memory machines were not characterized.
- The temporal result is synthetic; no real-camera quality or staleness study has been completed.
- This is a working technical report and open artifact, not peer-reviewed evidence.
6. Next hypotheses
- A trained intermediate decision head can retain full-depth margins while recovering the 11–22% compute exposed by raw truncation.
- Learned or task-conditioned vision-token selection can recover the measured prefix opportunity without uniform-resizing quality loss.
- Model-shaped fused 8-bit Metal kernels can improve the accepted MLX path beyond generic eager execution.
- A calibrated 2B→4B cascade can retain most of the 2B speedup while escalating uncertain or fine-detail frames.
- Task-aware temporal reuse can lower effective compute on labeled camera streams while bounding staleness.
7. Reproducibility and availability
The stable typed-question protocol, direct probability readout, shared-prefix batching and optional MLX backend live in Glance. Speedlab contains the live A/B interface, client telemetry, benchmark scripts, failed variants and full research record.
Yohei (@yoheinakajima): all three at a time sub 0.5 second latency!
- expression
- object detection
- finger count
switched to qwen 8B via glance i think direct on MLX
Similar Articles
@yoheinakajima: Jev-style logit read on a 4B open VLM, measured: http://glance.yohei.me vs the same model writing JSON: ~1/3 less time …
Yohei Nakajima presents a method to read typed visual judgements from a frozen open vision-language model using logits, achieving similar accuracy to hosted models with reduced time and GPU cost.
@eisokant: Excited to launch http://MLX.fast with @eigenlabs today. It's an open autoresearch competition to make Laguna XS 2.1 in…
Eigen Labs launches an open autoresearch competition called MLX.fast to optimize inference speed of the Laguna XS 2.1 model on consumer Macs, aiming to make it as fast as possible via community contributions.
@LinQ444: jev 和laya的对比 https://github.com/mizorewww/laya-mlx…
Laya-MLX is an open-weight tool for running typed decision AI models locally on Apple Silicon with low latency, providing native inference without cloud APIs. It includes benchmarks showing fast performance on devices like M3 Max.
@jun_song: The new engine for MLX is in its final stages of development. Just ran GLM-5.2 on a single MacBook (116GB) hitting 41.8…
Jun Song announces the final development stage of a new MLX engine, achieving 41.8 tok/s on a MacBook with a 256k context window and only ~4% quality loss, representing a significant performance improvement.
@modal: We worked with @lmsysorg and http://z-lab.ai to - integrate DFlash spec into @sgl_project - make it faster with overlap…
Modal collaborated with LMSys and Z Lab to integrate DFlash speculative decoding into SGLang, achieving up to 4.3x throughput improvement over baseline and 1.5x over native multi-token prediction for large language models.