Pin and measure v0, the reference baseline

v0 is the starting line: the pinned base at BF16, measured on our own hardware
so every later version has an exact thing to beat. Records throughput, the
vision check, the tool-call parse and both canaries.

The throughput is the notable result - at BF16 this 4B runs at about the same
single-stream rate as the 27B NVFP4 on the same box, which is a memory-bandwidth
finding and the case for quantizing the deployment lane.

README.md

@@ -17,9 +17,9 @@ tags:
 
 # Karti-Small-VL-4B
 
-**Status: in training. No checkpoint exists yet.** This page is being published
-from the scaffolding stage on purpose, and it will be updated as runs happen —
-including the ones that fail.
+**Status: v0 baseline pinned and measured. Training not yet started.** This page
+is published from the scaffolding stage on purpose, and it will be updated as
+runs happen — including the ones that fail.
 
 Karti-Small-VL-4B is Lumbridge's small **vision + tool-calling** model: a 4B
 model meant to run locally and do the two things a household agent actually
@@ -151,12 +151,52 @@ Karti-Small-VL-4B-2026.08.29-r007-a1b2c3d
 
 A **release** is a checkpoint the promotion gate accepted, and only then does it
 get a short name — `Karti-Small-VL-4B-v1`. Versions are immutable and are never
-reassigned, so a version number means something passed a gate rather than merely
-finished training.
+reassigned, so from v1 onward a version number means something passed a gate
+rather than merely finished training.
+
+`v0` is the exception that makes the rule usable: it is the **reference
+baseline** — the pinned base, measured on our own hardware, before any training.
+It is what every later version has to beat, so it is numbered rather than left
+floating.
 
 This replaces a week-anchored scheme that could not express iterating more than
 once a week without inventing a date.
 
+## Versions
+
+### `Karti-Small-VL-4B-v0` — reference baseline
+
+The starting line, pinned and measured so later versions have something exact to
+be compared against.
+
+| | |
+|---|---|
+| weights | [`Qwen/Qwen3.5-4B`](https://huggingface.co/Qwen/Qwen3.5-4B) @ `851bf6e806efd8d0a36b00ddf55e13ccb7b8cd0a` |
+| precision | BF16 |
+| parameters | 4,659,865,088 |
+| training applied | none — this is the baseline |
+| serving alias | `karti-vl` · `karti-vl-4b-base` |
+
+Measured on a DGX Spark (GB10, 121.7 GB unified), vLLM 0.27.1, BF16,
+`max_model_len` 32768, KV cache FP8, temperature 0, single stream:
+
+| check | result |
+|---|---|
+| generation, 128 tokens | **18.24 tok/s** |
+| generation, 512 tokens | **17.74 tok/s** |
+| vision — shapes and colours off a synthetic image | correct |
+| tool call via `qwen3_xml` parser | parsed — `cron(job="driveway-clear")` |
+| arithmetic canary `19 × 23` | 437 |
+| empty-content canary at `max_tokens: 80` | non-empty, `finish_reason: stop` |
+
+The throughput number is the interesting one: at BF16 this 4B runs at
+approximately the same single-stream rate as the 27B NVFP4 brain on the same
+box. That is a memory-bandwidth result, not a capability one, and it is the
+argument for quantizing the deployment lane rather than shipping BF16.
+
+Weights are not mirrored here — v0 is byte-identical to the pinned Qwen revision
+above, so that revision is the artifact and this table is its measurement.
+
 ## What it is being trained to do
 
 The tool surface it inherits from the 3B program, now with images in the

recipe.json

@@ -2,7 +2,7 @@
   "schema": "karti.model-recipe/v2",
   "model_name": "Karti-Small-VL-4B",
   "serving_alias": "karti-vl",
-  "status": "scaffolding-complete-no-run-executed",
+  "status": "v0-baseline-pinned-and-measured-no-training-run-executed",
   "weights_published": false,
   "private_training_rows_published": false,
   "base_model": {
@@ -95,5 +95,38 @@
       "mitigation": "enable_thinking:false pinned for every run and serving config",
       "required_canary": "a tight-max_tokens request must return non-empty content before any result from this model is believed"
     }
+  },
+  "releases": {
+    "v0": {
+      "role": "reference baseline; the pinned base measured on our hardware before any training",
+      "weights_repository": "Qwen/Qwen3.5-4B",
+      "weights_revision": "851bf6e806efd8d0a36b00ddf55e13ccb7b8cd0a",
+      "weights_mirrored_here": false,
+      "weights_mirror_note": "byte-identical to the pinned upstream revision; that revision is the artifact",
+      "precision": "BF16",
+      "training_applied": "none",
+      "gate_passed": "n/a - a baseline is not gated; v1 onward are",
+      "measured_on": "DGX Spark GB10, 121.7 GB unified, vLLM 0.27.1, max_model_len 32768, kv-cache fp8, temperature 0, single stream",
+      "measured_2026_08_29": {
+        "tok_per_s_128": 18.24,
+        "tok_per_s_512": 17.74,
+        "vision": "correct on synthetic shape/colour image",
+        "tool_call": "parsed via qwen3_xml",
+        "canary_19x23": 437,
+        "canary_empty_content_at_max_tokens_80": "non-empty, finish_reason=stop"
+      },
+      "observation": "at BF16 this 4B runs at roughly the same single-stream rate as the 27B NVFP4 on the same box - a memory-bandwidth result, and the argument for quantizing the deployment lane"
+    }
+  },
+  "serving": {
+    "aliases": [
+      "karti-vl",
+      "karti-vl-4b-base"
+    ],
+    "port": 8002,
+    "runtime": "vLLM 0.27.1",
+    "tool_call_parser": "qwen3_xml",
+    "chat_template": "the model's own; never overridden - train/serve parity depends on it",
+    "enable_thinking": false
   }
 }