Skip to content

Research: large-model background offloading on the RX 6700 XT (AirLLM eval + V620 sim)#6

Draft
marchah wants to merge 2 commits into
mainfrom
research/6700xt-background-offload
Draft

Research: large-model background offloading on the RX 6700 XT (AirLLM eval + V620 sim)#6
marchah wants to merge 2 commits into
mainfrom
research/6700xt-background-offload

Conversation

@marchah

@marchah marchah commented Jun 29, 2026

Copy link
Copy Markdown
Owner

What

Draft / research-only. Adds rx-6700-xt/BACKGROUND-OFFLOAD-FINDINGS.md capturing the evaluation of running models bigger than VRAM on the retired RX 6700 XT as a future dedicated background-task card. No scripts or runtime config changed — doc only.

Findings

  • AirLLM rejected for this hardware: PyTorch-only (CUDA/ROCm — no Vulkan; the PyTorch-Vulkan backend is a deprecated mobile path that can't run transformers), so on AMD it needs the finicky ROCm-in-a-VM route, and it's sub-1 tok/s (re-reads every layer from disk per token, unconditionally).
  • llama.cpp --n-cpu-moe + mmap is the path — same trick, done better, on the Vulkan stack already in use (works on gfx1031). Streams only active experts for MoE; only touches disk for genuine VRAM+RAM overflow.
  • Simulated a 12 GiB / 10 GiB 6700 XT on the V620 (no hardware install) running the existing Qwen3.6-35B-A3B Q5 with --n-cpu-moe 24 (~11.8 GiB VRAM) + a 10 GiB RAM cap: ~14–22 tok/s decode (vs ~53 full-VRAM). Read as an optimistic upper bound — the V620 is a stronger GPU on faster PCIe, and this is a favorable 3B-active MoE (big-active MoE / dense models will be much slower).
  • Offloading does not affect accuracy — it's a placement (speed) decision, not a math one; quantization is the independent quality lever.

Status / next steps

Parked until the card is physically installed and there's a concrete large-model background workload. Next steps (install + render-node split, pick MoE model, new rx-6700-xt/create-lxc-llamacpp-<model>.sh, benchmark) are listed in the doc.

The V620-simulation test was fully reversible; CT 120 (the V620 llama-server LLM runtime — not Hermes, which is a separate agent container that consumes its API) was restored to its normal config (ctx 262144 / parallel 4 / ~30 GiB VRAM) and verified healthy.

🤖 Generated with Claude Code

marchah and others added 2 commits June 29, 2026 14:53
…tion)

Research notes for a future dedicated background-task card. Evaluated AirLLM
(rejected: PyTorch/no-Vulkan, sub-1 tok/s) vs llama.cpp --n-cpu-moe + mmap
(the path forward). Includes a V620-simulated 12 GiB/10 GiB run of the 35B-A3B
MoE (~14-22 tok/s decode, optimistic upper bound), the offload-vs-accuracy note
(placement only, no quality impact), and next steps for when the card is installed.

No code/scripts changed — doc only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CT 120 serves the model (llama-server); Hermes is a separate agent container
that consumes its API. Fix the conflation in the goal statement.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant