hipfire

warpfront活跃维护

用 Rust 写的 RDNA 原生大模型推理引擎,直接跑在 AMD GPU 上,让 RDNA 显卡也能高效做 LLM 推理和量化。

RDNA-native LLM inference engine in Rust.

v0.4.4发布于 2026-10-27 07:16 UTC807star +3 / 7 天104fork同步于 2026-11-10 17:55 UTC

怎么上手

由 README 提炼,执行前请确认
curl -fsSL https://raw.githubusercontent.com/warpfront/hipfire/v0.4.5/scripts/install.sh | bash
硬件要求按 README 说明

面向 AMD GPU,优先适配 RDNA,也支持 CDNA;示例 27B 模型需 24GB 以上显存或 Strix Halo 系统,小卡可用 4B/9B;Qwen3.8-Flash 需 128GB Strix Halo 或双 R9700。

支持 Apple Silicon需要 CUDA支持 ROCm / AMD多卡 / 张量并行有 Docker 镜像
下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

面向 AMD GPU 的本地 LLM 推理引擎,用 Rust 和 HIP 编写,不依赖 Python 和 PyTorch

用 Rust 写的 RDNA 原生大模型推理引擎,直接跑在 AMD GPU 上,让 RDNA 显卡也能高效做 LLM 推理和量化。

核心能力

  • 自带 Rust 运行时、HIP 内核和 MQ3–MQ6 等量化格式
  • 提供 pull、run、chat、serve、bench、quantize 命令行工具
  • 内置 OpenAI 兼容 HTTP 服务,默认监听 127.0.0.1:11435
  • 支持投机解码、多 GPU 专家并行与张量并行
  • 附带 94 条精选模型注册表,可直接按标签拉取

容易踩的坑

需 Linux + ROCm 6 以上,RDNA4 要 ROCm 6.4+、gfx1151 要 ROCm 7.2+;首次 pull 会下载十几 GB 模型权重;Qwen 模型默认开启思考,max_tokens 偏小会返回空 content。

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v0.4.4
  1. v0.4.4hipfire 0.4.4最新正式版2026-10-27 · 2026-10-27 07:16 UTC

    hipfire v0.4.4

    Built from 943b5323da (origin/beta at the 07:00Z cutoff on 2026-10-27); the v0.4.4 tag is 75c28fc064, which only dates the CHANGELOG and sets CITATION to 0.4.4. The previous release is v0.4.3.1 (2026-10-24), which followed v0.4.3 (2026-10-24). The full change list is the v0.4.4 section of CHANGELOG.md.

    This release leads with speculative-decode speed on the 7900 XTX (two community PRs by @Ben1078), generic tensor parallelism as the default dense TP route, vision on by default with a streamed tower, and batched prefill for every LLaMA-arch model. It also lands a large Strix Halo (gfx1151) wave from @fivetide and @HUSRCF, hardens multi-slot swap (@ghazni101), and ships the TLS and CI repairs that left beta green.

    Provenance matters for several rows below. Where a row says contributor-measured, the merge gates ran the build, the CPU tests and a smoke on a different card, not the contributor's benchmark on the contributor's card; the card and fixture are named so the number can be reproduced.

    Headline numbers

    ChangeHardware and fixtureResultQuality
    gfx1100 int8-activation small-batch verify GEMV, default on (#987, @Ben1078)One 7900 XTX (hipx), qwen3.8-27b.mq4-xts, hipfire bench --spec mtp, Q8 KV, 256 tokens, committed mtpfloor prompts, fresh-process ABBA, precompiled pack. Maintainer gate (pr987/REPORT.md)Decode code-1k 104.7 -> 127.4 tok/s (1.217x), prose-1k 106.7 -> 131.1 (1.229x), code-32k 81.8 -> 95.5 (1.168x), prose-32k 51.7 -> 58.9 (1.139x); prefill equal; tau equal except prose-32k 1.38 -> 1.32. Author's runs (9K 68.5 -> 85.6, 39K 51.7 -> 61.0 tok/s) agree in directionNUMERIC, KLD-gated, not byte-identical. Standard-scoring .kldseq byte-identical to the gfx1100 pins in both arms (the route is never taken at 1023-row prefill); verify-shaped (--scored-max-batch 4) ON minus OFF: WT2 +0.000073, code24 -0.000054; serve battery 5/5 stop, text read. HIPFIRE_GFX1100_Q8X_VERIFY=0 restores the WMMA route
    gfx1100 WMMA split-K verify attention (1..=8 rows), default on (#989, @Ben1078)One 7900 XTX, same model and method. Standalone numbers are the author's (beta without #987); the stacked numbers are the maintainer gate (stacked on #987, fresh-process ABBA, MTP)Standalone: 9K 64.8 -> 69.6, 39K 51.8 -> 64.3, 101K 43.6 -> 68.5 tok/s. Stacked on #987: code 32K 95.7 -> 121.2 (1.27x), prose 32K 59.0 -> 73.3 (1.24x), 1K neutral. Kernel (4 rows, 9K/40K/100K): 194.5/777.0/2080.0 us -> 37.3/130.6/309.5 usNUMERIC, KLD-gated. Author: WT2 -0.000004, code24 +0.000225 (both inside the bar). Gate, verify-shaped ON-OFF at batch 4/8: WT2 -0.000051/+0.000593, code24 -0.000100/-0.000086, no paired CI. HIPFIRE_GFX1100_WMMA_VERIFY_ATTN=0 (or HIPFIRE_VERIFY_ATTN=0) restores the incumbent
    Dense Qwen3.5/3.6/3.8 serve --tp N loads the generic mesh executor by default (#927, HIPFIRE_DENSE_TP_ROUTE=auto)4x R9700 (hiptrx), qwen3.8-27b.mq4-xts, bench --matrix --spec off, 3 fresh processes per arm, median of the run medians, mesh vs hand route. Maintainer-measured. TP2 rows are on beta 3385df7ea5 (generic TP runs the LM head on rank 0 only; tp-followup-runs/bench-tp2/); TP4 rows are on the earlier build (generic-tp-hiptrx-runs/final-perf-tp4/, before the LM-head change)TP2 pp512 2,866.9 -> 3,293.4 (+14.9%), pp2048 2,746.1 -> 3,358.5 (+22.3%); TP2 decode ties the hand route: tg64@128 54.95 -> 54.89, tg64@4096 54.24 -> 54.19; TP4 pp512 1,919.4 -> 2,061.0 (+7.4%), tg64@128 43.96 -> 51.77 (+17.8%); short prompts are slower: pp16 496.2 -> 479.6 (-3.3%), pp32 880.7 -> 859.0 (-2.5%)Maintainer hwtest on 3385df7ea5: logits fnv64 equal to the hand route at TP2 and TP4 (tp-followup-runs/hw-new-tp{2,4}.log); serve battery and chain ran on TP2 and TP4 with the default route on the earlier build. HIPFIRE_DENSE_TP_ROUTE=hand rolls back
    **I
  2. v0.4.3.1hipfire 0.4.3.12026-10-24 · 2026-10-24 20:37 UTC
    查看更新说明

    hipfire 0.4.3.1 is a patch release on top of v0.4.3 with two fixes and one speedup.

    Fix: Qwen3.8-27B --spec mtp failed to load on v0.4.3. The load was refused with fused_rmsnorm_mq_rotate reported as outside the planned route. The typed MTP layer program uses plain RMSNorm/SwiGLU rotation, fused QKV/gate-up and residual GEMV kernels independently of the trunk's AWQ scales, and the sealed 27B native-MTP plan did not include that head closure. v0.4.3 regressed it when the MTP layer moved onto the step program (504eac3c5d); the sealed plan now includes the head closure (9113ce5f74). AR routing and the seal's rejection of unplanned kernels are unchanged. As in v0.4.2.1, MTP greedy output on the 27B can differ from plain decode at near-tied tokens (the batched verify differs from decode at the ULP level); this is not new in 0.4.3.1.

    Speed: A3B qwen3.6:35b-a3b-mq4rs decode on gfx1201 now takes the automatic PM4 replay route. The symmetric-expert A3B file used to decode on the HIP graph, because the retained-replay default admitted only .mq4r and dense Qwen3.5. It now takes the same PM4 replay default as .mq4r on an exact gfx1201 card (one GPU, no drafter). Output is bit-exact against the HIP route. Nothing to configure; replay.backend = "hip" turns it off.

    Decode tok/s, R9700 (gfx1201)HIP route (v0.4.3)PM4 replay (0.4.3.1)Change
    tg128, ctx 128157232+48%
    tg128, ctx 8K146.6217.0+48%
    1024-token reasoning generation154225.0+46%

    Measured on card B, hipfire bench --spec off --matrix --pp 128 --ctx 128,8192 --tg 128 --runs 3 --warmups 2 (the default config for both arms, the HIP arm set with replay.backend = "hip"), 3 fresh processes per arm. Greedy ids are identical between the two routes on prose, code, copy and 1024-token reasoning prompts, and the replay harness reports the logits, KV and recurrent state bit-equal. This changes the decode route only; prefill is unaffected (A3B mq4rs prefill on gfx1201 remains ~20K tok/s at 4K–8K prompts, as in v0.4.3). This does not apply to other GPUs.

    --spec mtp now also works on mq4rs: the registry entry declares the qwen3.6-35b-a3b.mtp head every other qwen3.6:35b-a3b* entry already carried, so the head is found and loads. The default stays AR (speculation.mtp=auto still resolves to AR for Qwen3.5), and an MTP-loaded request does not use PM4 replay.

    Fix: a verified-artifact cache write failure now warns once. When the cache could not be written, hipfire silently re-hashed the model on every request. It now prints one warning per process (warning: cannot write verified-artifact cache <path>: <error>; artifact verification will repeat on every load or request until it is writable). This is a follow-up to #923, which was fixed in v0.4.3.

    Internal: the railgun-cert inventory has rows for the Flash-Next gfx1201 recording predicates (HC down fused, MoE front, HC row fold, HC up v2). No runtime change.

    Validation (RC 130e3ab9a2): pre-commit-ci, the registry check and railgun-cert pass. On A3B mq4rs, the Redline PM4 route is bit-exact against the HIP route and greedy ids are identical across 3 fresh processes; tg128 is 231.4 / 232.3 / 231.9 tok/s. Qwen3.8-27B --spec mtp loads and serves. The post-land smoke passes on all 9 cells, including the 7900 XTX lanes. Flash-Next serve AR and MTP-auto transcripts are identical and greedy MTP identity passes. Strix Halo load, prefill and generate match v0.4.3.

    Released 2026-10-24.

    Install

    curl -fsSL https://hipfire.dev/install.sh | bash
    

    To pin this release and its prebuilt kernel packs:

    curl -fsSL https://hipfire.dev/install.sh | bash -s -- --tag v0.4.3.1
    

    Full notes: CHANGELOG.md.

  3. v0.4.3hipfire 0.4.32026-10-24 · 2026-10-24 05:24 UTC
    查看更新说明

    hipfire v0.4.3

    Released 2026-10-24. The previous release is v0.4.2.1 (patch release, 2026-10-14), which followed v0.4.2 (2026-10-14). The full change list is the v0.4.3 section of CHANGELOG.md.

    This release leads with prefill speed on the Radeon AI PRO R9700 for A3B (Qwen3.5/3.6-class mixture-of-experts) models, and ships the first Flash-Next sub-4-bit tiers, a large wave of community contributions, LFM2 support and the new PeaceMaker .rip / pm_loop kernel-authoring tools.

    Prefill perf comparison on Qwen3.6-35B-A3B (R9700, gfx1201)

    Prefill tok/s0.4.2 (mq4r)0.4.3 (mq4r)0.4.3 (mq4rs)Speedup
    pp5123,2923,33211,5893.5x
    pp10243,2483,60715,7184.8x
    pp40962,8863,73719,8286.9x
    pp81922,4883,61520,0358.1x
    pp163841,9573,56118,5459.5x

    The new qwen3.6:35b-a3b-mq4rs quant is where most of the gain comes from: 3.5x to 5.5x faster than the same 0.4.3 engine on the old mq4r file. The 0.4.3 engine alone is 1.0x to 1.8x on mq4r, and it removes 0.4.2's long-context falloff (0.4.2 loses 41% from pp512 to pp16384; 0.4.3 on mq4r does not fall off). Users on the old mq4r should pull mq4rs. The speedup column is 0.4.3 mq4rs over 0.4.2 mq4r.

    Fast mq4rs prefill is gfx1201 only. On other GPUs the mq4rs file needs HIPFIRE_MOE_SYM_IU4=0 (about 5x slower prefill).

    How it was measured: card B (R9700), hipfire bench --matrix --pp 512,1024,4096,8192,16384 --tg 1 --ctx 1 --runs 3 --warmups 1 --spec off, each cell the median of 9 samples from 3 fresh processes, arms interleaved in one timing hold (job j3197). "0.4.2" here means v0.4.2.1. Each version ran its default config, and the defaults differ: 0.4.2.1 uses KV q8 and a 512-row prefill chunk; 0.4.3 uses fp8 KV and an 8192-row chunk; and the symmetric IU4 MoE prefill route is only admitted on the mq4rs file. The 0.4.2 to 0.4.3 mq4r column is therefore "what a user gets from upgrading without changing the model file", not a single-variable engine A/B. The mq4rs arm used the published qwen3.6:35b-a3b-mq4rs file (sha256 8806a742d558ebe43256010096cd82cfac3a20be5218ad56a3f74267db001894, identical to the file on Hugging Face), and the mq4r arms used qwen3.6:35b-a3b-mq4r (sha256 4685c140…, matching its registry pin). Raw data: a3b-compare/raw/, report A3B-PREFILL-042-VS-043.md.

    Detail, this cycle's final lever steps on qwen3.6-35b-a3b-d53.mq4rs only (not part of the table): pp16000 (two chunks, 8192 + 7808 rows), 3 fresh processes per arm, three separate same-session A/Bs: 16,084.5 → 16,694.8 (+3.8%), 16,670.6 → 18,021.6 (+8.1%), 18,341.9 → 18,587.9 (+1.3%), +15.6% in total as the sum of the three, not a single A/B (the card runs a few percent slower on some days than others; the plan recorded about 3% between 20 and 22 October). These routes are exact-gfx1201 defaults, byte-identical to the code they replace: KLD unchanged on qwen3.6-35b-a3b-d53.mq4rs (the four-corpus KLD sequence is byte-equal to the previous build at every step, served text identical). This does not hold for the asymmetric qwen3.6:35b-a3b-mq4r file, whose prefill numerics change slightly (see Known issues). The benchmarked file uses the symmetric expert recipe (qt44 gate/up with a qt53 down projection, built with hipfire-quantize --moe-expert-down mq4g128v2-symmetric); see Known issues for what that means for the published A3B files.

    Every other number below comes from a named change-level measurement, not from a cumulative release matrix. Each row names its card, fixture and method. Numbers from different sessions are never silently chained: where a headline is the sum of several steps, the steps are listed. The A3B table above is a version-to-version comparison, not a change-level measurement, and its caveats are stated under it.

    Headline numbers

    ChangeHardware and fixtureResultQuality
    Flash-Next MQ6 INT8 prefill, now default on gfx1201One R9700, Flash-N
  4. v0.4.2.1hipfire 0.4.2.12026-10-14 · 2026-10-14 14:25 UTC
    查看更新说明

    hipfire 0.4.2.1 is a patch release on top of v0.4.2 with two fixes.

    Strix Halo NPU trunk: the built-in calibration now applies on any Halo kernel and NPU firmware. Before this release, npu_trunk=auto armed only on a machine whose kernel release, NPU firmware and NPU PCI slot matched the machine the built-in Halo calibration was measured on. Every other Halo logged npu-trunk: off (calibration key mismatch: kernel.uname_release) and served GPU-only. Now the built-in calibration applies on any kernel, firmware or PCI slot. When one of them differs, it uses a 5% safety margin: the NPU pipe must be predicted at least 5% faster than GPU-only. The load also logs one line when this happens: npu-trunk: built-in calibration measured on <kernel>/<fw>, this host <kernel>/<fw>; using it with margin 0.05. Arch, build, model, epilogue and trunk route still have to match exactly, and a user calibration file is still checked strictly. Output is exact on either route.

    Flash-Next: tool-call turns in the history replay the tokens the model emitted. This makes tool-call turns more robust when the tokens the model emitted differ from the chat template's own encoding of the same turn. Examples are a different BPE split, or spacing that the template rewrites around <tool_call>. In those cases a follow-up request used to miss its live continuation and re-prefill the whole conversation. Qwen4 now replays a cached tool-call turn as the exact body the model emitted. An edited turn misses the cache and falls back to the template render. HIPFIRE_QWEN_CACHE_TRACE=1 prints a [qwen4-session] line per request that shows what was reused.

    Changelog correction: the Flash-Next session cache's resident snapshot for deep appends past the pool budget (#847, HIPF-46) shipped in v0.4.2 but was missing from its notes. On Strix Halo it takes +512 tokens on a 256K prefix from 4.7 to 197.5 tok/s. Thanks @fivetide.

    Install

    curl -fsSL https://hipfire.dev/install.sh | bash
    

    To pin this release and its prebuilt kernel packs:

    curl -fsSL https://hipfire.dev/install.sh | bash -s -- --tag v0.4.2.1
    

    Full notes: CHANGELOG.md.

  5. v0.4.2hipfire v0.4.22026-10-14 · 2026-10-14 07:09 UTC
    查看更新说明

    hipfire v0.4.2

    Released 2026-10-14. The previous release is v0.4.1.1 (a patch release, tagged 2026-10-08), which followed v0.4.1 (2026-10-07). The full change list is the v0.4.2 section of CHANGELOG.md.

    Every number below comes from an individual change-level campaign or the NPU release gate, not from a cumulative release matrix; each row names its card, fixture and date. Synthetic pp8192 is not prompt-file prefill, and cold, first-after-ready and steady cache states differ. Multi-GPU numbers name the card count.

    Terms used in these notes

    • Flash-Next (FN): Qwen3.8-Flash-Next / Qwen4, normally shipped as gptq3 with q4 PLE where stated. Results for the MQ4-trunk candidate are reported separately.
    • 27B: Qwen3.8-27B mq4-xts, with qwen3.8-27b-dflash.mq4v2 as the draft in batching campaigns unless specified.
    • Halo is Strix Halo (gfx1151). R9700 is the Radeon AI PRO R9700 (gfx1201).
    • VMM: virtual memory management, the memory mode that batching serves use (serve.vmm_batch) to reserve lane state, checkpoints and KV space.
    • PLE: per-layer embedding, the large embedding table that Flash-Next stores as q8 or q4 sidecar files.
    • C1, C4, C8: concurrency (C) of 1, 4 and 8 simultaneous requests in a benchmark. C1 is a lone request.
    • Width (L), L8 and L16: the DFlash2 draft proposal width L, the number of tokens proposed per step. L8 is width 8 and L16 is width 16; these notes write them as "width 8" and "width 16".
    • IU4: the DFlash verify route that uses 4-bit verify activations, produced by the A4 producer and consumed by the IU4 GEMM, in place of the F16 verify.
    • AR: ordinary autoregressive decoding, with no speculation. MTP: the native multi-token-prediction speculative head. DFlash: speculative decoding with a draft model.
    • TTFT: time to first token. PM: PeaceMaker, the native kernel path. EP: the multi-GPU mode (topology.ep) in which every rank holds the trunk and an expert shard.
    • CS95: the reported uncertainty interval from predict ab for a measured change.

    Headline numbers

    ChangeHardware and fixtureResultSource
    Flash-Next 16K prefill with the NPU trunk on (v0.4.2 tag)Strix Halo + XDNA2, NPU trunk on, bounded memlock (LimitMEMLOCK=1318060032), 16,355-token prompt, client TTFT, 3 fresh processes × 3 requests2,386 tok/s (all-9 median TTFT 6,854 ms); steady requests 6,849.5 ms; greedy p16k byte-identical to the gate build; −3.4 % TTFT vs the gate build 1be80ed54, measured interleavedShipped-tip measurement (j327), 2026-10-14
    NPU trunk auto vs offStrix Halo + XDNA2, default serve config, p16k (16,355 tokens), 3 fresh processes per arm, median of per-process mediansTTFT 7,878 → 7,085 ms (−10.1 %); p56k 30,047 → 27,260 ms (−9.3 %)CHANGELOG, NPU trunk entry, 2026-10-13
    27B DFlash exact 16-row verify GEMMs (HIPFIRE_GFX1151_XLDS)Strix Halo, 27B XTS + paired DFlash draft, merge_sort_thinking_off.txt / prose_river_short.txt, 3 fresh processes per armcode 97.9 → 135.3 tok/s (+38.2 %); prose 19.0 → 26.3 tok/s (+38.4 %); AR unchangedCHANGELOG, gfx1151 XLDS entry, 2026-10-13
    Flash-Next EP2 owner-routed prefill + expert staging (opt-in EP)2× R9700, pinned Flash-Next XTS, committed prompts, 3 fresh processes per armp8k / p16k: one card 3,033 / 3,754 → EP2 3,943 / 4,308 tok/s (+30.0 % / +14.7 %)CHANGELOG, EP owner-routed prefill entry, 2026-10-13
    27B paired DFlash by defaultOne R9700, mq4-xts, singleton serve, C1 sampled, effort xhigh, 4,096-token cap, 3 fresh processes per arm44.00 → 74.49 tok/s (+69.3 %) vs the MTP auto kill-switch configurationCHANGELOG, 27B DFlash default entry, 2026-10-12
    DFlash width 8 on batching servesOne R9700, 27B mq4-xts + MQ4V2 draft, conc_steady 64 code prompts × 256, C8 steady greedy254.6 → 324.6 tok/s (+27.5 %); C1 114.8 → 107.8 (−6.1 %)CHANGELOG, `speculation.dflash_blo

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    What hipfire is

    hipfire is an inference engine for AMD GPUs. It ships its own Rust runtime, model implementations, quantization formats (MQ3–MQ6, MQ4R, MFP4), typed kernel dispatch and HIP kernels. ROCm is loaded dynamically. There is no Python, PyTorch, CUDA translation layer or third-party inference engine in the hot path.

    You get a curated model registry, a CLI (pull, run, chat, serve, bench, quantize) and an OpenAI-compatible HTTP daemon. Speculative decoding (DFlash draft models, native MTP heads), multi-GPU expert and tensor parallelism and the Redline replay path ship with the engine.

    Quickstart

    hipfire pull qwen3.8:27b-mq4-xts
    hipfire serve qwen3.8:27b-mq4-xts -d
    hipfire chat qwen3.8:27b-mq4-xts
    

    This downloads about 15 GB and needs a 24 GB+ card or a Strix Halo system. On smaller cards, use qwen3.5:4b or qwen3.5:9b with the same commands. Pick a model for your GPU lists recommendations for each GPU tier.

    For one-shot inference:

    hipfire run qwen3.8:27b-mq4-xts "What is the capital of France?"
    

    Qwen3.8-Flash (qwen3.8:flash-next) is a MoE model. The tag resolves to the split base qwen3.8-flash-next-base.mq4-xts (about 70.9 GB), plus a shared per-token-embedding (PLE) sidecar (29.1 GB for q4 rows, 54.4 GB for q8 rows) and, on gfx1201, a 213 KB expert hot-set file. The old 125 GB monolith (qwen3.8-flash-next.mq4-xts, formerly qwen3.8-flash-next-gptq3.mq4) stays published for existing clients:

    hipfire pull qwen3.8:flash-next
    hipfire serve qwen3.8:flash-next -d
    

    A 32 GB card alone is not enough for Qwen3.8-Flash. It needs a 128 GB Strix Halo system, or a discrete card with enough host RAM for the mapped experts (the 0.4.4 release smoke ran it on an R9700 and on a 7900 XTX), or two R9700s (EP2). Native context is 262K tokens, subject to available memory.

    Image generation (RDNA3/3.5 measured):

    hipfire pull flux.schnell:1
    hipfire img --out x.png flux.schnell:1 "a red cube on a wooden table"
    

    The daemon serves an OpenAI-compatible API on 127.0.0.1:11435. It listens on loopback only unless you set serve.host.

    curl -s http://127.0.0.1:11435/v1/chat/completions \
      -H "Content-Type: application/json" \
      -d '{"model": "qwen3.8:27b-mq4-xts",
           "messages": [{"role": "user", "content": "What is 2+2?"}],
           "max_tokens": 256,
           "chat_template_kwargs": {"enable_thinking": false}}'
    

    Qwen models think by default, and max_tokens counts the <think> span as well as the answer. If thinking is on and the cap is small, content can come back empty with finish_reason: "length". Turn thinking off as shown above, or raise max_tokens. Qwen3.8 and Ornith 1.5 default to medium reasoning effort. See docs/SERVE.md.

    What's new in 0.4.4

    Every figure in this section comes from the v0.4.4 release notes and the CHANGELOG 0.4.4 entry. Each is a measurement on one named fixture and card, not a general throughput claim. Rows marked contributor-measured were not re-run by the maintainers on the contributor's card; the merge gates ran the build, the CPU tests and a smoke on a different card. The CHANGELOG entry has the fixtures, methods, kill switches and upgrade notes.

    • 7900 XTX (gfx1100) speculative decode is faster (two PRs and a draft change by @Ben1078, default on for exact gfx1100, all NUMERIC, not byte-identical). On one 7900 XTX, qwen3.8-27b.mq4-xts, hipfire bench --spec mtp, Q8 KV, 256 tokens, fresh-process ABBA:
      • #987, an int8-activation GEMV for 2..=5-row verify (maintainer gate): decode code-1k 104.7 to 127.4 tok/s (1.217x), prose-1k 106.7 to 131.1 (1.229x), code-32k 81.8 to 95.5 (1.168x), prose-32k 51.7 to 58.9 (1.139x). Off: HIPFIRE_GFX1100_Q8X_VERIFY=0.
      • #989, a WMMA split-K verify attention (standalone figures are the author's; stacked figures are the maintainer gate): stacked on #987, code 32K 95.7 to 121.2 tok/s (1.27x) and prose 32K 59.0 to 73.3 (1.24x), 1K neutral. Off: HIPFIRE_GFX1100_WMMA_VERIFY_ATTN=0.
      • #998, an MTP draft over a 65,536-token vocabulary subset: a further 1.074x to 1.094x decode at 1K and 32K stacked on the other two, measured on the 27B at up to 39K context only. Greedy MTP text matches beta on 3 of 4 mtpfloor prompts. Off: HIPFIRE_GFX1100_DRAFT_VOCAB=0.
    • Dense serve --tp N loads the generic mesh executor by default (Qwen3.5/3.6/3.8 dense, #927; HIPFIRE_DENSE_TP_ROUTE=hand restores the hand route). It runs the LM head on rank 0 only, as the hand route does. Maintainer-measured on 4x R9700, qwen3.8-27b.mq4-xts, bench --matrix --spec off, 3 fresh processes per arm, mesh vs hand route. TP2 (2026-10-26, beta 3385df7ea5): pp512 2,866.9 to 3,293.4 tok/s (+14.9%), pp2048 2,746.1 to 3,358.5 (+22.3%), and decode matches the hand route (54.89 vs 54.95 tok/s at 128 context, 54.19 vs 54.24 at 4K). TP4 (2026-10-26, the #927 pre-land build, before the rank-0 LM head): pp512 1,919.4 to 2,061.0 (+7.4%), pp2048 1,997.4 to 2,113.4 (+5.8%), decode 43.96 to 51.77 tok/s (+17.8%) at 128 context. TP2 prompts of 16 and 32 tokens prefill 2.5% to 3.3% slower than on the hand route (pp16 479.6 vs 496.2 tok/s). speculation.mtp = on and uneven TP3/TP5 splits still take the hand route.
    • Vision is on by default with a streamed tower. vision_mode now defaults to auto: a present vision sidecar is loaded and the Qwen3.5/3.8-VL tower streams from host per block, so a vision load costs about 128-142 MiB of idle VRAM instead of about 0.94 GiB (vision_mode=resident keeps the whole-tower upload; hipfire config set vision_mode off restores the text-only load). Image turns prefill in batched chunks: on the R9700 (qwen3.8-27b.mq4-xts + vision, 1024x1024, HTTP TTFT, greedy) TTFT goes from 37.3 s to 0.51 s. Streamed-tower TTFT is 0.81 s on the 7900 XTX and 1.84 s on Strix Halo. Batched image prefill is numeric; the tower GEMM is bit-identical and the streamed embeddings are byte-identical to the resident path on gfx1201.
    • LLaMA-arch models prefill in batched chunks (LLaMA, Mistral, SmolLM2, #982), numeric rather than byte-identical (HIPFIRE_PREFILL_BATCHED=0 restores per-token). Maintainer gate: SmolLM2-360M mq4v1 on gfx1201, 148 to 3,705 tok/s at 1,169 tokens; Llama-3.2-1B HFQ4G256 on a 7900 XTX (gfx1100), 463 to 8,130 tok/s. A head_dim-64 Q8 flash decode tile (#978, also numeric) removes the decode fall-off with context for SmolLM2 and Llama-3.2-1B. MQ4G256V2 (.mq4) LLaMA-arch files still prefill per token.
    • Strix Halo (gfx1151) wave (@fivetide, @HUSRCF). Contributor-measured on Strix Halo: Qwen3-8B (qwen3-8b.mq4, 7,741-token prompt) DFlash prefill 538 s to 13.1 s and decode 7.4 to 20.8 tok/s (#958); 9B DFlash 2K 45.7 to 59.6 tok/s and 4K 36.0 to 56.5, byte-identical to the previous build (#961, #962, shared box, indicative). Flash-Next prefill gains (persistent HC-up v2, fused HC-down, one-pass MoE front) are byte-identical by GPU oracle, default on, with kill switches in the CHANGELOG. Qwen3-8B DFlash stays slower than AR at tau 0.2-0.8, so AR remains the faster choice there. A Flash-Next reload is no longer refused for RAM left in the TTM page pool, and hipfire pull no longer downloads the 305.5 MB trunk overlay on a host that will not apply it.
    • Flash-Next on the R9700: decode-share is on by default (admitted loads only; byte-identical; HIPFIRE_QWEN4_DECODE_SHARE=off disables it). One R9700, 3 rounds of fresh processes per arm: MTP decode 61.82 vs 51.14 tok/s with it off (+20.9%), pp16384 6,677.5 vs 6,686.7 (-0.1%). The second token after a 16K prompt takes 78.7 ms instead of 22.7 ms. The 0.4.3 Flash-Next defaults (16,384-row chunk, hot set) are unchanged. On one R9700 (split base, 3 fresh processes per arm, 2026-10-26) the hot set makes --spec auto decode on real text 34% to 50% faster than HIPFIRE_QWEN4_EXPERT_HOTSET=0 (prose 49.7 vs 37.2 tok/s, code 80.6 vs 55.2 and 78.6 vs 52.4) at equal pp16384 (6,648 vs 6,646 tok/s); it costs 4.2% at pp512 and 4.8% on synthetic random-id tg128. Against HIPFIRE_PREFILL_CHUNK_ROWS=4096, the 16,384-row chunk is 25.7% faster at pp16384 (6,648 vs 5,288 tok/s) and 1.9% to 3.7% slower on real-text --spec auto decode, so a 4,096-row chunk only helps decode-bound workloads with short prompts.
    • Long-context DFlash on the R9700: the native-fp8 split-KV verifier is default on for exact gfx1201 (#921, #922, @paleluna82-del; 27B-class H24/KV4/D256, fp8 KV, live context at or above 8,192, at most 16 verify rows; HIPFIRE_GFX12_FA2_SPLIT_VERIFY_FP8=0 turns it off). Maintainer-measured on one R9700, 27B mq4-xts with the registry DFlash draft, median over 3 fresh processes per arm: decode 16K 53.30 to 59.60 tok/s (+11.8%), 32K 40.40 to 51.40 (+27.2%), 64K 29.93 to 43.37 (+44.9%), 128K 18.93 to 33.70 (+78.0%); 4K is unchanged within noise. NUMERIC, not byte-identical (coherent output).

    Upgrade notes: greedy text can differ from 0.4.3.1 at near-ties because of the numeric changes above. Registry sampling for the Qwen3.5 and Qwen3.6-35B-A3B tags now defaults to presence_penalty 0.0 (was 1.5). The rest of the upgrade notes and known issues are in the CHANGELOG.

    Measured performance (v0.4.4)

    Each row is one measurement on the named date, fixture, card and build, in the claim language of BENCHMARKS.md. None is a speed floor, a product admission or a guarantee for other prompts, contexts or hosts. Decode is tok/s per request; prefill is prompt tok/s. The source in each row has the method; the CHANGELOG has the history.

    CardModel and routeFixture and methodResultDate, buildSource
    R9700qwen3.8-27b.mq4-xts: AR (--spec off), native MTP head (--spec mtp), registry DFlash draft (--spec dflash)committed prompts humaneval_0_has_close_elements.txt (code, 134 tokens) and fiction_lighthouse.txt (prose, 44 tokens), bench --runs 5 --warmups 3 --backend noslots --workload stateless, 128 tokens, 3 fresh processes x 5 runs (median of 15)decode AR 41.2 (code and prose); DFlash 313.6 (code), 63.4 (prose); MTP 95.0 (code), 55.5 (prose)2026-10-27, published v0.4.4 gfx1201 binary archive (tag 75c28fc064)v0.4.4 release-binary bench
    R9700qwen3.8-27b.mq4-xts, AR, fp8 KVbench --matrix --spec off --pp 512,2048,16384, 3 fresh processes x 5 runsprefill 4,936 (pp512), 5,278 (pp2048), 4,888 (pp16384)2026-10-27, published v0.4.4 gfx1201 binary archivev0.4.4 release-binary bench
    R9700qwen3.8-27b.mq4-xts + registry DFlash draft, fp8 KV, native-fp8 split-KV verifier (default)serve battery long turns, 1,024 max tokens, 3 fresh processes per armdecode 59.60 (16K), 51.40 (32K), 43.37 (64K), 33.70 (128K)2026-10-26, 0.4.4 cycle betaCHANGELOG 0.4.4 (#921, #922)
    7900 XTXqwen3.8-27b.mq4-xts + native MTP, Q8 KV (#987 + #989 + #998)committed mtpfloor prompts, bench --spec mtp, 256 tokens, fresh-process ABBAdecode 136.5-136.8 (code 1K), 141.1 (prose 1K), 129.5-129.9 (code 32K), 79.7-80.1 (prose 32K)2026-10-26, beta 085dd189b5 + #998#998 merge gate (speedups in release notes 0.4.4)
    Strix Haloqwen3.8-27b.mq4-xts + paired DFlash draftcommitted merge_sort_thinking_off code prompt, bench, 256 tokens, 3 fresh processesdecode 135.32026-10-13, v0.4.2 (not re-measured on 0.4.4)CHANGELOG 0.4.2
    R9700qwen3.8-flash-next-gptq3.mq4 (monolith, q4 PLE), native MTP, decode-share11-prompt MTP suite and bench --matrix, 3 rounds of fresh processesdecode 61.82 (MTP suite); pp16384 6,677.52026-10-27, v0.4.4 RC2 (125b2b5ca9)release notes 0.4.4
    R9700qwen3.8-flash-next-base.mq4-xts (split base, the qwen3.8:flash-next pull), hot set, q4 PLE rows: AR (--spec off) and native MTP (--spec mtp, which runs MTP + n-gram)committed prompts humaneval_0_has_close_elements.txt (code) and fiction_lighthouse.txt (prose), bench --runs 5 --warmups 3, 640 tokens, 3 fresh processes x 5 runs; pp16384 from bench --matrix --spec offdecode AR 49.7 (code), 45.6 (prose); MTP 82.9 (code), 48.5 (prose); prefill 6,647.8 (pp16384)2026-10-27, published v0.4.4 gfx1201 binary archivev0.4.4 release-binary bench
    Strix Halo + XDNA2qwen3.8-flash-next-gptq3.mq4 (monolith, q4 PLE, trunk overlay, NPU trunk auto)16,355-token prompt, cold serve TTFT, 3 fresh processes x 3 requestsprefill 2,472.7 (TTFT 6.61 s)2026-10-27, v0.4.4 release head 943b5323dav0.4.4 Halo 16K release gate
    R9700qwen3.6:35b-a3b-mq4rs, ARbench --matrix --spec off --pp 512,4096,16384 --tg 128 --ctx 128, 3 fresh processes x 5 runsprefill 11,788 (pp512), 19,867 (pp4096), 18,567 (pp16384); decode 242.2 (tg128 at 128 context)2026-10-27, published v0.4.4 gfx1201 binary archivev0.4.4 release-binary bench
    2x / 4x R9700qwen3.8-27b.mq4-xts, dense TP on the mesh routebench --matrix --spec off, 3 fresh processesTP2 pp2048 3,358.5, decode 54.89; TP4 pp2048 2,113.4, decode 51.77 (128 context)2026-10-26; TP2 beta 3385df7ea5, TP4 the #927 pre-land buildrelease notes 0.4.4, multi-gpu.md

    qwen3.6:35b-a3b-mq4rs loads on gfx1201 only; see MODELS.md. Flash-Next on a 24 GB card (7900 XTX) runs with host-mapped experts, so its speed depends on the host link; no v0.4.4 measurement of it is listed here. Earlier releases, including the 0.4.2 expert parallelism (EP2 to EP8), the Strix Halo NPU prefill route, engine-level YaRN and the 0.4.3 mq4rs quant, are described in the CHANGELOG.

    BENCHMARKS.md explains fixture identity and the requirements for admitting a measurement. Its older tables are historical, not current product baselines.

    Models

    The bundled registry (registry/v1.json) contains 94 curated entries (models, quant variants and draft sidecars) and 85 aliases. Run hipfire list -r for the live list.

    FamilyPull tags
    Qwen 3.8 denseqwen3.8:27b (MQ4V2 default), qwen3.8:27b-mq4-xts (flagship), -mq4-xt, -mq4-pro; MQ3, MQ5 and MQ6 -xt / base / -pro tiers; drafts qwen3.8:27b-draft-mq3 … -mq6
    Qwen 3.8 Flashqwen3.8:flash-next (alias qwen3.8:flash; MQ4 XTS split base), -mq3-xts, -mq2-xts, -mq2-xts-4500
    Qwen 3.6 35B-A3Bqwen3.6:35b-a3b (MQ4P default), -mq2, -mq3p, -mq4p, -mfp4, -mq4r, -mq4rs (symmetric experts, gfx1201 fast prefill), -mq5, -mq6
    Qwen 3.6 denseqwen3.6:27b, qwen3.6:27b-mq3, drafts qwen3.6:27b-draft, -draft-mq3
    Qwen 3.5 denseqwen3.5:0.8b, 2b, 4b, 9b, 27b, with -mq3 / -mq6 variants and 9b / 27b drafts
    Qwen 3.5 MoEqwen3.5:35b-a3b
    Qwen3qwen3:0.6b, qwen3:8b
    Muse Glimmermuse-glimmer, muse-glimmer:fast (MQ4R), muse-glimmer:draft
    Ornith 1.5ornith-1.5:35b-a3b, ornith-1.5:fast (MQ4R)
    DeepSeek V4 Flashdeepseek-v4-flash
    MiniMax-M2.7minimax-m2.7
    North-Mini-Code-1.0north-mini-code
    Carnice (Hermes tool calls)carnice:9b, carnice:27b, -mq6 variants
    Qwopusqwopus:4b, 9b, 27b, -mq6 variants, qwopus3.6:27b-coder
    LFM2.5lfm2.5:350m, 1.2b, 1.2b-thinking, 8b-a1b
    NEX N2 Mininex-n2:mini
    VibeThinkervibethinker:3b, vibethinker:3b-mq6
    FLUX (image)flux.schnell:1 and others in IMAGEGEN.md

    Curated weights are published under huggingface.co/hipfire-models. docs/MODELS.md covers sizes, minimum VRAM, sampling defaults, sidecars and provenance. To bring your own model, use hipfire quantize.

    Qwen 3.8 Flash Next split-PLE tiers (0.4.3)

    The hipfire-models/qwen3.8-flash-next repository publishes three plain split-PLE trunk files at its root, next to the shared PLE sidecar. The sizes below are file sizes in bytes, not VRAM or peak-memory requirements. Publishing a file is not a claim that every GPU route or speed has been measured on it. The published model card records the receipt-backed measurements and their acceptance scope.

    TierFile (HF link)BytesSHA-256
    MQ3qwen3.8-flash-next-base.mq3-xts59109362200d35896ca69b87d3e93176847a036db3e2cb1554931f130a842b13718b486238b
    MQ2 (6,306 hot)qwen3.8-flash-next-base.mq2-xts46895167000e2ba747485190da92cd7a36d3f56809e6db31a3ec328f5ab23e000275d798e57
    MQ2 (4,500 hot)qwen3.8-flash-next-base.mq2-xts-4500445372534009087d7d8f67629a3256c26bfeb705e7ed22dd1622bb91e074035543d6caea5c2
    Shared PLE sidecar (Q4)qwen3.8-flash-next.ple-q429120146432fc78d30b9d2376db2b713732e80de2069f1cd1d6e1e40b50c716927dcc18ee1e

    Trunk plus the Q4 sidecar totals 88,229,508,632 (MQ3), 76,015,313,432 (MQ2 6,306) and 73,657,399,832 (MQ2 4,500) bytes on disk. The MQ2 tiers need hipfire at or after ea2abd111f06339e9f25ac86715b7d210d0c5ae8; the MQ3 tier needs ca0aee9c925b4180651b194b440bcda80f656ac5.

    MQ2 KLD on an RX 7900 XTX (gfx1100), post-land. Mean KLD against the FP8 reference, hipfire ea2abd111f06339e9f25ac86715b7d210d0c5ae8, with the shipping MQ2 hashes above. WikiText-2 (wt2): 32 chunks, 8160 scored rows; code24: 24 chunks, 6120 scored rows. Pre-land references describe earlier d2 predecessor bytes, not fresh measurements of the published roots; decode rows are paired against the weight-only reference and prefill rows against the prefill reference. The pre-land decode references (MQ2 6,306: 0.1851 wt2 / 0.1981 code24; MQ2 4,500: 0.2078 / 0.2077) are weight-only model KLD, not GPU route measurements; the XTX columns are GPU route measurements.

    TierCorpusRoutePre-land referenceXTX post-landPaired Δ (95% CI)Relative ΔStatus
    MQ2 6,306wt2decode0.18510.1966+0.0115 (+0.0075, +0.0155)+6.23%accepted by Kaden exact-row exception
    MQ2 6,306code24decode0.19810.2083+0.0103 (+0.0018, +0.0160)+5.18%accepted, relative budget
    MQ2 6,306wt2prefill0.20950.2106+0.0011 (−0.0058, +0.0080)+0.55%accepted, not significant
    MQ2 6,306code24prefill0.21110.2112+0.0001 (−0.0059, +0.0068)+0.05%accepted, not significant
    MQ2 4,500wt2decode0.2078not re-measured (identity + G2 pass)——not re-measured (identity + G2 pass)
    MQ2 4,500code24decode0.20770.2192+0.0116 (+0.0053, +0.0179)+5.56%accepted, relative budget
    MQ2 4,500wt2prefill0.22740.2291+0.0017 (−0.0055, +0.0091)+0.76%accepted, not significant
    MQ2 4,500code24prefill0.2237not re-measured (identity + G2 pass)——not re-measured (identity + G2 pass)

    Six of the eight cells were measured on the XTX. The MQ2 6,306 wt2 decode row (0.1966, +6.23%) exceeds the 6% relative budget and is accepted only as an explicit exact-row exception by Kaden; it is not a budget pass. The two remaining MQ2 4,500 cells were not re-measured. Product identity compared the builds on earlier d2 bytes (32 identical greedy token ids); G2 AR-lane parity passed on the published root hashes. Neither is a KLD measurement. This is not an all-eight-measured result. MQ3 XTX evidence is refusal-only; no XTX KLD or speed measurement is claimed.

    GPU support

    FamilyArchitecturesNotes
    Vega / CDNAgfx906, gfx908, gfx940–gfx942Wave64 HIP; gfx906 dp4a MMQ prefill; some formats use a per-token GEMV fallback
    RDNA1gfx1010–gfx1013Portable HIP and Redline dispatch; MQ6/HFQ6 GEMV admitted in 0.4.4 (#478; resolve-tested on CPU, not on RDNA1 hardware)
    RDNA2gfx1030–gfx1032Portable HIP and Redline dispatch; MQ6/HFQ6 GEMV admitted in 0.4.4 (#478; resolve-tested on CPU, so the load still warns "UNVALIDATED on RDNA2")
    RDNA3gfx1100–gfx1103WMMA kernels, validated MQ4R Redline route; gfx1100 int8 MTP verify GEMV, WMMA verify attention and MTP draft vocabulary (default on)
    RDNA3.5gfx1150–gfx1152WMMA kernels; Strix Halo (gfx1151) XDNA2 NPU prefill route
    RDNA4gfx1200, gfx1201WMMA kernels, retained-PM4 Redline route, native-fp8 split-KV DFlash verify, opt-in EP2-EP8 expert parallelism, dense TP2/TP4

    Kernels are chosen through typed per-architecture dispatch tables. A specialization that is not available falls back to the portable or architecture fallback kernel. It is never borrowed from a neighbouring GPU family. Support for a GPU family does not mean every optimized route is admitted on it.

    Redline

    Redline is hipfire's in-tree dispatch and retained-replay layer. It records the actual kernel graph, derives resource dependencies, retains invariant command state, and lowers validated paths through public ROCr queue interfaces. If a graph is unsupported, shadow validation fails, the ABI does not match, a queue faults or the model changes, Redline falls back to ordinary HIP dispatch.

    The Golden Redline guide reproduces the sealed MQ4R fixture (python3 -m tools.redline golden). Historical MQ4R measurements are in the gfx1201 campaign report. For the integration boundary, see HIPFIRE-GRAFT.md.

    PeaceMaker

    PeaceMaker is hipfire's own kernel toolchain. It builds AMD GPU and XDNA2 NPU programs directly, without hipcc. It works on typed machine code, and it can lift existing code objects so they can be checked against what PeaceMaker emits. It has six crates:

    CrateRole
    peacemaker-irTyped RDNA machine-code representation and instruction tables
    peacemaker-liftLifter for ELF, offload bundles, descriptors and metadata. Decoded kernels are re-encoded from typed fields and compared word for word
    peacemaker-isaKernel builder and emitter (peacemaker-isa binary), with region import, wait-ledger checks and certification
    peacemaker-authorPM kernel language (milestone M0, experimental, build-time only)
    peacemaker-ripStandalone .rip front end that lowers Rust-shaped kernel scripts onto the builder, without rustc
    peacemaker-npuXDNA2 / AIE2P program builder: encoder/scheduler, CDO/PDI and DPU transaction writers, CPU simulator

    Since 0.4.2, more production routes run builder-emitted, M7-certified PeaceMaker kernels. These ship as embedded kernels/*.hxaco modules with shape contracts. The hipcc versions of those kernels are kept only as oracle twins for exactness tests, not as runtime fallbacks. Examples from the CHANGELOG:

    • sampled DFlash device acceptance on gfx1201
    • CPU-AR sampled target rows and ordered acceptance on gfx1151 and gfx1201
    • Qwen3.8-Flash EP owner assignment on gfx1201
    • the gfx1151 MTP prompt-fill projections

    The Strix Halo NPU prefill route builds its programs with peacemaker-npu. The offline railgun-cert recording-inventory gate keeps the list of recording and capture predicates in sync with the source tree. A kernel route with a certified PeaceMaker kernel is still subject to hipfire's normal admission and validation gates.

    PeaceMaker is also published as a standalone repository, github.com/warpfront/peacemaker. scripts/mirror-push.sh peacemaker builds a history-preserving split of the PeaceMaker crates and their path dependencies. It then checks that the split builds and tests on its own, checks author identities and runs the publication guard on every commit. Only then does it push to main. Like hipfire, PeaceMaker is Apache-2.0. Some files remain MIT under their per-file SPDX header, and the mirror's LICENSE adds the LLVM exception notice (see scripts/mirror_split.py).

    Install

    Linux with ROCm 6 or newer:

    curl -fsSL https://raw.githubusercontent.com/warpfront/hipfire/v0.4.5/scripts/install.sh | bash
    
    # Or install the integration branch for testing:
    curl -fsSL https://raw.githubusercontent.com/warpfront/hipfire/v0.4.5/scripts/install.sh \
      | bash -s -- --branch beta
    

    RDNA4 requires ROCm 6.4 or newer, and gfx1151 requires ROCm 7.2 or newer. Release-tag installs download a verified prebuilt kernel pack for the detected arch when one is available. Otherwise they build kernels locally with hipcc. See Prebuilt kernel packs.

    Before the first pull, hipfire doctor checks the driver and ROCm install, and hipfire fit <model> --ctx N says whether that model loads at that context on this machine, what the load would choose, and what to change if it does not.

    hipfire version compares the installed binary, the managed source checkout and the daemon. To switch revisions, use hipfire update @beta, hipfire update --tag <tag> or hipfire update --commit <sha>. To uninstall while keeping models and settings:

    curl -fsSL https://raw.githubusercontent.com/warpfront/hipfire/v0.4.5/scripts/uninstall.sh | bash
    

    --dry-run previews the uninstall. --purge also deletes ~/.hipfire and asks for confirmation first.

    Native Windows and WSL2 are untested on GPU hardware; install notes, limits, and how to help test (scripts/windows-check.ps1) are in docs/GETTING_STARTED.md. NixOS has a flake and a module (docs/NIXOS.md):

    nix develop github:warpfront/hipfire  # dev shell with Rust + ROCm
    nix build github:warpfront/hipfire    # build package
    

    Containers (docs/CONTAINER.md):

    docker compose up -d      # or: podman compose up -d
    curl http://127.0.0.1:11435/v1/models
    

    The image is ghcr.io/warpfront/hipfire:latest (docker pull ghcr.io/warpfront/hipfire:0.4.5); HIPFIRE_IMAGE=ghcr.io/warpfront/hipfire:0.4.5 pins compose to a release.

    Deprecated features

    PFlash prefill compression, CASK / TriAttention KV eviction, Givens/asymmetric KV modes and the legacy DFlash knobs have been deprecated since 0.4.0. They are unsupported and will be removed in 0.5.0. See configuration for supported settings and validation for the current gates.

    Documentation

    PageTopic
    GETTING_STARTED.mdInstall, first run, what to read next
    PICK-A-MODEL.mdModel recommendations by GPU tier
    CLI.mdEvery subcommand, flags, file locations
    MODELS.mdCurated tags, BYO models, file extensions
    QUANTIZE.mdhipfire quantize for HF / safetensors
    CONFIG.mdEvery config key and env override
    SERVE.mdOpenAI-compatible HTTP API
    multi-gpu.mdEP, TP and pipeline parallelism; budgets and refusals
    IMAGEGEN.mdFLUX image generation
    ARCHITECTURE.mdEngine layout and dispatch
    QUANTIZATION.mdMQ formats, KV cache modes, FWHT
    BENCHMARKS.mdAdmitted measurements and claim requirements
    VALIDATION.mdCorrectness and speed gates
    methodology/perf-benchmarking.mdBenchmark protocol
    peacemaker-isa map / peacemaker-author mapPeaceMaker builder and kernel language
    npu/README.md / peacemaker-npu mapXDNA2 NPU builder, simulator and tools
    NIXOS.md / CONTAINER.mdNixOS and container builds

    Contributing

    See CONTRIBUTING.md, including the release cadence and PR cutoff. Install local hooks with ./scripts/install-hooks.sh. ./scripts/no-gpu-ci.sh runs the no-GPU CI subset, but it does not replace the hardware gates. No single gate establishes correctness on its own. Choose the route your change needs from docs/VALIDATION.md:

    • scripts/serve_harness.py for generation and state-lifecycle changes.
    • scripts/redline_daemon_harness.py for kernel, dispatch, graph or replay changes.

    Do not bypass hooks with --no-verify.

    Discord: https://discord.gg/F3BaywB8Rs

    Acknowledgements

    hipfire's gfx906 MMQ prefill path follows the design of the MMQ kernels in upstream llama.cpp. The community-maintained gfx906 forks of llama.cpp also informed that work. CREDITS.md lists contributors.

    License

    hipfire is licensed under Apache-2.0 as of v0.3.0. See LICENSE, LICENSE-APACHE and NOTICE. Releases up to and including v0.2.1 were dual MIT/Apache-2.0, and that grant is not revoked. Files whose authors have not elected Apache-2.0 remain MIT (LICENSE-MIT) and say so in their SPDX-License-Identifier. The decision record is docs/governance/relicense-2026-05.md. Architectural work that originated in hipfire is catalogued in PRIOR-ART.md. Derivative works should attribute it as described in AGENTS.md.