poros-train 0.2.1

Fine-tune large models on small GPUs by streaming a frozen quantized base, with exact parity to standard QLoRA.

   

 Install    Quickstart    Benchmarks    Models    How it works    Docs    Paper 

---

Poros streams the frozen base of a QLoRA fine-tune through the GPU one block at a time, so only the adapters and a single block are ever resident. The adapter it produces is bit-for-bit identical to a fully resident run, verified with torch.equal (not allclose): all four surfaces — loss, adapter weights, gradient norms, and optimizer state — are gated directly at 7B and 32B; at 72B, loss and weights are gated directly and the other two are inferred from the bit-identical weight trajectory.

• 32B trains in 11.61 GB peak VRAM (44.88 GB resident) — inside a 16 GB budget
• 72B trains end-to-end on a single RTX 5090 — 18.13 GB training peak on the 5090 (18.87 GB canonical; 81.57 GB resident)
• Parity is 0.00e+00, not "close" — gated over 200-step and 1000-step runs, with dropout, gradient accumulation, and torch.compile
• One line on top of your existing PEFT script

Install

pip install poros-train            # CLI + config, no GPU needed
pip install "poros-train[ml]"      # + torch, transformers, peft, bitsandbytes
pip install "poros-train[ml,bench]"  # + benchmark harness

Python 3.11+, PyTorch 2.10+, Transformers 5.5+, Linux with CUDA. The base install runs poros --help, poros check, and poros doctor on CPU-only machines.

Quickstart

Already have a Hugging Face + PEFT script? Add one line and keep your loop:

import poros

model = poros.prepare(model)   # your loop, your config, untouched
trainer.train()

Poros prepared model
        model  Qwen/Qwen2.5-7B
   model_type  qwen2
 architecture  certified
      adapter  lora (certified)
    precision  NF4
        stack  certified
   block_size  4
    guarantee  official bitwise path (NF4, deterministic)

prepare() never touches your training setup — learning rate, LoRA config, optimizer, and data stay exactly as you wrote them. It detects the architecture, wraps the model in place, and reports which guarantee applies. Paths not gated at 0.00e+00 are labeled experimental or target. Reverse it any time with poros.unprepare(model).

No script yet? PorosTrainer is the five-line path:

from poros import PorosTrainer

trainer = PorosTrainer.from_pretrained(
    "Qwen/Qwen2.5-32B", quantization="nf4", lora_rank=16, lora_alpha=32,
)
trainer.train("OpenAssistant/oasst1", steps=200, seq_len=512)
trainer.save("./poros-qwen32b-lora")

The saved adapter is a standard PEFT adapter — load it with PeftModel.from_pretrained, or merge for vLLM/TGI with poros export ./poros-qwen32b-lora -o ./merged. See examples/inference.py.

If a block doesn't fit your card, PorosOOMError suggests a smaller block_size to try. Details: docs/quickstart.md · docs/api.md.

Benchmarks

Consumer cards, measured. Every row has a raw artifact in docs/validation/; the datacenter matrices (A100, B300, RTX PRO 6000) live in docs/official-a100-results.md and docs/official-b300-results.md.

RTX 3090 (24 GB) — Qwen2.5 QLoRA, all methods on identical data, seeds, and deterministic kernels (rank-16 LoRA, NF4, seq_len 512, 200 steps):

Scale	Method	Peak VRAM	s/step
7B	PEFT QLoRA	16.37 GB	0.51
7B	Accelerate CPU-offload	9.71 GB	0.73
7B	Unsloth QLoRA	8.66 GB	0.53
7B	Poros	6.90 GB	0.87
32B	PEFT QLoRA	OOM	—
32B	Accelerate CPU-offload	OOM	—
32B	Unsloth QLoRA¹	22.29 GB	2.07
32B	Poros	11.61 GB	3.21

¹ Unsloth at 32B fits only with its own use_gradient_checkpointing="unsloth" mode; without it, it OOMs at ~23 GB. Final losses match to ≤4×10⁻⁴ across methods (kernel dispatch); Poros is bit-identical to its resident reference on the primary platform.

RTX 5090 (32 GB) — official validation runs (PyTorch 2.11.0+cu128):

Run	Steps	Peak VRAM	Result
Qwen2.5-32B, synthetic	50	11.02 GB	loss tracks the A100 trajectory to ~2×10⁻⁴
Qwen2.5-32B, real data (oasst1)	100	11.02 GB	padding-masked CE, same 11.02 GB envelope
Qwen2.5-72B, end-to-end	10	18.13 GB train · 30.57 GB process peak	streamed load + training on one card; loss matches the PRO 6000 run to ~1×10⁻⁵

The 72B process peak is the startup self-check probe, not the loader — the streamed loader's own ceiling is 1.63 GB at 72B. The 5090 runs use the instrumented single-pass validation protocol, so step-time comparisons belong in the 3090 table above.

The cost, on consumer hardware: 0.87 vs 0.51 s/step at 7B on the 3090 (about 1.7×). At 32B and 72B there is no resident consumer baseline to be slower than — it OOMs. If your model fits comfortably resident, run it resident.

The streamed NF4 loader (default) keeps host RAM at 12.1 / 34.7 / 48.2 GB RSS for 7B / 32B / 72B (standard path: 15.3 / 62.0 / 136.5 GB).

Reproduce any row with the shipped configs, e.g. poros bench run configs/bench/official_a100_qwen25_32b.yaml. Consumer guidance: docs/consumer-gpus.md.

Supported models

Every validated family is gated at exactly 0.00e+00 on real hardware — byte-identical load plus bitwise training parity. The four surfaces (loss, adapter weights, gradient norms, optimizer state) are gated directly at 7B and 32B; at 72B, loss and weights are gated directly and the other two are inferred from the bit-identical weights.

Family	model_type	Coverage
Qwen2.5	qwen2	0.5B–72B, incl. DeepSeek-R1-Distill-Qwen
Qwen3	qwen3	32B
Qwen3.5 / Qwen3.6 dense	qwen3_5	0.8B–27B
Gemma 3	gemma3	27B
Gemma 4	gemma4	31B

Check any model without downloading it:

poros check Qwen/Qwen3.5-27B   # resolves model_type + status, no torch needed

Unvalidated architectures fail loudly instead of training with an unverified guarantee. MoE models with fused expert layers (Qwen3-MoE, GLM-4.5+, gpt-oss) are not NF4-quantizable and are out of scope. Roadmap and the registry mechanism: docs/architecture-support.md.

How it works

A frozen base receives no gradients — it sits in VRAM only because the forward pass reads it. Poros bounds residency to one block plus prefetch in both directions: the forward streams blocks through a small GPU window, the backward reloads each block and recomputes its forward before differentiating adapters and block inputs.

Exactness comes from RNG capture. Recomputing a block would normally redraw its dropout masks and silently change the gradients; Poros snapshots CPU and CUDA RNG state before each block's forward and restores it inside torch.random.fork_rng during recomputation, so the backward runs on the identical graph. Nothing about the learning problem changes — same kernels, same optimizer, same data order.

The formal statement and full audit matrix are in the paper. Configurations that would break parity silently (block-major gradient accumulation with dropout) raise instead of degrading.

Limitations

• Slower than resident training — 1.6–4.3× per step, hardware-dependent. That is the trade.
• Single GPU in v0.1; multi-GPU is v0.2 work.
• Dense architectures only — fused-expert MoE is not NF4-quantizable.
• LoRA-family adapters on a frozen base — full fine-tuning is out of scope.
• Host RAM holds the streamed base: provision to the measured RSS peaks above.
• The 72B end-to-end process peak is ~30.5 GB today (a 32 GB card) — the training step itself needs 18.87 GB.

The complete list: docs/limitations.md.

Docs

Quickstart	prepare(), PorosTrainer, exporting adapters
API	every public surface, typed
Architecture support	validated registry, poros check, adding families
Consumer GPUs	3090/4090/5090 guidance
Parity modes	what 0.00e+00 covers, mode sweep
Benchmarks	running the harness, HTML reports
Validation artifacts	raw gate JSONL for every claim

Citation

@article{tigres2026poros,
  title   = {Poros: Bit-Exact Large-Model Fine-Tuning on Consumer GPUs},
  author  = {Tigres, Jeffrey},
  journal = {arXiv preprint arXiv:ARXIV_ID},
  year    = {2026}
}

License

Apache-2.0. Built by Caistro Labs.