mammoth-1 — ROCmFPX GGUF

baselabs/mammoth-1, Base Labs' 27B decision model (post-trained from Qwen3.5-27B), quantized to the ROCmFPX formats for AMD GPUs. Give it a state and a set of questions; it returns a probability for every option of every question from one shared prefill.

These files run with llama-decide, a small tool in HarshaVardhan3002/ROCmFPX that reads the same request format as Base Labs' own runtime. A normal chat server is not the way to use this model.

Start with Q4_0_ROCMFP4_STRIX. It is the closest 4-bit file to the original.

These files only load in a ROCmFPX build of llama.cpp. They have not been tested on AMD hardware yet.

Not an official release of Base Labs or Baseten. All credit for the model goes to Base Labs.

Files and measured quality

Measured against the BF16 model (55 GB, perplexity 6.8738) on WikiText-2 test, 40 chunks of 512 tokens. KLD is the mean KL divergence of the next-token distribution from BF16 (lower is better). Same top is how often the quant picks the same next token as BF16. These numbers use ordinary left-to-right attention on plain text; they show how much each file changes the weights, not decision accuracy, which was not measured.

The 6-bit file is named mammoth-1-Q6_K_ROCMFPX.gguf so that Hugging Face lists it as a 6-bit quant. Its weights are the ROCmFPX Q6_0_ROCMFPX type, not a stock llama.cpp Q6_K, and it needs the same fork as the other files.

Not published: Q3_0_ROCMFPX (14.9 GB, PPL 7.0924, KLD 0.0549, same top 89.54%) is larger than both 4-bit files and further from BF16.

Decisions

The GGUF files carry the decision settings from the original checkpoint (qwen35.decision.*: block-bidirectional attention on the full-attention layers and the 256 answer labels), so llama-decide needs no extra files.

git clone https://github.com/HarshaVardhan3002/ROCmFPX && cd ROCmFPX
cmake -B build -DGGML_VULKAN=ON          # or -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1151 (gfx1100 for RX 7900)
cmake --build build --target llama-decide -j
build/bin/llama-decide -m mammoth-1-Q4_0_ROCMFP4_STRIX.gguf -ngl 999 -f request.json

request.json: a state (text or JSON) and questions, as in Base Labs' card:

{
  "state": {
    "task": "Pick up the red mug from the table and place it on the shelf.",
    "observations": ["The gripper closed around the handle of the red mug.",
                     "The arm lifted the mug 12 cm above the table.",
                     "The mug slipped and fell back onto the table, upright and intact."],
    "gripper_force_newton": 4.1
  },
  "questions": {
    "success": {"type": "noul", "instructions": "Was the task completed successfully?"},
    "failure_mode": {"type": "choice", "instructions": "What is the main reason for the outcome?",
      "criteria": {"grasp_slip": "The object slipped out of the gripper.", "collision": "The arm or the object hit something.",
                   "wrong_object": "The robot handled the wrong object.", "no_failure": "Nothing went wrong."}},
    "progress": {"type": "score", "instructions": "How far did the robot get with the task?",
      "criteria": ["did not start", "grasped the object", "lifted the object", "placed the object on the shelf"]}
  }
}

Answer from mammoth-1-Q4_0_ROCMFP4_STRIX.gguf (CPU backend): success 0.019; failure_mode grasp_slip 0.976; progress most likely "lifted the object" (0.533), then "grasped the object" (0.373).

Options: --debias N (average over N cyclic shifts of the answer labels), --causal (plain causal attention instead of the trained block-bidirectional mask). llama-decide was checked against Base Labs' PyTorch runtime on the 9B sibling elephant-1 (probabilities within 0.004); for mammoth-1 only the example above was run.

How these were made

1. convert_hf_to_gguf.py --outtype bf16 from the fork, which also writes the decision settings.
2. Importance matrix from the BF16 model on the GPU over a general calibration text (calibration_datav3), 512-token chunks.
3. llama-quantize --imatrix, one run per type (ROCmFPX fb08d7c merged onto upstream llama.cpp).
4. Quality: the BF16 reference ran on an NVIDIA GPU with stock BF16 kernels. Each quant was expanded back to F16 (llama-quantize --allow-requantize ... F16), which keeps its stored weights, and scored on the same GPU with stock F16 kernels. The fork's own CUDA kernels for these types are not correct on NVIDIA, so they were not used. As a check, this method gave KLD 0.0050 for elephant-1's Q8_0_ROCMFPX where the CPU backend gave 0.0054. AMD GPU kernels compute the same math in a different order, so results on an AMD GPU can differ slightly.

The 8-bit file is not as close to BF16 as a stock Q8_0 usually is: ROCmFPX block scales have a fixed smallest step, so 8-bit blocks of small weights keep fewer than 8 bits (ROCmFPX#118).

License

MIT, same as the base model.