Edge AI Inference: Modellkjøring i CDN-laget
Det raskeste inference-kallet er det som aldri krysser et hav. Edge AI flytter kvantiserte modeller til CDN-laget -- Cloudflare Workers AI, Deno, Vercel -- og plasserer intelligens på samme nivå som statiske ressurser. Dette er en produksjonsguide for når det fungerer, når det feiler, og hva det faktisk koster.
Innholdsfortegnelse
Det raskeste inference-kallet er det som aldri krysser et hav.
I to tiår eksisterte CDN-er for å cache bytes: bilder, skript, HTML-fragmenter. Kontrakten var enkel. Plasser statisk innhold nær brukeren. Reduser rundturstid. Fakturer per gigabyte.
Den kontrakten har endret seg. CDN-laget kjører nå modeller. Ikke lekedemoer. Produksjonsklassifiserere, embedding-generatorer, PII-detektorer, innholdsmoderering. Små modeller, aggressivt kvantiserte, som kjører på samme nettverksnivå der CSS-filene dine bor.
Dette er ikke et teoretisk skifte. Cloudflare Workers AI leverer inference fra over 300 datasentre. Deno Deploy kjører ONNX-modeller på edge. Vercel leverer AI SDK-hjelpere som fronter edge-distribuerte funksjoner. Infrastrukturen er reell. Spørsmålet er ikke lenger «kan vi?» men «når bør vi, og hva gir vi opp?»
Vi har kjørt edge inference i produksjon for klassifiserings- og embedding-arbeidsbelastninger. Denne artikkelen er det vi lærte: arkitekturen, kostnadsmodellen, kvantiseringsavveiningene, og de operasjonelle mønstrene som overlever kontakt med reell trafikk.
I. Latensargumentet
Latens er ikke et tall. Det er en brukeropplevelse.
Et sentralisert GPU-kluster i us-east-1 leverer første-token-latens på 200-800ms for et typisk LLM-kall. Legg til nettverkstransitt for en bruker i Oslo, og du ser på 300-1000ms før den første byten med intelligens ankommer. For en bruker i São Paulo, doble det.
Edge inference endrer regnestykket:
Sentralisert (us-east-1):
Bruker (Oslo) -> CDN edge (Oslo) -> Origin (Virginia) -> GPU-kluster -> tilbake
Nettverks-RTT: ~120ms * 2 = ~240ms
Inference: ~200-600ms
Total TTFT: ~440-840ms
Edge inference:
Bruker (Oslo) -> CDN edge (Oslo) -> lokal modell -> tilbake
Nettverks-RTT: ~5ms * 2 = ~10ms
Inference: ~50-300ms (kvantisert, liten modell)
Total TTFT: ~60-310ms
For klassifiseringsoppgaver -- «er denne kommentaren giftig?», «hvilket språk er dette?», «inneholder dette PII?» -- er edge-banen 3-8 ganger raskere. Ikke fordi modellen er raskere. Fordi nettverket forsvant.
Første-token-latens betyr mest for interaktive flyter: autofullføring, inline-moderering, sanntidsklassifisering, embedding-generering for søk-mens-du-skriver. Dette er oppgavene der 400ms føles ødelagt og 60ms føles umiddelbart. Den menneskelige perseptuelle terskelen for «øyeblikkelig» er omtrent 100ms. Edge inference bringer deg under den for de rette arbeidsbelastningene.
For langformgenerering -- sammendrag over flere avsnitt, kodefullføring, resonnementskjeder -- er edge-historien svakere. Du trenger større modeller, lengre kontekstvinduer og mer minne enn edge-noder typisk tilbyr. Latensfordelen eksisterer, men overskygges av genereringstiden.
Kjenn formen på arbeidsbelastningen din før du velger topologien.
II. Hva «edge» faktisk betyr i 2026
Ordet «edge» er overbelastet til det meningsløse. La oss være presise.
CDN edge-noder er lette beregningsinstanser som kjører i Points of Presence (PoP-er) -- de samme datasentrene som serverer cachede ressurser. De har begrenset minne (128MB-512MB per isolat), begrenset kjøretid (typisk 30s-50ms CPU-tidsbudsjetter), og ingen permanent GPU. Inference kjører på CPU-er eller, i økende grad, spesialbygde akseleratorer samlokalisert med CDN-infrastruktur.
Regional edge er noe annet. Dette er fulle beregningsregioner nærmere brukerne enn en enkelt sentralisert sky, men ikke så distribuert som CDN PoP-er. Tenk Fly.io-maskiner, Railway-regioner eller AWS Local Zones.
På enheten er den ultimate edge: brukerens nettleser eller telefon. WebGPU inference, Core ML, ONNX Runtime Web.
Denne artikkelen fokuserer primært på CDN-lag-edge -- det mest begrensede og mest distribuerte nivået. Mønstrene gjelder, med modifikasjoner, for regional edge og på-enhet.
Distribusjon vs. kapasitet:
CDN Edge (300+ PoP-er) | Lavest latens, minste modeller
Regional Edge (20-50) | Mer minne, mellomstore modeller
Sentralisert sky (3-8) | Full GPU, største modeller
───────────────────────────┼─────────────────────────────────
Flere lokasjoner | Mer kapasitet
III. Modellkvantisering: Kunsten å degradere kontrollert
Du kan ikke kjøre en modell med 7 milliarder parametre i float32 på CDN edge. Matematikken er ubarmhjertig: 7B parametre * 4 bytes = 28GB. En Cloudflare Worker får 128MB.
Kvantisering er broen. Reduser presisjon, reduser størrelse, aksepter noe kvalitetstap. Spørsmålet er alltid: hvor mye kvalitet ofrer du, og kan applikasjonen din tolerere det?
Kvantiseringslandskapet
INT8 -- 8-bits heltallskvantisering. Kutter modellstørrelsen med ~4x sammenlignet med float32. Kvalitetstap er typisk 1-3% på standardbenchmarks. Dette er det konservative valget. De fleste modeller overlever INT8 uten meningsfull degradering for klassifisering, embedding og kortgenereringsoppgaver.
INT4 -- 4-bits kvantisering. Kutter størrelsen med ~8x. Kvalitetstap er 3-8% avhengig av modell og oppgave. Brukbart for klassifisering og embedding. Risikabelt for nyansert generering.
GPTQ (Post-Training Quantization) -- En kalibreringsbasert metode som finner optimale kvantiseringsparametre ved hjelp av et lite kalibreringsdatasett. Produserer høykvalitets INT4-modeller. Standarden for offline kvantisering av store språkmodeller.
AWQ (Activation-Aware Weight Quantization) -- Beskytter den 1% av «fremtredende» vekter som betyr mest for modellkvaliteten, og kvantiserer alt annet aggressivt. Overgår ofte GPTQ ved samme bitbredde. Vårt standardvalg for edge-utrulling.
# Kvantisering av en modell med AWQ for edge-utrulling
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "mistralai/Mistral-7B-Instruct-v0.3"
quant_path = "mistral-7b-awq-int4"
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
quant_config = {
"zero_point": True,
"q_group_size": 128,
"w_bit": 4,
"version": "GEMM"
}
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
Praktisk veiledning
For edge inference, vår størrelsesregel:
- Under 500M parametre, INT8: Kjører komfortabelt i de fleste edge-miljøer. Embedding-modeller (BGE, E5, GTE), små klassifiserere, språkdetektorer.
- 500M-3B parametre, INT4/AWQ: Får plass i begrensede miljøer med nøye minnehåndtering. Phi-3 Mini, Gemma 2B, TinyLlama.
- 3B-7B parametre, INT4/AWQ: Krever regional edge eller generøse minnebudsjetter. Gjennomførbart på Cloudflare Workers AI (som styrer modellplassering), trangt ellers.
- Over 7B: Sentralisert. Ikke tving det.
Mål kvalitet på din faktiske oppgavefordeling, ikke på akademiske benchmarks. En modell som scorer 2% lavere på MMLU kan score 15% lavere på ditt spesifikke PII-deteksjonskorpus. Bygg oppgavespesifikke evalueringer og kjør dem mot hver kvantiseringsvariant.
IV. Cloudflare Workers AI: Arkitektur og virkelighet
Cloudflares Workers AI er den mest modne CDN-lag inference-plattformen. Å forstå arkitekturen avdekker både potensialet og begrensningene ved edge AI.
Hvordan det fungerer
Workers AI kjører ikke modeller i Worker-isolatet ditt. Worker-en din gjør et API-kall til @cf/-navneromte modeller. Cloudflare ruter kallet til nærmeste PoP som har modellen lastet. Modellen kjører på Cloudflares inference-maskinvare -- en blanding av GPU-er og spesialbygde akseleratorer distribuert over nettverket.
// Cloudflare Workers AI -- tekstklassifisering
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const { text } = await request.json<{ text: string }>();
// Klassifisering på edge
const result = await env.AI.run(
"@cf/huggingface/distilbert-sst-2",
{ text }
);
return Response.json({
label: result[0].label,
confidence: result[0].score,
served_from: request.cf?.colo // hvilken PoP håndterte dette
});
}
};
// Embedding-generering -- samme edge-bane
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const { texts } = await request.json<{ texts: string[] }>();
const embeddings = await env.AI.run(
"@cf/baai/bge-base-en-v1.5",
{ text: texts }
);
// Lagre i Vectorize eller returner direkte
return Response.json({ embeddings: embeddings.data });
}
};
Modellkatalogen
Per tidlig 2026 tilbyr Workers AI ~30 modeller på tvers av kategorier: tekstgenerering (Llama, Mistral, Phi), tekstklassifisering, embeddings (BGE, GTE), oversettelse, bildeklassifisering, tale-til-tekst (Whisper) og bildegenerering (Stable Diffusion-varianter). Katalogen vokser kvartalsvis.
Modellene er ferdigkvantiserte. Du velger ikke kvantiseringsmetode. Cloudflare optimaliserer for sin maskinvareprofil. Dette er en avveining: du mister kontroll over kvantiseringsparametre, men får automatisk distribusjon og maskinvarebevisst optimalisering.
Begrensninger du vil møte
Kaldstart. Den første forespørselen til en modell ved en gitt PoP medfører modelllastingstid -- 1-5 sekunder avhengig av modellstørrelse. Påfølgende forespørsler er raske. For latensfølsom produksjonsbruk trenger du varmestrategier: syntetiske helsesjekker, minimumsforespørselsrater eller aksept av sporadiske kaldstartstraffer.
Modellutvalg. Du kjører det Cloudflare tilbyr. Ingen tilpassede modeller (ennå). Ingen finjusterte varianter av katalogmodeller. Hvis du trenger en spesialisert modell, er Workers AI ikke veien.
Kontekstvinduer. Mindre enn sentraliserte utrullinger. Llama-modeller på Workers AI støtter typisk 2048-4096 tokens, ikke 32K-128K du får fra en dedikert vLLM-instans.
Ratebegrensninger og prising. Generøst gratisnivå (10 000 nevroner/dag), men produksjonsbelastninger trenger betalt nivå. Prising er per nevron (en Cloudflare-spesifikk enhet omtrent proporsjonal med beregning), noe som gjør kostnadsprediksjon mindre intuitivt enn per-token-prising.
Ikke streaming for alle modeller. Tekstgenerering støtter streaming; klassifiserings- og embedding-kall er kun batch-respons.
Wrangler-konfigurasjon
# wrangler.toml
name = "edge-inference-service"
main = "src/index.ts"
compatibility_date = "2026-01-01"
[ai]
binding = "AI"
Enkelt. Kompleksiteten ligger i å vite hvilke modeller du skal bruke og når du skal falle tilbake.
V. ONNX Runtime Web og WebGPU: Nettleseren som inference-motor
CDN edge er ikke den eneste edge. Nettleseren er det.
ONNX Runtime Web kjører ONNX-modeller i nettleseren ved hjelp av WebAssembly (CPU) eller WebGPU (GPU-akselerasjon). Dette er ekte på-enhet-inference -- ingen serverkall i det hele tatt. Modellen lastes ned én gang, caches i nettleseren og kjører helt klientsiden.
// Nettlesersiden inference med ONNX Runtime Web
import * as ort from 'onnxruntime-web';
// Konfigurer WebGPU-backend (faller tilbake til WASM)
ort.env.wasm.numThreads = 4;
async function classifyText(text: string): Promise<string> {
const session = await ort.InferenceSession.create(
'/models/distilbert-classification.onnx',
{ executionProviders: ['webgpu', 'wasm'] }
);
// Tokeniser (med en lettvekts-tokeniser)
const encoded = tokenizer.encode(text);
const inputIds = new ort.Tensor('int64',
BigInt64Array.from(encoded.map(BigInt)),
[1, encoded.length]
);
const results = await session.run({ input_ids: inputIds });
const logits = results.logits.data as Float32Array;
return logits[0] > logits[1] ? 'positive' : 'negative';
}
Når nettleser-inference vinner
- Absolutt personvernkritiske arbeidsflyter. Analyse av juridiske dokumenter der tekst aldri må forlate enheten. Medisinsk forscreening. Kategorisering av privatøkonomi.
- Offline-kapasitet. PWA-er som klassifiserer, embedder eller modererer uten tilkobling.
- Kostnadseliminering. Hvis du serverer 10M klassifiseringsforespørsler/måned, eliminerer flytting til nettleseren hele inference-regningen. Brukerens enhet betaler beregningskostnaden.
Når det ikke gjør det
- Modellstørrelse. En 500MB ONNX-modellnedlasting ved første besøk er uaktuelt for de fleste webapplikasjoner. Praktisk grense: 50-150MB for akseptabel brukeropplevelse.
- Enhetsvariasjon. En 2024 MacBook Pro med WebGPU kjører inference 20 ganger raskere enn en 2020 budsjett-Android-telefon med WASM-fallback. Du må designe for gulvet, ikke taket.
- WebGPU-tilgjengelighet. Støttet i Chrome, Edge og Firefox (bak flagg). Safari-støtte er ufullstendig per tidlig 2026. Din fallback til WASM må være sømløs.
Bygg for progressiv forbedring: prøv WebGPU, fall tilbake til WASM, fall tilbake til edge API, fall tilbake til sentralisert. Hvert nivå er en kapasitet, ikke et krav.
VI. Praktiske bruksområder: Der edge inference forsvarer sin plass
Ikke hver ML-oppgave hører hjemme på edge. Her er hvor vi deployer edge inference i produksjon, og hvorfor.
Klassifisering
Språkdeteksjon, sentimentanalyse, intensjonsruting. Dette er de kanoniske edge inference-oppgavene. Modellene er små (50-200M parametre), latens betyr noe, og utdataene er en etikett -- ikke generert tekst. En distilbert-klassifiserer på edge returnerer en etikett på 15-40ms. Samme kall til et sentralisert API tar 150-400ms inkludert nettverk.
Embedding-generering
Søk-mens-du-skriver, semantisk likhet, anbefalinger. Embedding-modeller (BGE-base, E5-small) er 100-400M parametre og produserer vektorer med fast lengde. Generer embeddings på edge, spør vektordatabasen fra nærmeste region. Embedding-steget er den latenssensitive delen; vektorsøket tåler et regionalt hopp.
Bruker skriver spørring
|
v
Edge: generer embedding (BGE-base, ~30ms)
|
v
Regional: vektorsøk (Pinecone/Qdrant, ~20ms)
|
v
Edge: formater og returner resultater (~5ms)
Totalt: ~55ms vs ~250ms sentralisert
PII-deteksjon
Forhåndssjekk av data før de forlater edge. Kjør en liten NER-modell på edge for å detektere navn, e-poster, telefonnumre, adresser. Flagg eller rediger før forespørselen når applikasjonsserveren din. Dette er ikke bare et latensspill -- det er et datastyringsgrep. PII som aldri forlater edge-PoP-en havner aldri i dine sentraliserte logger.
Innholdsmoderering
Giftighetsskåring, NSFW-deteksjon, spamklassifisering. Dette er portvaktfunksjoner: de kjører før innhold entrer systemet ditt. Edge-plassering betyr at modereringsbeslutninger skjer ved inntakshastighet, ikke ved køprosesseringshastighet. For plattformer med brukergenerert innhold kutter dette eksponeringsvinduet fra sekunder til millisekunder.
Hvor edge inference ikke hører hjemme
- Flerrundesamtaler. Krever tilstand, kontekstvinduer og modellstørrelser som overskrider edge-budsjetter.
- Langformgenerering. Token-for-token-generering på edge er tregere enn en enkelt rundtur til en sentralisert GPU for alt utover en setning.
- RAG med store korpora. Retrieval-augmented generation trenger vektorlagre, dokumentbiter og syntesemodeller som ikke får plass innenfor edge-begrensninger.
- Finjusterte domenemodeller. Hvis modellen din er spesialtrent, kan ikke Workers AI servere den. Du trenger egen infrastruktur.
VII. Kostnadsmodellen: Edge vs. sentralisert GPU
Kostnadssammenligninger innen inference er forræderske. Enheter er forskjellige. Prismodeller er forskjellige. Men retningsøkonomien er klar.
Sentralisert GPU
En dedikert A100-instans (AWS p4d.24xlarge) koster ~$32/time. Ved full utnyttelse med batching serverer den omtrent 500-2000 forespørsler/sekund for en 7B-modell, avhengig av sekvenslengde. Det er $0,016-$0,064 per 1000 forespørsler ved full last. Men du betaler for instansen enten den er opptatt eller ledig. Utnyttelse under 60% dobler din effektive kostnad.
Edge inference (Cloudflare Workers AI)
Workers AI-prising er per nevron, med gratisnivået som dekker 10 000 nevroner/dag. På betalt plan skalerer kostnadene med bruk. For klassifiserings- og embedding-oppgaver er typisk kostnad $0,01-$0,05 per 1000 forespørsler. Ingen ledigkostnad. Ingen GPU-reservasjon.
Lønnsomhetsgrensen
Kostnadssammenligning (klassifisering, 1M forespørsler/dag):
Sentralisert GPU (reservert):
Instans: $32/t * 24 = $768/dag
Ved 1M foresp./dag: $0,77 per 1000 forespørsler
(forutsetter enkeltmodell, moderat batching)
Sentralisert GPU (serverless, f.eks. Replicate):
~$0,10-$0,30 per 1000 forespørsler
Edge (Workers AI):
~$0,01-$0,05 per 1000 forespørsler
Edge (nettleser/ONNX):
$0,00 (brukerens enhet)
Edge vinner overbevisende for ujevne, klassifiseringstunge arbeidsbelastninger. Sentralisert vinner for vedvarende, høygjennomstrømningsgenerering. Krysningspunktet avhenger av trafikkmønsteret, modellkompleksiteten og om du kan holde GPU-er varme.
For de fleste applikasjoner er svaret begge deler: edge for den raske banen, sentralisert for den tunge banen. Arkitekturen er ikke enten/eller. Det er en ruteringsbeslutning.
VIII. Arkitekturmønstre som overlever produksjon
Mønster 1: Edge-først med sky-fallback
Standardmønsteret. Rut alle inference-kvalifiserte forespørsler til edge. Hvis edge-modellen ikke kan håndtere forespørselen (for kompleks, kontekst for lang, modell utilgjengelig), fall tilbake til sentralisert.
Forespørsel
|
v
+----------------+
| Edge-ruter |
| (kompleksitets-|
| estimator) |
+-------+--------+
|
+--------+--------+
| |
Enkel/Rask Kompleks/Lang
| |
v v
+----------+ +---------------+
| Edge AI | | Sentralisert |
| (Workers | | GPU-kluster |
| AI, 30ms| | (vLLM, 400ms)|
+----------+ +---------------+
| |
+--------+--------+
|
v
Respons// Edge-først-ruting i en Cloudflare Worker
async function handleInference(
request: Request,
env: Env
): Promise<Response> {
const { text, task } = await request.json<InferenceRequest>();
// Rask bane: klassifisering og embedding på edge
if (task === 'classify' || task === 'embed') {
try {
const result = await env.AI.run(
EDGE_MODELS[task],
{ text }
);
return Response.json({ result, tier: 'edge' });
} catch (e) {
// Fall gjennom til sentralisert
}
}
// Treg bane: generering og komplekse oppgaver sentralisert
const response = await fetch(env.CENTRAL_INFERENCE_URL, {
method: 'POST',
headers: {
'Authorization': Bearer ${env.INFERENCE_API_KEY},
'Content-Type': 'application/json'
},
body: JSON.stringify({ text, task })
});
const result = await response.json();
return Response.json({ ...result, tier: 'centralized' });
}
Mønster 2: Delt inference
Kjør første trinn i en pipeline på edge, send mellomresultater til sentralisert for det kostbare trinnet. Vanlig for søk: embed på edge, hent og re-ranger sentralt.
Edge PoP (Oslo) Region (eu-west-1)
+-----------------+ +-------------------+
| Embed spørring | vektor | Vektorsøk |
| (BGE, 30ms) |--------->| Re-rangering |
| | | (cross-encoder, |
+-----------------+ | 80ms) |
| Generer utdrag |
| (LLM, 200ms) |
+-------------------+Mønster 3: Spekulativ edge-dekoding
Et frontlinjemønster lånt fra spekulativ dekoding i LLM-er. En liten edge-modell genererer et utkast til respons. En sentralisert modell verifiserer og korrigerer. Hvis edge-utkastet er godt nok (og for enkle spørringer er det ofte det), ser brukeren sub-100ms latens. Hvis ikke, ankommer den sentraliserte modellens korreksjon innenfor det normale latensvinduet.
Dette fungerer for forutsigbare spørringer: FAQ-svar, malsvar, enkle fullføringer. Det fungerer ikke for kreative eller resonneringstunge oppgaver der den lille modellens utkast konsekvent er feil.
Mønster 4: Edge-forbehandling, sentral resonnering
Det mest konservative mønsteret. Edge håndterer tokenisering, PII-deteksjon, inputvalidering og formatering. Det sentrale klusteret håndterer all inference. Edge legger til 5-15ms med forbehandling, men fjerner søppelforespørsler, reduserer tokenantall og håndhever datastyring før forespørselen noensinne treffer en GPU.
IX. Den operasjonelle virkeligheten: Overvåking av edge inference i skala
Edge inference introduserer overvåkingsutfordringer som sentraliserte utrullinger ikke har.
Observerbarhetsproblemet
Modellen din kjører på over 300 lokasjoner. Kaldstartatferd varierer per PoP. Maskinvare varierer. Nettverksforhold varierer. En kvalitetsdegradering i Asia-Stillehavet dukker kanskje ikke opp i dine aggregerte metrikker.
Du trenger per-PoP-overvåking. Ikke valgfritt.
// Strukturert logging for edge inference-observerbarhet
interface InferenceMetric {
timestamp: number;
colo: string; // Cloudflare PoP-identifikator
model: string;
task: 'classify' | 'embed' | 'generate';
latency_ms: number;
tokens_in: number;
tokens_out: number;
cold_start: boolean;
fallback: boolean;
confidence: number; // modellens konfidensskår
error?: string;
}
async function instrumentedInference(
env: Env,
request: Request,
task: string,
input: unknown
): Promise<{ result: unknown; metric: InferenceMetric }> {
const start = performance.now();
const colo = request.cf?.colo ?? 'unknown';
try {
const result = await env.AI.run(MODEL_MAP[task], input);
const metric: InferenceMetric = {
timestamp: Date.now(),
colo,
model: MODEL_MAP[task],
task: task as InferenceMetric['task'],
latency_ms: performance.now() - start,
tokens_in: estimateTokens(input),
tokens_out: estimateTokens(result),
cold_start: (performance.now() - start) > COLD_START_THRESHOLD,
fallback: false,
confidence: extractConfidence(result)
};
// Send til analyse (ikke-blokkerende)
env.ANALYTICS.writeDataPoint(metric);
return { result, metric };
} catch (error) {
// ... feilsporing med PoP-kontekst
}
}
Hva du bør varsle på
- P99-latens per PoP som overstiger 3x P50-grunnlinjen. Kaldstarter forårsaker topper; vedvarende forhøyelse betyr at noe er galt.
- Fallback-rate over terskel. Hvis mer enn 5% av edge-forespørsler faller tilbake til sentralisert, undersøk. Modelllastingsfeil, minnepress eller forespørselsmønstre som overskrider edge-kapasitet.
- Konfidensavdrift. Hvis gjennomsnittlig modellkonfidens for en gitt oppgave synker over tid, har inndatadistribusjonen skiftet. Modellen kan trenge retrening, eller terskelen for edge/sentral-ruting må justeres.
- Kaldstartfrekvens. Spor hvor ofte hver PoP serverer en kaldstart-forespørsel. Hvis en PoP syklerer konstant, er trafikken for sparsom der til at edge inference er lønnsomt. Rut den PoP-en til sentralisert og spar kaldstartstraffen.
Dashboardet du faktisk trenger
Glem forfengelighetsmetrikker. Ditt edge inference-dashboard har tre paneler:
- Latens-varmekart per PoP. Fargekodet verdenskart som viser P50 inference-latens på hver lokasjon. Rødt betyr «undersøk eller rerut.»
- Fallback-fossefall. For hver forespørsel som falt tilbake fra edge til sentralisert: hvorfor, hvorfra og hvor mye latens det la til.
- Kostnad per nyttig inference. Ikke kostnad per forespørsel -- kostnad per forespørsel som returnerte et resultat applikasjonen faktisk brukte. En klassifisering med 0,51 konfidens som sjekkes på nytt sentralt er ikke en nyttig edge inference; den er bortkastet.
X. Begrensninger: Den ærlige listen
Edge inference er ikke magi. Her er det som vil bite deg.
Modellstørrelsestak. Den største modellen du praktisk kan kjøre på CDN edge er 3-7B parametre, kvantisert til INT4. Det utelukker modellene de fleste tenker på når de sier «AI» -- GPT-4-klasse, Claude-klasse, Llama 70B. Edge AI er småmodell-AI.
Ingen finjustering på edge. Du kan ikke deploye tilpassede finjusterte modeller til Workers AI eller lignende plattformer (per tidlig 2026). Hvis bruksområdet ditt krever domenespesifikke modeller, trenger du egen serveringsinfrastruktur, noe som betyr regional edge i beste fall.
Minnepress. Edge-isolater har harde minnegrenser. En modell som får plass i minnet kan likevel gå tom for minne hvis forespørselsbatchingen er for aggressiv eller kjøremiljøet har minnefragmentering. Test under realistisk samtidig last, ikke enkeltforespørsels-benchmarks.
Kaldstart er reell. Modelllasting tar 1-5 sekunder. For lavtrafikkutrullinger kan hver forespørsel være en kaldstart. Varmeholding legger til kostnad og kompleksitet.
Kvalitetsvarians på tvers av kvantisering. En modell kvantisert for edge kan produsere subtilt forskjellige resultater enn samme modell ved full presisjon. For klassifisering betyr dette vanligvis ingenting. For generering eller ekstraksjon kan det bety enormt mye. Evaluer alltid på kvantiseringsnivået du deployer.
Leverandørlåsing. Workers AI-modeller er Cloudflare-spesifikke API-kall. ONNX Runtime Web er portabelt, men krever at du håndterer modelldistribusjon. Det finnes ingen universell edge inference API. Planlegg abstraksjonslaget tidlig.
XI. Hvorfor dette betyr noe for edge-først-arkitektur
Vi bygger på Cloudflare Workers. Vi tenker i edge-først-termer. Dette er ikke stammelojalitet; det er et veddemål på hvor kapasitetskurven er på vei.
Banen er klar: modeller blir mindre og bedre. Kvantisering blir mindre tapsbringende. Edge-maskinvare blir mer kapabel. WebGPU modnes. Settet av oppgaver du kan kjøre på CDN-laget utvides hvert kvartal.
For tre år siden betydde «AI på edge» funksjonsflagg og A/B-testlogikk. For to år siden betydde det grunnleggende tekstklassifisering. I dag betyr det embedding-generering, flerspråklig NER, innholdsmoderering og små generative modeller. Neste år vil det bety mer.
Arkitekturen som vinner er den som kan absorbere denne ekspansjonen uten redesign. Edge-først med sky-fallback er den arkitekturen. Den starter konservativt -- klassifiser og embed på edge, generer sentralt -- og absorberer naturlig ny kapasitet ettersom modeller krymper og edge-maskinvare vokser.
Kapabilitetsmigrasjonen over tid:
2024: Klassifisering, språkdeteksjon
2025: Embeddings, NER, innholdsmoderering
2026: Små genereringsoppgaver, PII-deteksjon, spekulativ dekoding
2027: Multimodal klassifisering, sanntidsoversettelse (projisert)
2028: På-enhet + edge kollaborativ inference (projisert)
──────────────────────────────────────────────>
Flere oppgaver flytter fra sentralisert til edge
For Gothars klienter betyr dette konkret verdi: lavere latens for brukerrettet intelligens, redusert dataeksponering gjennom edge-lokal prosessering, og infrastrukturkostnader som skalerer med bruk snarere enn reservasjoner. Klientene som adopterer edge-først inference-mønstre nå vil ha et strukturelt fortrinn ettersom kapasitetsfronten beveger seg utover.
Referanser
- Cloudflare Workers AI Documentation. https://developers.cloudflare.com/workers-ai/
- ONNX Runtime Web. https://onnxruntime.ai/docs/tutorials/web/
- WebGPU W3C Specification. https://www.w3.org/TR/webgpu/
- Deng, T. et al. "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration." MLSys 2024. https://arxiv.org/abs/2306.00978
- Frantar, E. et al. "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers." ICLR 2023. https://arxiv.org/abs/2210.17323
- Cloudflare AI Gateway and Model Routing. https://developers.cloudflare.com/ai-gateway/
- Vercel AI SDK Documentation. https://sdk.vercel.ai/docs
- Deno Deploy and Edge Functions. https://deno.com/deploy
- Leviathan, Y. et al. "Fast Inference from Transformers via Speculative Decoding." ICML 2023. https://arxiv.org/abs/2211.17192
- vLLM: Easy, Fast, and Cheap LLM Serving. https://github.com/vllm-project/vllm
- Cloudflare Network Map and PoP Locations. https://www.cloudflare.com/network/
- ONNX Model Zoo. https://github.com/onnx/models
Det er noe treffende ved intelligens på kanten. I århundrer var beslutninger sentraliserte -- i rettsaler, i hovedsteder, i stormaskiner. Distribuerte systemers utviklingsbue bøyer mot subsidiaritet: håndter ting på det laveste nivået som kan håndtere dem kompetent. En CDN-node som kan klassifisere en kommentar trenger ikke spørre Virginia om tillatelse. En nettleser som kan embedde en spørring trenger ikke krysse et hav. Dette er ikke bare ingeniørmessig effektivitet. Det er et stille argument om hvor intelligens bør leve: ikke i en katedral, men i sognet. Nær bakken. Nær behovet. Nær mennesket som stilte spørsmålet og fortjener et svar før de er ferdige med å blunke.
