A 763B Model on a 12GB Card: What Actually Happens, and What It Costs in Quality

🎯 The claim on the table 0:00

A 763-billion-parameter model answering at roughly 11 tokens per second on a 12 GB gaming card — an RTX 5070, a six-core i5, 62 GB of system RAM and an NVMe drive. Not a cluster, not a server rack. The video's opening summary is the whole episode in miniature: it solved four of four competition maths problems, built a chess engine and a 3D action game from one prompt each, both with one fatal bug, and it fixed both bugs in one try when they were described in plain English. It also failed two hard coding tests and can take nearly a minute before it starts answering.

Every one of those claims is either checkable against a published artifact or honestly labelled as this machine's measurement. What the video does not resolve — and what this article adds — is the quality question, because the quantization publisher's own benchmarks tell a more optimistic story than the engine's reported perplexity does.

🧠 What the 763B actually is 1:02

The model is DeepSeek-V4.1-Flash, and the version in play is the -1017 update of 17 October 2026 — which is where the 763B figure comes from. Worth being precise, because two numbers circulate: the original deepseek-ai/DeepSeek-V4.1-Flash has 552B backbone parameters; the -1017 release is 763.2B. The article you may have read on this site about the 552B model was measuring the earlier one.

The video's explanation of why any of this is possible is the correct one: each token only touches 6 of 384 experts, so most of the model can sit somewhere slow and be pulled in on demand. Everything that follows — compression, offloading, SSD as memory — is an elaboration of that single fact about sparse experts.

🗜 2-bit that is not rounding 1:37

The compression method comes from the lab that produced GPTQ: Das Lab at the Institute of Science and Technology Austria (ISTA), published as GSQ and RCO, with code in IST-DASLab/GSQ and IST-DASLab/RCO. The video's one-line summary — "two ideas from a research lab in Austria" — is accurate.

The division of labour is worth stating precisely, because the narration blurs it slightly. From the quantisation card itself:

• GSQ (Gumbel Softmax Quantization) is the low-bit quantiser: it keeps the rounding decision differentiable — continuing to tune a weight instead of snapping it to the nearest value — so 2 bits can still represent the weight meaningfully.
• RCO (Riemannian Constrained Optimization) is the allocator: it assigns one of several quantization types to each of the model's tensors while holding a fixed total size budget, reformulating the budget constraint as a smooth manifold in logit space so it can optimise directly on task loss without a separate constraint hyperparameter.

Two consequences the video does not spell out. The assignment is per layer, not per expert, because GGUF cannot express per-expert types — so the search's freedom is coarser than it sounds. And the Engram lookup tables are held at a fixed 4.50 bits per weight in every build and excluded from the search, because they are a lookup rather than a matmul weight.

📦 The artifact, and the quality question 2:58

The build he runs is the IQ2_XXS from ISTA-DASLab's GSQ-RCO GGUF set: 2.00 bits per weight, 138.24 GB of transformer backbone, plus a shared 110.60 GB Engram file and a 0.97 GB vision projector. Three builds exist:

Now the disagreement that matters. The video reports — accurately, from Strata's own display — that the quant is "about 15% worse on its quality score overall and about 5 to 9% on code and agent work". The publisher's benchmarks show no measurable loss at this size: IQ2_XXS is reported at 100.0% of the base model's task average, matching it on AIME25 (100.00 vs 100.00), GPQA-Diamond (90.91 vs 90.91) and LiveCodeBench v6 (89.71 vs 89.71). IQ1_M retains 98.7%.

One update the video predates by three days: on 27 October the quant set moved to llama.cpp's own DeepSeek-V4.1 layout and now loads in llama.cpp b11870 or newer, images included. Strata is no longer the only way to run these files.

⚙️ Strata's plan: VRAM, RAM, and the SSD as memory 3:16

The engine is Strata — open source, MIT, built by Niko1221, and by far the most popular project in this niche at the time of writing (36,290 stars). Its job is to make a model larger than VRAM + RAM work by treating storage as part of the memory hierarchy.

He logged it second by second while the model wrote: GPU 11.4 GB at 100%, system memory around 46 GB, SSD reads between 1 and 1.5 GB/s continuously. That last line is the actual story of the video — the drive is not storage any more, it is a tier of memory, and its speed sets your tokens per second. The card's own guidance says the same thing: keep the Engram file on an SSD so paging stays cheap.

🔧 Setup reality: three ways to be caught out 4:20

• Disk. The download is about 257 GB in his accounting (138 GB model + 111 GB Engram + an ~8 GB drafter); the card's numbers are 248.84 GB for the quant plus the Engram file and a 0.97 GB vision projector. Either way: 300 GB free on an NVMe drive.
• Driver. You need NVIDIA driver 580 or newer (CUDA 13). On an older driver the DeepSeek engine refuses to install — it is a hard stop, not a warning.
• Memory. 46 GB minimum as tested, 64 GB comfortable. He has 62 GB, which is why RAM sits at about 46 GB used with the rest of the system still alive.

Setup itself is one install command and one launch command; Strata downloads the model, verifies files and starts a server that speaks the OpenAI-compatible API, so any client or agent can point at it. Strata's documentation also exposes an Anthropic-Messages-compatible endpoint, which matters if you want to drive it from Claude Code rather than an OpenAI-style client.

🚀 Speed, measured 5:10

Same prompt three times: 10.45, 11.63 and 11.34 tokens per second. First word under 2 seconds cold, and 0.16 s warm. Strata's own estimate for this hardware was about 4.7 tok/s, so the measured result is more than double the engine's prediction — which says something about how conservative those estimates are, not that the engine is wrong.

Long answers settle at 8–10 tok/s, because more experts have to be fetched from RAM and disk per token. And the default is a "faster mode" that uses five of the six experts per token; switching to all six dropped the same test to 8.7–9.2 tok/s — about 20% slower for, in his words, a very small quality change.

🧾 Long memory, slow prefill 6:06

A secret code hidden in the middle of a long, boring document: found at about 5,700 tokens and again at about 22,800 tokens. Both passed. The interesting number is the cost of reading: first word after 15.8 seconds at 5.7K tokens and 41.4 seconds at 22.8K, which implies prefill of roughly 350–500 tokens per second.

That is the honest trade-off at this size on this hardware. Fine for "read this document and answer questions about it while I make coffee"; painful for an agent loop that re-sends a long context on every turn — which is exactly what coding agents do.

🧮 Reasoning holds, precision slips 6:44

Four competition problems — one from AIME 2025 and three from AIME 2024, with thinking enabled — four correct, each in one to two and a half minutes. Small traps passed too: the smallest number whose factorial ends in exactly 25 zeros (105), counting the letter R in "strawberry raspberry" (6), and an LRU cache graded against hidden tests (5/5).

Then the harder code, and the pattern the video identifies is the one worth remembering:

His conclusion — "the reasoning is strong, but on long precise code it gets one small detail wrong" — is the correct read, and it is also exactly what the publisher's benchmark parity would predict: AIME and GPQA reward multi-step reasoning, where a 2-bit model is fine; exacting parsers reward bit-level precision in a long generated artifact, where the errors that don't show up in perplexity do show up in code.

🏗 Five builds, two bugs, two fixes 8:14

Five artifacts from one prompt each, all of which ran: an SVG poster of a glowing graphics card (about 6 minutes), a canvas lighthouse scene with sweeping beam and drifting clouds (6 minutes), a rotatable 3D solar system with a ringed planet and orbiting moon (under 5), a chess game against the computer with castling, promotion, check and checkmate and a three-move search (8,400 tokens, ~15 minutes), and a 3D wave-based action game with upgrades and a boss every fifth wave (6,200 tokens, ~12 minutes).

Two of them shipped with one fatal bug each, and both bugs are instructive because they are the kind a model can write fluently and never notice:

• Chess: both armies rendered in the same light colour, and the engine chose the best move for the human — it was trying to lose.
• 3D game: bullets passed straight through enemies because the hit check compared height as well, and the bullets flew higher than the enemies. Wave 1 could never be cleared.

The fix round is the most encouraging part of the video: hand the model its own code back, describe each bug in one plain sentence, ask for the fix. It found both chess problems (the missing colour and the flipped side) and, for the game, pointed at the exact line and removed height from the hit check. Each fix took about five minutes, and afterwards the computer actually played — taking a free pawn on move two and the queen the moment it was offered.

👁 Vision and other languages 10:06

The model is multimodal, and the vision tests are the strongest results in the video. A bar chart read for every value plus a trick question — which month had the biggest increase — came back perfect: it noted that June has the tallest bar but March the biggest jump. A café dashboard screenshot rebuilt as a web page matched on numbers, colours and status badges, with the only miss being two column headings running together.

The language test answers his own earlier worry about English-weighted sensitivity data. Paragraphs in Hindi, Marathi, Czech and French: Hindi and Marathi read naturally, French was good if slightly repetitive, and Czech had one grammar slip — an adjective that did not agree with its noun. So 2-bit compression did not wipe out non-English capability; it sanded one corner off it. He asks native speakers to judge in the comments, which is the correct epistemics for a four-paragraph sample.

🧭 What this changes 11:41

The closing argument is the one worth carrying: the size of the model you can run at home is no longer set by your graphics card alone. It is set by memory, the SSD and smart compression. That is a real shift in the economics of local inference, and this video is good evidence for it — a 763B model, at usable speed, on hardware a gamer already owns.

✅ Claims checked

Transcript notes. The auto-captions garble a few technical names, all corrected above against the cards and repositories: "GSQ" and "RCO" are correct, "Strata" is correct, "AIM 2025/2024" is AIME, and the model is DeepSeek-V4.1-Flash-1017 (the 17 October update) rather than the original release. "508 GB" for the full release is consistent with a 763B model at 5–6 bits per weight plus the Engram tables.

🔑 Key takeaways

• A 763B MoE at ~11 tok/s on a 12 GB RTX 5070 is real, and it works because only 6 of 384 experts fire per token — sparsity is the whole trick, not cleverness at the model level.
• The 763B number belongs to the -1017 update. The original DeepSeek-V4.1-Flash is 552B backbone; the update adds enough (including 196.6B of Engram lookup tables) to reach 763.2B. Two different models, often conflated.
• GSQ is the quantiser, RCO is the allocator. The video reverses the two. GSQ makes 2-bit rounding differentiable per tensor; RCO assigns quantization types across tensors under a fixed size budget.
• The quality evidence is genuinely split. The publisher reports 100% of base task average on AIME25, GPQA-Diamond and LiveCodeBench v6 at 2.00 bpw; the engine reports ~15% worse perplexity. Perplexity and task accuracy are different things, and the video's hands-on results sit between them.
• The SSD became a tier of memory. 1–1.5 GB/s of continuous reads while generating; your drive speed is now part of your tokens-per-second equation, and a slow disk makes every word slower.
• Prefill is the real cost. 16 seconds to first word at 6K tokens, 41 seconds at 23K — fine for document Q&A, hostile to multi-turn agent loops that resend context.
• The failure pattern is precise: strong reasoning (4/4 AIME), weak exactness in long generated code (a parser that treats -2^2 as +4 and accepts "3 4"). Verify code; trust the maths.
• The fix loop is the real workflow. Two of five builds shipped with one fatal bug each; describing each bug in one sentence fixed both in one try, in about five minutes. At zero marginal cost, iteration beats one-shot quality.
• Non-English survives compression, with a dent. Hindi and Marathi read naturally, French slightly repetitive, Czech had one agreement error — a four-paragraph sample, honestly labelled as needing native judgement.
• Hard requirements before you try: NVIDIA driver 580+, 300 GB free NVMe, 46 GB RAM minimum (64 comfortable), and patience. And since 27 October, llama.cpp b11870+ runs these files too — Strata is no longer mandatory.

🔗 Resources & links

The artifacts in the video

• ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF — the IQ1_M / IQ2_XXS / IQ2_XS builds, sizes, benchmark table, llama.cpp usage
• deepseek-ai/DeepSeek-V4.1-Flash-1017 — the base model (MIT)
• deepseek-ai/DeepSeek-V4.1-Flash — the original 552B-backbone release, for comparison
• Niko1221/Strata — MIT inference engine, expert offload across VRAM/RAM/NVMe, OpenAI- and Anthropic-compatible endpoints
• The video's guide repository — commands, test scripts, raw logs, all model outputs (no licence, new)

The methods

• GSQ — Gumbel Softmax Quantization and its code
• RCO — Riemannian Constrained Optimization and its code
• Das Lab, ISTA — the group behind GPTQ, GSQ and RCO
• llama.cpp b11870 — the first release that loads the updated DeepSeek-V4.1 layout

⏱ Timestamp index