Think of the model as a stack of papers and your GPU's memory as a desk. LaunchReady works out whether the stack fits on the desk, with room left for everyone using it, before you download it.
It estimates how much GPU memory (the memory on the graphics card, where a model has to sit while it runs) a model needs, from the model's published description files. Then it tests those estimates on real GPUs and follows published setup instructions word for word to see what breaks.
Each finding starts in plain English, with the technical evidence under it. Every number is tagged measured (read from a real run or a real file) or projected (calculated, not tested) and links to its file. Measured results are from 2026-11-03 unless noted.
4–6%measured vs projected gap
The estimates held up on two standard models
The number of users came within 4–6% of what was measured, slightly on the cautious side. One was a dense model (a standard design). The other was a mixture of experts, or MoE (a model that stores many specialist parts but uses only a few for each word).
Qwen3-4B (dense), users at 4,096 tokens: projected 7.12, measured 7.41, a gap of −3.9%
OLMoE-1B-7B (MoE), users at 4,096 tokens: projected 20.22, measured 21.47, a gap of −5.8%
Model weights, same two models: −0.9% and −0.1% against measured
Tokens are pieces of words. 4,096 tokens is the context, meaning how much text one conversation can hold. Run on 2× Tesla T4 on Kaggle with vLLM 0.32.0 (a program that serves a model to users).
On the line means projected equals measured. On a phone, swipe sideways to see all three panels, or tap the chart to open it.
A hybrid Mamba model is a design where most layers keep a fixed-size note for each user, instead of a record that grows with the conversation. On granite-4.0-h-tiny, a team sizing from my projection would have expected more than twice the users the engine could hold.
Users at 4,096 tokens: projected 118.08, measured 50.58
Two errors multiply to make that miss:
confirmed×1.72, less memory left for users. vLLM's log shows 2.93 GiB per GPU measured against 5.04 GiB projected, because overhead beyond the weights was 3.70 GiB measured, not the 2 GiB the formula assumes.
hypothesis×1.36, each user costs more. The size is known: 124 MB measured against 92 MB projected. The cause is not: how vLLM pages Mamba state is the likely reason, and it is not confirmed.
The tool now warns about this gap, and I did not retune it from one model. Lightning is also a hybrid Mamba model, so its capacity projection carries the same risk.
Quantization means storing each number in a model with fewer bits, so the file is smaller. NVFP4 is one such format. The estimate treats every number as 4-bit, but the real file keeps some at higher precision, so the tools now use real file sizes when they exist.
Files labeled "Q4_K_M" hold more than the label suggests
Q4_K_M is a label for GGUF, a model file format for local tools. Three Lightning files with that name store about 6.1 bits per weight, so they take more memory than the label implies.
What my tool assumes: projected 4.85 bits per weight, or 18.58 GiB against a 23.73 GiB file measured (bartowski)
No GPU involved, and no weights downloaded. launchready fit still uses 4.85, which the checklist marks not ready; the brief and recipes use real file sizes instead.
Three published setup instructions broke when followed word for word
I ran the commands on model cards (a model's published instructions) word for word, the way a first-time developer would, and each of these stopped them from getting an answer.
Qwen3-4B card, vLLM command. Fails on vLLM 0.32.0 with an unrecognized --enable-reasoning flag, exiting after 30 s measured, on 2× Tesla T4.
Qwen3-4B card, Python snippet on a 16 GB Mac. Offloads to disk with only a one-line log notice, and printed no answer before the 2,700 s cap measured. The same snippet worked on 2× Tesla T4 in 115 s measured.
Lightning NVFP4 card, llama.cpp recipe. Asks for :Q4_K_M, but the official GGUF repo has no such file, so it exits after 6 s measured.
I applied this work to one launch: NVIDIA Nemotron 3.5 Lightning on a single RTX 5090. The verdict today is not ready, mostly because nothing has been measured on a 5090.
1ready
5not ready
21unknown
27 checks in all. These are counts of checklist items from evidence in the repo, not hardware measurements. The one ready item is a document check.
Readiness checklist: each check with its status, evidence and what closes it.
Lightning model brief: capabilities, hardware needs, engine support and ecosystem impact, projected unless marked measured.
GGUF headers and Hugging Face file sizes, read without a GPU.
Quickstart audits (running published setup instructions word for word), on Kaggle 2× T4 and a MacBook Air M4 with 16 GB.
projected
Everything about Lightning running on an RTX 5090. With vLLM: 20.08 GiB of weights, 0.28 GiB per 40,960-token conversation and about 18 conversations (formula and table).
With a GGUF file: about 6.0 GiB left with 8 slots, from a 23.73 GiB file (formula and table).
Not measured
Lightning on an RTX 5090 has not been run. No speed, memory or quality number on this page comes from a 5090 (progress).
The kit is dry-run only, on Tesla T4 with Qwen3-4B, not Lightning. Those outputs prove the scripts run and are not headline results.
Fixes from the dry runs are confirmed on T4 only, not on Lightning, and the status for lost requests has never triggered on a GPU (what each fix changed).
Chat template (how a conversation is formatted for the model), tool calling (the model using outside tools), a long soak run (hours under steady load) and a tokenizer comparison (how text is split into tokens) have not been tested (list).
