User feedback: navigating to relevant docs was cumbersome. The natural
first decision is "1 GPU or 2 GPUs?" and the existing docs mixed model-
specific reference with deployment guidance.
New navigation:
- README.md adds a "Pick your path" pivot pointing at hardware-axis pages
- docs/SINGLE_CARD.md — 1× 3090 deployment menu (workload → compose →
TPS) with all single-card configs (vLLM + llama.cpp), VRAM budget,
prefill cliffs explained operationally, what single-card can't do
- docs/DUAL_CARD.md — 2× 3090 mirror (4 dual variants + TP=2 explainer +
what dual unlocks vs single + Marlin pad fork dependency)
Slimming:
- models/qwen3.6-27b/README.md: dropped duplicated variant tables
(now in GPU-count pages); kept model-specific content (quants, Genesis
patch surface table, what's working / not, VRAM diagram)
- models/qwen3.6-27b/USE_CASES.md: deleted. Per-workload content
absorbed into the GPU-count pages (deduplicated). Troubleshooting
list moved to docs/FAQ.md as a new "Troubleshooting" subsection.
Image-token cost / vision specifics absorbed into SINGLE_CARD.md.
Reference updates: 8 files updated (engines/VLLM.md, engines/README.md,
COMPARISONS.md, ARCHITECTURE.md, EXAMPLES.md, FAQ.md, INTERNALS.md,
top-level README) — all USE_CASES.md links re-pointed to SINGLE_CARD/
DUAL_CARD where appropriate.
Net delta: -167 lines (was 197 in USE_CASES + duplicated tables in
model README; now 342 lines split between SINGLE_CARD + DUAL_CARD with
content deduplicated against each other).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Four comparisons:
vs Ollama — same llama.cpp engine but with a wrapper. We own different
ground: pinned-everything reproducibility, full engine flag access
(--cache-type-k q4_0, --mmproj, --spec-type ngram-mod, --parallel),
vLLM as a second engine. Ollama wins on first-contact UX; we win on
"reproducible config another rig can match exactly."
vs LM Studio — desktop GUI vs CLI/Docker. Different audience.
vs raw llama.cpp build — same engine, no Docker. We're the thin
wrapper users can drop any time. Pick raw if you're a llama.cpp
committer or your platform doesn't have an official image.
vs cloud APIs (Together / Fireworks / Anthropic) — the real comparison.
Includes:
- Pricing landscape table (verify-before-quoting disclaimer)
- Self-host break-even math: ~$120/month operating, breakeven at
~93 TPS sustained generation (5-yr amortization)
- When self-host wins outside cost: latency floor (120ms TTFT),
no rate limits, data residency, customization, predictable
cost, offline, learning value
- When cloud wins outside cost: bursty low-volume, multi-region,
frontier-quality (Sonnet/Opus class), maintenance offload
- The class where club-3090 is genuinely better than both: heavy
agentic IDE flows, privacy-sensitive analytics, long-context
where cloud tier-pricing punishes 256K
Closes with a "if you want X pick Y" decision table.
Linked from top-level README.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
