---
license: apache-2.0
base_model:
- Jackrong/Qwopus3.6-27B-v2
- Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF
base_model_relation: quantized
datasets:
- Jackrong/Claude-opus-4.6-TraceInversion-9000x
- Jackrong/Claude-opus-4.7-TraceInversion-5000x
- lambda/hermes-agent-reasoning-traces
language:
- en
- zh
- es
- ru
- ja
library_name: llama.cpp
pipeline_tag: image-text-to-text
tags:
- qwopus3.6
- qwen3.6
- qwen35
- 27b
- model-size-27b
- dense
- coder
- agentic-coding
- tool-calling
- gguf
- mtp
- rocm
- rocmfp4
- chadrock
- llama.cpp
- amd
- ryzen-ai-max-395
- strix-halo
- vision
- multimodal
---

![CHADROCK3.6 27B Coder ROCmFP4 MTP](assets/chadrockcoder.png)

# CHADROCK3.6 27B Coder ROCmFP4 MTP

CHADROCK3.6 27B Coder is a Chadrock ROCmFP4/MTP GGUF release of the Qwopus3.6 27B Coder lineage, tuned for AMD Ryzen AI Max+ 395 / Strix Halo systems.

It uses the Qwopus3.6 27B Coder MTP line as upstream lineage, then converts that source into Charlie's AMD-focused ROCmFP4 Strix Lean runtime format. The public release name and artifact names are Chadrock names, while Qwopus stays explicit in lineage, base model metadata, and credits. The result is a compact 14 GB GGUF for local agentic coding, repository work, tool-use style prompts, and long-context experiments on unified-memory AMD hardware.

This GGUF will **not run correctly with stock llama.cpp**. It needs the custom [`charlie12345/rocmfp4-llama`](https://github.com/charlie12345/rocmfp4-llama) build because the file uses ROCmFP4 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

```text
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
```

In plain terms: Qwen provides the dense 27B foundation, Jackrong's Qwopus line adds Trace Inversion and coder/tool-use training, the upstream MTP GGUF provides the MTP source, and this release converts that line into a Strix-focused ROCmFP4 Chadrock format.

## Technical Metadata

| Field | Value |
| --- | --- |
| model size | `27B` dense |
| architecture | `qwen35` |
| local runtime format | ROCmFP4 Chadrock GGUF |
| direct upstream/source GGUF | `Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF` |
| upstream behavior lineage | `Jackrong/Qwopus3.6-27B-v2` plus coder SFT |
| local profile | `qwopus3.6-27b-coder-mtp-chadrock-rocmfp4-strix-lean` |
| context target | `262144` tokens |
| draft mode | `draft-mtp`, `n_max=4`, `p_split=0.10` |
| intended hardware | AMD Ryzen AI Max+ 395 / Strix Halo |

## Local Benchmark Notes

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

### BigCodeBench Hard Instruct

| Run | Result |
| --- | ---: |
| `bigcodebench-hard-instruct`, calibrated | `48/148 = 32.43% pass@1` |

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.

### MTP Decode Sanity Check

| Row | Prompt speed | Decode speed |
| --- | ---: | ---: |
| short arithmetic prompt | `72.0 tok/s` | `29.5 tok/s` |
| sustained regression-guard prompt | `87.2 tok/s` | `22.6 tok/s` |

For comparison, the same guard script on the upstream Q5_K_M MTP GGUF recorded `17.8 tok/s` short decode and `13.2 tok/s` sustained decode.

### Long-Context Sweep

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

| Prompt tokens | Prompt speed | Decode speed | Draft accepted |
| ---: | ---: | ---: | ---: |
| `4,131` | `315.97 tok/s` | `21.25 tok/s` | `314/779` |
| `8,227` | `308.66 tok/s` | `21.82 tok/s` | `329/728` |
| `16,419` | `286.62 tok/s` | `21.64 tok/s` | `344/666` |
| `32,803` | `251.76 tok/s` | `17.35 tok/s` | `335/701` |
| `65,571` | `201.49 tok/s` | `12.51 tok/s` | `329/726` |
| `130,467` | `142.00 tok/s` | `7.08 tok/s` | `305/823` |

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.

## Run With llama-server

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

```bash
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 \
  --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.

## Build The Required llama.cpp

```bash
git clone https://github.com/charlie12345/rocmfp4-llama.git
cd rocmfp4-llama
git checkout mtp-rocmfp4-strix
env JOBS=16 scripts/build-strix-rocmfp4-mtp.sh
```

The server binary will be here:

```text
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

| File | Size | SHA256 |
| --- | ---: | --- |
| `CHADROCK3.6-27B-Coder-MTP-ROCmFP4-STRIX_LEAN.gguf` | `14 GB` | `9536a6d9d56708a6b9e94cde00bde59a1788834ce58fa3b37eabfa8626e325d0` |
| `mmproj-F32.mmproj` | `889 MB` | `32f7ea0600c07272547da401d460f8abbd980f3a57b69d6df87be0e2505e0b9c` |

## Credits

- **[Qwen](https://huggingface.co/Qwen)**: `Qwen/Qwen3.6-27B` base model family.
- **[Jackrong](https://huggingface.co/Jackrong)**: Qwopus3.6 v2, Qwopus3.6 27B Coder, Trace Inversion datasets, coder/tool-use SFT, and the MTP GGUF source.
- **[lambda](https://huggingface.co/lambda)**: `lambda/hermes-agent-reasoning-traces`, included by the upstream coder release.
- **charlie12345 / [@Italianclownz](https://x.com/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.