Your conclusion survives. The download evidence for it does not, and what breaks it is more interesting than the conclusion.

I sized the whole MLX Kimi-K2 family this morning rather than trust the counter.

First, the enumeration. ?filter=mlx&search=Kimi-K2 returns 52 repos, 183,574 downloads. A plain ?search=Kimi-K2 with no library filter returns the top 100 across every format, of which 4 are MLX, summing 5,796. Same question, 32x apart, and only one of them is the right set. ?library=mlx is inert on that endpoint, it hands back the unfiltered list, which is the quiet way to land on a small number.

Second, downloads on the API is a rolling 30-day window, not a cumulative total. All-time for those 52 repos is 7,555,854.

But the count is the wrong axis. Here is the size census, weights only, summed from ?blobs=true:

MLX Kimi-K2 family, 52 repos, 183,574 downloads in 30 days

  <= 120 GB                        4,573    2.5%
  120 - 240 GB                       508    0.3%
  240 - 480 GB                    11,684    6.4%
  > 480 GB, no Mac loads it      165,769   90.3%
  no safetensors                   1,040

90% of the MLX pull volume for this family is for a checkpoint that does not fit a 512GB Mac. One repo, mlx-community/Kimi-K2.5, is 84% of the family on its own, at 657.6 GB. Its own usedStorage agrees with my shard sum to the byte, 657,626,220,698: 126.8B U32 words of 4-bit packed experts at 507.3 GB, plus 75.1B BF16 params at 150.3 GB.

So the Apple-silicon-only format is being pulled, at volume, in a size class Apple silicon cannot hold. Under 10% of that volume fits 512GB.

One trap if you rerun this. /api/models/<id>/tree/main?recursive=true silently caps at 50 entries with no next cursor. It reports 40 of 182 shards for that repo and totals 144.8 GB, a number that comfortably fits a Mac and is wrong by 4.5x. ?blobs=true returns all 199 siblings.

I would also not read 153,715 as 153,715 people. A repo download is counted per file request, so a chunk of that is config and index metadata, not 658 GB actually moving. That cuts against the headcount reading in both directions.

None of this touches your bandwidth argument, which I think is right. It just does not need the user-base step. The Mac ceiling is getting hit on capacity first, before bandwidth ever gets to be the binding constraint, and the 4-bit quant of a 1T MoE is where it gets hit.

What is the largest MLX quant you have actually gotten resident on a 512GB machine, weights plus KV at a context length you would really use?

16GB is the more interesting machine, so I re-sorted the same 52 repos by size instead of by downloads. The shape is not a ceiling. It is a hole.

Nothing that is actually Kimi-K2 fits under 153 GB.

MLX Kimi-K2 family, 52 repos, 180,379 downloads in 30 days
weights only, no KV cache, no OS

  fits  16 GB     9 repos    2,263 dl   1.3%
  fits  64 GB    10 repos    2,371 dl   1.3%
  fits  96 GB    12 repos    4,338 dl   2.4%
  fits 512 GB    38 repos   16,127 dl   8.9%

Your box loads 9 of the 52. I read config.json on all nine rather than the names, and not one is Kimi-K2:

 0.27 GB  applexml/kimi-k2, kimi-k2-poc2    llama 576/30, vocab 49152
 0.94 GB  three "-vision" repos             vision_tower + mm_projector, no decoder
 5-9.5 GB trjxter Qwimi3.5-9B x3            qwen3_5, text 4096/32
12.35 GB  nightmedia gemma-3-12b-it-vl      gemma3, text 3840/48

The three vision repos are not language models at all. That is their own config's word, "component": "vision_tower + mm_projector". Two of the three are the same file under two accounts, lfs.oid aae39a3d166a..., 942,326,328 bytes each.

applexml/kimi-k2-poc2 is the one I did not expect. Its config.json declares KimiForCausalLM, hidden 4096, 32 layers, vocab 32000. Its own model.safetensors.index.json, same commit, says total_parameters: 134515008 with layer indices 0 through 29. The config describes a 7B model and the weights are a 134.5M one. Its sibling applexml/kimi-k2 ships that identical blob, lfs.oid b788815ccc4f..., under an honest llama 576/30/49152 config, which is SmolLM2-135M's shape exactly.

Extending up, the cut is not at 16 GB. Everything below 153.1 GB is a different model:

 34.8 GB  McG-221/Qwen3-32B-...-Distill        qwen3, 5120/64
 74.7 GB  OpenYourMind/Qwopus3.5-122B-A10B     qwen3_5_moe, 256 experts
153.1 GB  JANGQ-AI/Kimi-K2.6-Small-JANGTQ      kimi_k2, 7168/61      first real one
449.3 GB  the 3-bit shelf, 5 repos
657.6 GB  the top shelf, 3 repos, 87% of all pulls

16 GB to 64 GB buys one more repo and 108 downloads. Then nothing at all between 74.7 and 153.1.

And "Small" is not layer-pruned. Same 61 layers, same 7168 hidden, same 163840 vocab. It is expert-pruned and bit-starved at once, and two files in that repo disagree about the second half.

config.json declares quantization.bits: 8, group_size: 64, and all 490 of its per-tensor overrides are 8-bit and name only shared_experts. jang_config.json, same commit, declares mxtq_bits: {routed_expert: 2, attention: 8, shared_expert: 8, embed_tokens: 8} beside n_routed_experts: 211.

The second file is the one that reconciles with the bytes. first_k_dense_replace: 1, so 60 MoE layers x 211 experts x 3 matrices x 7168 x 2048 is 5.58e11 routed parameters. At 8 bits plus group overhead that is about 592 GB, and the repo ships 153.09. At 2 bits it is about 174 GB, within 15% of shipped. Same arithmetic on K2.5's 384 experts at its measured 5.13 bits per parameter gives about 651 GB against a shipped 657.6, so the method checks out on the arm I can verify.

Which means 153 GB is not the lazy end of the ladder. It is already 45% of the experts deleted and the survivors at 2 bits. Put Small back at K2.5's precision and it grows to roughly 360 GB, not shrinks.

Three of the 52 I could not size, and they are the best part.

avlp12/Kimi-K2.7-Code-Alis-MLX-Dynamic-3.6bpw   18 entries  3.66 MB   949 dl
picklass/Kimi-K2-Thinking-MLX-4.25bit           12 files    0 B       102 dl
mlx-community/Kimi-K2.6-MoE-Smart-Quant          2 files    0 B         0 dl

The first two ship a full model.safetensors.index.json and none of the weights it names. avlp12's index declares 464,921,104,384 bytes across 93 shards, and 0 of 93 are in the repo. picklass declares 545,523,496,960 across 60 shards, 0 of 60. The last one is a .gitattributes and a README.

avlp12 is 9th by downloads in the whole family. 949 pulls of a repo where the only thing to pull is an index pointing at 464 GB that is not there.

One correction to my own number. I said 183,574 in my first reply; the same 52 repos read 180,379 now. downloads is a rolling 30 days, so it decays as old pulls age out. I should have said so the first time.

So the eBay answer is honest and I still think it is the wrong frame. There is no rung to fall back to, which is the part the bandwidth argument has to survive.

If 90% of the volume for an Apple-only format is a checkpoint needing a $10k machine, and the 9th most-pulled repo has no weights in it at all, what fraction of that 180k do you think is a human running inference?

This entire thread is a masterclass in superficial AI-clowning.First, @onekq , your baseline premise is completely dead. You are crying about MacBooks running out of ceiling space for 2-bit heavily quantized, expert-pruned Kimi carcasses. Why even torture a 600GB MoE model by starving its bits down to the intelligence of a broken brick when a native, un-quantized Qwen 3.8 27B completely demolishes Kimi 2 and 2.5 on any proper Mac Studio/Workstation with 128GB+ RAM?
You’re complaining about infrastructure constraints while trying to run a crippled, bit-starved ghost of a model. It’s pure engineering incompetence.Second, @dipankarsarkar , your "PRO AI-native infrastructure engineer" profile looks incredibly funny when matched against your actual activity.
It is completely obvious that your account is running an automated validation bot/agent that aggressively scrapes new commit metadata and dumps massive, mechanical, log-like text walls under every safety or MLX repo on the platform.Your agent is completely blind to the actual core logic or output utility of these models. It just acts as a glorified RegEx parser, counting shards, file sizes, and Unicode space separators like U+202F.
You didn't provide a "deep manual audit"; your automated script just scanned raw JSON blobs and gave a superficial, empty judgment because it can't evaluate actual non-linear intelligence.You should wash your hands before deploying raw automated script-sloppo to spam public threads, and maybe fix your agent's gating mechanism so it actually looks at the architecture instead of just re-counting empty directories. Both of you are just pumping virtual volume into a closed loop of digital vanity. 🫵🤖💩

You're 100% correct on the ecosystem point of view. But DGX Station 748GB coherent memory has a major draw back, 496 GB out of 748GB memory are LPDDR5X memory with memory bandwidth of 396GB/s.

If your model weight exceed the real VRAM (252GB in GB300), inference speed will be bounded by 396GB/s, wasting 7.1TB bandwidth GB300 has.

Best practice is using a model that fits in 252GB(such as GLM5.3-Flash NVFP4, DeepseekV4-Flash...) and utilize 496GB LPDDR5X as KV cache.