experts4bit-qlora

Fine-tune large MoE models on a single GPU.

Quantize the experts. Train adapters. Move weights to RAM or SSD when GPU memory runs out.

On a 12 GB card: with OFFLOAD_EXPERTS=1, Qwen3-30B-A3B QLoRA-trains TC1's matched set (fp32 adapters, seq 2048, r 16) at micro-batch 1 × accum 8 at 10.463 GB peak allocated on an RTX A2000 12 GB, while the rest of its packed experts stay in pinned CPU RAM (e4b.train.frontier.qwen3.a2000-12gb.2026-10-02, one draw; micro-batch 2 ran out of memory on that shared card). The command · how to read the number

Mixture-of-Experts (MoE) models keep many expert networks but activate only a few per token. Their fused expert weights can escape ordinary load_in_4bit=True loading and stay in full precision. This runtime loads those weights in 4-bit, trains them with QLoRA, and serves the model.

New here? Start with Loggetta. pip install loggetta installs this runtime and its kernels. Use loggetta inspect to check your machine and loggetta plan to plan supported training. Use this package directly when you need control over loading, training, serving, or memory placement.

Limits. GPU execution needs Linux and NVIDIA CUDA; the fast kernels need an sm_80+ GPU. Every measured training and serving result uses one GPU per process; running one model across two or more GPUs is untested. Support varies by model family and execution path. 4-bit saves memory but is not automatically faster than bf16, and vLLM was faster in the measured Qwen decode comparison. Check the fit.

Install · Results · Model support · Task guides · Hugging Face

Latest released package: experts4bit-qlora 0.58.1 · Current development status: docs/STATUS.md on main (this README describes main) · Released documentation for 0.58.1: docs/ · README.md · CHANGELOG.md

Install

pip install "experts4bit-qlora[train,fast]"

GPU execution needs Linux + NVIDIA CUDA. Fast kernels need an sm_80+ GPU, Triton ≥ 3.4; the streaming loader needs transformers ≥ 5.0. The base runtime needs torch ≥ 2.2; the fast extra applies the kernel package’s newer PyTorch floor. CI tests Python 3.11. Start with a CUDA-compatible PyTorch installation for your GPU.

For a smaller install, the base package provides quantization and adapters; [train] adds the trainer; [fast] adds grouped-nf4-gemm. Exact dependency floors live in pyproject.toml.

Load a model and check it

This downloads Qwen3-30B-A3B and keeps its frozen experts in host RAM. Allow enough RAM and disk space for the checkpoint.

import torch
from experts4bit_qlora import load_moe_4bit_streaming, verify_moe_4bit

model, config = load_moe_4bit_streaming(
    "Qwen/Qwen3-30B-A3B", "cuda", torch.bfloat16,
    r=8, alpha=16, quant_type="nf4", offload=True,
)
verify_moe_4bit(model, strict=True)  # raises if an expert stack stayed high precision

To train the built-in Alpaca example:

MODEL=Qwen/Qwen3-30B-A3B OFFLOAD_EXPERTS=1 STEPS=150 R=8 TRAIN_EXPERTS=1 OUT=./out python -m experts4bit_qlora.train

For your own dataset and reusable native adapters, see Loggetta's training guide.

Choose the path you need

What is measured

These are specific workloads, with public results and controls. The table is checked against claims.json in CI. Measured means a public run record; the full register also labels private, superseded, and retired results.

The speed rows profile both frameworks on one stack (torch 2.12.1). The GPU-time ratio is the host-independent figure; the wall-clock ratio grows on a slower host, because Unsloth runs 14× e4b's CPU ops per step at the field recipe. On packed rows the wall ratio read 1.472 (e4b.train.h2h.unsloth.qwen3.5090.2026-10-08.packed-4k-device-ratio) and 1.773 (e4b.train.memory.packed-4k-position-defaults.5090.2026-10-07) on two hosts. The earlier field-recipe readings, 2.352 and 2.468, were wall ratios from before the reentrant checkpoint. The offload row uses a different training setup.

Qwen comparison · Packed 4K result · All current results

New in 0.58.1

• Mixtral-8x7B's NF4 decode at 2 to 4 requests takes K33's per-row GEMV by default on the RTX 5090.
  • With E4B_NF4_SMALLM_BW unset, Mixtral's NF4 expert calls of 2 to 4 tokens run grouped-nf4-gemm K33's bandwidth GEMV.
  • Two requests decode 2.12452x and four 1.76481x as fast, inside P110's quality bars at group 4 (e4b.serve.p234.nf4-smallm-bw.mixtral-nf4.5090.2026-10-24).
  • Outputs change by default at two and four requests there. One request is unchanged, and E4B_NF4_SMALLM_BW=0 restores the previous output.
  • The default covers only what P234 read: mixtral, Mixtral-8x7B's two expert shapes with 8-expert top-2 routing, on sm_120 at 170 SMs. Anything else resolves off and names why in nf4_smallm_bw["source"]. Calls of 5 to 8 tokens stay opt-in.
• The release-day head-to-heads, each re-read at the released pins with every pinned release proven by its bytes, in docs/REPRODUCE.md's new table:
  • Serving: vLLM 0.32.0 is ahead of e4b's int4 serving, 1.038 at one request and 1.203 at sixteen, on one RTX 5090.
  • Decode GEMV: bitsandbytes 0.50.2 is faster than grouped-nf4-gemm's decode GEMV at all 30 op-level cells, timed eager with Python dispatch.
  • Training: the comparison against Unsloth 2026.10.8 is NOT_READ. Both Unsloth draws failed TC1's engagement check.
  • Memory planning: loggetta's planner covers 18 of 21 measured training rows.
  • Losses stand beside wins, and unread rows say so.

New in 0.58.0

• Qwen3-30B-A3B's int8 lm_head serves 2 to 8 requests by default. With the int8 head on (its default at the 151936 x 2048 head), the head's 2- to 8-row calls run grouped-nf4-gemm K37's linear_i8 over the head's own int8 codes instead of F.linear on their bf16 rounding: 2, 4 and 8 requests decode 1.0311x, 1.0243x and 1.0165x as fast (the smallest of four ABBA pairs at each, inside P153's quality bars; e4b.serve.p232.int8-head-rows.qwen3.5090.2026-10-24). Outputs change by default at those request counts: greedy text can differ (76 of 112 greedy rows matched in P232); one request and 9 or more are unchanged, and E4B_INT8_HEAD_ROWS=1 restores the previous output. Other heads and families stay at 1 until a read of their own.
• TC1's field recipe fits a 24 GiB RTX 4090 with three opt-in levers (NF4_QLORA_COMPACT_DELTA=1, NF4_QLORA_PAD_BUCKETS=1, E4B_CHUNKED_LM_LOSS=256) and grouped-nf4-gemm 0.51.0: two RTX 4090s on two machines trained all 60 steps with no out-of-memory error, 586 MiB of the card's total left at the fullest step (e4b.train.4090-fit.field.4090.2026-10-24). FIT covers that fixture only (Qwen3-30B-A3B, sequence 2048, micro-batch 2 x accumulation 4, r 16); the levers stay opt-in, and no speed is claimed.
• A served adapter's base is verified, not reported unverified. The paged server compares each qfp-v1 fingerprint a backend-adapter/2 manifest records with the base it serves: the attention projections as loaded, and the expert stacks read from the served arena. A match serves with no opt-in; an expert mismatch is refusal 12 (E4B_PAGED_ADAPTER_ACCEPT_BASE_MISMATCH=experts serves it anyway, reported in /health), and an attention mismatch is refusal 11, with no override.
• A merged NF4 arena, opt-in. experts4bit_qlora.merged_arena.write bakes a trained expert delta offline into a new NF4 arena, and E4B_PAGED_MERGED_ARENA=1 serves it with the adapter it was merged from; any other pairing is refusal 13. It stays off by default until its registered served read gates it.
• A shared KV pool, opt-in. With E4B_PAGED_KV_POOL=shared, slots claim KV blocks as they write them, the scheduler admits by reserved blocks, and the pool is sized from the device's free memory, so a request waits for blocks rather than running the pool dry. /health reports the sizing. No speed is claimed.
• Small-batch serving levers, each opt-in until a served read of its own: E4B_NF4_SMALLM_BW (2- to 8-token steps on the bandwidth GEMV), E4B_DENSE_LT_PIN (a pinned cuBLASLt GEMM for named dense projections at 2 to 8 rows), E4B_K25_PLAN=m1 and E4B_ATTN_SPLIT_FIXED; also E4B_PAGED_PREFILL_EVERY and E4B_PAGED_LOADED_CHUNK_TOKENS, which space and shorten prefill while requests decode.
• Deterministic training, opt-in. E4B_TRAIN_DETERMINISTIC=1 turns on the deterministic token gather and deterministic algorithms for each backward, and refuses at trainer start unless CUBLAS_WORKSPACE_CONFIG is :4096:8 or :16:8. No default changes, and no cost is stated.

New in 0.57.0

• The paged server serves a trained adapter. E4B_PAGED_ADAPTER=<dir> loads one adapter trained with bf16 attention (one trained on 4-bit attention is refused). The server verifies the directory before it reads any weight (paths, sizes, sha256, tensors, shapes, dtypes, finiteness), merges the attention LoRA into the bf16 projections at load, so serving it adds no per-token work, and refuses to start, naming each reason, rather than serve the base model in the adapter's place. Expert LoRA is refused for now. /health reports the adapter's id, manifest hash and merge report.
• An adapter can carry a manifest the server checks. backend-adapter/2 records a canonical fingerprint of the quantized base (scheme qfp-v1: the same base fingerprints alike whether its NF4 absmax is stored nested or expanded), the training facts that decide whether serving is exact, and the LoRA scale actually applied; the server checks every field and refuses by name a manifest it cannot accept. Comparing the expert base's fingerprint at serve time is the next step; until then that check stays an explicit opt-in refusal. docs/ADAPTER_PORTABILITY.md states, from code, which training and serving pairings are exact, bounded behind a registered gate, or refused.
• gpt-oss expert LoRA, opt-in. E4B_GPTOSS_EXPERT_LORA=1 wraps gpt-oss's experts for LoRA on the unfused reference loop, graded against an independent oracle on CPU. It refuses offload, and its speed against a fused route is unmeasured.
• The plan prices the loss the run takes. When the chunked LM loss refuses an LM head whose width differs from the configured vocabulary, the planner now prices the stock loss, as the run does.

New in 0.56.1

• Sixteen requests decode 1.4654× as fast on Qwen3-30B-A3B, one request unchanged, every token identical (the smallest of four ABBA pairs). K25, the batched NF4 decode GEMM, now runs at tile plan c1 on qwen3_moe where its decode resolved to K39's prmt (grouped-nf4-gemm 0.50.0 or later, on NVIDIA). Elsewhere it stays on today, recorded in info["k25_plan"]. The plan changes tiling and staging only, so the values are bit-identical to today's. Measured on one RTX 5090 against the today plan, both under K39's decode: the smallest of four ABBA pairs. E4B_K25_PLAN=today opts out. (P161, e4b.serve.p161.k25-plan-c1.qwen3.5090.2026-10-20)

New in 0.56.0

Serving defaults on qwen3_moe. Each was measured alone on Qwen3-30B-A3B on one RTX 5090 (170 SMs); their combined effect has not been read. Two need a newer grouped-nf4-gemm than [fast] installs (0.43.0 or later): K25's prmt decode needs 0.50.0 and the int8 head needs 0.48.0. Below those each resolves off, recorded, and nothing breaks. To get them, run pip install -U grouped-nf4-gemm.

• Sixteen requests decode 1.0925× as fast, one request unchanged, every token identical. (The smallest of four ABBA pairs.) K25, the batched NF4 decode GEMM, now decodes its codebook with grouped-nf4-gemm K39's byte-permute decode (lut="prmt"), bit-identical to the select tree it replaces. It needs grouped-nf4-gemm 0.50.0 or later and an NVIDIA device; otherwise it resolves to the tree, recorded in info["k25_lut"]. E4B_K25_LUT=tree opts out. (P158, e4b.serve.p158.k25-prmt.qwen3.5090.2026-10-20)
• One request decodes 1.052× as fast from the lm_head on its per-row int8 grid (the smallest of four ABBA pairs; grouped-nf4-gemm K36; at Qwen3-30B-A3B's 151936 x 2048 head only; needs grouped-nf4-gemm 0.48.0 or later, else it resolves off). Outputs change: the logits differ from the bf16 head's, inside the quality gates read on Qwen3-30B-A3B @ad44e777. Sixteen requests read 0.992, a cost not yet attributed. E4B_INT8_HEAD_BW=0 restores the bf16 head. (P153, e4b.serve.p153.int8-head-bw.qwen3.5090.2026-10-19)
• One request decodes 1.044× as fast with the paged FP8 attention decode capped at 16 splits (the smallest of four ABBA pairs; buckets 1, 2 and 4 move; bitwise-identical to the library's plan at contexts up to 1024). Sixteen requests are unchanged. E4B_ATTN_SPLIT_CAP=0 opts out. (P143, e4b.serve.p143.attn-split-cap.qwen3.5090.2026-10-19)

Training, opt-in. Each was measured on the card named, against the baseline its bullet names.

• Layer-major training under expert offload steps 2.365× as fast on Qwen3-30B-A3B on one RTX 4090 (the smaller of two ABBA pairs of median step times). layer_major_step (experts4bit_qlora.engines.layer_major) runs a step's micro-batches layer by layer, so each offloaded layer is staged once per step instead of once per micro-batch. It replicates at 2.311× on an RTX 5090 and holds on Mixtral-8x7B at 2.118× on an RTX 4090, each the smaller of two ABBA pairs of median step times. Opt-in. (P137, e4b.train.p137.layer-major-offload.qwen3.4090.2026-10-18; P140, e4b.train.p140.layer-major-offload.qwen3.5090.2026-10-18; P144, e4b.train.p144.layer-major-offload.mixtral.4090.2026-10-18)
• The CLI trainer can take the fused training path. In 0.55.0, python -m experts4bit_qlora.train always ran the reference loop. FAST_TRAIN=1 now puts it on the fused path, and LAYER_MAJOR=1 implies it. At the CLI's own default recipe on Qwen3-30B-A3B with OFFLOAD_EXPERTS=1, LAYER_MAJOR=1 steps 1.455× as fast as FAST_TRAIN=1 alone on one RTX 4090 (the smaller of two ABBA pairs of median step times). An explicit FAST_TRAIN=0 keeps the reference loop. (P146, e4b.train.p146.layer-major-cli.qwen3.4090.2026-10-18)

Mixtral serving.

• Mixtral-8x7B decodes with its B=1 fold stack by default. The T1 glue, its second round and the router epilogue now resolve to auto on Mixtral; fused q/k/v does not engage on this family. A one-request step takes 0.9393 of its time without them (median step time, the larger of two interleaved blocks) (about 20.2-20.5 ms to 19.0 ms) on one RTX 5090. Opt out per knob: E4B_FUSE_T1_GLUE=0, E4B_FUSE_T1_GLUE_R2=0, E4B_FUSE_ROUTER_EPI=0. (P135, e4b.serve.p135.fold-speed.mixtral.5090.2026-10-18)
• E4B_SERVE_ATTN_INT8=1: int8 weight-only attention projections on Mixtral, opt-in. q/k/v/o are held in int8 with a per-row fp32 scale, and decode calls of 1-16 rows run grouped-nf4-gemm's K37 kernels (from 0.49.0). On one RTX 5090 the served read decodes one request 1.161x as fast (the smallest of four ABBA pairs) and sixteen 1.018x, with decode quality inside its registered bound. It stays opt-in until a routing-matched read: the default-flip PR is held. (P149, e4b.serve.p149.int8-attn.mixtral.5090.2026-10-20)

Scale.

• One full-depth QLoRA optimizer step on Qwen3-235B-A22B on one GPU. All 94 decoder layers and every routed expert, two optimizer steps plus a fresh-process repeat of step 0, on one RTX PRO 6000 Blackwell Workstation Edition. (Q235, run q235-pro6000-8, MILESTONE PASS)

Check the fit

• Models: use the architecture support matrix. Support and test coverage vary by family and execution path.
• Memory: CPU/NVMe offload trades transfer time and host storage for GPU memory. Measure your workload.
• Speed: 4-bit saves weight memory; it is not automatically faster or more energy-efficient than bf16 when both fit.
• Serving: vLLM was faster in the measured Qwen decode comparison. This runtime focuses on fitting and controlling low-bit MoEs; see the serving results.
• Platforms: CUDA execution is the tested path. ROCm, macOS, Windows and other non-CUDA GPU execution are outside this package's scope.

Documentation and machine-readable data

Task guides · API and capability map · Claims and evidence · Package compatibility · Documentation index · llms.txt · Contributing

License

MIT. The vendored bitsandbytes code is also MIT; see third-party notices. For integration or research work: jordananderson.work.