Claude Fable 5 en local? El càlcul apunta a 1,4 TB i 64 acceleradors
Claude Fable 5 no té pesos públics, així que Kai utilitza Kimi K3 per estimar el maquinari d’un model de frontera: 1,4 TB només per als pesos i una recomanació de 64 acceleradors per servir-lo amb eficiència.
Es pot substituir Claude Fable 5 per un model executat dins de l’empresa? El vídeo de Kai respon amb una distinció essencial: Claude no es pot instal·lar localment perquè Anthropic no publica els pesos ni l’arquitectura completa. Per calcular l’escala del maquinari, utilitza Kimi K3 com a exemple obert de model de frontera.
La conclusió és contundent. Els pesos de Kimi K3 ocuparien aproximadament 1,4 TB fins i tot en format de 4 bits, abans d’afegir memòria de treball, context i programari de servei. La inferència eficient deixa de ser un projecte d’escriptori i passa a ser infraestructura de centre de dades.
1. No hi ha un nombre exacte de GPU per a Claude Fable 5
Anthropic ofereix Claude Fable 5 mitjançant Claude, l’API i plataformes de núvol, però no en distribueix els pesos. Tampoc no revela públicament el nombre total de paràmetres ni tots els detalls de l’arquitectura.
Això impedeix calcular quanta memòria necessitaria una còpia local real. Qualsevol afirmació exacta del tipus “Claude Fable 5 requereix quatre o vuit GPU” és una especulació. El cost local de Claude, estrictament parlant, no existeix perquè el model no està disponible per descarregar.
Kai evita presentar una estimació inventada i canvia la pregunta: què exigiria un model obert de dimensió frontera que es compara amb Fable en algunes proves?
2. Kimi K3 serveix com a substitut mesurable, no com a equivalent
Kimi K3 publica dades que permeten fer aritmètica: 2,8 bilions de paràmetres, arquitectura Mixture of Experts, 896 experts totals i 16 experts activats per cada token. També anuncia una finestra de context de fins a un milió de tokens.
Que només s’activin 16 experts redueix el càlcul necessari per generar cada token, però no elimina els altres 880. El sistema ha de mantenir tots els experts disponibles perquè l’encaminador pot seleccionar-ne un conjunt diferent en el token següent.
Per tant, una arquitectura MoE pot ser més eficient en còmput que un model dens de la mateixa mida total, però els pesos continuen ocupant una quantitat enorme de memòria.
El vídeo no afirma que Kimi K3 sigui idèntic a Claude. Els resultats de benchmark no garanteixen el mateix rendiment en una feina concreta, i el mateix equip de Kimi admet que els models propietaris més forts encara conserven avantatges generals.
3. El mínim matemàtic: 1,4 TB en MXFP4
Kimi anuncia pesos MXFP4, un format de quatre bits. Quatre bits equivalen a mig byte per paràmetre. El càlcul simplificat és:
2,8 bilions de paràmetres × 0,5 bytes = 1,4 bilions de bytes, és a dir, aproximadament 1,4 TB en notació decimal.
Aquesta xifra és només el terra. Encara falten metadades de quantificació, memòria del runtime, activacions, memòria cau del context, converses simultànies i un marge operatiu. Carregar el fitxer no és el mateix que servir el model a bona velocitat.
Fins i tot una hipotètica versió de dos bits rondaria els 700 GB només per als pesos i implicaria compromisos addicionals de qualitat i compatibilitat.
4. El Mac Studio de 512 GB i quatre H100 queden lluny
El Mac Studio amb M3 Ultra es pot configurar amb 512 GB de memòria unificada, una xifra extraordinària per a un ordinador de sobretaula. Tot i així, és poc més d’un terç dels 1,4 TB estimats.
Quatre GPU NVIDIA H100 de 80 GB sumen 320 GB de memòria, encara menys. Aquesta configuració pot executar models locals molt capaços, però no pot allotjar tots els pesos de Kimi K3 en MXFP4.
Això no invalida la IA local. Models més petits poden programar, cercar documents, classificar contingut i automatitzar tasques privades. El que no poden fer és convertir la memòria disponible en la mida d’un model de 2,8 bilions de paràmetres.
5. DGX B200: arriba al terra però no deixa espai per treballar
Un NVIDIA DGX B200 integra vuit GPU B200 i 1.440 GB de memòria HBM3e. La xifra sembla encaixar gairebé exactament amb els 1,4 TB dels pesos.
El problema és precisament aquest “gairebé”. Quedarien només uns 40 GB nominals per a tota la resta: format de quantificació, runtime, activacions, context i servei de peticions. En un sistema d’aquesta escala, no és un marge pràctic.
El B200 demostra que el model arriba a la dimensió d’un servidor complet de deu unitats de rack només per superar el llindar aritmètic. No demostra que pugui respondre amb latència o rendiment útil dins d’un sol node.
6. DGX B300: 2,3 TB ofereixen una possibilitat real
El DGX B300 incorpora vuit GPU B300 de 288 GB cadascuna, amb un total de 2,3 TB de memòria GPU. Això deixaria prop de 900 GB més enllà dels pesos simplificats i fa plausible carregar el model amb memòria de treball.
Encara no es pot afirmar quants tokens per segon produiria, quina longitud de context suportaria de manera pràctica o quantes peticions simultànies atendria. En la data del vídeo, Kimi anunciava els pesos complets per al 27 de juliol de 2026; calen els fitxers finals, el programari compatible i benchmarks reals.
Un B300 pot ser un punt de partida creïble per fer arrencar el model. No és necessàriament la configuració recomanada per oferir-lo com a servei.
7. Kimi recomana 64 acceleradors per a una inferència eficient
El blog tècnic de Kimi recomana desplegar K3 en supernodes amb 64 acceleradors o més. No diu que 64 siguin imprescindibles per carregar els pesos, sinó que la comunicació d’alt ample de banda a aquesta escala afavoreix una inferència eficient.
Amb servidors de vuit GPU, 64 acceleradors equivalen almenys a vuit nodes. A partir d’aquí calen xarxa d’alta velocitat, emmagatzematge, distribució de càrrega, monitoratge i personal especialitzat.
Ja no parlem d’un ordinador personal potent. Parlem d’un clúster que s’ha de dissenyar i operar com una infraestructura de centre de dades.
8. Cent usuaris no signifiquen cent peticions simultànies
El nombre d’empleats no determina per si sol el maquinari. Si cent persones envien una consulta cada deu minuts i cada resposta ocupa el sistema durant trenta segons, una distribució uniforme produeix unes cinc peticions actives de mitjana, no cent.
La concurrència pot créixer molt amb agents de programació, perquè una sola persona pot llançar diverses tasques alhora. També importa la longitud del context: una petició pròxima al màxim d’un milió de tokens consumeix molta més memòria de runtime que una consulta breu.
Per dimensionar el sistema cal conèixer:
- el màxim de peticions actives en hora punta;
- la mida real dels prompts i de les respostes;
- la latència acceptable;
- els tokens per segon necessaris;
- el nivell de disponibilitat i redundància.
Sense aquestes dades, “maquinari per a cent usuaris” no té una resposta única.
9. Potència, refrigeració i cost converteixen el projecte en infraestructura
NVIDIA especifica un consum màxim d’uns 14,5 kW per DGX B300. Vuit unitats arribarien aproximadament als 116 kW abans de sumar refrigeració, xarxa, emmagatzematge i pèrdues de la instal·lació.
El vídeo situa el lloguer de vuit nodes B200 en l’ordre de centenars de milers de dòlars al mes, segons tarifes públiques puntuals. És una estimació d’escala, no un pressupost: els preus varien per proveïdor, compromís, regió i utilització.
La compra tampoc no elimina el cost recurrent. Cal electricitat, climatització, espai de rack, manteniment, recanvis i enginyers capaços de resoldre fallades distribuïdes.
10. L’estratègia més realista és híbrida
La recomanació final és provar primer un model més petit en maquinari llogat. Un pilot amb usuaris reals revela si el model resol les tasques, si la velocitat és acceptable i quant esforç operatiu exigeix.
Per a moltes empreses, l’arquitectura útil combina:
- models locals més petits per a documents privats, classificació i feines repetitives;
- serveis de núvol per a problemes excepcionals que necessiten un model de frontera;
- encaminament de tasques segons cost, sensibilitat i dificultat.
Un model “prou bo” que pot servir tota l’organització sol aportar més valor que un model gegant que només atén unes quantes persones.
Conclusions principals
Claude Fable 5 no es pot executar localment perquè Anthropic no en distribueix els pesos. Kimi K3 permet estimar què suposa allotjar una alternativa oberta de mida frontera: 1,4 TB de pesos a quatre bits, més tota la memòria de servei.
Un Mac Studio de 512 GB i quatre H100 no hi arriben. Un DGX B200 toca el mínim sense marge; un B300 de 2,3 TB és més plausible. Però la recomanació de 64 acceleradors, els 116 kW potencials per a vuit nodes i la complexitat operativa confirmen la idea central: la IA privada de frontera és un projecte de centre de dades, no una funció d’un portàtil.
Contrast i context
Fonts consultades
-
01
YouTube · Kai What Would It Cost to Run Claude Fable 5 Locally?
- 02
- 03
- 04
- 05
- 06
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
You have probably seen videos on YouTube where people say you can replace Claude or Claude Code with a local model. For some jobs, that is true. Smaller local models can write useful code, search your files, summarize documents, and handle repetitive work privately. But what if you want the kind of open model people are now comparing with Claude Fable 5? Fable 5 sits at the top of the intelligence charts today. So what kind of computer would you actually need to run something in that class locally? A question on X put it very simply. What computer do I need to run the latest KIMI-K3? How many Nvidia GPUs or how many Mac studios? I also found a Reddit thread asking what it would take to run a fable class model locally for 100 people. The answers were all over the place.
-
0:42
, obre el vídeo en una pestanya nova
One person guessed 4H100 GPUs. Another said 8B200. Someone else just said you would need a rack. So that is what we cover in this video. We will use KIMI-K3 as a public example, do the basic memory math, and answer three questions. Can a Mac studio run it? Can one Nvidia server run it? And what changes when 100 people use it at once? The short answer is that this is much closer to a data center project than a desktop project. Let me show you why. I want to be upfront about one thing. We cannot do this calculation with the real Claude Fable 5, because anthropic does not publish the parameter count, the full architecture, or the model weights.
-
1:22
, obre el vídeo en una pestanya nova
Anyone giving you an exact GPU count for Fable 5 is just guessing. KIMI-K3 gives us something real to calculate. KIMI says K3 has 2.8 trillion parameters and a 1 million token context window. Its launch materials compare it directly with Fable 5 across coding and agent benchmarks. That does not make KIMI identical to Fable though. KIMI's own blog says K3 still trails the strongest proprietary models overall. And a benchmark score is not the same as doing your actual work well. One person in that Reddit thread saw a claim that an open model beat Fable on some benchmarks. They replied, this is a sign to retire the said benchmarks. That is a fair warning. So I am not calling KIMI-K3 a Fable 5 replacement. I am using it because it is a frontier scale model with a published size. KIMI says the full weights land by July 27th, 2026. Until those files and the serving software are public, what we can calculate is the memory floor.
-
2:17
, obre el vídeo en una pestanya nova
So let us run the math. KIMI-K3 is a mixture of experts model. It has 896 experts, but only 16 are active for each token. That reduces the amount of computation needed for each answer. It does not make the other experts disappear. For fast serving, all of those experts still need to be available across the system because the model may pick different experts for the very next token. KIMI says the weights use a 4-bit format called MXFFP4. 4-bits is half a byte per parameter. So the simple math is 2.8 trillion parameters times half a byte. That gives you about 1.4 terabytes just for the raw weights. And that number does not include the extra data. The 4-bit format carries the inference software, active conversations, or any safety margin. It is the floor, not the real total. Now we can answer the laptop question.
-
3:08
, obre el vídeo en una pestanya nova
The largest Mac Studio can be configured with 512 gigabytes of unified memory. That is definitely not enough. Even if someone eventually ships a 2-bit version, the raw weights would still need about 700 gigabytes. And the Mac Studio tops out at 512. A Mac Studio can run very useful local models. It cannot hold the full KIMI K3 in memory. What about the comments saying 4H100? 4H100 GPUs with 80 gigabytes each give you 320 gigabytes. That is even less memory than the largest Mac Studio. So 4H100s are not enough either. Now we get to the first serious server. A DGX B200, the Blackwell box, has 8B200 GPUs and 1.44 terabytes of total GPU memory. KIMI K3 needs about 1.4 terabytes for the simple 4-bit estimate. On paper, that looks almost perfect.
-
4:01
, obre el vídeo en una pestanya nova
In practice, it leaves only about 40 gigabytes. The 4-bit format, the runtime memory, the context, and the serving software all need space too. So an 8B200 server reaches the arithmetic floor. I would not call it a practical, fast setup. The DGX B300 is more believable. It has 8B300 GPUs and about 2.3 terabytes of GPU memory. That leaves roughly 900 gigabytes beyond the raw 4-bit weights. One B300 server may be able to load KIMI K3 with useful headroom. We still need the real weights and real benchmarks before anyone claims how fast it will be. But KIMI's own launch blog points to a much larger setup. For efficient inference, KIMI recommends a super node with 64 or more accelerators. KIMI is not saying 64 accelerators are the minimum to start the model. But if the company that built K3 recommends 64 for efficient inference, one server is not the full answer. Those are 8 GPU servers.
-
4:59
, obre el vídeo en una pestanya nova
So we are talking about at least 8 servers. That is not a computer under your desk. That is a data-centered deployment. So the Reddit thread asked about 100 users, but one comment corrected the question. And it is exactly the right correction. 100 users is not the same as 100 parallel requests. Suppose 100 employees each send one request every 10 minutes, and each answer keeps the system busy for 30 seconds. If the requests arrive evenly, the average is about five active requests, not 100. But AI agents change that fast. One developer might have several coding jobs running at once, and the context window matters too. KIMI K3 supports up to 1 million tokens in one request, though that is a maximum, not a normal target. Longer prompts and more active requests need more runtime memory. That is why hardware for 100 users has no single answer.
-
5:50
, obre el vídeo en una pestanya nova
You have to know how many requests are active at your busiest moment, how long the prompts are, and how fast answers need to come back. The physical setup is easy to underestimate. NVIDIA lists 1 DGXB300 at 14.5 kilowatts. Run eight of them, and the published figures hit about 116 kilowatts before cooling. One person in that thread said their company runs several dozen B200, and turning them on sounded like sitting behind an Airbus A380. Not a benchmark, but it makes the scale clear. You need high speed networking, storage, power, cooling, monitoring, and people who can actually operate the thing. And the rental math is large too. Multiply today's public 8B200 node prices by 8 nodes, and the compute alone lands somewhere around 313,000 to $57,000 per month. That is rough scale math, not a quote, but it tells you the order of magnitude. The best answer in that thread came from someone who ran an LLM service for thousands of users.
-
6:52
, obre el vídeo en una pestanya nova
They said a model that is good enough, and that you can scale beats a supermodel that only serves a couple of people. That is the practical answer for most companies. A smaller private model handles document search, extraction, classification, or routine coding. The hardest task still goes to cloud or GPT. That is the pattern I keep finding from people who already spent thousands on local hardware. It was almost never fully local. Local models for private or repetitive work, cloud models for the hardest tasks, and the simplest buying advice in the thread. Rent the hardware for a couple of weeks and see whether a few real users like the results. That test tells you more than any benchmark chart. Whether the model can do your work, whether it is fast enough, and how much effort it takes to keep running. So, what would it cost to run Cloud Fable 5 locally? Honestly, you cannot.
-
7:42
, obre el vídeo en una pestanya nova
Because the weights do not exist outside anthropic. But using Kimi K3 as a frontier scale stand-in, the answer is clear. A single Mac studio is not enough. 4H100 are not enough. An 8GPUB200 server reaches the raw weight requirement, but leaves almost no room for the rest of the system. And for efficient inference, Kimi itself recommends 64 or more accelerators, which is 8 servers, not one. For 100 employees, the final number depends on how many requests are truly active at once. Not the headcount. Local AI is real. Private AI is real. But private frontier AI at this scale is a data center project, not a laptop feature. More GPUs can make a model faster. They cannot make the wrong model equal to Cloud Fable 5.
