2.8T Parameters, Open-Sourced. Now What About 1.56TB?

When a 2.8-trillion-parameter model open-sources its weights, the first instinct is to open the repository page and hit download. What waits there instead is a colder set of numbers: roughly 1.56TB of weights split across 96 files, 112 files in the repository counting configs and documentation, all in native MXFP4 format. The questions behind the download button change immediately: which channel carries the weights, where do they go once downloaded, how large a cluster does it take to run them - or should you skip the download and call the API instead. Based on first-hand captures from each channel on November 5, 2026, this review splits the paths for putting Kimi K3.1 Pro to work into four routes and compares them one by one. The division of labor first: our earlier local deployment VRAM SOP answers how much VRAM it takes to run the model, which is an estimation method; this piece answers where the weights come from and what each of the four routes costs, and the two articles are upstream and downstream of each other. The hotspot coverage in this batch tells the story of the release itself, in K3.1 Pro open-weights coverage; this review does not retell the event, it only compares channels and routes, so the angles do not overlap.

The data discipline comes first: every number in this piece was captured on November 5, 2026, from first-hand APIs and pages, with no benchmarks cited and no cross-leaderboard comparisons. On the weights side, item by item: the official HuggingFace repository moonshotai/Kimi-K3.1-Pro shows 797 downloads and 517 likes as captured via the hf-mirror API, the repository holds 112 files including non-weight files, and the gated field is False, meaning no application is needed to download - though HF is unreachable by direct connection from mainland China and requires a mirror or proxy. The hf-mirror site carries the same-name repository, its page showing 590 likes at capture time; the gap versus 517 comes from cache timing, and mirror figures may lag. ModelScope lists moonshotai/Kimi-K3.1-Pro, its API returning Code 200 with the architecture field KimiK31ForConditionalGeneration; the download count is unverified, so no figure is quoted. The third-party mirror unsloth/Kimi-K3.1-Pro shows 0 downloads captured, alongside several personal re-uploads. On the price side: OpenRouter listed 454 models site-wide that day, with moonshotai/kimi-k3.1-pro at 2 dollars per million input tokens, 10 dollars per million output tokens and 0.2 dollars per million cache-read tokens, context length 1048576, modality labeled text, image and video. Two background notes: the official architecture label for K3.1 Pro is Gated DSA, and at capture time there were no official GGUF or INT4 derivative branches - the model ships natively as MXFP4 weights with MXFP8 activations under quantization-aware training.

One Table for Every Entry Point

The captured data folds into a single table covering the six entry points behind the four routes:

Three boundaries before reading it. First, the dollar figures in the price column are OpenRouter's captured rates for that day, not the vendor's official pricing; the official list price on platform.kimi.ai is unverified, and the two ledgers do not explain each other. Second, the modality label text, image and video only says what a request may carry in, not a measured verdict on multimodal capability. Third, downloads and likes are point-in-time captured data, mirrors may lag, and the numbers will not necessarily look the same days later. Without these three boundaries, the table is easy to misread.

Two figures are especially easy to misread. The 112 versus 96 gap is not a contradiction but a difference of scope: 96 counts the weight files themselves, 112 counts everything in the repository, and mixing the two leads to a wrong size estimate. The 797 downloads should not be read as a popularity chart either - a freshly listed 1.56TB repository is completed by very few users, so that number measures the access threshold, not demand. The 517 and 590 likes are the same: page states at capture time, not reputation scores of any kind.

Route One: the Official API, the Default Answer

For most people the answer is to start with kimi-k3.1-pro on platform.kimi.ai. The reasoning is plain: on this route there is no 1.56TB, no cluster, no bandwidth anxiety, and cost is billed purely per token. One engineering detail worth noting is controllable reasoning effort: the official offering exposes reasoning_effort at three levels, low, high and max, so easy tasks can be pushed down to low to save money and latency while hard tasks open it up. The official list price is unverified here and no figures are quoted; for budgeting, go by the current note on platform.kimi.ai. For how the input, output and cache parts of a bill interact, the site's LLM API pricing comparison covers the full methodology, so it is not repeated here.

When does another route become necessary? Typically in three cases: the model must sit inside your own data flow, compliance forbids data leaving your domain, or call volume is high enough that per-token billing clearly loses to dedicated capacity. All three point to route three, not the aggregator - the aggregator still solves calling convenience, not data flow. Separating want-to-self-host from must-self-host saves most pointless 1.56TB downloads, and that is the single conclusion this piece most wants to leave behind.

Route Two: OpenRouter, Convenience and a Second Ledger

The value of an aggregator is switching between many models from one entry point. Under the OpenRouter capture, moonshotai/kimi-k3.1-pro lists 2 dollars per million input tokens, 10 dollars per million output tokens and 0.2 dollars cache read, with context 1048576 and modality labeled text, image and video. Those 2-dollar and 10-dollar figures match what earlier site coverage of K3.1 quoted, but this piece still cites them as captured on November 5, 2026. Two standing reminders apply. One, an aggregator's captured rate is not the vendor's official price: it carries the channel's own margin and settlement terms, so budgeting must go back to the official ledger. Two, the video modality label only means the entry point is open, not that video understanding has been measured at any level. The same site lists the previous generation, moonshotai/kimi-k3, at 0.192 dollars input, 16 dollars output and 0.182 dollars cache read; the two generations have different price structures, so the numbers are listed without interpretation. One more detail: OpenRouter listed 454 models site-wide that day, a large enough pool, which also means its labeling conventions do not fully align with any vendor's own site - treating its fields as official specs will lead you astray.

Route Three: Downloading Weights, for Teams with Clusters Only

This is the heaviest route and the most underestimated. The weights run about 1.56TB across 96 files in MXFP4 format, with the architecture labeled Gated DSA. First, where to download: the official HF repository is gated False, no application needed, but direct connection from mainland China is blocked; the same-name repository on hf-mirror is reachable directly from mainland China; ModelScope carries an official listing, its API returning 200, reachable directly, making it the first choice for an official mainland source. On the HF channel the command looks like this:

huggingface-cli download moonshotai/Kimi-K3.1-Pro --local-dir ./Kimi-K3.1-Pro

Downloaded is not the same as runnable. Following the conclusion of the site's VRAM estimation article, a 2.8T-class model carries a VRAM threshold at the terabyte scale even with MXFP4 weights, which no single consumer machine can meet; it takes a multi-GPU cluster or cloud instances, and the estimation method is in the local deployment VRAM SOP. On the engine side the official recommendations are two: vLLM ships official recipes and SGLang ships an official cookbook - see vLLM and SGLang - and both toolchains have been adapting to models of this scale. Last, a safety habit: the third-party mirror unsloth/Kimi-K3.1-Pro shows 0 downloads captured, alongside several personal re-uploads, and unofficial mirrors carry a real risk of tampered files, so verify hashes after downloading before using anything - that step cannot be skipped. As for the third-party adaptation repos such as DSpark that surfaced in search results, this piece does not trust any of them.

Route Four: Wait for the Ecosystem, the Status Is One Sentence

A common question: is there a GGUF or INT4 version, so a single-GPU workstation at home might have a chance? The status at capture time: no official GGUF, INT4 or any other derivative branch has been released; the model is natively MXFP4 weights with MXFP8 activations, and quantization-aware training means it arrives compressed out of the box - which also means pushing it further down waits on the community. As of November 5, 2026, no credible community distillation or small-parameter quantization has appeared, and third-party adaptation repos are not trusted. This section states the status only, predicts no timeline, and invents nothing unverified.

Why the Table Has No Performance Scores

This piece deliberately cites no benchmarks. The reason is one of scope: the question here is where the weights come from and what each route costs, while model strength is another question that demands purpose-built measurement. Different leaderboards use different evaluation setups and cannot be aligned horizontally, and comparing scores across boards is the kind of claim that looks most like a conclusion and holds up least - a boundary every comparison on this site keeps. So the table carries only objective parameters: channel, official status, accessibility, size and price. Which model is stronger is outside this piece's range.

The Advice: Most People Stop at Station Two

The four routes compress into one sentence: most developers and products stay on route one or route two - the official API for stability, the aggregator for convenience - and both are token bills that never touch the 1.56TB. Route three belongs only to teams with a multi-GPU cluster or a cloud budget; before acting, size the threshold with VRAM estimation, and verify hashes after downloading. Route four requires no action, only waiting, and nothing on the first two routes is affected by that wait. Put the other way: if you opened the repository page only because it felt right to download an open-sourced model, the best decision is usually not to download.

FAQ

Q1: Are the 2-dollar and 10-dollar figures in the table Kimi's official pricing?

A1: No. They are OpenRouter's captured rates on November 5, 2026, and an aggregator's captured rate is not the vendor's official price. The official list price on platform.kimi.ai is unverified here and no figures are quoted; for budgeting, go by the current note on the official page.

Q2: The HF page shows 517 likes and hf-mirror shows 590 - which one is correct?

A2: Both are point-in-time captured data. They were captured through different entry points, the gap comes from cache timing, and mirrors may lag. Whichever figure you cite, mark it as captured on November 5, 2026, and do not treat likes as a fine-grained metric.

Q3: Do I need to apply for access before downloading the weights?

A3: No. The official repository's gated field is False, so no application is needed. What mainland users should watch is network reachability: direct HF connection is blocked, so use hf-mirror or ModelScope, the latter being an official listing reachable directly.

Q4: I have eight consumer-grade GPUs - can I run this model?

A4: Essentially no. A 2.8T-class model carries a VRAM threshold at the terabyte scale even with MXFP4 weights, and a single consumer machine cannot assemble that much. Size the threshold with the VRAM estimation method first, then decide between a cluster and the cloud.

Q5: Is there a GGUF or INT4 quantized version to download?

A5: As captured on November 5, 2026, no official quantized derivative branch exists, and the model is natively MXFP4. Third-party adaptation repos carry tampering risks and are not trusted; until a credible community version appears, this line can only wait.

Related reading

• Local deployment VRAM SOP - VRAM estimation and setup before starting route three.
• K3.1 Pro open-weights coverage - the release story and its wording.
• LLM API pricing comparison - how to break down input, output and cache bills.
• Kimi 3D coverage - earlier K3.1 wording and the site's first mention of the 2-dollar and 10-dollar rates.