LocalAI QuickStart: Kör OpenAI-kompatibla LLMs lokalt
Självhänseende av OpenAI-kompatibla API:n med LocalAI på några minuter.
LocalAI är en självhostad, lokal-först inferensserver designad för att bete sig som en drop-in OpenAI API för att köra AI-arbetsbelastningar på din egen hårdvara (bärbar dator, arbetsstation eller on-prem-server).
Projektet siktar på praktisk kompatibilitet för att “ersätta molnet API-URL”, samtidigt som det stöder flera bakgrunder och modaliteter (text, bilder, ljud, embeddings och mer).

Vad LocalAI är och varför ingenjörer använder det
LocalAI erbjuder en HTTP REST API som speglar viktiga OpenAI-endpunkter, inklusive chat-completions, embeddings, bildgenerering och ljudendpunkter, så att befintlig OpenAI-kompatibel verktygsmatris kan pekas om till din egen infrastruktur.
Bortom grundläggande textgenerering sträcker sig LocalAIs funktionsuppsättning över vanliga “produktionsbyggstenar” såsom embeddings för RAG, diffusion-baserad bildgenerering, tal-till-text och text-till-tal, med valfri GPU-accelerering och distribuerade mönster.
Om du utvärderar självhostad LLM-serverdrift är LocalAI intressant eftersom det fokuserar på API-kompatibilitet (för enklare integration) samtidigt som det tillhandahåller en inbyggd webbläsargränssnitt och en modellgalleri-arbetsflöde för att minska friktionen vid installation och konfiguration av modeller.
För en bredare jämförelse av alternativ för självhostad och molnbaserad LLM-hostning – inklusive Ollama, vLLM, Docker Model Runner och hanterade molnleverantörer – se LLM-hostningsguiden för 2026.
Om du vill ha en sidledes uppdelning av LocalAI jämfört med Ollama, vLLM, LM Studio och andra, täcker jämförelse av de viktigaste lokala LLM-verktygen 2026 API-stöd, hårdvarukompatibilitet och produktionsredo. För den bredare fallet för att behålla modeller på din egen infrastruktur, täcker självhostad LLM och AI-soveränitet datalagring och efterlevnadsdrivkrafter.
LocalAI-installationsalternativ som fungerar väl i praktiken
LocalAI kan installeras på flera sätt, men för de flesta team är den snabbaste och lägst risk startpunkten containerlösningar (Docker eller Podman). Om du vill ha en kommandoreferens medan du arbetar igenom exemplen nedan, täcker Docker-cheatsheetet de vanligaste och mest användbara Docker-kommandona.
Snabbaste start med Docker
Detta startar LocalAI-servern och binder API och webbläsargränssnitt på port 8080:
docker run -p 8080:8080 --name local-ai -ti localai/localai:latest
LocalAIs container-dokumentation kallar detta den snabbaste vägen för att få igång en fungerande server,
med API:t tillgängligt på http://localhost:8080.
Välja rätt LocalAI-containerbild
LocalAI publicerar flera containervarianter så att du kan matcha din hårdvara:
- En CPU-bild för bred kompatibilitet.
- GPU-specifika bilder för NVIDIA CUDA, AMD ROCm, Intel oneAPI och Vulkan.
- All-in-One (AIO)-bilder som är förkonfigurerade med modeller mappade till OpenAI-liknande modellnamn.
Det ursprungliga GitHub-README:t inkluderar konkreta docker run-exempel för CPU-endast och flera GPU-alternativ
(NVIDIA CUDA-variant, AMD ROCm, Intel, Vulkan), samt AIO-varianter.
Spara modeller mellan omstarter
Om du inte monterar lagring kan dina nedladdade modeller inte bestå över containerlivscykelsändringar. Containerguiden rekommenderar att montera ett models-volym, till exempel:
docker run -ti --name local-ai -p 8080:8080 \
-v "$PWD/models:/models" \
localai/localai:latest-aio-cpu
Detta gör /models inuti containern bestående på din värd.
En minimal Docker Compose QuickStart
LocalAI tillhandahåller också en referens docker-compose.yaml i repository:t,
som demonstrerar ett vanligt mönster: bind port 8080, montera en /models-volym, sätt MODELS_PATH=/models,
och ladda eventuellt förhand en modell genom att specificera den i kommandolistan (repo-exemplet visar phi-2).
Docker Compose-cheatsheetet är en smidig referens när du anpassar detta till din konfiguration.
En “bra standard” Compose-uppsättning (CPU) ser ut så här:
services:
localai:
image: localai/localai:latest
container_name: local-ai
ports:
- "8080:8080"
volumes:
- ./models:/models
environment:
- MODELS_PATH=/models
Den nyckelidén är densamma som i det ursprungliga exemplet: värdens modelskatalog ↔ container /models.
Om du också använder Dockers inbyggda docker model-verktyg bredvid LocalAI, täcker Docker Model Runner-cheatsheetet pull, run, package och konfigurationskommandon.
Icke-container LocalAI-installationer
LocalAI stöder också installationer via plattformsspecifika metoder (till exempel en macOS DMG och Linux-binärer), och bredare deploymentsalternativ som Kubernetes.
Om du föredragar scriptade installationer på Linux,
beskriver DeepWiki quick start en install.sh-väg som automatiskt detekterar hårdvara och konfigurerar systemet därefter.
En förutsägbar användningssekvens
En pålitlig LocalAI-arbetsflöde är:
Starta LocalAI → installera eller importera en modell → verifiera inlästa modeller → anropa OpenAI-kompatibla endpunkter.
Denna sekvens matchar den officiella “Prova det” och “Konfigurera modeller” vägledning, som ramar in processen kring att starta servern, installera modeller via galleri eller CLI, och sedan testa endpunkter med curl.
Starta servern och bekräfta att den är frisk
När servern är igång är en vanlig hälsokontroll readyness-endpunkten:
curl http://localhost:8080/readyz
Felsökningsguiden använder /readyz som en första diagnos för att bekräfta att LocalAI är responsiv.
Installera en modell från galleriet eller importera en URI
LocalAI tillhandahåller två huvudsakliga modellonboarding-flöden:
- Modellgalleri-installation via webbläsargränssnitt, där du öppnar UI, går till fliken Modeller, bläddrar efter modeller och klickar på Installera.
- CLI-driven installation och körning, med
local-ai models list,local-ai models installochlocal-ai run.
Dokumentationen stöder också att importera modeller via URI (Hugging Face-repositorier, direkta modellfil-URI och andra registrier), och webbläsargränssnittet inkluderar en dedikerad Importera Modell-flöde med en YAML-editor för avancerad konfiguration.
Verifiera vad LocalAI tror att den kan servera
För att lista distribuerade modeller genom OpenAI-kompatibla API:t:
curl http://localhost:8080/v1/models
Detta rekommenderas uttryckligen både som ett “nästa steg” efter containerinstallation och som en felsökningsdiagnos.
Viktiga kommandoradsparametrar att lära sig
LocalAIs CLI är byggt kring local-ai run-kommandot, med en omfattande konfigurationsyta.
Vi behöver lyfta fram två viktiga driftsbeteenden:
- Varje CLI-flagga kan ställas via en miljövariabel.
- Miljövariabler har företräde framför CLI-flaggor.
Här är parametrarna som de flesta praktiker använder tidigt, grupperade efter avsikt.
Alla standardvärden och env-var-namn är hämtade från det ursprungliga CLI-referensen. Om du utvärderar Ollama bredvid LocalAI, täcker Ollama CLI-cheatsheetet dess serve, run, ps och modellhanteringskommandon för jämförelse.
Grundläggande server- och lagringsflaggor
| Vad du vill ha | Flagga | Miljövariabel | Notera |
|---|---|---|---|
| Ändra bindadress och port | --address |
LOCALAI_ADDRESS |
Standard är :8080. |
| Ändra var modeller bor | --models-path |
LOCALAI_MODELS_PATH |
Kritisk för bestående lagring och diskplanering. |
| Separera flyktig tillstånd från konfiguration | --data-path |
LOCALAI_DATA_PATH |
Lagrar bestående data som agenttillstånd och jobb. |
| Ställ in uppladdningsplats | --upload-path |
LOCALAI_UPLOAD_PATH |
För filrelaterade API:er. |
LocalAIs FAQ dokumenterar också standardmodelleringslagringsplatser och rekommenderar uttryckligen LOCALAI_MODELS_PATH eller --models-path om du vill ha modeller utanför standardkatalogen (till exempel för att undvika att fylla en hemkatalog).
Prestanda- och kapacitetsflaggor
| Vad du vill ha | Flagga | Miljövariabel | Notera |
|---|---|---|---|
| Justera CPU-användning | --threads |
LOCALAI_THREADS |
Föreslås att matcha fysiska kärnor; används brett för prestandajustering. |
| Kontrollera kontext per modell | --context-size |
LOCALAI_CONTEXT_SIZE |
Standardkontextstorlek för modeller. |
| Aktivera GPU-accelereringsläge | --f16 |
LOCALAI_F16 |
Dokumenterad som “Aktivera GPU-accelerering”. |
| Begränsa inlästa modeller i minne | --max-active-backends |
LOCALAI_MAX_ACTIVE_BACKENDS |
Aktiverar LRU-utdrift när den överskrids; kan begränsa minnesavtryck. |
| Stoppa inaktiva eller fastnat bakgrunder | --enable-watchdog-idle / --enable-watchdog-busy |
LOCALAI_WATCHDOG_IDLE / LOCALAI_WATCHDOG_BUSY |
Användbart när du kör många modeller eller instabila bakgrunder. |
För bredare kompatibilitet och accelerationsbegränsningar dokumenterar modellkompatibilitetstabellen vilka bakgrunder som stöder vilka accelereringslägen (CUDA, ROCm, SYCL, Vulkan, Metal, CPU), och noterar också att modeller som inte är explicit konfigurerade kan laddas automatiskt, medan YAML-konfiguration låter dig låsa beteende. För högre-genomströmmande multi-GPU-deployment med PagedAttention, går vLLM quickstart-guiden igenom en jämförbar OpenAI-kompatibel server med produktionsinriktad konfiguration.
API-, säkerhets- och UI-flaggor
| Vad du vill ha | Flagga | Miljövariabel | Notera |
|---|---|---|---|
| Kräva API-nycklar | --api-keys |
LOCALAI_API_KEY / API_KEY |
När inställd måste alla begär autentiseras med en konfigurerad nyckel. |
| Tillåt webbläsare att anropa API:t | --cors / --cors-allow-origins |
LOCALAI_CORS / LOCALAI_CORS_ALLOW_ORIGINS |
Håll inaktiverat om du inte behöver det. |
| Inaktivera webbläsargränssnittet helt | --disable-webui |
LOCALAI_DISABLE_WEBUI |
API-endast-läge för hårdnadsdeployment. |
| Förstärk felrespons | --opaque-errors |
LOCALAI_OPAQUE_ERRORS |
Användbart i högsäkerhetsmiljöer. |
Om du exponerar LocalAI fjärran bör du skydda endpunkter och kan begränsa åtkomst med en API-nyckel, API-nyckeln ger effektivt full åtkomst.
Webbläsargränssitt-tour och hur det mappar till systemet
Som standard serverar LocalAI ett inbyggt webbläsargränssnitt bredvid API:t (om du inte inaktiverar det). Dokumentationen anger att UI:t är tillgängligt på samma värd och port som servern, vanligtvis http://localhost:8080.
Vad du kan göra i det inbyggda UI:t
Webbläsargränssnittet är ett webbläsarbaserat gränssnitt som täcker:
- Modellhantering och galleriblättrandeupplevelse
- Chatsamspel
- Bildgenerering och text-till-tal-gränssnitt
- Distribuerad och P2P-konfiguration
Rutstrukturer ger en klar mentall modell för UI-ytan:
/för dashboarden/browseför modellgalleri-bläddraren/chat/för chatt/text2image/för bildgenerering/tts/för text-till-tal/talk/för röstinteraktion/p2pför P2P-inställningar och övervakning
Modellgalleri och “Importera Modell”-arbetsflöde
För ingenjörer är den viktigaste UI-funktionen modellonboarding. Den officiella “Konfigurera Modeller”-guiden beskriver:
- Installera modeller via fliken Modeller med ett-klick-installation.
- Importera modeller via en Importera Modell-UI som stöder ett enkelt läge (URI + preferenser) och ett avancerat läge med en YAML-editor och valideringsverktyg.
Detta är viktigt eftersom LocalAI slutkörar modeller baserat på YAML-konfiguration: du kan hantera individuella YAML-filer i modelskatalogen, använda en enda fil med flera modelldefinitioner via --models-config-file, eller referera till fjärr-YAML-URL vid start.
Exempel du kan klistra in i en terminal
LocalAIs OpenAI-kompatibla endpunkter är designade för att acceptera bekanta begäransformat och returnera JSON-svar (med ljudendpunkter som returnerar ljudpayload).
Exempel på chat-completions med curl
Sidans “Prova det”-sektion visar att anropa chat-completions-endpunkten direkt:
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [
{ "role": "user", "content": "Skriv en förklaring på ett stycke om vad LocalAI är." }
],
"temperature": 0.2
}'
AIO-bilder levereras med förkonfigurerade modeller mappade till OpenAI-liknande namn som gpt-4, och container-dokumentationen förklarar att dessa drivs av öppen källkod-modeller.
Om du inte använder en AIO-bild, ersätt "model" med modellnamnet du installerade (kontrollera med /v1/models).
Exempel på embeddings för RAG-pipeliner
LocalAI stöder embeddings och dokument att embeddings-endpunkten är kompatibel med flera bakgrunder, inklusive llama.cpp, bert.cpp och sentence-transformers.
En minimal “embedd den här texten”-begäran mot OpenAI-kompatibel endpunkt ser ut så här:
curl http://localhost:8080/v1/embeddings \
-H "Content-Type: application/json" \
-d '{
"model": "text-embedding-ada-002",
"input": "LocalAI embeddings är smidiga för semantisk sökning och RAG."
}'
LocalAIs embeddings-dokumentation visar också hur embeddings aktiveras via YAML-konfiguration genom att ställa in embeddings: true.
Exempel på att använda en OpenAI-kompatibel klient
LocalAI är designad så att du kan använda standard OpenAI-klientbibliotek genom att peka dem mot LocalAI-bas-URL (och eventuellt ställa in en API-nyckel om du aktiverade autentisering). Detta “drop-in ersättnings”-mål beskrivs både i det ursprungliga README:t och i OpenAI-kompatibilitetsdokumentationen.
En typisk konfiguration är:
- Bas-URL:
http://localhost:8080/v1 - API-nyckel: antingen inte krävs (standard) eller krävs om du konfigurerade
--api-keys
Säkerhet och felsökningsväsentligheter
Säkra en LocalAI-server innan du exponerar den
LocalAI kan köras fullt öppen på localhost som standard. Om du binder till ett publikt gränssnitt eller exponerar den genom en ingress, lägg till minst en av dessa kontroller:
- Aktivera API-nyckelautentisering med
--api-keys/API_KEY. - Sätt en omvänd proxy och nätverkskontroller framför den (brandvägg, tillåtlängd, VPN).
- Inaktivera webbläsargränssnittet om du bara behöver API:t (
--disable-webui). - Håll CORS inaktiverat om inte en webbläsarbaserad klient verkligen behöver det.
När API-nycklar är aktiverade, accepterar OpenAI-kompatibla endpunkter autentiseringsuppgifter på vanliga platser som en Authorization Bearer-header eller x-api-key-header.
Snabba diagnoser när något inte fungerar
LocalAIs felsökningsguide föreslår ett litet set av kontroller som löser de flesta “kör den”-incidenter:
# readyness
curl http://localhost:8080/readyz
# lista modeller
curl http://localhost:8080/v1/models
# version
local-ai --version
Den dokumenterar också att aktivera felsökningsloggning via DEBUG=true eller --log-level=debug, och för Docker-deployment, kontrollera container-loggar med docker logs local-ai.