Replace approx-sign tildes with U+2248 to avoid GFM strikethrough misparse

BENCHMARK.md

@@ -24,7 +24,7 @@ No discrete GPU, no CUDA. All acceleration is via the integrated Arc GPU.
 
 Two backends were benchmarked, both Vulkan on the Arc iGPU:
 
-- **Model:** Qwen2.5-VL-3B-Instruct, q4_K_M (~2.0 GB) + `mmproj-F16` vision projector (~1.3 GB)
+- **Model:** Qwen2.5-VL-3B-Instruct, q4_K_M (≈2.0 GB) + `mmproj-F16` vision projector (≈1.3 GB)
 - **Backend A — Ollama** (IPEX-LLM portable build, Vulkan): `OLLAMA_IGPU_ENABLE=1`
   (integrated GPUs are dropped by default). API: native `/api/chat`, `keep_alive: -1`.
 - **Backend B — llama.cpp** (`llama-server`, Vulkan build `b9966`): runs the GGUF +
@@ -37,7 +37,7 @@ difference** — see the latency ladder below for why.
 
 HuggingFace `rajistics/indian_food_images`, test split.
 20 classes, 941 test images. Benchmark samples **10 images/class = 200 images**,
-downloaded to disk before the run (the HF signed URLs expire ~15 min, shorter
+downloaded to disk before the run (the HF signed URLs expire ≈15 min, shorter
 than a full CPU run).
 
 **Task:** constrained top-1 classification. The model is shown one dish photo
@@ -109,7 +109,7 @@ clearly matches." Result: **74% → 86% (+12 points)**, and the magnets collapse
 | pav_bhaji | 8/10 | 6/10 | −2 (anti-default cost) |
 
 Wrong guesses landing on `pav_bhaji`: **15 → 1**. On `dal_makhani`: **13 → 2**.
-Cost: the longer prompt adds tokens, so latency rose ~5.2s → ~6.5s median. Net
+Cost: the longer prompt adds tokens, so latency rose ≈5.2s → ≈6.5s median. Net
 trade: **+12 accuracy points for +1.3s** — worth it for an accuracy-critical app.
 `paani_puri` (2/10) is the one class descriptions did not rescue.
 
@@ -120,10 +120,10 @@ iGPU. Only the model changes.
 
 | Model | Size | Top-1 | Latency (median) | Notes |
 |---|---|---|---|---|
-| moondream (1.8B) | 1.7 GB | 37.0% | ~17 s (n=200) | scene captioner, not a fine-grained dish classifier — see below |
+| moondream (1.8B) | 1.7 GB | 37.0% | ≈17 s (n=200) | scene captioner, not a fine-grained dish classifier — see below |
 | Qwen2.5-VL-3B-Instruct | 2.0+1.3 GB | 86.0% | 6.5 s | baseline for the prompt-engineering work above |
 | **Qwen3-VL-4B-Instruct** | 2.4+0.8 GB | **93.0%** | 5.8 s | newer generation beats the older, bigger... |
-| Gemma-4-E4B-it | 4.6+0.9 GB | ~78% (partial, crashed) | ~3–5 s (partial) | **unstable on Arc/Vulkan — see below** |
+| Gemma-4-E4B-it | 4.6+0.9 GB | ≈78% (partial, crashed) | ≈3–5 s (partial) | **unstable on Arc/Vulkan — see below** |
 
 **Qwen3-VL-4B vs Qwen2.5-VL-3B (+7 points, same-or-better latency):** a newer,
 slightly larger model decisively beat the older one, confirming that "newer
@@ -145,7 +145,7 @@ not a constrained classifier.
 
 **Gemma-4-E4B — unstable on this hardware, not benchmarked to completion.**
 Two failures on two configs: with 4 parallel slots the `llama-server` process
-crashed outright around image 126 (VRAM/memory pressure from the larger, ~5.6 GB
+crashed outright around image 126 (VRAM/memory pressure from the larger, ≈5.6 GB
 model); with `--parallel 1` it did not crash but **hung** — one request stalled
 for 5 minutes before being force-cancelled, then every request after it queued
 and also stalled. Per-token eval time was visibly degrading right before the hang
@@ -154,8 +154,8 @@ this architecture, not a benchmark or prompt problem. It also required an
 explicit `chat_template_kwargs: {"enable_thinking": false}` API flag — Gemma 4 is
 a reasoning model that writes a hidden chain-of-thought into a separate
 `reasoning_content` field, and without disabling that it returns empty answers
-under a short `max_tokens` budget. The ~32 clean responses obtained before the
-first crash were 25/32 (~78%) correct, suggesting real accuracy is competitive —
+under a short `max_tokens` budget. The ≈32 clean responses obtained before the
+first crash were 25/32 (≈78%) correct, suggesting real accuracy is competitive —
 but two failures on two different configs is a stability finding, not noise.
 
 ### Few-shot prompting — negative result
@@ -179,10 +179,10 @@ upgrade above, which fixed the same class for free.
 
 llama-server exposes 4 parallel slots. For **Qwen2.5-VL-3B**, firing 4 concurrent
 requests instead of one-at-a-time processes the 200-image set in **117 s
-(0.58 s/image)** vs ~21 min serial — an **~11× wall-time speedup at the same
+(0.58 s/image)** vs ≈21 min serial — an **≈11× wall-time speedup at the same
 85–86% accuracy**. A single 768px request does not saturate the Arc's 112 EUs;
 batching fills the GPU, so per-call latency under load actually drops (median
-~2.1 s). This speeds up *bulk work*; a single-photo app still sees the ~6.5 s
+≈2.1 s). This speeds up *bulk work*; a single-photo app still sees the ≈6.5 s
 per-image number.
 
 **This does not generalize to the larger model.** The same experiment on
@@ -201,13 +201,13 @@ model reaches the GPU:
 
 | Setup | Per image (warm) | Speedup | Vision encoder |
 |---|---|---|---|
-| CPU only | ~75 s | 1.0× | CPU |
-| Ollama, Arc (Vulkan) | ~52 s (median 52.5) | ~1.5× | **CPU** (forced) |
-| **llama.cpp, Arc (Vulkan)** | **~5 s (median 5.2)** | **~14×** | **GPU** |
+| CPU only | ≈75 s | 1.0× | CPU |
+| Ollama, Arc (Vulkan) | ≈52 s (median 52.5) | ≈1.5× | **CPU** (forced) |
+| **llama.cpp, Arc (Vulkan)** | **≈5 s (median 5.2)** | **≈14×** | **GPU** |
 
 llama.cpp full run: min 1.9 / median 5.2 / mean 5.2 / max 8.7 s (199 warm calls).
 
-### Why Ollama was stuck at ~1.5× — and llama.cpp fixed it
+### Why Ollama was stuck at ≈1.5× — and llama.cpp fixed it
 
 The Ollama server log shows it refuses to put the vision projector on the GPU:
 
@@ -219,19 +219,19 @@ llama-server ... --no-mmproj-offload --image-min-tokens 1024
 On a **shared-memory** iGPU, Ollama's heuristic keeps the **vision encoder (mmproj)
 on the CPU** and offloads only the LLM text layers. Single-image latency is
 dominated by vision encoding (forced to ≥1024 vision tokens), so accelerating only
-the text layers barely helps — hence ~1.5×.
+the text layers barely helps — hence ≈1.5×.
 
 **The fix:** run `llama-server` directly with the GGUF + mmproj and `-ngl 99`, which
 offloads **both** the text layers **and** the vision projector to the Arc GPU. That
-single change moved the bottleneck onto the GPU and cut latency from ~52 s to ~5 s —
-a **~10× win over Ollama, ~14× over CPU** — at identical accuracy.
+single change moved the bottleneck onto the GPU and cut latency from ≈52 s to ≈5 s —
+a **≈10× win over Ollama, ≈14× over CPU** — at identical accuracy.
 
 **Diagnostic note:** `ollama ps` reports `100% GPU` in the Ollama case, but that only
 counts the LLM text weights in VRAM. It does **not** reveal the vision encoder is on
 CPU — that is only visible in the verbose startup log. For a VLM, "100% GPU" from
 `ollama ps` is necessary but not sufficient.
 
-**Takeaway:** with the vision encoder on the GPU, a 3B VLM is a **~5 s/image**
+**Takeaway:** with the vision encoder on the GPU, a 3B VLM is a **≈5 s/image**
 machine on this integrated Arc — usable for a real app, not just a demo.
 
 ## Cloud: HF ZeroGPU (A10G) vs local Arc iGPU
@@ -244,7 +244,7 @@ the identical 200-image, disambiguated-prompt benchmark against it.
 |---|---|---|
 | Accuracy | 93.0% (186/200) | **92.8%** (167/180 valid) |
 | Latency (median) | 5.8 s | **2.9 s** |
-| Speedup | 1× | **~2×** |
+| Speedup | 1× | **≈2×** |
 
 Accuracy is identical within noise — quantization (q4 vs BF16) made no
 measurable difference here. Latency is roughly **2× faster on the A10G**, a real
@@ -300,20 +300,20 @@ exact same disambiguated-classification question as the local runs.
 The first full run scored only 83.5%, entirely explained by **20 quota-exhausted
 errors on the last two classes** (pizza, samosa — last in iteration order): HF's
 free ZeroGPU tier grants a limited number of GPU-seconds per day, and it ran out
-after ~180 calls at ~3 s of GPU time each. Excluding those 20 non-answers gives
+after ≈180 calls at ≈3 s of GPU time each. Excluding those 20 non-answers gives
 the true 92.8% above. For any bulk/benchmark use of the free tier, budget for
 this — HF's own error message point to HF PRO for more daily quota.
 
 ## Reproduce
 
-**Backend A — Ollama (Arc, ~52 s/img):**
+**Backend A — Ollama (Arc, ≈52 s/img):**
 
 ```
 serve-arc.bat            # from ollama-ipex/: sets OLLAMA_IGPU_ENABLE=1, Ollama on Arc
 python bench_hf.py 10    # 10 images/class = 200 images -> bench_hf_results.jsonl
 ```
 
-**Backend B — llama.cpp (Arc, ~5–6 s/img, best accuracy):**
+**Backend B — llama.cpp (Arc, ≈5–6 s/img, best accuracy):**
 
 ```
 llama-cpp\llama-server.exe ^
@@ -323,7 +323,7 @@ llama-cpp\llama-server.exe ^
 
 python bench_llamacpp.py      # bare prompt      -> 74%  (bench_hf_results_llamacpp.jsonl)
 python bench_llamacpp_v2.py   # disambiguated    -> 86%  (bench_hf_results_llamacpp_v2.jsonl)
-python bench_parallel.py 4    # v2 prompt, x4    -> 86%, 200 imgs in ~2 min (bench_hf_results_parallel.jsonl)
+python bench_parallel.py 4    # v2 prompt, x4    -> 86%, 200 imgs in ≈2 min (bench_hf_results_parallel.jsonl)
 ```
 
 The GGUFs are from `unsloth/Qwen2.5-VL-3B-Instruct-GGUF` (Q4_K_M + mmproj-F16).
@@ -354,7 +354,7 @@ python3.13 bench_zerogpu.py <hf_token_file>   # -> 92.8% valid, 2.9s median (ben
 Requires `app.py` deployed to the `RonitP1/KhanaVision` Space with the
 `RAW_PROMPT:` prefix convention (see Cloud section above) so the benchmark's
 constrained-classification prompt bypasses the app's normal JSON-analysis
-wrapper. Free-tier ZeroGPU quota covers ~180 calls/day; budget accordingly.
+wrapper. Free-tier ZeroGPU quota covers ≈180 calls/day; budget accordingly.
 
 All benchmarks reuse cached images in `bench_hf_images/` and write per-image
 results to their respective `.jsonl`.
@@ -365,13 +365,13 @@ results to their respective `.jsonl`.
 |---|---|
 | Ollama → llama.cpp (mmproj on GPU) | latency 52 s → 5 s, accuracy unchanged |
 | bare prompt → disambiguated prompt | accuracy 74% → 86%, latency +1.3 s |
-| Qwen2.5-VL-3B → Qwen3-VL-4B | accuracy 86% → 93%, latency unchanged (~6 s) |
+| Qwen2.5-VL-3B → Qwen3-VL-4B | accuracy 86% → 93%, latency unchanged (≈6 s) |
 | few-shot reference images | **negative** — 2/10 → 1/10 (token-budget conflict, see above) |
-| serial → parallel ×4 (Qwen2.5-VL-3B) | 200-img wall time ~21 min → ~2 min |
+| serial → parallel ×4 (Qwen2.5-VL-3B) | 200-img wall time ≈21 min → ≈2 min |
 | serial → parallel ×4 (Qwen3-VL-4B) | **no gain** — model already saturates the GPU at concurrency 1 |
 | flash-attn (`-fa on`) | neutral here (vision-prefill bound, not attention bound) |
-| local Arc → HF ZeroGPU A10G | latency 5.8 s → 2.9 s (~2×), accuracy unchanged |
+| local Arc → HF ZeroGPU A10G | latency 5.8 s → 2.9 s (≈2×), accuracy unchanged |
 
 **Best overall config: Qwen3-VL-4B + disambiguated prompt = 93% top-1.**
-Local (Arc iGPU, free, always-on): **~5.8 s/image.**
-Cloud (HF ZeroGPU, free, ~180 calls/day quota): **~2.9 s/image.**
+Local (Arc iGPU, free, always-on): **≈5.8 s/image.**
+Cloud (HF ZeroGPU, free, ≈180 calls/day quota): **≈2.9 s/image.**