Kan lokale LLM worden gebruikt voor AI-codering? ~Samenvatting van AI-coderingstrends in juli 2026, gezien aan de hand van data~
auteur: @kotauchisunsun
Releasedatum: 2026/08/12
AI Coding Agent-trends in augustus 2026
Sinds juli 2025 exploiteren we een site genaamd AI Coding.Info.
Dit is een site die gebruikstrends met betrekking tot AI-coderingsagenten zoals Claude Code, Codex CLI, Github Copilot en Gemini observeert vanaf een vast punt op basis van informatie in Github-opslagplaatsen. Om het gebruik van AI Coding Agent te bepalen, voeren we dagelijks enquêtes uit onder de volgende omstandigheden.
- Dagelijkse inspectie van 9.000 openbare repositories op Github
- TOP 300 Github-sterren per programmeertaal
- Onderzoek gedaan vanuit 30 soorten programmeertalen
- Richt zich op 16 soorten AI-coderingsagenten
- Alleen wanneer de regelbestanden die door verschillende AI Coding Agents worden gebruikt zich in de Github-repository bevinden, wordt vastgesteld dat AI Coding Agent wordt gebruikt.
Trends van afgelopen maand
https://ai-coding.info/reports/articles/20260703
Het gebruikspercentage van AI-coderingsagenten is 13,0%
De bezettingsgraad van de AI Coding Agent-repository was 13,0%, een stijging van 0,9% ten opzichte van de 12,1% de vorige keer.
Gebruikspercentage van AI Coding Agent op 1/8/2026
https://ai-coding.info/?date=2026-08-01#adoption-rate
Gebruikspercentage van AI Coding Agent op 1 juli 2026
https://ai-coding.info/?date=2026-07-01#adoption-rate
Trends in het gebruikspercentage van AI Coding Agent van 1/7/2026 tot 1/8/2026
https://ai-coding.info/?date=2026-04-01&since=2026-07-01&until=2026-08-01#share-trend
Aandeel van AI-coderingsagent per product
Het aandeel per product is als volgt.
| Ranglijst | Productnaam | Aandeeltarief |
|---|---|---|
| 1e plaats | Codex-CLI | 40,8% |
| 2e plaats | Claude Code | 32,0% |
| 3e plaats | Copilootagent | 15,1% |
| 4e plaats | Tweelingen CLI (Antizwaartekracht) | 5,3% |
| 5e plaats | Cursor | 4,4% |
Terwijl het aandeel van Codex CLI toeneemt, blijft Claude Code hetzelfde. Copilot Agent en Gemini CLI (Antigravity) laten ook een lichte daling zien. Cursor is iets waar ik een beetje aandacht aan heb besteed. Cursor wordt overgenomen door SpaceX. Er was nieuws.
https://www.nikkei.com/article/DGXZQOGN16BC70W6A610C2000000/
Zal er daarom een verandering plaatsvinden in de aandelenkoers van deze Cursor? Dat dacht ik ook, maar vorige maand was het 4,7% en deze maand was het 4,4%, dus er is niet zoveel verandering. Kijkend naar het aantal hieronder genoemde opslagplaatsen: op 1 juli waren er 85 opslagplaatsen die Cursor adopteerden, en op 1 augustus blijft het aantal ongewijzigd op 85. Wat dit fenomeen betreft, is de populatie van opslagplaatsen die AI Coding Agent gebruiken over het geheel genomen toegenomen, maar het aantal Cursor-gebruik is niet toegenomen. Als gevolg hiervan daalt het totale marktaandeel. Dit is een fenomeen geworden. Vanwege de kenmerken van AI Coding.Info-onderzoek zal het aantal opslagplaatsen met Cursor-specifieke configuratiebestanden (.cursor) echter niet veranderen. Dat gezegd hebbende, ondersteunt Cursor zelf AGENTS.md. AI Coding.Info stelt dat het aantal repository's met AGENTS.md = het aantal Codex CLI-adoptie, dus hoewel Cursor wordt gebruikt, is het mogelijk dat het wordt meegeteld als Codex CLI, en bestaat de mogelijkheid dat het aantal toepassingen op een onzichtbaar deel toeneemt.
Aandelenkoers AI Coding Agent op 1-8-2026
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#agent-share
Aandelenkoers AI Coding Agent op 1/7/2026
https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#agent-share
AI Coding Agent-gebruiksstatus per programmeertaal
De programmeertaal waarin AI Coding Agent het meest wordt gebruikt is 'TypeScript', de tweede is 'Python', de derde is 'Rust', de vierde is 'Go' en de vijfde is 'C#'. De acceptatiegraad van AI-codering voor TypeScript blijft hoog, terwijl de samenstelling van Python'', Rust'' en Go'' als tweede groep, en C#'' als derde groep de afgelopen jaren een consistente trend is geweest.
Rangschikking van AI Coding Agent per programmeertaal op 1-8-2026
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#language-agent-rank
Ranglijst AI Coding Agent per programmeertaal op 1 juli 2026
https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#language-agent-rank
Maandelijkse trends in het aantal repositories dat door AI Coding Agent wordt gebruikt
Het aantal opslagplaatsen bedroeg 1.794 op 1-7-2026, maar is gestegen tot 1.940 op 1-8-2026, en het aantal opslagplaatsen dat gebruikmaakt van AI Coding Agent is met 146 toegenomen.
Veranderingen in het aantal opslagplaatsen dat AI Coding Agent gebruikt van 1/7/2026 tot 1/8/2026
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#time-based-bar-chart
Kan lokale LLM worden gebruikt voor AI-codering?
In juni werd de volgende generatie LLM's, Mythos en Fable 5, uitgebracht door Claude en schokte de industrie met hun prestaties. Daarna bracht het Chinese bedrijf Kimi echter een model met open gewicht uit, genaamd Kimi-K3, dat bijna een Fable-klasse is. Dat werd een hot topic. Zelfs als we naar de daadwerkelijke benchmarks kijken, liggen de cijfers dichtbij.
https://artificialanalysis.ai/#intelligence-category-tabs
Toen ik dat dacht,
**Is lokale LLM niet ook een optie voor AI-codering? **
Ik denk dat jij dat misschien wel denkt. Ik heb dat gebied onderzocht. In de onderstaande tabel staan de belangrijkste LLM-modellen met open gewicht uit de bovenstaande grafiek.
| Modelnaam | Bedrijfsnaam | Aankondigingsdatum | Aantal parameters | Aantal actieve parameters | Contextlengte | Intelligentie-index |
|---|---|---|---|---|---|---|
| Kimi K3(max) | Kimi(China) | 2026/07 | 2.800 miljard | 104B | 1M | 60 |
| GLM-5.2(max) | Z AI(China) | 2026/06 | 756B | 40B | 1M | 53 |
| DeepSeek V4 Flash 0731 | DeepSeek(China) | 2026/07 | 284B | 13B | 1M | 52 |
| MiMo-V2.5-Pro | Xiaomi(China) | 2026/04 | 1.023 miljard | 42B | 1M | 43 |
| Muse Glimmer (hoog) | Meta(VS) | 2026/08 | 30B | 256K | 35 | |
| Gemma 4 31B (redenering) | Google (VS) | 2026/04 | 30,7B | 256K | 30 |
Maar werken deze ook daadwerkelijk op uw pc? Ik begrijp dat niet echt. Daarom was de bepalingsmethode die we overwogen
Het vereiste VRAM-geheugen is
2[GB] per parameter 1[B]
is. Of het werkt, kunt u grofweg inschatten op basis van de VRAM-geheugencapaciteit van uw pc en het aantal parameters van het model dat u wilt gebruiken. daarom,
** Wiskundig gezien is er 5,6 TB (5.600 GB) geheugen vereist om Kimi-K3 te gebruiken. **
De reden hiervoor zal ik uitleggen. In het standaard gedistribueerde LLM-model worden gewichten uitgedrukt in decimale getallen met een nauwkeurigheid van bf16 of fp16. Deze vereisen 2 bytes voor elke parameter. De notatie die je vaak ziet, zoals 30[B], is het aantal parameters, en B staat voor miljard en vertegenwoordigt 10^9. Daarom is te zien dat een model zoals 30[B] 30×10^9 gewichtsgegevens heeft. En 1[GB]=1*10^9[Byte]. Als we er op die manier over nadenken, hebben we eerder vermeld dat standaardgewichten worden opgeslagen in 2 bytes, dus er zijn 2 bytes per gewicht nodig, wat 2 [GB] betekent om 1 [B]-parameters in het geheugen op te slaan. Dit is de berekening. Dit is de eerder genoemde betekenis van "2[GB] per parameter 1[B]". Dit is echter slechts een benadering; dit is de minimale vereiste om de gewichten in VRAM te laden, en aangezien er daarnaast geheugen kan worden gebruikt, is het ten strengste raadzaam dit niet te overschrijden. Dit is de VRAM-capaciteit.
Dit is waar het concept van kwantisering in het spel komt. Mogelijk heb je Q4_0 of Q4_K_M gezien. Dit is een techniek die het gewicht comprimeert tot het aantal bits. Daarom is in het geval van Q4_0 de gewichtscapaciteit grofweg 4 bits (het vierde deel van Q4_0). Daarom bedraagt de capaciteit in dit geval 0,5[GB] per 1[B]. Een snelle referentietabel hiervan ziet er als volgt uit:
| Kwantiseringsmethode | Vereiste hoeveelheid geheugen per 1[B] [GB] |
|---|---|
| bf16,fp16(standaard) | 2.0 |
| Q8_0 | 1,0 |
| Q4_0 | 0,5 |
Mogelijk ziet u een notatie als Q4_K_M, maar grofweg is het een model dat de nauwkeurigheid verhoogt in vergelijking met Q4_0, maar iets meer geheugencapaciteit gebruikt. Het is goed om je hiervan bewust te zijn. Er is een andere manier om dit te weten te komen: kijk eenvoudigweg naar de bestandsgrootte van het gewichtsbestand (safetensor of gguf). Als dit de VRAM-geheugencapaciteit overschrijdt, zal het over het algemeen niet werken. Ik denk dat jij dat wel kunt denken.
Vanaf hier hebben we een snelle referentietabel gemaakt van de hoeveelheid VRAM-geheugen, de kwantiseringsmethode en het aantal parameters.
| VRAM-geheugencapaciteit [GB] | Aantal parameters (bf16,fp16)[B] | Aantal parameters (Q8_0)[B] | Aantal parameters (Q4_0)[B] |
|---|---|---|---|
| 8 | 4 | 8 | 16 |
| 16 | 8 | 16 | 32 |
| 24 | 12 | 24 | 48 |
| 32 | 16 | 32 | 64 |
| 64 | 32 | 64 | 128 |
| 128 | 64 | 128 | 256 |
| 256 | 128 | 256 | 512 |
| 512 | 256 | 512 | 1024 |
| 1024 | 512 | 1024 | 2048 |
| 2048 | 1024 | 2048 | 4096 |
Hoe lang kan dit ongeveer gedaan worden? Gezien het feit dat, als het een model is met 8 GB VRAM, het een RTX 5050 zal zijn, en de Amazon-prijs 55.000 yen is. Dit zou kunnen werken als het model ongeveer 8[B] gekwantiseerd is met Q8_0. Dat is het niveau.
Wanneer het VRAM toeneemt naar 16GB, wordt het een model rond de RTX 5060 Ti, die ongeveer 108.000 yen kost. Op dit punt zal, met Q4_0-kwantisering, een LLM van klasse 30[B] werken of niet. Dat is het niveau.
Wanneer het VRAM toeneemt tot 32 GB, wordt het het vlaggenschipmodel van de RTX 5090 en kost het 795.000 yen. Als het hierop aankomt, denk ik dat het op een niveau is waarop je het niet kunt doen, tenzij je veel vastberadenheid hebt. Ik denk het wel. Dit is de kwantisering van Q8_0, en of het 30[B] klassenmodel werkt of niet. Het zal ongeveer hetzelfde niveau zijn.
Dit gebied is de bovenste regel op het niveau van consumentenproducten. Als het op professioneel niveau aankomt, is de RTX PRO 6000 Blackwell uitgerust met 96 GB geheugen. **De prijs is 2,35 miljoen yen. ** Hier werkt, zelfs op het Q4_0-kwantiseringsniveau, alleen het 192[B]-model, dus het vlaggenschipmodel werkt niet.
En aangezien er gegevens waren voor het GPU-cluster dat op de server moest worden geïnstalleerd, zal ik deze alleen ter referentie plaatsen. In het geval van NVIDIA B300 is het geheugen 288 GB en is de prijs 8,63 miljoen yen. Als dit het geval is, kan DeepSeek V4 Flash 0731 met Q8_0-kwantisering werken. Q4_0 zal werken. Als je er twee hebt (equivalent aan 17 miljoen yen), kan MiMo-V2.5-Pro met Q4_0-kwantisering werken.
https://www.nttpc.co.jp/cgi-bin/gpu/simulation/custom/index.cgi
Daarom, als je de hoeveelheid geheugen en het aantal parameters vergelijkt, is dit het ongeveer. Natuurlijk valt er over meer te discussiëren dan dit, en of dit wel of niet in het geheugen zal worden opgenomen. Genereert het voldoende TOK/s om normaal te worden gebruikt? Er is nog een probleem. Dit artikel gaat over de basisprincipes. LLM heeft architecturen genaamd Dense en MoE, en in MoE worden alleen de actieve parameters daadwerkelijk berekend, en afhankelijk van de uitvoeringsmethode is er een manier om de hoeveelheid fysiek geheugen te verminderen door de benodigde experts uit de opslag uit te lezen, enz., in plaats van alle experts voortdurend in het geheugen op te slaan. Er zijn echter enkele speciale aspecten aan de manier waarop het model wordt uitgevoerd, en het laden van opslag naar geheugen kan een knelpunt worden. Er zijn enkele van dit soort verhalen, maar hier negeren we dergelijke details en beschouwen we eenvoudigweg de capaciteit wanneer alle gewichten van het model in het geheugen zijn opgeslagen.
Dus als je het huidige gekwantiseerde vlaggenschipmodel Q4_0 of Q8_0 wilt gebruiken, heb je een machine nodig die minstens 10 miljoen yen kost. Dat is het gevoel ervan. Aan de andere kant kan het werken als je speciale hardware gebruikt om een nog grotere kwantisering te bereiken. Er zijn bijvoorbeeld mensen die 2-bits kwantisering en 3-bits kwantisering uitvoeren op de M4 Mac met 128 GB geheugen (uitverkocht) en DGX Spark (128 GB geheugen).
https://zenn.dev/tkhr_sait/articles/20260508_try-local-deepseek-v4
https://dev.classmethod.jp/articles/dgx-spark-deepseek-v4-flash-0731-llama-cpp/
Aan de andere kant is dit waarschijnlijk de limiet voor een individu. Het is een huidgevoel. Persoonlijk let ik op 1-bit kwantisering. Beroemde modellen zijn onder meer Bonsai en technologie zoals BitNet, maar de knowhow voor 1-bit-kwantisering is niet openbaar gemaakt, dus ik heb het niet geprobeerd (het zou waarschijnlijk enorm veel tijd kosten en de nauwkeurigheid van de gevolgtrekkingen verminderen).
Dus persoonlijk, als er een 1-bit gekwantiseerde versie van DeepSeek (ongeveer 35,5 GB) zou worden uitgebracht, zou ik een wereld kunnen zien waarin het lokaal zou kunnen worden uitgevoerd op een GPU van consumentenkwaliteit, afhankelijk van wat vindingrijkheid, maar omdat we dat momenteel niet hebben, is het behoorlijk moeilijk. Dat is de eerlijke waarheid.
Daarom,
**Het is niet realistisch om het vlaggenschipmodel met een lokale LLM te gebruiken. **
Dat is mijn algemene indruk. Als je echt wilt dat het werkt, denk ik dat je wat tests moet doen.
gedachten
Deze keer concentreerde ik mijn lezing op de lokale LLM. Toen Kimi-K3 uitkwam, was ik behoorlijk geschokt en de Fable-klas verhuisde naar de plaatselijke LLM! Het was behoorlijk indrukwekkend, maar ik kan het niet eens verplaatsen met de apparatuur die ik heb. Dat was mijn eerlijke indruk. Ik heb in het verleden een artikel over lokale LLM gepost, maar dat werkte toen niet zo goed, dus ik zou er zelf graag wat dieper op willen ingaan. Dat dacht ik.