Het nieuwe open-sourceproject Swiftlet draait met agressieve kwantisatie Qwen3-80B in 4,3 GB RAM op een MacBook en Qwen3-35B op een iPhone. Deze gids behandelt wat dat voor ontwikkelaars echt betekent, waar de kwaliteitsafwegingen zitten en hoe je vandaag nog een lokaal LLM-eindpunt in een echt product koppelt.
Swiftlet is een open-sourceproject (github.com/leonickson1/Swiftlet) dat grote taalmodellen op Apple-hardware draait met extreme kwantisatietechnieken. Het kan Qwen3-80B draaien in 4,3 GB RAM op een Mac en Qwen3-35B op een iPhone. Het is geschreven in Swift en geoptimaliseerd voor het Metal-GPU-framework van Apple.
Swiftlet gebruikt agressieve kwantisatie, waarschijnlijk minder dan 2 bit, om de modelgewichten ver onder hun oorspronkelijke grootte te comprimeren. Een model met 80B parameters op volledige precisie (FP16) vraagt ruwweg 160 GB geheugen. Bij 4-bitkwantisatie is dat ongeveer 40 GB. Op het niveau van 4,3 GB dat Swiftlet haalt, is de kwantisatie extreem, gemiddeld rond 0,4 bit per parameter, met technieken als gegroepeerde kwantisatie en op belang gewogen bittoewijzing om de kwaliteit van de meest kritieke gewichten te behouden.
Dat hangt af van de taak. Extreme kwantisatie behoudt de algemene kennis en het vermogen om instructies te volgen van het model goed, maar verslechtert de prestaties bij taken die nauwkeurig numeriek redeneren, complexe meerstapslogica of lange gestructureerde uitvoer vragen. Voor gespreksinterfaces, contentgeneratie en classificatie is de kwaliteit verrassend bruikbaar. Voor codegeneratie of complex redeneren kan een minder gekwantiseerd kleiner model (zoals Qwen3-35B op 4-bit) betere resultaten geven. Benchmark voordat je uitrolt.
Ja. Swiftlet biedt een lokaal HTTP-eindpunt (meestal op localhost:8080) dat prompts accepteert en completions teruggeeft. Elke webapp kan dat eindpunt aanroepen. Met We.Inc beschrijf je je app in gewone taal, krijg je meteen een werkende React-app, voeg je een fetch-aanroep naar het lokale Swiftlet-eindpunt toe en heb je in minuten een werkend product. De gegenereerde code kun je exporteren naar GitHub, dus je zit niet vast aan een platform.
Swiftlet haalde op augustus 3, 2026 de voorpagina van Hacker News met 260 punten en 116 reacties. De pitch: draai Qwen3-80B, een taalmodel van frontierklasse met 80 miljard parameters, in 4,3 GB RAM op een MacBook. Een model van 35B draait op een iPhone.
Kort samengevat: Swiftlet (github.com/leonickson1/Swiftlet) gebruikt extreme kwantisatie om modellen die normaal 160 GB geheugen nodig hebben in consumenten-Apple-hardware te laten passen. De afweging in kwaliteit is echt maar smaller dan je zou verwachten. Als je een product wilt bouwen dat wordt aangedreven door een lokale LLM zonder API-kosten, is dit de toegankelijkste manier om te beginnen. Koppel een We.Inc-app aan het lokale eindpunt, publiceer hem en je gebruikers merken nooit dat het model op je laptop draait.
De kern is geen magie. Het is kwantisatie die verder gaat dan de meeste tools.
De rekensom: Qwen3-80B op FP16 (de standaardprecisie voor inferentie) heeft ruwweg 160 GB geheugen nodig. Bij de veelgebruikte 4-bitkwantisatie (GGUF Q4_K_M) is dat ongeveer 40 GB. Swiftlet gaat naar ongeveer 0,4 bit per parameter gemiddeld, met gegroepeerde kwantisatie en op belang gewogen bittoewijzing. De meest kritieke gewichten (attention heads, eerste en laatste lagen) krijgen meer bits; het grootste deel van de feed-forwardlagen krijgt er minder.
Het hardwaredoel: Apple Silicon. Swiftlet is geschreven in Swift en gebruikt Metal voor GPU-versnelling. M1/M2/M3/M4-Macs met uniform geheugen zijn het beste omdat GPU en CPU dezelfde RAM-pool delen, wat de geheugenkopieerbottleneck vermijdt die lokale inferentie op basis van NVIDIA beperkt.
Wat je krijgt: een lokale HTTP-server (meestal localhost:8080) die prompts accepteert en completions teruggeeft. De snelheid van tokengeneratie op een M3 MacBook Pro wordt gerapporteerd op 8-12 tokens per seconde voor het 80B-model, wat bruikbaar is voor interactieve toepassingen maar niet direct.
Extreme kwantisatie is niet gratis. Hier houdt het stand en hier niet, op basis van de HN-discussie en vroege tests:
Houdt goed stand:
Verslechtert merkbaar:
De praktische les: als je product een chatbot, een samenvatter of een contenttool is, is de 80B met extreme kwantisatie verrassend capabel. Als je product code genereert of rekent, test dan liever de 35B met hogere kwantisatie. Meer bits per parameter op een kleiner model verslaat vaak minder bits op een groter model.
Het bouwpad is eenvoudig. Je hebt geen cloud-API-sleutel of factureringsaccount nodig.
Stap 1: installeer en start Swiftlet. Kloon de repo, download de gekwantiseerde Qwen3-80B-gewichten (het bestand van 4,3 GB) en draai de server. Op een Mac met 8 GB RAM of meer start hij in ongeveer 30 seconden.
Stap 2: bevestig dat het eindpunt werkt. Stuur een testprompt naar localhost:8080 met curl of een andere HTTP-client. Je zou binnen enkele seconden een completion terug moeten krijgen.
Stap 3: bouw de applicatielaag. Hier besteed je de meeste tijd. Je hebt een frontend nodig die gebruikersinvoer naar het lokale eindpunt stuurt en het antwoord toont. Met We.Inc beschrijf je de app die je wilt ("een schrijfassistent die een alinea neemt en drie herschreven versies teruggeeft") en bouwt de AI een werkende React-app met live voorbeeld. Pas daarna de API-aanroep aan zodat hij naar je Swiftlet-eindpunt wijst.
Stap 4: publiceer of exporteer. Je kunt rechtstreeks vanuit We.Inc publiceren op een eigen domein (de app roept tijdens uitvoering je lokale eindpunt aan) of de code naar GitHub exporteren en zelf uitrollen. De code is standaard React, Vite en TypeScript zonder eigen afhankelijkheden.
Het resultaat: een webapp van productiekwaliteit, aangedreven door een lokaal 80B-model, zonder doorlopende API-kosten.
Lokaal wint wanneer:
De cloud wint wanneer:
De eerlijke middenweg: gebruik Swiftlet voor ontwikkeling en demo's en schakel voor productieschaal over naar een cloud-eindpunt (OpenRouter, Together AI, de Qwen-API). De appcode is in beide gevallen dezelfde; je wijzigt alleen de URL van het eindpunt.
Een model van 80B op een laptop draaien is een mijlpaal, niet omdat de kwaliteit die van een datacenter evenaart, maar omdat het de API-sleutelbarrière helemaal wegneemt. Iedereen met een MacBook kan nu lokaal een model van frontierklasse draaien en erop bouwen.
Voor ontwikkelaars die AI-gestuurde tools bouwen, verandert de kostenvergelijking. API-rekeningen voor producten in prototypefase waren een echt wrijvingspunt. Swiftlet neemt die wrijving weg tijdens ontwikkeling en testen. Het model draait op je eigen machine, kost niets per zoekopdracht en de inferentie is snel genoeg voor interactief gebruik.
Gecombineerd met een builder als We.Inc die de frontend en hosting regelt, is het pad van "ik heb een idee voor een AI-tool" naar "hij staat live op een eigen domein" nu: installeer Swiftlet, beschrijf de app, wijs hem naar localhost, publiceer. Dat is een betekenisvolle vermindering van het aantal stappen tussen idee en product.
Begin gratis met bouwen met We.Inc en koppel het aan je lokale Swiftlet-eindpunt. Exporteer de code naar GitHub wanneer je wilt.
Gratis beginnen · Geen creditcard nodig