# US-042 — GGUF/llama.cpp node backend

Status: planned
Priority: High (unlocks DeepSeek-V4-Flash on volunteer hardware — the pool's core value)
Stage: Draft design

## Goal

Run **DeepSeek-V4-Flash** as the first real large-model target on volunteer
hardware via GGUF/llama.cpp. This epic is no longer GLM-oriented: the initial
objective is to prove that DeepSeek-V4-Flash can load and serve correctly on
consumer/unified-memory nodes, then expand from there.

## Context

The node backend is transformers-only (`model_backend.py` →
`AutoModelForCausalLM`). For DeepSeek-V4-Flash (158B MoE, official weights FP8
160 GB) the only quantizations that run on consumer hardware are GGUF
(IQ2 87 GB → Q4_K_M-XL 175 GB) — llama.cpp format. The transformers-compatible
quants (FP8, NVFP4, GPTQ W4A16) all need datacenter GPUs. Volunteer machines —
including our own Strix Halo boxes (128 GB and 80 GB unified memory, GPU via
Vulkan/ROCm, no FP8 support on RDNA3.5) — run these models today only under
llama.cpp.

## Design directions to evaluate (design-it-twice)

**A. llama.cpp as a per-node shard executor.** Node loads a *layer range* of a
GGUF via llama-cpp-python; our existing hop protocol (X-Meshnet-Route,
activations over HTTP/relay) moves hidden states between nodes. Requires
llama.cpp partial-layer loading and activation import/export — investigate
feasibility first; this is the riskiest unknown.

**B. llama.cpp RPC mode under tracker orchestration.** llama.cpp ships a
native RPC backend that splits one model across machines. The tracker would
provision/route to an llama.cpp RPC cluster rather than our own hop pipeline.
Less code, but bypasses our billing/telemetry hop instrumentation and relay
NAT path — needs a story for both.

**C. Whole-model GGUF nodes (no sharding).** A node with enough memory serves
a full GGUF (e.g. IQ2/IQ3 on a 128 GB box); the tracker routes whole requests
to it (single-hop route). Smallest step, no cross-node activation work, and
already useful: Strix Halo 128 GB serves DeepSeek-V4-Flash IQ3_XXS (114 GB)
via llama.cpp Vulkan today.

Recommended sequencing: C first (small, real value), then A/B investigation.

## Also in scope

- Model catalog: allow GGUF entries with quant selection; feature
  `DeepSeek-V4-Flash` IQ4_XS/UD-Q4_K_XL as a curated/featured entry once at
  least direction C works (a featured model nobody can load is an anti-feature)
- Hardware detection: recognize Strix Halo/unified-memory APUs and Vulkan
  (`hardware.py` currently reports "CPU mode" on these boxes)
- `MESHNET_DOWNLOAD_DIR`/`--download-dir` applies to GGUF files as well

## Acceptance criteria (phase C)

- A node with `--gguf <repo-or-path> --quant IQ3_XXS` serves
  `/v1/chat/completions` via llama.cpp with GPU offload where available
- Tracker treats it as a full-coverage node (single-hop routes, billing works)
- Streamed responses work through the tracker proxy and the relay (US-036)
- `python -m pytest` passes from repo root (llama.cpp behind an optional extra)