@miller-tech/uap 2.16.7 → 2.19.5

package/config/capacity-policy.json

@@ -39,6 +39,39 @@
         "knownRestarts": 0,
         "allowedNew": 0
       }
+    },
+    {
+      "name": "mission-orchestrator",
+      "systemd": {
+        "unit": "uap-orchestrator.service",
+        "scope": "user"
+      },
+      "budget": {
+        "rssMiB": 512,
+        "note": "uap orch poll loop clock over the mission ledger (added 2026-10-03). Polls every 300s; RSS covers node + better-sqlite3."
+      },
+      "restartBudget": {
+        "knownRestarts": 0,
+        "allowedNew": 3
+      }
+    },
+    {
+      "name": "strata-server",
+      "http": {
+        "url": "http://127.0.0.1:8080",
+        "kind": "strata",
+        "metricsMustMatch": {
+          "kv": "int8",
+          "max_context": 131072
+        }
+      },
+      "budget": {
+        "note": "The local Qwen3.8 backend since 2026-10-04 (the gsq-rco llama-server above is its retired predecessor, unit kept for rotation). Unit-less: launched by /home/cogtek/dev/strata/run-iq3_xxs.sh (flash-next IQ3_XXS pack, --expert-cache auto, --vram-reserve-mib 1200, --spec 4, --kv int8, --max-context 131072, single rail). No restartBudget: with no unit, NRestarts does not exist; liveness IS the /metrics probe. metricsMustMatch pins the two load-bearing numbers the note mentions — kv kind and pool size — so a relaunch with different flags reads as RED, the execStartMustContain doctrine applied to a service with no ExecStart."
+      },
+      "headroom": {
+        "gpuMinFreeMiB": 200,
+        "_headroom_comment": "200, not the 600 the llama.cpp-era entries use: strata deliberately fills the card (--vram-reserve-mib 1200 is its OWN internal headroom, reported reserve-aware at /metrics), and the measured steady state with the desktop sharing the GPU is ~245 MiB free. A 600 floor would hold the doctor permanently RED at the operator's chosen operating point and train everyone to ignore it. 200 still alerts when something NEW eats the card or strata loses its reserve."
+      }
     }
   ]
 }

package/config/model-profiles/qwen38.json

@@ -1,27 +1,27 @@
 {
   "_profile": "qwen38",
-  "_description": "Qwen3.8 27B GSQ-RCO — local llama.cpp (buun fork) deployment for agentic tool-calling workloads. Successor to qwen36; the default local executor in UAP routing. Routes through the anthropic-proxy for the tool/finalize guardrails, NOT the inference server directly.",
-  "_engine": "buun-llama-cpp b1261-ed67e11b8 (llama.cpp fork) via uap-gsq-rco-server.service on :8080. Serves /props, /slots, /metrics and /v1. Weights: Qwen3.8-27B-GSQ-RCO-IQ3_S.gguf (ISTA-DASLab non-uniform 3.50 bpw, 10.96 GiB) + mmproj-Qwen3.8-27B-BF16.gguf (vision/video) + Qwen3.8-27B-DFlash2-Q4_K_M.gguf draft.",
-  "_engine_history": "CORRECTED 2026-09-20. This profile previously described ninfer-serve and asserted that /props, /slots and /metrics did not exist and that chat_template_kwargs was rejected with HTTP 400. That backend is not what is running; all three endpoints are live. Verify against /props before trusting engine claims here.",
-  "model": "qwen38-gsq-rco-27b",
+  "_description": "Qwen3.8 Flash-Next — local Strata serve-layer deployment for agentic tool-calling workloads. Successor to qwen36 and to the 2026-09-20 GSQ-RCO llama.cpp deployment; the default local executor in UAP routing. Routes through the anthropic-proxy for the tool/finalize guardrails, NOT the inference server directly.",
+  "_engine": "strata serve layer 0.1.37 (python server + native engine binary) on :8080, no systemd unit — launched by /home/cogtek/dev/strata/run-iq3_xxs.sh. Serves llama.cpp-shaped /props, /slots and /v1, plus a JSON /metrics (engine/live/requests — NOT Prometheus text; `uap inference health` auto-detects it). Weights: strata-data pack iq3_xxs (Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS, native experts + PLE shard) with MTP speculative drafts (spec 4, spec-min-p 0.5, mtp_max 4) and an auto-sized expert cache (~14.5 GiB, 91% hit rate observed). Model id advertised at /v1/models: qwen3.8-flash-next-iq3_xxs; the server ignores requested model ids entirely, which is why stale client pins (e.g. a resumed session still naming qwen36 ids) keep working.",
+  "_engine_history": "SUPERSEDED 2026-10-04: this profile described buun-llama-cpp behind uap-gsq-rco-server.service (2 rails sharing a 229376-cell VBR pool, DFlash2 draft). That unit is now INACTIVE — the box serves the Strata layer on :8080 instead (tuned 2026-10-03: +15% over the llama.cpp fork on agent workloads). The old description was itself a 2026-09-20 correction of a ninfer-serve description. Verify against /metrics before trusting engine claims here; the dead unit's ExecStart still reports -c 229376 to systemctl, and on 2026-10-04 `uap inference health` printed that stale pool size for the live (131072) backend.",
+  "model": "qwen3.8-flash-next-iq3_xxs",
   "max_tokens": 57344,
-  "_max_tokens_comment": "Deliberately generous: 50% of the 114688 window, the same ratio the previous 65536/131072 pairing used. The engine returns chain-of-thought in a SEPARATE reasoning_content field (--reasoning-format auto), so reasoning spends completion budget without ever appearing in content. A tight cap therefore does not produce a short answer, it produces an EMPTY one with finish_reason=length — measured previously as ~90% first-turn decode failure that read as bad output format and was really budget truncation. Do not lower this without re-measuring decode compliance.",
+  "_max_tokens_comment": "Deliberately generous: 50% of the 114688 window, the same ratio the previous 65536/131072 pairing used. The engine returns chain-of-thought in a SEPARATE reasoning_content field, so reasoning spends completion budget without ever appearing in content. A tight cap therefore does not produce a short answer, it produces an EMPTY one with finish_reason=length — measured previously as ~90% first-turn decode failure that read as bad output format and was really budget truncation. Do not lower this without re-measuring decode compliance. (The proxy additionally clamps tool turns to PROXY_TOOL_TURN_MAX_TOKENS=32768 regardless.)",
   "temperature": 0.3,
   "top_p": 0.9,
   "top_k": 20,
   "min_p": 0.05,
   "repetition_penalty": 1.0,
-  "_sampling_comment": "Carried over from qwen36 unchanged: these are UAP's tool-call-tuned values, not the vendor's chat defaults, and nothing has been re-measured on 3.8. They deliberately differ from the server's own defaults (temp 0.7 / top_p 0.95 / top_k 20 / min_p 0, plus DRY 0.8 allowed_length 16). Left untouched on 2026-09-20 because the 2-rail work measured throughput, not output quality. Re-tune with `uap tune` before changing them.",
+  "_sampling_comment": "Carried over from qwen36 unchanged: these are UAP's tool-call-tuned values, not the vendor's chat defaults. They were re-measured only against the llama.cpp GSQ-RCO engine, never against strata — strata's own defaults (spec 4, spec-min-p 0.5) affect drafting, not base sampling, so the values are carried as-is. Re-tune with `uap tune` before changing them.",
   "stop_sequences": [
     "<|im_end|>"
   ],
   "timeout_ms": 300000,
   "context_window": 114688,
-  "_context_window_comment": "THIS IS A PER-SESSION CAP, AND IT IS LOAD-BEARING (set 2026-09-20). The server runs -np 2 -c 229376 with kv_unified=true, which means 229376 is ONE SHARED POOL, not a per-rail allowance: /slots reports n_ctx=229376 for BOTH slots and each rail may address the whole pool. The proxy's own detection (anthropic_proxy.py _maybe_recheck_context_window) reads slots[0].n_ctx and overrides the PROXY_CONTEXT_WINDOW env pin, so without a profile every session would be told it owns 229376 — two concurrent sessions would then demand 458752 cells from a 229376-cell pool and thrash the prefix cache. A profile context_window is the mechanism that applies a per-session cap (anthropic_proxy.py:13933). It is not the only writer of monitor.context_window — :3245 sweeps every live monitor whenever upstream n_ctx changes — but the recheck runs BEFORE the profile override on each request (:13893), so the cap is restored on the next call rather than lost. 114688 x 2 rails = exactly the pool. In practice sessions sit far below it: the proxy prunes at 0.70 (~80k) toward 0.50 (~57k). IMPORTANT GAP: this cap is OPT-IN. _resolve_profile_name returns None when no x-uap-model-profile header (or uap_model_profile body param) is present, and there is no default-profile setting, so a client that does not send it gets the full shared pool. opencode, codex and claude-local are configured to send it; factory/droid custom models have no header field and CANNOT, so keep factory to one local session at a time. Note also that /v1/models advertises the process-wide window (229376), not this cap — a client that sizes itself from discovery rather than its own config will still aim at the pool.",
+  "_context_window_comment": "THIS IS A PER-SESSION CAP, AND IT IS LOAD-BEARING. Strata serves ONE rail with a 131072-cell pool (--max-context 131072, /slots reports n_ctx=131072); the proxy's detection reads slots[0].n_ctx and would otherwise tell every session it owns the whole pool. 114688 deliberately sits BELOW the pool (87.5%): the difference (~16k cells) is the engine's own working room (prompt scratch, conversation cache, expert-cache bookkeeping), so a session at the cap cannot crowd the engine out of its own pool. Consequence of the smaller backend: admission is now 1, not 2 — a second hot session at this cap would demand 229376 cells from a 131072-cell pool, the exact overcommit the per-session cap exists to prevent. In practice sessions sit far below it: the proxy prunes at 0.70 (~80k) toward 0.50 (~57k). IMPORTANT GAP (unchanged from the llama.cpp era): this cap is OPT-IN. A client that does not send the x-uap-model-profile header gets the whole pool. opencode, codex and claude-local send it; factory/droid custom models cannot, so keep factory to one local session at a time. /v1/models advertises the process-wide window (131072), not this cap.",
   "optimize_for_tool_calls": true,
   "mode_switch_buffer_tokens": 500,
   "enable_thinking": true,
-  "_thinking_comment": "Top-level. The previous ninfer engine REJECTED chat_template_kwargs (HTTP 400 chat_template_option_not_supported), which is why qwen36.json carries the nested form and this profile dropped it. The current backend runs llama.cpp --jinja, where chat_template_kwargs is native and supported. The proxy probes the backend once and adapts (PROXY_CHAT_TEMPLATE_KWARGS=auto|on|off), so the top-level form remains correct and safe either way.",
+  "_thinking_comment": "Top-level. The proxy probes the backend once and adapts (PROXY_CHAT_TEMPLATE_KWARGS=auto|on|off), so the top-level enable_thinking form remains correct across both the llama.cpp and strata backends.",
   "dynamic_temperature": {
     "enabled": true,
     "decay": 0.5,
@@ -34,45 +34,44 @@
     "_comment": "Reduces round-trips by encouraging multi-tool emission in one turn."
   },
   "concurrency": {
-    "max_parallel_requests": 2,
-    "_comment": "Matches the server's 2 rails AND the proxy settings that scripts/sync-local-agent-configs.sh installs in the same change: PROXY_CONCURRENCY_LIMIT=2, UAP_MODEL_SLOTS=2 and — the one that actually protects the shared pool — PROXY_SESSION_ADMISSION_LIMIT=2. Those three must move together with this field: raising it while the proxy still serializes at 1 makes callers fan out and buy latency rather than throughput, and raising admission above the rail count admits more hot sessions than the pool can hold. NOTE this value is aspiration until that script is actually run; the live proxy env is the authority. Whether the second rail is EARNING anything is a separate question — check llamacpp:n_busy_slots_per_decode in /metrics: a prior reading of 1.002 over 139 requests meant the workload never had two concurrent requests at all.",
+    "max_parallel_requests": 1,
+    "_comment": "Strata runs ONE rail with a 131072-cell pool (its predecessor ran two rails over 229376). One admitted hot session at the 114688 cap is all the pool can hold, so slots, proxy concurrency and session admission all drop to 1 together — exactly the move-together rule the 2-rail comment below codified, in the opposite direction. scripts/sync-local-agent-configs.sh installs the matching PROXY_CONCURRENCY_LIMIT=1, UAP_MODEL_SLOTS=1, PROXY_SESSION_ADMISSION_LIMIT=1. Cost: a mission-deliver run now queues behind opencode instead of overlapping; that is the accepted trade for the 114688 single-session window. NOTE the live proxy env is the authority until that script is run — a profile of 1 against a proxy still admitting 2 overcommits the 131072 pool.",
     "kv_capacity_shared": true,
-    "_kv_shared_comment": "true since 2026-09-20: the fork forces --kv-unified whenever VBR runs with -np > 1 ('-np 2 without --kv-unified would disarm the degrade controller'). Rails share one 229376-cell pool rather than owning private slices."
+    "_kv_shared_comment": "One rail, one pool: trivially shared, and still true that a rail addresses the WHOLE pool rather than owning a slice. Kept true so consumers that branch on it keep treating the pool as a shared resource."
   },
   "server_optimization": {
-    "kv_dtype": "vbr",
-    "_kv_dtype_comment": "VBR dynamic turbo: entry tier t8 (~q8_0 quality) degrading toward floor t4 (4.125 bits/value ~ q4_0) only as the pool fills, under an explicit 5120 MiB KV budget (--vbr-vram 5120M). The explicit budget replaced 'auto' on 2026-09-18 after auto resolved 9536 MiB and overcommitted the card through THREE SIGABRT core dumps. A fourth dump followed WITH the 5120M budget already in place; that one was fixed by dropping the pool 262144 -> 229376, not by the budget. Do not fold it into the budget's evidence.",
+    "kv_dtype": "int8",
+    "_kv_dtype_comment": "Fixed-tier int8 KV (8 bpv) with --kv-resident 32768, NOT the old VBR dynamic degrade — there is no floor to pin at, and the kv-at-floor finding no longer applies. Strata manages pool pressure itself (conversation cache eviction); the profile's job is only to keep the per-session cap below the pool.",
     "prefill_chunk": 1024,
-    "max_context": 229376,
-    "kv_capacity": 229376,
-    "_capacity_comment": "Shared pool total across both rails, NOT per rail. Per-session allowance is context_window above.",
-    "parallel_rails": 2,
+    "max_context": 131072,
+    "kv_capacity": 131072,
+    "_capacity_comment": "Whole pool, one rail. Per-session allowance is context_window above (114688, deliberately under the pool).",
+    "parallel_rails": 1,
     "speculative_decoding": {
       "enabled": true,
-      "type": "draft-dflash",
-      "draft_model": "Qwen3.8-27B-DFlash2-Q4_K_M.gguf",
+      "type": "mtp",
+      "draft_model": "strata-data/mtp/rt (MTP head, not a separate draft model)",
       "draft_max": 4,
-      "draft_min": 0,
-      "_comment": "A real 1.06 GiB draft MODEL, not self-speculation. Replaces the previously recorded '--spec mtp --draft-tokens 3 --lm-head-draft' (that was the ninfer engine's built-in MTP). DFlash2 was measured on this box 2026-09-12 to beat the native MTP head at every depth (45/31/30 vs 36/20/13 t/s at 2k/32k/92k)."
+      "draft_min_p": 0.5,
+      "_comment": "Strata's native MTP speculative path (--spec 4 --spec-min-p 0.5, mtp_max 4, plus a lookup-3 secondary). Replaces the DFlash2 draft model of the llama.cpp era: observed 2026-10-04 at 84-89% acceptance on agent workloads (vs 62% on one 311-token outlier), which is what carries decode to the observed 46-52 tok/s."
     },
-    "_comment": "These are the flags uap-gsq-rco-server.service is actually running under, recorded so a rebuild reproduces the measured behaviour.",
-    "_budget_tier_comment": "Budget arithmetic worth knowing: 5120 MiB / 229376 cells = 22.86 KiB/token, which is EXACTLY the t4 floor (4.125 bpv). The budget was sized so the full pool fits only at the WORST quality tier; at the t8 entry tier it covers roughly 107k tokens. Consequence of --kv-unified that did not exist at one rail: KV precision is now COUPLED ACROSS SESSIONS. A lone agent at 60k sits at t8; add a second agent at 60k and both degrade toward t4."
+    "_comment": "These are the flags run-iq3_xxs.sh actually runs strata with, recorded so a rebuild reproduces the measured behaviour. The load-bearing pair (kv int8, max-context 131072) is pinned in config/capacity-policy.json under the strata-server http entry, where `uap doctor` verifies them against /metrics."
   },
   "measured": {
-    "date": "2026-09-20",
+    "date": "2026-10-04",
     "gpu": "NVIDIA GeForce RTX 3090, 24576 MiB",
-    "_gpu_comment": "llama-server resident is NOT a constant: VBR maps KV lazily, so it tracks pool occupancy. 16652 MiB was a cold-start reading on an empty pool and should not be quoted as steady state. Measured under real load the same day: ~19.5 GiB resident, ~3.2 GiB free. Budget headroom against the 3.2 GiB figure, not the cold one — and remember a vision request allocates image-encode buffers on top.",
-    "decode_tokens_per_second": 43,
-    "_decode_comment": "CODE GENERATION at shallow depth, which is the closest single number to agent work. Decode here is strongly workload- AND depth-dependent, so one number is always a simplification. Measured 3 reps each, greedy, 220 max_tokens, via scripts/bench-decode-reps.sh: code 41.1/45.7/43.0 tok/s | prose 25.4/25.1/32.3 | counting 52.2/52.7/54.2. Depth matters as much: an earlier probe run measured ~72 at ~100 tokens of context but only ~32 at 27k. The DFlash2 rows above (45/31/30 t/s at 2k/32k/92k) remain the best depth-resolved characterisation. An earlier version of this file recorded 72 tok/s from a SINGLE rep on 'count from 1 to 40' — a degenerate, near-perfectly draftable prompt at zero depth. Do not quote a decode number without saying which workload and what depth.",
-    "draft_acceptance": 0.71,
-    "_draft_acceptance_comment": "Code generation, 3 reps: 67.8/73.4/71.7%. Strongly prompt-dependent — prose only reaches 30.5-39.8%, while counting hits 93.9-97.7%. The 0.90 previously recorded here came from the counting prompt and is not characteristic of anything an agent does.",
-    "prefill_tokens_per_second": 900,
-    "_prefill_comment": "Bulk prefill on unique (uncacheable) prompts: ~927 t/s at 3.5k, ~899 at 13.7k, ~883 at 27.4k, ~751 at 41k. A previously recorded 105 t/s was fixed per-request overhead measured on a ~100-token prompt, not a prefill rate — wrong by roughly 8x. Rough model: ms/token = 1.03 + 6.3e-6*N.",
+    "_gpu_comment": "Strata's own reserve-aware /metrics reported ~950 MiB free under live load (--vram-reserve-mib 1200 already held out; arena 40925 MiB across host+device, expert cache ~14.5 GiB). Host-wide free via nvidia-smi is the doctor's number; engine.vram_free_mib is strata's view, and both are checked now.",
+    "decode_tokens_per_second": 47,
+    "_decode_comment": "CODE GENERATION on real agent traffic, observed 2026-10-04 over the live session: 41.5-51.6 tok/s at 19-20k prompt depth, 36.6 at 38.6k depth, 43.2-47.4 in the 11-12k range, one 45.9 sustained across a 7071-token generation. Depth matters as much as workload: 47 here is a mid-depth code-workload number, not a constant. Do not quote a decode number without saying which workload and what depth.",
+    "draft_acceptance": 0.84,
+    "_draft_acceptance_comment": "Agent-tool workloads observed 2026-10-04: 84-89% per request (80/93, 66/77, 91/110, 4535/5427 tokens) with one 62% outlier on a 311-token short generation. The prior engine's counting-prompt 0.90 remained dishonest; this figure is from real agent traffic only.",
+    "prefill_tokens_per_second": 950,
+    "_prefill_comment": "Observed 2026-10-04 on live traffic: 900-1025 tok/s reading 3.7-11.6k unique tokens per turn (with 15.5k+ reused from the conversation cache at 95-99% reuse). Strata reports read-rate only on non-reused tokens, same convention as the old profile.",
     "concurrent_2_rail_throughput": null,
-    "_concurrency_comment": "STILL UNMEASURED. Decode on this card is memory-bandwidth-bound, so the expected win from the second rail is OVERLAP (no head-of-line blocking; one session's prefill can proceed during another's decode), NOT 2x throughput. The honest acceptance test is llamacpp:n_busy_slots_per_decode from /metrics: a prior investigation recorded 1.002 over 139 requests, i.e. the workload never actually had two concurrent requests and the second rail bought nothing. Require that metric to exceed 1 under real load before claiming the rail is earning its keep."
+    "_concurrency_comment": "Moot at one rail: there is no second rail to measure. Kept null so no concurrent-throughput claim survives from the 2-rail era."
   },
   "routing": {
     "endpoint": "http://127.0.0.1:4000/v1",
-    "_comment": "Route through the anthropic-proxy, NOT the inference server directly — the proxy applies the tool/finalize guardrails and, via this profile, the per-session context window that clients size their history to. Clients select this profile with the header 'x-uap-model-profile: qwen38' (or a uap_model_profile body param)."
+    "_comment": "Route through the anthropic-proxy, NOT the strata port directly — the proxy applies the tool/finalize guardrails and, via this profile, the per-session context window that clients size their history to. Clients select this profile with the header 'x-uap-model-profile: qwen38' (or a uap_model_profile body param)."
   }
 }