Note that the Pi agent reaches the fleet via ~/.pi/agent/models.json
(outside the repo), that the model ids are stable and referenced by
settings.json, and the two resolution rules (default = provider+model pair;
subagents = unique bare id). Gives the per-slot contextWindow values.
llama.cpp splits -c across -np slots; to give each of the 2 slots the full
262144 native context, set CTX_SIZE=524288. KV ~32 GiB; fits the 96 GiB
unified pool. Update env default, serve-script fallback, and the deployment
doc line.
- Restore the pre-2026-08-17 Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive
Q6_K_P + ngram-mod setup as frank-default-small on Dankserver (port 7770,
upstream llama.cpp b10121, MoE experts on CPU via --n-cpu-moe 36).
- Rename the CIRU Qwen3.8-27B ActiveFPX setup from frank-default-small to
frank-default-large (Dankclaw, port 52625); bump to CTX_SIZE=262144
(native max) and PARALLEL=2 (96 GiB unified pool).
- Retire the Qwen3.8-27B IQ4_XS FastMTP frank-default-large (Dankserver) to
.AGENTTRASH.
- deploy.sh: SERVICE[dankserver]=frank-default-small,
SERVICE[dankclaw]=frank-default-large; HEALTH_WAIT[dankserver]=600.
- CTX_SIZE 65536 -> 131072 (user request). KV at 128K is 8 GiB
(64 KiB/token f16); estimated ~43 GiB used of the 64 GiB SVM pool,
~21 GiB headroom.
- REASONING off -> on with REASONING_FORMAT=deepseek, so <think>
reasoning lands in message.reasoning_content (OpenAI-compatible)
instead of being left unparsed in content.
- Dankclaw System Specs: correct RAM to 64 GiB (61 visible), GPU
budget to the rocm-smi 64 GiB SVM figure, and replace the vLLM
relevance section with the CIRU ROCmFPX runtime facts. Note the
retired vLLM venvs in .AGENTTRASH. Refresh the disk figures.
- deployment.md: update the dankclaw target row (CIRU runtime).
Retire the vLLM service (frank-default-small, port 52625) on Dankclaw
and serve jcbtc/Qwen3.8-27B-CIRU-ActiveFPX-PromptForge through the CIRU
ROCmFPX llama.cpp runtime instead.
- Build llama-server from ciru-ai/ROCmFPX tag
qwen3.8-activefpx-promptforge-v2.3 (commit 103af8b41) against the
private TheRock ROCm 7.15 SDK in the retired ling3-ciru venv. The
model card requires ROCm 7.15 for the advertised Strix Halo
performance; the system ROCm 7.2.4 selects slower kernels.
CK pinned at fdf4bb7fcc984811cef48ce817d89aac064b984a; generated
ck/config.h + ck/version.h copied into the CK source tree so the
ggml-hip build can include them. LLAMA_BUILD_WEBUI=OFF (HF bucket
llama-ui returns 404; server is consumed via the OpenAI API).
- New scripts/serve-frank-small.sh + frank-default-small.env: 64K ctx,
one slot, f16 KV, context checkpoints, prompt cache, native depth-4
MTP on ROCm0, PromptForge DualView sidecars (FFN + GDN), temp 0.7
top-p 0.95, reasoning off. LD_LIBRARY_PATH puts the 7.15 SDK libs
before any system ROCm.
- Update the systemd unit description (same service name and port).
- deploy.sh: update the dankclaw target comment.
- Docs: new docs/ciru-activefpx-promptforge.md with the build runbook;
update docs/index.md and AGENTS.md topology.
- The vLLM venvs (vllm-venv, vllm-vk-venv) were moved to
/home/dank/.AGENTTRASH/ on the target; the vllm-vulkan plugin and
docs were removed from the repo in an earlier commit.
The box was upgraded from 32 GB to 64 GB. Two vLLM sizing pages
still stated 30 GiB physical RAM; rocm-smi reports 64 GiB and free
shows 61 GiB visible. Update the hardware tables and the ROCm
overcommit guidance to match.
Also removes the vllm-vulkan backend page, its index links, and the
frank-vk-compat plugin from the working tree. The vLLM service on
Dankclaw is being retired in favor of the CIRU llama.cpp runtime.
The Avesed template only shows a generic format; the Qwen3.5-MoE
model kept emitting <function=get_weather(city=...)> (args baked into
the name). Add a WORKED EXAMPLE block derived from the actual tool
schema (name + parameter keys) to the system prompt.
The Avesed tokenizer_config.json ships no chat_template, so vLLM used its
built-in template, which does not render the <tool_call> instructions;
the model then emitted malformed XML (arguments baked into the function
name) and the qwen3_xml parser could not extract clean calls.
Clients send tool_choice=auto; without these flags vLLM rejects with
HTTP 400. The Avesed chat template renders the Qwen3 XML tool format,
so qwen3_xml is the matching parser.
- frank-default-large: GGML_CUDA_FA_ALL_QUANTS=ON is mandatory in the
FastMTP build; without it q8_0 KV + FA falls back to a slow path and
prefill collapses ~12x (95 -> 1312 t/s at 8K, measured)
- frank-default-small: FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE + pure-python
flash_attn (triton_amd) + stub; without it the vision encoder warmup
OOMs via torch SDPA
- MODEL_FILE -> Qwen3.8-27B-Uncensored-Q6_K.gguf (22.43 GB, no bundled
MTP head; repo ships a standalone draft sidecar)
- SPEC_DRAFT_MODEL -> Qwen3.8-27B-Uncensored-draft-Q8_0.gguf (3.16 GB)
- CACHE_TYPE_K=q8_0, CACHE_TYPE_V=f16 (mismatched, FA retained via the
GGML_CUDA_FA_ALL_QUANTS rebuild of head HIP + worker CUDA at 9b05354ec)
- Split kept at 0.53 for phase 1 (Q6_K frees ~4.7 GiB on the worker at
this split); re-maximize after measuring draft placement
- KV math: K 1088 B/token + V 2048 B/token = 784 MiB per FA layer
- FLM_MODEL=qwythos:9b, CTX 262144, turbo+asr kept
- Add FLM_CONFIG_PATH/FLM_XCLBIN_PATH: the custom tag lives in the user
registry (~/.config/flm/model_list.json) + user xclbins; without them
flm hits the unknown-tag fallback and serves llama3.2:1b silently
- Note FLM 0.9.45 -> 1.0.1 runtime upgrade (pack declares flm_version 1.0.0)
0.54 measured: weight boundary moved to 35 blocks but the KV-per-device
count (round(f x 66), independent of weight boundary) flipped to 9 FA ->
KV 9216 MiB -> OOM by ~740 MiB. The flip sits at f ~0.538, just below
the weight threshold for block 35 -> the 35-block config is unreachable.
0.53 gives 34 blocks (0-33), 8 FA, KV 8192 MiB under every rounding rule
(round/floor/ceil of 0.53x66 = 34.98 -> 34 or 35, never 36), predicted
~1.1 GiB free.
Single full-context slot instead of two half-context slots. The 3090 takes
~33 of 66 layers (up from 26): the VRAM budget frees up because the f16 KV
pool shrinks 401400 -> 262144. 33 layers is the max with a safety margin
(34 -> 244 MiB headroom, 35 -> OOM). Verified math: /tmp/vram-math.py from
live journal buffers.
Streaming requests with role=developer get HTTP 200 + error JSON as
first body; pi sees a chunkless stream. Fix: compat.supportsDeveloperRole
false on the model entry. Verified by field bisection + headless pi run.
Frank