- kingjones-strix-rocmfp4 reactivated as the ACTIVE large runbook:
runtime build recipe (WEBUI=OFF gotcha), deployed serving profile,
fa-on-works-unpatched evidence, MTP heads documented unloadable,
swap procedure + 2026-08-30 validation record
- agentionai-fast-imatrix marked RETIRED (rollback record kept)
- freetoken-frank-default-small: model/lineage/template sections now
Huihui abliterated FP8; new operational quirk: chat API 422 without
explicit model field
- LLM index + AGENTS fleet table/runtime sections current; both
services' history chains fixed (small was still Tiel in AGENTS.md)
- worklog entry added; models.json contextWindow for large corrected
to the real per-slot 131072 (llama clamps n_ctx_train/parallel)
FreeToken v0.1.2 serving batsclamp/Huihui-Qwen3.6-35B-A3B-abliterated-FP8 as frank-default-small on Dankserver (RTX 3090).
freetoken
dankserver
frank-default-small
qwen3.6
moe
fp8
2026-08-30
FreeToken frank-default-small Runbook
The frank-default-small service on Dankserver is served by
FreeToken v0.1.2 — an edge-native MoE serving engine that keeps
expert weights in host RAM with an LRU GPU cache. Model history on this
runtime: official Qwen/Qwen3.6-35B-A3B-FP8 (since 2026-09-02) →
batsclamp/Huihui-Qwen3.6-35B-A3B-abliterated-FP8 (2026-08-30,
same format and pool budget). The engine itself replaced the llama.cpp
Tiel-Coder-35B-A3B (UD-Q6_K_XL) deployment.
Model
Field
Value
HuggingFace
batsclamp/Huihui-Qwen3.6-35B-A3B-abliterated-FP8
Lineage
Qwen/Qwen3.6-35B-A3B → huihui-ai abliterated → this FP8 (quantizer batsclamp)
Architecture
qwen3_5_moe (Qwen3_5MoeForConditionalGeneration)
Quant
native modelopt block-fp8 e4m3, dynamic activations, 128×128 weight_block_size, bf16 weight_scale_inv — byte-format identical to the official FP8 repo
BF16 kept
lm_head, embed_tokens, all norms, router gates, mamba state params, visual encoder, MTP module
Experts
un-fused per-expert layout (mlp.experts.{0..255}.*) matching official Qwen FP8 — same FreeToken loader path
froggeric/Qwen-Fixed-Chat-Templates (fixed Qwen3.6 template, shipped in tokenizer_config.json; FreeToken reads it from the checkpoint — no override)
Important: this is the Huihui abliterated finetune (refusals
removed) — not the base Qwen weights served before 2026-08-30, and not
the earlier Tiel-Coder finetune. Expect a direct-answers assistant.
FreeToken v0.1.2 supports these safetensor quants for qwen3_5_moe:
Format
Detection
Works
BF16 (no quant config)
default
✅ (experts too large for 60 GB RAM)
modelopt block-fp8 (128×128)
quant_method: "fp8" + weight_block_size
✅ (current)
NVFP4 (modelopt)
quant_algo: "NVFP4"
✅ (best for VRAM)
NVFP4 (compressed-tensors)
4-bit float, group_size=16, strategy=tensor_group
✅
Per-tensor FP8 (modelopt)
scalar weight_scale
✅
Per-channel FP8 (compressed-tensors)
weight_scale: [O, 1]
❌ loader bug
Quark W8A8 INT8
per-channel scales
❌ loader bug
GGUF
only gemma4 arch
❌ for qwen3_5_moe
Files
File
Purpose
scripts/serve-frank-small.sh
Serve script (launches ft serve)
scripts/frank-default-small.env
Tunables (model path, pool sizes)
scripts/frank-default-small.service
Systemd unit
Limitations
Model identity: serves the Huihui abliterated FP8 finetune, not the Tiel-Coder coder finetune from the llama.cpp era.
JIT compilation: first startup compiles flashinfer/tvm-ffi kernels
(~5–15 min cold). Cached afterward in ~/.cache/flashinfer and
~/.cache/tvm-ffi.
CUDA toolchain: driver-only install (no system CUDA toolkit). The
venv provides pip-installed nvcc 13.2.86 for JIT compilation. All
nvidia-cu13 packages must be at the same version.
Env var collisions: never name tunables TEMP, HOST, or
GPU_MAX_HEAP_SIZE (HIP runtime reads these).
Operational quirks
model field is required in /v1/chat/completions bodies —
FreeToken rejects requests without it with a 422 (Field required),
unlike llama.cpp's server which defaults to the loaded model. Send
"model": "frank-default-small".
Load on this swap took well under the old llama.cpp numbers:
weights → experts (parallel build) → CUDA graph capture → Uvicorn
in ~2 minutes; the 2026-08-30 swap verified ~40 tok/s decode on a
282-token completion.