Reviewed repository / hardware evidence

BTL-4: GPU & VRAM requirements

BTL-4 is a 35.11 billion-parameter Apache-2.0 repository whose Hub configuration names Qwen3_5MoeForConditionalGeneration and whose card points to Ornith-1.0-35B as a base model. It is a useful counterexample to sizing from active-expert intuition: the public safetensors total is the resident-weight input unless a documented offload path says otherwise.

See the precision plan → Inspect the source repository →

Decision summary

Where the memory boundary actually lands.

At INT4, the weight-plus-headroom floor is 19.62 GiB. That clears a 21.6 GiB usable budget on one 24 GB card by less than two GiB, making cache and runtime validation essential. INT8 first clears a 48 GB tier, and BF16 first clears 96 GB. Two or more GPUs only help if the chosen runtime supports the required sharding.

Why this page exists. BTL-4 earns a reviewed page because its 24 GB INT4 boundary, MoE architecture, and limited adoption signals create a different decision from a generic dense 35B guide.

Weights first / precision by precision

The reproducible memory floor.

Every row uses 35.11B parameters × bits ÷ 8 ÷ 1024³, then adds 20% planning headroom. The single-card tier assumes 90% of labeled VRAM is available.

Mode	Bits	Raw weights	+ 20% floor	First single-card tier	24 GB GPU count*	Calculator
INT4	4 bits	16.35 GiB	19.62 GiB	24 GB	1	Edit plan →
INT8	8 bits	32.7 GiB	39.24 GiB	48 GB	2	Edit plan →
BF16	16 bits	65.39 GiB	78.47 GiB	96 GB	4	Edit plan →

*GPU count is capacity division against 90% usable VRAM. It does not prove the runtime can shard the model, avoid replication, or deliver acceptable interconnect performance.

INT4 card-fit matrix

Test the floor against common memory tiers.

Positive margin means the INT4 weight-plus-headroom floor fits inside the declared usable budget. It is not leftover context capacity: cache, runtime workspace, and system allocations are still unknown.

Card memory	90% usable	One-card result	Capacity-only count
8 GB	7.2 GiB	Short by 12.42 GiB	3
12 GB	10.8 GiB	Short by 8.82 GiB	2
16 GB	14.4 GiB	Short by 5.22 GiB	2
24 GB	21.6 GiB	Clears by 1.98 GiB	1
32 GB	28.8 GiB	Clears by 9.18 GiB	1
48 GB	43.2 GiB	Clears by 23.58 GiB	1
80 GB	72 GiB	Clears by 52.38 GiB	1
96 GB	86.4 GiB	Clears by 66.78 GiB	1
141 GB	126.9 GiB	Clears by 107.3 GiB	1

Public source record

What the repository declares.

Metadata refreshed Aug 15, 2026. Open the source before relying on any field.

Open badtheorylabs/BTL-4 →

Repository: badtheorylabs/BTL-4
Safetensors total: 35.11B parameters
Architecture: Qwen3_5MoeForConditionalGeneration
Model type: qwen3_5_moe
Library: transformers
License metadata: apache-2.0
Access gated: No
Base model: Ornith-1.0-35B
Languages: Not declared in card metadata
Created: Aug 5, 2026
Last modified: Aug 7, 2026
Hub signal: 8.8K downloads · 81 likes

Do not confuse capacity with deployment

Repository-specific caution.
The repository's current download and like counts are small compared with established releases, and the trending score is not a quality judgment. Architecture support, expert routing, exact checkpoint files, prompt format, and benchmark behavior require direct inspection. This page deliberately refuses to convert social attention into a production recommendation.

Formula boundary.
No KV cache, activations, graph capture, allocator fragmentation, offload, operating-system reserve, throughput, latency, or power is included.

Source boundary.
Hub trend, downloads, and likes help discover repositories. They are not a benchmark, endorsement, security review, or license opinion.

Before downloading weights

Three checks specific to this repository.

Verify Qwen3.5 MoE architecture support and expert placement in the intended runtime before buying around the 24 GB result.
Inspect the Ornith-1.0-35B lineage and repository instructions instead of inferring behavior from the BTL-4 name or parameter total.
Run task and safety evaluations locally because the small adoption signal provides too little evidence for a production-quality conclusion.

Passive backlink / model-card distribution

Let the repository carry its hardware evidence.

Add this passive SVG badge to a README, model card, documentation page, or benchmark report. It states the source-backed BTL-4 INT4 floor and links to the assumptions—not to a download or quality claim.

Why this repository benefits. Use this badge only with BTL-4 evidence, where the 19.62 GiB INT4 floor sits narrowly inside a 24 GB card policy. Its destination separates Qwen3.5 MoE capacity from architecture support and the repository's still-limited adoption signal.

Markdown for a README or model card

[![BTL-4 INT4 floor 19.62 GiB - ResearchAudio](https://tools.researchaudio.io/badges/models/btl-4-gpu-requirements.svg)](https://tools.researchaudio.io/models/btl-4-gpu-requirements/?utm_source=model_badge&utm_medium=model_card&utm_campaign=ai_evidence_lab&utm_content=btl-4-gpu-requirements#hardware-plan)

Badge visits use utm_source=model_badge, utm_medium=model_card, and this repository’s slug. Copying does not submit or store anything.

Nearest reviewed parameter totals

These pages use the same formula and source rules, making the capacity boundary comparable without pretending the models have equivalent quality or runtime behavior.

BTL-4 FAQ

Three answers with the assumptions attached.

Use these as a first-pass hardware screen. Replace parameter arithmetic with exact artifact bytes and architecture-aware cache inputs before deployment.

Open the editable GPU calculator →

How much VRAM does BTL-4 need?

BTL-4 has 35.11 billion safetensors parameters in the public Hub metadata. The weight-plus-20%-headroom floors are 19.62 GiB at INT4, 39.24 GiB at INT8, and 78.47 GiB at BF16. These estimates exclude KV cache, activations, runtime workspace, fragmentation, offload, and speed.

Can BTL-4 run on one GPU?

The first listed card tier whose 90%-usable budget clears the INT4 weight floor is 24 GB. That is an arithmetic starting point, not a runtime guarantee.

Does the Hugging Face signal prove BTL-4 is good?

No. Downloads, likes, and trending position are discovery signals. They do not prove task quality, safety, speed, runtime compatibility, or licensing suitability.