chadrock3.6-27b-coder-rocmfp4-mtp

CHADROCK3.6 Coder ROCmFPX / ROCmFP4 MTP

This repo contains the CHADROCK3.6 Coder releases for AMD Ryzen AI Max+ 395 / Strix Halo systems:

• CHADROCK3.6-27B-Coder-MTP-ROCmFP4-STRIX_LEAN.gguf: the original dense 27B ROCmFP4/MTP Coder lane.
• CHADROCK3.6-35B-A3B-Coder-MTP-ROCmFPX-MoEQuality-7.08BPW.gguf: the additive 35B A3B MoEQuality ROCmFPX/MTP Coder lane.

The existing 27B ROCmFP4 lane is preserved. The 35B MoEQuality file is added as a second download lane for users who want the larger A3B Coder behavior with a higher-quality ROCmFPX tensor mix.

CHADROCK3.6 Coder uses Qwopus3.6 Coder lineage, then converts the source models into Charlie's AMD-focused ROCmFP4 / ROCmFPX runtime formats. The public release names and artifact names are Chadrock names, while Qwopus stays explicit in lineage, base model metadata, and credits.

The 27B file is a compact 14 GB GGUF for local agentic coding, repository work, tool-use style prompts, and long-context experiments. The 35B A3B MoEQuality file is a larger 30 GB GGUF aimed at better tool-use/coder behavior while keeping draft-MTP serving available on unified-memory AMD hardware.

These GGUFs will not run correctly with stock llama.cpp. They need a pinned ciru-ai/ROCmFPX runner because the files use ROCmFP4 / ROCmFPX tensor types that upstream llama.cpp does not currently understand.

The model file is already provided here. You do not need to rebuild or quantize the model. Build the custom llama server once, download the files, and run the profile below.

Why This Build Exists

CHADROCK3.6 27B Coder is the Strix-focused Chadrock release of a dense agentic coding model lineage. It is intended for coding, tool use, debugging, structured developer workflows, and runtime experimentation on AMD hardware. Chadrock adds the AMD runtime piece:

• ROCmFP4 Strix Lean tensor recipe
• native draft-MTP serving
• AMD ROCm/HIP backend path
• 262K context target
• q4_0 KV cache profile for long local sessions
• optional vision projector companion file

This release is best treated as a model/runtime pairing for Strix Halo rather than a generic GGUF quant.

Model Lineage

Qwen/Qwen3.6-27B
  -> Jackrong/Qwopus3.6-27B-v2
       datasets:
         - Jackrong/Claude-opus-4.6-TraceInversion-9000x
         - Jackrong/Claude-opus-4.7-TraceInversion-5000x
  -> Jackrong/Qwopus3.6-27B-Coder
       adds:
         - lambda/hermes-agent-reasoning-traces
         - agentic coding and tool-use SFT
  -> Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF
  -> jcbtc/chadrock3.6-27b-coder-rocmfp4-mtp

Qwen/Qwen3.6-35B-A3B
  -> Jackrong/Qwopus3.6-35B-A3B-Coder
  -> Jackrong/Qwopus3.6-35B-A3B-Coder-MTP-GGUF
  -> CHADROCK3.6-35B-A3B-Coder-MTP-ROCmFPX-MoEQuality-7.08BPW.gguf

In plain terms: Qwen provides the foundation models, Jackrong's Qwopus lines add Trace Inversion and coder/tool-use training, the upstream MTP GGUFs provide the MTP sources, and this release converts those lines into Strix-focused Chadrock runtime formats.

Technical Metadata

27B ROCmFP4 Lane

35B A3B ROCmFPX MoEQuality Lane

Local Benchmark Notes

All numbers below were measured locally on AMD Ryzen AI Max+ 395 / Strix Halo.

Tool Eval Full 69 - 35B A3B ROCmFPX MoEQuality

The 35B A3B MoEQuality lane was run through the local Tool Eval full 69 deterministic tool-use suite with the raw llama.cpp endpoint, temperature=0, seed=42, parallel=1, --no-think, and --structured-response-format json_object.

The run artifacts were audited for the earlier structured-output harness failure mode. No HTTP 400, sampler initialization, or backend schema-support failure signatures were found in the JSON, progress log, or generated report. The structured-output cases below are scored model behavior, not backend failures.

BigCodeBench Hard Instruct

The scored run used the local profile qwopus3.6-27b-coder-mtp-chadrock-rocmfp4-strix-lean in the June 13 full coding benchmark folder. That local profile name records source lineage and build path; the public release name is CHADROCK3.6 27B Coder.

Apples-to-Apples Q5_K_M Comparison

The cleanest decode-speed comparison is the same CHADROCK CLI guard run against the upstream Qwopus3.6 27B Coder MTP Q5_K_M GGUF and this Chadrock ROCmFP4 build, using the same prompts, runtime build, machine, and MTP guard harness.

Prompt processing is better represented by the no-cache long-context sweep below, where Chadrock ROCmFP4 measured 315.97 tok/s at 4K prompt tokens and 142.00 tok/s at 130K prompt tokens.

Long-Context Sweep

The no-cache forced context sweep generated 512 tokens at each context length:

These are local server measurements, not universal llama.cpp claims. Throughput depends heavily on driver version, clocks, prompt shape, KV cache settings, and MTP acceptance.

Best Settings / Advanced Setup

For the pinned runner build, copy-paste build commands, request-level speculative controls, and the latest Chadrock ROCmFP4 reproduction notes, use the advanced Ciru setup page:

https://llm.ciru.ai/chadrock-rocmfpx/

The current pinned runner build is:

ciru-ai/ROCmFPX commit: 7aa484a2f0a504dc612a3d74a068024f3e6d6353
historical score tag: chadrock-rocmfp4-mtp-scores-20260621

For this published CHADROCK3.6-27B-Coder GGUF, the validated card profile is:

backend: ROCm0 target + ROCm0 draft
context: 262144
batch / ubatch: 512 / 512
target KV: q4_0 / q4_0
draft KV: q4_0 / q4_0
MTP: draft-mtp, n_max=4, n_min=0, p_min=0.0, p_split=0.10
serving: one slot, metrics on, no mmap
sampler: temperature=1.0, top_p=0.95, top_k=20, reasoning off

For the added CHADROCK3.6-35B-A3B-Coder-MTP-ROCmFPX-MoEQuality-7.08BPW GGUF, the Tool Eval profile was:

backend: Vulkan0 target + Vulkan0 draft
context: 65536
batch / ubatch: 2048 / 512
target KV: q8_0 / q8_0
draft KV: f16 / f16
MTP: draft-mtp, n_max=3, n_min=0, p_min=0.25, p_split=0.10
serving: one slot, metrics on, no context shift, text-only with --no-mmproj
sampler: temperature=0, top_p=0.95, top_k=20, seed=123, reasoning off
chat template: Froggeric Qwen fixed chat template

Use the advanced page if you are testing the newer request-level ROCmFPX runner or comparing against the separate Qwable 5 27B Coder ROCmFP4 speed lane. The settings above are the best published-card settings for the actual GGUF in this repo.

Run With llama-server

27B ROCmFP4 Lane

Build Charlie's custom llama.cpp once, download this GGUF and the projector file, then run:

HSA_OVERRIDE_GFX_VERSION=11.5.1 \
GGML_HIP_ENABLE_UNIFIED_MEMORY=1 \
/path/to/rocmfp4-llama/build-strix-rocmfp4/bin/llama-server \
  -m CHADROCK3.6-27B-Coder-MTP-ROCmFP4-STRIX_LEAN.gguf \
  --mmproj mmproj-F32.mmproj \
  --alias chadrock3.6-27b-coder \
  --host 127.0.0.1 \
  --port 8080 \
  --jinja \
  -c 262144 \
  -ngl 999 \
  -fa on \
  -dev ROCm0 \
  -b 512 \
  -ub 512 \
  -t 16 \
  -tb 32 \
  -ctk q4_0 \
  -ctv q4_0 \
  --ctx-checkpoints 0 \

  --checkpoint-every-n-tokens -1 \

  --spec-type draft-mtp \
  --spec-draft-device ROCm0 \
  --spec-draft-ngl all \
  --spec-draft-type-k q4_0 \
  --spec-draft-type-v q4_0 \
  --spec-draft-n-max 4 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.0 \
  --spec-draft-p-split 0.10 \
  --parallel 1 \
  --metrics \
  --no-mmap

Use --parallel 1 for this MTP profile. Multi-slot serving changes draft-MTP behavior and is not the intended configuration.

For text-only use, you may omit --mmproj.

For vision use, keep mmproj-F32.mmproj beside the main GGUF, but run with MTP off. In practice, that means using the vision projector and removing the --spec-* draft-MTP flags from the command.

The projector is a GGUF-format projector file with a .mmproj repo extension so Hugging Face's GGUF metadata badge tracks the 27B language model rather than the smaller projector.

35B A3B ROCmFPX MoEQuality Lane

For the 35B MoEQuality file, use a ROCmFPX runner with Vulkan support and the same Froggeric Qwen fixed chat template used for the local Tool Eval run:

/path/to/rocmfpx-vulkan/bin/llama-server \
  -m CHADROCK3.6-35B-A3B-Coder-MTP-ROCmFPX-MoEQuality-7.08BPW.gguf \
  --alias chadrock3.6-35b-a3b-coder-moequality \
  --host 127.0.0.1 \
  --port 8080 \
  --jinja \
  -c 65536 \
  --reasoning off \
  --reasoning-format none \
  -sm none \
  -ngl 999 \
  -fa on \
  -b 2048 \
  -ub 512 \
  --no-context-shift \
  -dev Vulkan0 \
  --chat-template-file /path/to/froggeric-qwen-fixed-chat-template.jinja \
  -t 16 \
  -tb 32 \
  -ctk q8_0 \
  -ctv q8_0 \
  --spec-type draft-mtp \
  --spec-draft-device Vulkan0 \
  --spec-draft-ngl all \
  --spec-draft-type-k f16 \
  --spec-draft-type-v f16 \
  --spec-draft-n-max 3 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.25 \
  --spec-draft-p-split 0.10 \
  --no-spec-draft-backend-sampling \
  --parallel 1 \
  --temp 0 \
  --top-p 0.95 \
  --top-k 20 \
  --seed 123 \
  --metrics

For text-only serving, omit the projector. If you use the included mmproj-CHADROCK3.6-35B-A3B-Coder-MTP-F32.mmproj projector, validate your vision path separately and run with MTP off unless your local runner supports that combination.

Build The Required llama.cpp

git clone https://github.com/ciru-ai/ROCmFPX.git
cd ROCmFPX
git checkout 7aa484a2f0a504dc612a3d74a068024f3e6d6353
env JOBS=16 scripts/build-strix-rocmfp4-mtp.sh llama-server llama-bench

The server binary will be here:

build-strix-rocmfp4/bin/llama-server

About ROCmFP4 / Chadrock

Charlie's ROCmFP4 method adds AMD-focused GGUF tensor formats and backend paths to llama.cpp.

ROCmFP4 is not stock Q4, MXFP4, or NVFP4. It uses custom 4-bit tensor layouts, Codebook10 values, finite unsigned E4M3 scale semantics, tensor-aware Strix presets, ROCm/HIP kernels, Vulkan support, and MTP regression guards.

Why it matters: Strix Halo has a large unified-memory pool, but good local serving still depends on memory bandwidth, tensor layout, KV traffic, and draft-token acceptance. Chadrock is built for that exact hardware shape.

Files

Credits

• Qwen: Qwen/Qwen3.6-27B base model family.
• Jackrong: Qwopus3.6 v2, Qwopus3.6 27B Coder, Trace Inversion datasets, coder/tool-use SFT, and the MTP GGUF source.
• lambda: lambda/hermes-agent-reasoning-traces, included by the upstream coder release.
• charlie12345 / @Italianclownz: ROCmFP4 llama.cpp fork, Strix Halo build path, and AMD-focused MTP runtime work.

Notes

This is an experimental AMD ROCmFP4/MTP build. It is intended for local evaluation, coding workflows, and runtime experimentation on compatible AMD hardware.