x4 pair round two: pure Vulkan changes nothing, and the first verdict was wrong

Asked whether Vulkan on both devices unlocks the split. It does not: the
per-tensor design aborts byte-identically, because the gate is not the driver
mix but `--override-tensor` — `has_tensor_overrides()` is a required term of
the scheduler's `pipeline_parallel` flag (llama-context.cpp:433, the only place
in the tree that reads it), and that flag sets `n_copies` in
`ggml_backend_sched_new`. With `n_copies == 1` a pre-allocated weight on a
non-primary device has no backend and the graph aborts.

Chasing it exposed a harness artifact that invalidated the earlier conclusion:
llama-bench splits a device LIST with `/` and SWEEP values with `,`, so
`-dev CUDA0,Vulkan1` was two single-device runs all along (and `-ts 0.85,0.15`
two sweep values, i.e. device 0 takes everything — which is where the bogus OOM
came from). With the correct syntax two-device splits work in both flavours:

  pure Vulkan  -dev Vulkan1/Vulkan0 -ts 0.85/0.15 -> 27.55 tok/s @64k (12.8 GiB on the 3090)
  cross-vendor -dev CUDA0/Vulkan1   -ts 0.15/0.85 -> 27.23 tok/s @64k, pp512 268.5 (15.0 GiB)
  iGPU alone                                       25.77 tok/s @64k, pp512 231.8

+7 % decode, +16 % prefill — real but not a regime change, and it costs the
3090 ~15 GiB, which this fleet spends on its only vision endpoint. The design's
premise still fails: whole layers carry their experts (1.62 GiB each), the 12
attention layers are spread every 4th, and the 32.8 GiB PLE must stay on the
main device, so KV cannot be consolidated on the 3090.

Also records the evening's incident (a dead rootless podman pause process took
all container management down; `podman system migrate` panics in 5.7.0; reboot
repaired it) and the netavark host-address lesson from the hermes 502.

serverAppConfigs-docs/log.md

@@ -659,3 +659,50 @@ timestamp: 2026-09-14
   halogen's ledger read `400384 positions, ~27.2 GiB` against a 33.5 GiB budget
   with 15.2 GiB left).
 - New page: [[x4-pair-experiment]].
+
+## 2026-09-16 (later) — the x4 pair, round two: the first conclusion was a parsing artifact
+- Asked whether **pure Vulkan** changes the answer (both devices can run Vulkan —
+  `Vulkan0 = RTX 3090 (NV_coopmat2)`, `Vulkan1 = RADV STRIX_HALO (KHR_coopmat)`).
+  It does not: the per-tensor design still aborts, byte-identically.
+- **The real gate is `-ot`, not the driver mix.** `has_tensor_overrides()` is a
+  required term of `pipeline_parallel` in `llama-context.cpp:433` — the ONLY place
+  in the tree that reads it — and that flag is what sets `n_copies` in
+  `ggml_backend_sched_new` (`ggml-backend.cpp:25`). With `n_copies == 1` a
+  pre-allocated weight on a non-primary device has no backend, so the graph
+  aborts at `ggml-backend.cpp:941` with the leaf's own op name (`(NONE)`).
+  `-ot exps=CPU` works only because the CPU backend is last in the list.
+- **Then the correction.** `llama-bench --help` says `-dev <dev0/dev1/...>`: `/`
+  splits a device LIST, `,` splits SWEEP values. So `-dev CUDA0,Vulkan1` was two
+  *single-device* runs — the earlier "CUDA + Vulkan cannot serve one model", the
+  "load failures", and the OOMs were artifacts (the OOM was 111 GiB on the 24 GiB
+  card). The bench table's `dev` column had been printing the truth all along.
+- **With the correct syntax two-device splits work, in both flavours** (64k depth,
+  `-d 65536`; placement proven by `nvidia-smi` sampled during the run):
+  - pure Vulkan `-dev Vulkan1/Vulkan0 -ts 0.85/0.15` — 12.8 GiB on the 3090,
+    **27.55 tok/s** (pp512@64k 224.3)
+  - cross-vendor `-dev CUDA0/Vulkan1 -ts 0.15/0.85` — 15.0 GiB on the 3090,
+    27.23 tok/s with **pp512@64k 268.5**
+  - against the iGPU alone: 25.77 tok/s / 231.8 — so **+7 % decode, +16 % prefill**
+- **And the split still cannot reach the design's premise**: whole layers move
+  their experts with them (1.62 GiB per layer), the 12 attention layers are spread
+  every 4th across the depth, and the 32.8 GiB PLE must stay on the main device —
+  so KV cannot be consolidated on the 3090.
+- **Incident, same evening:** the rootless podman pause process died (memory
+  pressure from the 116 GiB iGPU runs is the plausible cause). Every `podman`
+  command then failed (`invalid internal status … could not find any running
+  process`), every container start failed on aardvark-dns binding `10.89.x.1:53`
+  (the rootless netns holding the bridges was gone), and all 28 quadlets looped.
+  `podman system migrate` — podman's own named remedy — **panics** in 5.7.0
+  (`teardownNetworkBackend`). Repair was a **reboot**: all 28 containers returned
+  on their own (linger + `WantedBy=default.target` present), e2e gate green after.
+- **A second, pre-existing defect surfaced by that reboot:** `hermes.franksdank.cloud`
+  returned 502. hermes-webui is `Network=host`, so 8787 is a bare host-netns bind
+  and netavark DNATs only *published* ports — from inside the Caddy container
+  `192.168.0.143:8787` and `10.89.1.1:8787` are refused while
+  `host.containers.internal:8787` (169.254.1.2) answers 200. Fixed in the
+  Caddyfile, the stale claim in its comment replaced with the measurement, and the
+  seam that guarded it **strengthened** (it accepted any numeric upstream, so the
+  LAN IP had been passing it; reverting now fails it — teeth verified).
+- Both endpoints restored and healthy: frank-large `400384 positions, ~27.2 GiB`
+  against a 33.5 GiB budget (no clamp), frank-small 200 on 7771. Page: 
+  [[x4-pair-experiment]] (rewritten).