Lokale LLM's in softwaremodernisering: welke rol kunnen ze vandaag spelen?

Er is een golf van applicaties die worden herbouwd en vervangen. Bij Eli5 bekijken we elke week artikelen over softwaremodernisering om echte waarde te vinden voor CTO's, PM's en PO's die te maken hebben met de modernisering van legacy software. Deze week bespraken we een Reddit-rapport dat beweert dat een open-weight model van 22GB beter presteert dan een frontier coding model bij het oplossen van bugs, samen met een begeleidend artikel over wat het daadwerkelijk kost om dat model thuis te laten draaien. De benchmark vergelijkt eerder twee harnesses dan twee modellen, en het echte argument voor lokale modellen zit in data residency, niet in de ranglijst.
Bronnen: r/ClaudeCode en Alibaba Cloud-gemeenschap
Samenvatting
Een anonieme poster op r/ClaudeCode meldde dat Alibaba's Qwen3.8-27B, een open-weight model dat is gecomprimeerd tot ongeveer 22GB zodat het op één machine draait, beter presteerde dan Claude Code op Opus 5 bij hoge inspanning op recente bugfix-taken uit de praktijk. Het gemeten resultaat is twaalf oplossingen tegen elf van de eenentwintig, één seed, wat de auteur als voorlopig beschrijft, naast een geclaimd voordeel in mediane tijd tot herstel. Het model liep in Pi, een open source coding harness, en de enige wijziging aan het model zelf was een verwisselde chattemplate. De tweede bron, gepubliceerd door Alibaba Cloud, zet uiteen wat het kost om een 27B-model thuis te laten draaien: ongeveer 24GB VRAM, grofweg 1.300 tot 1.800 dollar voor een tweedehands build, 4-bit kwantisatie als het gangbare compromis, en 16GB VRAM als de maat die niet volstaat. De bron sluit af met de aanbeveling van een hosted plan van zes dollar per maand. We bespraken beide met Kishan Chamman, onze CTO.
Review en inzichten
De benchmark vergelijkt twee harnesses, en slechts bijkomstig twee modellen. Pi wordt kaal geleverd. Wie het draait, schrijft de skills, stelt de instructies in en bepaalt wat de taak eigenlijk is. Claude Code komt geconfigureerd door Anthropic aan en weet hoe het moet coderen nog voordat iemand iets heeft getypt. De vergelijking in die post gaat dus tussen een opstelling die iemand handmatig heeft afgestemd en een opstelling die zo uit de doos kwam, en het resultaat kan volkomen echt zijn terwijl het heel weinig zegt over de twee onderliggende modellen. De naaste analogie is iOS tegenover Android. De een levert een vaste set tools aan en verwacht dat die worden gebruikt zoals bedoeld. De ander komt kaal en wordt gevormd door wie de eigenaar is, wat sommige teams past en andere irriteert.
Een verandering in output kan van buitenaf niet worden herleid tot het model of tot de harness. Veel mensen hebben de indruk dat Opus 5 en Sonnet 5 breedsprakiger zijn dan 4.8, dat ze meer tokens en meer minuten besteden om op hetzelfde punt uit te komen, en die indruk delen wij. Wij kunnen het niet onderbouwen, dus blijft het een indruk. Anthropic heeft wel gepubliceerd dat de tokenizer met deze generatie is veranderd. Daarbuiten is het giswerk, omdat het model en de harness de output samen produceren en beide worden bijgewerkt volgens het schema van iemand anders. Het zelf in handen hebben van de harness dicht dat gat, en dat is een beter argument voor lokale modellen dan de kwaliteitsclaim waarop dit artikel is gebouwd.
De reden om een model op onze eigen hardware te zetten, is toegang. Sommige codebases staan op machines zonder netwerkverbinding. Een kast met een model erop kan die ruimte in worden gedragen en het werk doen waar de data al staat. Hetzelfde geldt in een gebouw met slechte wifi, iets wat vanuit een kantoor met glasvezel gemakkelijk te vergeten is. Zodra het model lokaal draait, volgt de rest vanzelf: de inferentie gebeurt op de machine, elke tussentijdse conclusie blijft op de machine, en de zorgen over training, telemetrie en guardrails die content blokkeren, zijn niet langer van toepassing. Geen van beide bronnen noemt hier iets van, omdat beide druk zijn met discussiëren over kwaliteit en prijs.
Beide bronnen vergelijken een aankoop met een prijs die gesubsidieerd wordt. Het stuk van Alibaba zet een machine van 1.300 dollar naast een abonnement van zes dollar per maand, en zes dollar per maand is niet wat het kost om die rekenkracht te leveren. Hetzelfde geldt voor de abonnementen van tweehonderd dollar die de Reddit-thread als gangbaar tarief behandelt. Wij weten hoe groot het gat is omdat wij bewust API-tarieven betalen, zodat prototypewerk buiten training blijft, en een paar prototypes liepen op tot enkele duizenden dollars aan tokens. Een abonnement en een API-sleutel kopen dezelfde rekenkracht tegen wild uiteenlopende prijzen, en de goedkope variant is een kostenpost voor klantwerving. Elke bouwen-of-abonneren-berekening die daarop rust, verschuift zodra de subsidie verschuift. Wij schreven eerder dit jaar over CAPEX en OPEX, en een machine voor lokale inferentie hoort in dat gesprek thuis, afschrijving en elektriciteit inbegrepen.
De hardware die dit aangenaam maakt, is hardware voor liefhebbers. Eén reageerder in de thread meldt goede resultaten op een RTX 4090 met een context van 200k, de duurste consumentenkaart op de markt op het moment dat die uitkwam, en nu bekleedt de 5090 die positie. Zulke kaarten zijn niet voor iedereen. Een MacBook Pro met 64GB geheugen kan een model van dit formaat draaien, en dat zal traag zijn. Daarnaast is er een beperking die in geen enkel benchmarkcijfer opduikt: een model dat in het geheugen geladen is, bezet geheugen dat de werkdag nodig heeft, en een machine die alleen de chatbot kan draaien, is een machine waarop niemand kan werken. Komt er een tweede persoon bij die er vragen aan stelt, dan stijgt de hardwarebehoefte opnieuw, ongeveer evenredig met het aantal mensen dat het gebruikt. Een lokaal model is een tool voor één gebruiker totdat iemand het in infrastructuur inbouwt.
Het moeilijke aan modernisering is menselijk, en niets hiervan raakt daaraan. Een LLM kan niet afleiden waarom dingen op een bepaalde manier zijn gedaan, zoals Kishan het in de opname verwoordde. Wij gaan nog steeds om tafel met de ontwikkelaars en teams die die beslissingen namen, en dat werk is geen greintje sneller geworden. Het voorwerk eromheen wel: een beeld vormen van een codebase, repositorygeschiedenis lezen om te zien wie welke onderdelen beheerde en wat wanneer veranderde, sneller door een documentatieset heen werken dan enig team handmatig voor elkaar krijgt. Wij benaderden dit vanuit de andere richting toen wij een beoordeling schreven van een platform dat beloofde het menselijke werk weg te engineeren, en het model naar lokale hardware verplaatsen verandert niets aan de aard van het probleem. Ook de planning blijft bij ons liggen. Een model neigt naar datgene waarop het getraind is, en het kan overgehaald worden om een onafhankelijke sparringpartner te spelen, maar er bestaat geen gouden regel voor deze beslissingen. Meerdere benaderingen zijn verdedigbaar, elk met een prijskaartje, en iemand moet beslissen welke risico's de organisatie neemt en wat zij bereid is uit te geven.
Het verband met softwaremodernisering
Het assessment is waar een lokaal model zich het eerst terugverdient, en wat het laat werken is een skill. Intern draaien wij al iets wat daar dicht bij komt: een skill die een set mappen doorloopt, de documenten daarin leest en de requirements eruit haalt, opgezet met één regel instructie. Een assessment heeft dezelfde vorm, maar dan gericht op een repository, een documentatieset en een stapel interviewtranscripten, met ons eigen assessmentframework als context waaruit het werkt. De nieuwere harnesses hebben veel minder geschreven instructie nodig dan hier vroeger voor nodig was, omdat ze het meeste ervan afleiden uit een korte set richtlijnen.
Context bepaalt grotendeels wat lokaal kan blijven. Een cloud-endpoint biedt een miljoen tokens en een goed uitgeruste lokale machine komt niet verder dan ongeveer een kwart daarvan, wat het hardst aankomt bij de assessment, het meest contexthongerige deel van het project. Het materiaal bepaalt de rest. Een organisatie die haar broncode, haar documentatie of haar opgenomen interviews het pand niet uit mag laten gaan, bevindt zich in een andere positie dan een organisatie die een zero-retention-overeenkomst heeft getekend en zich daar prettig bij voelt.
Dit is dus een beslissing per fase. Analyse van materiaal dat geen netwerkgrens mag overschrijden, kan draaien op hardware binnen die grens, trager en met minder context, en het laat een artefact achter dat de organisatie in eigendom heeft. Synthese met lange context en het zware generatiewerk blijven waar de capaciteit zit. Organisaties die de vraag één keer voor het hele project beantwoorden, eindigen ofwel met hardware die twee keer per jaar wordt gebruikt, ofwel met materiaal buiten het pand dat daar nooit weg had mogen gaan.
Afsluitende opmerkingen
De post heeft het op het belangrijkste punt bij het rechte eind. Een model dat draait op hardware die een team al bezit, kan nu echt werk verzetten aan echte code, en zes maanden geleden gold dat niet. De conclusie die eruit getrokken wordt, is een ander verhaal, want twaalf opgeloste taken tegen elf, één seed, een op maat gebouwde harness tegen een standaardversie, beslecht niets. Iemand in dezelfde thread liet de opstelling los op een React-codebase van 17.000 regels en vond hem sterk in implementatie en zwak in review, waar de belangrijkste kritieke bevinding een ontbrekend bestand was dat niet ontbrak. Het stuk van Alibaba is eerlijk over de hardware en scheef over de conclusie: het zet de kosten accuraat uiteen en beveelt vervolgens het eigen abonnement aan.
Twee dingen zijn hier het vermijden waard. Hardware kopen om iets op te lossen dat in werkelijkheid een configuratieprobleem is, is het eerste. De lokale vraag beslechten op basis van de prijzen van vandaag is het tweede, want die prijzen worden gesubsidieerd. De goedkopere zet is uitzoeken welke fasen van het werk materiaal raken dat de organisatie niet mag verlaten. Dat antwoord verloopt niet zodra het volgende model uitkomt.
Vragen waar we steeds op terugkwamen
Wat is een lokale LLM, in gewone taal? Een model waarvan de bestanden op een machine in het pand staan en dat vragen beantwoordt zonder iets over het internet te sturen. Het model in dit verhaal is ongeveer 22 gigabyte groot, wat op een goed gespecificeerde laptop of een kleine desktop past, en het draait zonder account, zonder abonnement en zonder verbinding. Het model zelf komt nog steeds ergens vandaan, want Qwen is van Alibaba, dus wat verandert is waar het draait en wie de gestelde vragen te zien krijgt. We hebben eerder gepleit voor het uitwisselbaar houden van modellen, en dit is datzelfde argument, inclusief de hardware.
Wat kost het om er zelf een te hebben? Een capabele tweedehands machine kost 1.300 tot 1.800 dollar tegen de prijzen van medio 2026, en het eerlijke bedrag omvat ook wat daarna komt. Stroom voor een machine die een werkdag lang onder belasting draait, vervanging binnen een paar jaar naarmate modellen erboven uit groeien, en de uren die iemand besteedt aan het opzetten en actueel houden ervan. Cloudtoegang voor hetzelfde werk is een maandelijkse post zonder al die bijkomstigheden. Puur op geld liggen de twee opties dicht genoeg bij elkaar dat de doorslaggevende factor meestal iets anders is.
Is het net zo goed, en is het snel genoeg? Het is een gecomprimeerde kopie van het model, dus het is meetbaar zwakker, en het is trager dan een clouddienst. Compressie, quantisatie genoemd, verkleint een model zodat het in het beschikbare geheugen past, en gepubliceerde benchmarkscores worden altijd gemeten op het ongecomprimeerde origineel. In de praktijk uit zich dat in meer fouten bij het lastigste redeneerwerk en meer variatie tussen runs van dezelfde opdracht, wat ertoe doet bij een assessment dat als basis voor een plan overeind moet blijven. Snelheid bestaat uit twee delen. Tekst komt eruit met ongeveer 26 tot 30 tokens per seconde op een gangbare opstelling, waarbij tokens ruwweg woordgrote stukjes zijn, dus het schrijft sneller dan wie dan ook leest. Het wachten zit daarvóór, want het laden van een grote set documenten in het model kan enkele minuten duren voordat het eerste woord verschijnt.
Kan een heel team op één machine werken? Niet comfortabel. Eén persoon tegelijk krijgt de hele machine, en elke extra persoon die er vragen aan stelt verhoogt de hardwarebehoefte ongeveer in gelijke mate. Daarmee is een lokaal model een hulpmiddel voor één specialist of één fase van het werk. Er iets van maken dat een afdeling samen gebruikt, betekent servers aanschaffen en beheren, en dat is een apart project met een eigen budget en een eigen eigenaar.
Moet iemand het beheren? Ja, en dit is de kostenpost die het gemakkelijkst over het hoofd wordt gezien. Een werkende opstelling bestaat uit een specifiek modelbestand, een specifieke compressie daarvan, de omgeving waarin het draait en een set instructies die het gedrag bepalen, en elk van die onderdelen kan de output ongemerkt bederven zodra het verandert. Eén tester in de door ons bekeken discussie ontdekte dat een verdwaald stukje tekst in een bestand het redeneren van het model stilzwijgend kon uitschakelen, zonder dat daar ergens iets van werd vastgelegd. Een organisatie die dit serieus aanpakt, heeft hiervoor een aangewezen eigenaar nodig, net zoals iemand eigenaar is van de buildserver.
Waar te beginnen
Voordat dit een beslissing over tooling wordt, moet een organisatie weten welke delen van haar landschap materiaal bevatten dat niet naar buiten mag, en wat een serieuze analyse van dat materiaal zou vergen. Een moderniseringsassessment levert beide op, samen met het beeld van het huidige systeem dat elk hulpmiddel, lokaal of gehost, nodig heeft voordat het iets kan bijdragen. Daar zouden wij beginnen.
Volledige video-aflevering
De eerste stap om de moderniseringsreis te starten
Softwaremodernisering en architecturale herbouw vormen de kern van Eli5. Wij lossen complexiteit op en leveren directe bedrijfswaarde door te focussen op pragmatische, cloud-native transities.
Voordat de keuze wordt gemaakt om het legacysysteem in te kapselen, een nieuw SaaS-product aan te schaffen of AI te gebruiken om eigen tools te bouwen, is volledig inzicht in het huidige technologielandschap essentieel.
Een gratis brainstorm over de legacystack is te boeken. Het is de essentiële eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.
De eerste stap naar uw modernisering
Softwaremodernisering en architectuurherbouw vormen de kern van Eli5. We halen de complexiteit weg en leveren directe businesswaarde met pragmatische, cloud-native trajecten.
Voordat u besluit of u uw legacysysteem inpakt, een SaaS-product koopt of met AI eigen tools bouwt, hebt u volledig zicht nodig op uw huidige techlandschap.
Wilt u een vrije brainstorm over uw legacystack? Dat is de eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.



