Små och lokala LLM är ofta inramade som ett billigt alternativ till gränsmodeller. Att inramning är fel. De är inte en degraderad version av samma sak. De är ett annat arkitektoniskt val, valt för kontroll, förutsägbarhet, och Survivalable fellägen.

Jag är lika skyldig som vem som helst för att driva "de är fria" berättande ... som om det var den enda avgörande faktorn. Men som att välja en databas / hosting plattform för ett system du behöver för att förstå Vilka kompromisser du gör.

Använda en liten modell via Ollama Ordförande, L.M. Studio, ONNX körtid, eller liknande handlar inte om att spara pengar. Det handlar om att välja där icke-determinism tillåts förekomma.

Den verkliga skillnaden: Misslyckandelägen

Stora gränsmodeller är bredare och mer flytande. De förtätar mer av mänskligt uttryckt logik, spänner över fler domäner, och producerar mer övertygande resonemang spår. Det gör dem också farligare i system som kräver garantier.

Gränsmodeller är förnuftiga när bredd krävs och utgångar är rådgivande genom design - kreativ utformning, öppen prospektering, eller syntes över okända domäner. Men det är inte de flesta produktionssystem.

Deras misslyckanden är Semantisk snarare än strukturell. Detta är kategorin fel: behandla en probabilistisk komponent som om det vore en systemgräns. De genererar giltiga utseende utgångar som är fel på subtila sätt. Dessa misslyckanden är:

• Dyrt att upptäcka
• Dyrt att felsöka
• Ofta endast synlig efter skada görs

Små modeller misslyckas annorlunda.

När en liten modell är förvirrad, tenderar den att:

• Bryt scheman
• Emit ogiltig JSON
• Trunkera utgångar
• Förlust av struktur

Dessa är billiga misslyckanden. De är detekterbara med enkel validering. De utlöser retries eller reserv omedelbart. De avancerar inte tyst tillstånd.

Detta är ingen svaghet, det är ett drag.

Varifrån denna princip kommer

Denna insikt är inte abstrakt teori - det är grunden för Tio bud om användning av LLM. – Huvudprincipen:

LLM tolkar verkligheten. De får aldrig tillåtas definiera den.

När du följer denna princip, upptäcker du något överraskande: du slutar behöva dyra modeller. En 7B-parametermodell som kör lokalt kan klassificera, sammanfatta och generera hypoteser bara bra - eftersom deterministiska system runt det hanterar allt som faktiskt behöver vara korrekt.

Små modeller är inte "svaga" - de är ofta tillräckligt eftersom problemet redan har minskats när det når dem.

Gränsmodellerna säljer dig pålitlighet du bör bygga själv.

Den rätta mentala modellen

Precis som DuckDB inte är "billig SQL" och Postgres är inte "worse Azure SQL", små LLMs upptar en olika punkt i designutrymmetDu väljer dem när:

Bekymra sig om en liten modellfördel |---------|----------------------| | Plats Körs på din hårdvara, ditt nätverk, din jurisdiktion | Revisionsförmåga Varje slutsats är loggad, reproducerbar, inspekteras | Blastradie Misslyckanden är inneslutna, inte förökade genom API-kedjor | Korrekt tillämpning till Validering sker utanför modellen på | Gränslös icke-determinism Osäkerhet är strängt begränsad på grund av bristande säkerhet

Hur jag använder detta i praktiken

Mina projekt visar det här mönstret flera gånger:

GrafRAG med tre extraktionslägen

Mitt GraphRAG genomförande erbjuder tre lägen:

LLM anropar på bästa sätt |------|-----------|----------| | Heuristisk till 0 per styck och ren determinism via IDF + struktur och | Hybrid 1 per dokument och liten modell validerar kandidater | LLM Ordförande till 2 per styck med maximal kvalitet vid behov på plats

och hybridläge är den söta platsen: heuristisk utvinning finner kandidater (deterministiska), sedan en liten lokal modell validerar och berikar dem. En LLM samtal per dokument, inte per bit.

Med Ollama kör lokalt, kostnaden är $0. Men det är inte därför jag använder det - kostnadsbesparingar är en bieffekt av korrekt abstraktion, inte målet. Jag använder det eftersom misslyckandena är billiga och uppenbara.

ONNX Embeddings: Ingen LLM krävs

Semantisk sökning med ONNX och Qdrant visar ett annat mönster: vissa uppgifter behöver inte en LLM alls. BERT inbäddningar via ONNX Runtime ger dig:

• CPU-vänlig slutledning - ingen GPU krävs
• Deterministiska resultat - samma insats ger alltid samma inbäddning
• Lokalt genomförande - inga API-samtal, ingen latens, inga prisgränser
• En modell på 90 MB - Springer var som helst.

För hybridsökning, Jag kombinerar dessa inbäddningar med BM25 scoring. LLM visas bara vid syntestid - och även då, en liten lokal modell fungerar bra eftersom det är förklarar Struktur som deterministiska system redan har validerat.

DocSummarizer: Struktur först, LLM andra

DocSummarizer Ordförande förkroppsligar denna filosofi:

1. Prövning i sak dokument med deterministiska bibliotek (OpenXML, Markdig)
2. Kryddnejlikor innehåll med hjälp av strukturella regler (rubriker, stycken, kodblock)
3. Bäddning bitar med ONNX BERT
4. Hämta relevanta bitar via vektorsökning
5. Syntes med Ollama - det enda probabilistiska steget

Den LLM är den sista steget, arbetar med förvalt, förstrukturerat innehåll. Det kan misslyckas - och när det gör det, misslyckandet är uppenbart eftersom strukturen redan är korrekt.

TinyLM: Lokal chatt med gränser

Liten MJÖLM visar lokal LLM-användning i en Windows-skrivbordsapp. Den stöder:

• Ollama- gränssnittName
• Direkt GGUF-modellbelastning
• RAG-minne (med deterministisk hämtning)

Chattgränssnittet är probabilistiskt. Minnet, filhanteringen och statsförvaltningen är deterministiska. Misslyckande i den ena korrumperar inte den andra.

De tre frågorna

Frontier modeller är kraftfulla verktyg när de används avsiktligt. Men de ökar uttryckskraft snabbare än de minskar risken. Små modeller, när inbäddade i deterministiska system, ger dig bara tillräckligt med osäkerhet för att utforska - utan att fördunkla sanning eller ansvar.

Den rätta frågan är inte "vilken modell är bäst?"

Det är:

1. Var hör sannolikheten hemma?
2. Var måste determinismen vara absolut?
3. Vilka misslyckanden kan detta system överleva?

Om svaret innebär tillstånd, biverkningar, pengar, politik eller garantier - modellen ska aldrig vara ansvarig. Och om modellen bara finns där för att klassificera, sammanfatta, rangordna, eller föreslå hypoteser, är en liten lokal modell ofta Rätt val, inte den ekonomiska.

Mönstret: Tråkig maskin + liten modell

Detta är arkitekturen som fungerar:

┌─────────────────────────────────────────────────────┐
│                 DETERMINISTIC LAYER                 │
│  State machines, queues, validation, storage        │
│  (DuckDB, Postgres, Redis, file systems)           │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                   INTERFACE LAYER                   │
│  Schema validation, retries, fallbacks             │
│  (Polly, FluentValidation, custom guards)          │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                  PROBABILISTIC LAYER                │
│  Classification, summarisation, hypothesis gen     │
│  (Ollama, ONNX, small local models)                │
└─────────────────────────────────────────────────────┘

LLM är på nederst, inte toppen. Det föreslår; de deterministiska lager disponera.

Tillförlitlighet handlar inte om att undvika misslyckanden

Alla tre perspektiv - frågorna, mönstret och denna slutliga princip - reduceras till samma regel:

Tillförlitlighet handlar om att välja misslyckanden du kan överleva.

Med LLMs innebär det att hantera icke-determinism genom deterministiska metoder:

• Budord I: Staten bor utanför modellen
• Budord VII: Gör fel högt och tråkigt
• Budord IX: Bygga tråkiga maskiner först

Små modeller gör detta lättare eftersom deras misslyckanden är högt. Ogiltig JSON. Trunkerad utgång. Schema överträdelser. Detta är gåvor - de säger omedelbart att något gick fel.

Gränsmodellfel är tystFörtroende hallucinationer. Semantisk drift som bara blir synlig när en kund klagar eller en revision misslyckas.

Jag kommer att ta högljudda misslyckanden varje gång.

Relaterad läsning

Filosofin

• Tio bud om användning av LLM - Principerna bakom detta tillvägagångssätt
• Varför jag inte använder LangChain - Ramens komplexitet vs. tydlighet
• Varför kommersiella AI-projekt är dumma - Fallet för lokal-första AI

Genomförande

• DiagramRAG: Minsta möjliga genomförande - Tre extraktionsmetoder i praktiken
• Semantisk sökning med ONNX och Qdrant - CPU-vänliga inbäddningar
• DocSummarizer- verktyg - Struktur först, LLM andra
• Hybridsökning och automatisk indexering - Produktionsklar sökning

Arkitekturen

• DiSE: Behandla LLM:er som opålitliga - "Otillförlitliga gudar"-mönstret.
• Bot-detektion med LLM-rådgivare - LLM som rådgivare, inte controller
• Noll PII-kundinformation - Semantisk förståelse med gränser

Externa resurser

• Ollama Ordförande - Kör LLMs lokalt med ett kommando
• ONNX körtid - Plattformsöverskridande ML-slutsats
• LM Studio (LM Studio) - Desktop app för lokala LLMs
• lama.cpp - Effektiv C++ slutledning