~/fba-lab/lab/qwen-c/01-blueprint

FBALab

Code · architecture · study mode

AboutRoadmapSpeedrun
FBALab

Study mode — no GPU required.

Interactive LLM training & inference lab.

Qwen CAboutContactTermsPrivacyCookiesCommunity

© 2026 FBA Lab

Contact · contact@bubblspace.com · +91 75061 55016

INFERENCE SIMULATION

Qwen3 Pure C — 1 · Blueprint

running
◷run_viz.c▸Config struct◎learner⌁01-blueprint$no GPU
active
weights
Load the model
The 4 GB weight file is mapped into memory in milliseconds. No copying — the OS pages in only what inference needs.
run_viz.c · stage 01–02
load
runtime
Run inference
Your prompt flows through 28 layers of attention and computation, one token at a time.
stage 03–04
forward
output
Generate text
The model scores all 151,936 possible next words and picks one. Then repeats.
stage 05–06
1/5
Blocks
Quick summary

The model's blueprint — before loading a single weight, the program reads these numbers to know the model's exact shape: how wide, how deep, how big the vocabulary.

Full explanation below the code →

fba-lab — run_viz.c · Config structexecuting
parsing header.txt → Config blueprintdim1024n_layers28Config ready — no weight bytes loaded ✓
Explanation

Before the program can load weights or allocate memory, it needs to know the model's dimensions. Think of Config as the blueprint before construction — it tells the program how many layers to build, how wide each one is, and how big the vocabulary is. Without it, every allocation and every loop bound would be a guess.

Each field describes a different dimension of the model's shape: - dim — how many numbers represent one position in the model at any layer (1024 here) - hidden_dim — how wide the FFN layer expands to inside each transformer block (3072) - n_layers — how many times the attention+FFN block repeats (28 for Qwen3-0.6B) - n_heads / n_kv_heads — how many parallel attention patterns run simultaneously. Qwen3 uses Grouped Query Attention where 16 query heads share 8 key/value heads, saving memory without losing much quality - vocab_size — how many possible tokens exist (151,936 — every possible subword chunk the model can read or write) - seq_len — the maximum context window: how many tokens can be in the conversation at once - head_dim — how wide each individual attention head is (dim / n_heads)

Nothing in Config is a weight — these are just integers. They're parsed from a header file once at startup. Every buffer size, every matmul dimension, every loop bound in the entire program comes from here.

Why it matters

If Config is wrong, every pointer offset and buffer size is wrong — the model would load but produce garbage logits.

Think about

What problem does Config solve before mmap or malloc runs?

// architecture

Live diagram

100%
Transformer bundles everything needed at runtimeTransformerConfigblueprintWeightsfloat* ptrsRunStatescratch + KV cachefdmmap handledatammap ptrfile_sizebytesload_config()header.txt → Config
2 · Load weights →
Step 1 of 10Skill: Model & Memory
01Blueprint02Load weights03Buffers04Forward pass05Tokenizer06Generate loop07GEMV, not GEMM08Every op a kernel09Attention & memory10Prefill vs decode