Lokal AI eller moln-AI i appbyggare: kostnad, integritet och hastighet

Den strukturella skillnaden

Nästan varje AI-appbyggare skickar din prompt till en modell som drivs av tredje part, får tillbaka kod och fakturerar dig för det. Den designen får konsekvenser som inte har med produktkvalitet att göra: varje generering kostar leverantören pengar, alltså mäts varje generering. Dina prompter, och ofta koden som skapas av dem, passerar infrastruktur du inte kontrollerar.

Lokal generering vänder på det. Modellfilen laddas ner till webbläsarens cache en gång och körs sedan på ditt eget grafikkort via WebGPU. Prompten lämnar aldrig datorn, och marginalkostnaden för en generering är din egen elräkning.

Kostnad

Molngenerering mäts för att den måste mätas – leverantören betalar en API-räkning för varje anrop. Det är därför gratisnivåer är små och tung användning trycker upp dig genom prisplanerna.

Lokal generering har ingen kostnad per anrop att skicka vidare, vilket är skälet till att den kan erbjudas utan tak. Bytet sker i förväg: en modellnedladdning på några hundra megabyte upp till några gigabyte, och en dator som klarar att köra den.

Vad siffrorna faktiskt är här

Abstrakta jämförelser är lätta att skriva och oanvändbara att planera efter, så här är de konkreta talen på den här plattformen.

• Gratis – 0 kr. Fem molngenereringar per månad. Obegränsad lokal generering via WebGPU. Inga AI-funktioner inuti apparna du bygger, och ingen källkodsexport.
• Premium – 179 kr per månad. Tjugofem molngenereringar, obegränsat antal sparade projekt, ZIP-export, publicering på subdomän och AI-funktioner tillgängliga inuti dina genererade appar.
• Pro – 299 kr per månad. Femtio molngenereringar, de större lokala modellerna, Shopify, egna domäner, webhooks och Fortnox samt automatiska SEO-granskningar.

Två saker är värda att läsa två gånger. Obegränsad lokal generering är obegränsad på samtliga planer, gratisplanen inkluderad, vilket betyder att månadssiffran är en molnbudget snarare än ett användningstak. Och "AI inuti dina appar" är något annat än "AI som bygger dina appar" – window.NorthernGoAI i en genererad app är en betalfunktion som går via molnproxyn, så den som kör gratis kan bygga obegränsat lokalt men inte lansera en app som anropar en modell under körning.

Vilka modeller som faktiskt körs lokalt

Körmiljön i webbläsaren är @mlc-ai/web-llm, och modellerna är kvantiserade byggen som cachas i webbläsaren efter första nedladdningen.

• Qwen 3.5 4B – standardvalet, tillgängligt på alla planer. Den som de flesta faktiskt kommer att använda.
• Qwen 3.5 9B, Qwen 2.5 Coder 7B, Llama 3.1 8B och Ministral 3 Reasoning – större eller specialiserade modeller på Pro. Qwen 2.5 Coder är den kodtränade och är oftast den bästa i setet för att generera en app.

Kör du redan modeller på egen hårdvara kan du hoppa över webbläsarkörningen helt och rikta genereringen mot din egen Ollama i stället. Det ger dig modellval och kvantiseringar som webbläsarens cache inte kan hålla, till priset av ett genuint krångligt uppsättningssteg som handlar om CORS.

Hårdvarukravet är ett verkligt krav

WebGPU-inferens är ingen funktion som degraderar mjukt. Antingen stöder webbläsaren WebGPU och grafikkortet har tillräckligt med minne för modellen, eller så körs lokal generering inte alls.

4B-modellen går bekvämt på en modern laptop med integrerad grafik. Modellerna på 7 till 9 miljarder parametrar vill ha ett dedikerat kort med flera gigabyte ledigt grafikminne, och på mindre än det vägrar de antingen ladda eller går så långsamt att en resa till molnet hade varit snabbare. Vikterna laddas ner en gång per webbläsarprofil, inte en gång per projekt, så en annan webbläsare eller en rensad cache betyder ny nedladdning. Sitter du på surf med datatak: gör det innan du åker.

För själva mekaniken bakom att köra det här i egen kod i stället för i byggaren, se WebGPU och lokala modeller i en React-app.

Integritet

Det här är den tydligaste skillnaden och den svåraste att fejka. Vid molngenerering överförs och behandlas din prompt av en extern leverantör, oavsett vad integritetspolicyn säger om lagring. Vid lokal generering behandlas prompten av ditt eget grafikkort och inget anrop lämnar webbläsaren. För den som hanterar kunduppdrag, interna system eller reglerad data är den skillnaden ingen marknadsföringsdetalj – den avgör om verktyget alls går att använda.

Det förändrar också pappersarbetet. En molnleverantör i din genereringskedja är ett biträde du måste kunna namnge; lokal körning tar bort den posten ur listan i stället för att krympa den. Bygger du under EU-regler går GDPR-checklistan för EU-grundare igenom var det hör hemma i förhållande till datan din färdiga app samlar in – vilket i praktiken är den del tillsynsmyndigheter bryr sig betydligt mer om.

Hastighet och kvalitet – den ärliga delen

Lokala modeller är mindre än de toppmodeller som körs i molnet, och det märks. En modell på 4 miljarder parametrar som Qwen 3.5 4B är genuint bra på fristående komponenter, enklare sidor, formulär och små spel. Den är inte likvärdig med en stor molnmodell på komplex logik över flera filer, och varje jämförelse som påstår motsatsen säljer något.

Fördröjningen går åt andra hållet. När modellen väl är laddad finns ingen nätverksresa, så svaren börjar direkt och fortsätter fungera när uppkopplingen inte gör det.

Var kvalitetsskillnaden visar sig i praktiken

Att veta att små modeller är sämre är mindre användbart än att veta hur de är sämre. Genererade appar här är ett enda monolitiskt HTML-dokument – all uppmärkning, all formgivning och all logik i en fil – vilket sätter en särskild sorts press på en liten modell. Fyra felmönster återkommer.

Längd. Ett långt dokument är en lång generering, och små modeller tappar tråden eller kapar av innan de blir klara. En app med fyra vyer är där 4B-modellen börjar producera en vacker första skärm och en halvfärdig tredje.

Tillstånd som korsar vyer. Allt där en ändring i en vy måste speglas i två andra är resonemang över avstånd, och det är precis vad antalet parametrar köper.

Att hålla kontraktet. Plattformens SDK injiceras i appen och ska bara anropas, aldrig byggas om. Små modeller är märkbart mer benägna att hjälpsamt skriva sin egen window.NorthernGoDB-omslutning med fetch i stället för att använda den som redan finns, vilket ger en app som ser rätt ut och inte sparar någonting.

Långa instruktioner. Systemreglerna som håller genererade appar konsekventa är långa. En toppmodell håller alla i huvudet; en 4B-modell följer de första och glömmer resten.

Inget av det gör lokal generering oanvändbar. Det gör den till ett bra verktyg för en avgränsad uppgift och ett dåligt för ett ambitiöst första utkast.

Agenterna är inte desamma på varje motor

Molnvägen använder tre specialiserade roller: en Arkitekt som planerar strukturen, en Byggare som skriver koden och en Granskare som kan försöka laga mekaniska skador. Den granskningen lägger inte till resonemang som Byggaren aldrig gjorde.

Lokalt körs Byggaren på ditt grafikkort. En kort följdfråga från Arkitekten kan också köras lokalt. På Premium eller Pro kan ett nytt lokalt bygge fortfarande be molnet om en strukturskiss när du är online (hoppas över utan nät, på Gratis och vid uppdateringar). Det finns ingen LLM-granskare som skriver om koden på den lokala vägen — en syntaxkontroll stoppar JavaScript som inte går att tolka; den lagar inte logik. En trasig app från en liten modell förblir en app från en liten modell.

Vad som är identiskt oavsett vilken motor du använder

Det här är delen som gör valet lågriskabelt, och den är värd att säga rakt ut eftersom den är ovanlig.

Resultatet har samma form åt båda hållen. Samma enskilda HTML-dokument, samma vanliga JavaScript, samma Tailwind från CDN och samma injicerade SDK – window.NorthernGoDB för den inbyggda Supabase-databasen och inloggningen, window.NorthernGo för e-post och export till CSV eller Word, och samma vägar för publicering och export. Det finns inget filformat som bara finns lokalt och ingen projekttyp som bara finns i molnet.

Motorn är alltså ett beslut per generering, inte ett arkitektoniskt beslut. Du kan starta ett projekt med den lokala modellen, byta till molnet för ett svårt steg och byta tillbaka, utan att något i projektet behöver migreras. Det betyder också att motorvalet inte har någon betydelse för om du kan lämna med din kod, vilket är en annan fråga och en viktigare.

Ett arbetsflöde som använder båda ordentligt

Mönstret som slösar minst ser ungefär ut så här. Gör det första strukturella passet i molnet, där resonemangskvaliteten är värd sin kostnad, och landa en arkitektur du är nöjd med. Iterera sedan lokalt för allt kosmetiskt och stegvist – texter, färger, ett extra fält, ett nytt kort – eftersom det är exakt de avgränsade uppgifter en liten modell klarar bra och exakt de ändringar du gör trettio gånger. Gå tillbaka till molnet först vid nästa genuint strukturella ändring.

Ett par saker kräver dessutom molnet. Bildgenerering och bildanalys går via molnet oavsett vilken motor du genererar kod med, och detsamma gäller uppladdade dokument. Behöver din app en genererad hero-bild är det ett molnanrop hur du än föredrar att bygga.

Hur du väljer

Den användbara frågan är inte vilket som är bäst, utan vilket som passar uppgiften. Använd lokal generering för snabb iteration, för allt som rör känsligt underlag, för obegränsat experimenterande och för arbete offline. Använd molngenerering när du behöver maximal resonemangskvalitet i ett komplext bygge. En plattform som erbjuder båda låter dig välja per uppgift i stället för att låsa dig vid en kompromiss.