Plugin

Libre WebUI använder plugin för att ansluta externa AI-leverantörer och modellförmågor tillsammans med lokal Ollama.

Plugintyper

Typ	Syfte
Chatt/komplettering	Text- och chattmodeller från leverantörs-API:er
Inbäddningar	Vektorinbäddningar för dokumentsökning och minne
Bildgenerering	Bildmodeller och ComfyUI-liknande backend
Text-till-tal	Leverantörer av talsyntes
Tal-till-text	Leverantörer av transkribering
Ljudgenerering	Leverantörer av ljud och ljudgenerering
Videogenerering	Leverantörer av asynkron videogenerering

Plugin kan tillhandahålla statiska modellmappningar och, när det stöds, uppdatera tillgängliga modeller från leverantörs-API:er.

Inbyggda leverantörsfamiljer

Libre WebUI innehåller leverantörsdefinitioner för vanliga tjänster:

• OpenAI och OpenAI-kompatibla API:er
• Anthropic
• Google Gemini
• Groq
• Kimi Code från Moonshot AI
• Mistral
• OpenRouter
• Hugging Face
• GitHub Models
• MLX LM för lokal inferens på Apple Silicon
• ComfyUI
• ElevenLabs

Leverantörskataloger ändras ofta. När ett plugin stöder direkt modellidentifiering ska gränssnittet betraktas som den aktuella sanningskällan.

Ägarskap och auktorisering

Plugindefinitioner är delad konfiguration på instansnivå. Varje rutt under /api/plugins kräver autentisering, och endast administratörer kan ladda upp, installera, uppdatera eller ta bort en definition. Aktivering fungerar annorlunda: varje autentiserad användare kan endast aktivera eller inaktivera ett delat plugin för sitt eget konto. Tillståndet lagras i SQLite och finns kvar när backend startas om, utan att påverka en annan användares aktiva leverantörer.

Vid uppgradering kopieras den äldre globala aktiveringslistan .status.json en gång till de konton som redan finns, men endast för definitioner som exakt motsvarar Libre WebUIs kompilerade förtroendeankare. Äldre anpassade eller överskuggande definitioner förblir inaktiva i karantän. Konton som skapas efter migreringen börjar utan aktiverade plugin.

Medföljande definitioner betraktas endast som betrodda när deras normaliserade innehåll motsvarar en hash som har kompilerats in i backend. Skrivbara definitioner godkänns i SQLite utifrån normaliserad källsökväg och definitionens fullständiga hash. När en administratör installerar, uppdaterar eller importerar om en definition registreras godkännandet. Direkta filändringar gör det ogiltigt. Vid godkännande och uppdatering rensas aktiveringen för alla konton innan filen ersätts, så varje användare måste aktivera den granskade definitionen på nytt. Anpassade definitioner från tiden före uppgraderingen måste importeras om av en administratör innan de kan visas i kataloger, identifiera modeller, ta emot autentiseringsuppgifter eller köra någon förmåga.

Pluginvariabler delas upp efter syfte. Endast administratörer kan lagra kända variabler för anslutningsdirigering:

endpoint, base_url, api_path, models_endpoint, api_url, image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint, voice_clone_endpoint, api_mode, model och model_id. En förmågas deklarerade config.endpoint_variable, config.models_endpoint_variable eller config.voice_clone_endpoint_variable räknas också som anslutningsdirigering, även när variabeln har ett annat namn.

Användare som inte är administratörer kan fortfarande spara genereringskontroller, till exempel temperatur och strömningsinställningar. Gamla dirigeringsrader som tillhör en användare utan administratörsbehörighet ignoreras, returneras inte som konfigurerade värden och tas bort när kontots alla pluginvariabler återställs. Därmed kan en senare rollhöjning inte tyst återuppliva en vilande rutt.

Autentiseringsuppgifter

Autentiseringsuppgifter kan komma från miljövariabler eller användarinställningar.

Exempel på miljövariabler:

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GROQ_API_KEY=gsk_...
GEMINI_API_KEY=...
MISTRAL_API_KEY=...
OPENROUTER_API_KEY=sk-or-...
KIMI_API_KEY=...
GITHUB_API_KEY=github_pat_...
ELEVENLABS_API_KEY=...

För delade driftsättningar är autentiseringsuppgifter på användarnivå vanligtvis bättre, eftersom varje användare styr sin egen fakturering och sina gränser hos leverantören. Miljönycklar är användbara för enanvändarinstallationer, demonstrationer och hanterade driftsättningar.

En miljönyckel fungerar endast som reserv när förfrågan använder den dirigering och autentiseringsprojektion som kommer från en medföljande plugindefinition som inte är överskuggad. En importerad definition, en skrivbar definition som överskuggar ett medföljande ID eller en åsidosättning av anslutningsdirigeringen som sparats av en administratör kräver en autentiseringsuppgift som har sparats av samma konto. Innan Libre WebUI tillåter reservvärdet från miljön jämförs rotslutpunkten, autentiseringsfälten, förmågeslutpunkterna och väljarna för slutpunktsvariabler samt definitioner och standardvärden för kända dirigeringsvariabler. Den kompilerade manifest-hashen är fortsatt auktoritativ även när katalogerna för äldre och medföljande plugin delar sökväg, som i standardlayouten för containrar. Ett överskrivet paketmanifest kan inte göra sig självt betrott.

Regeln gäller identifiering, Chat, Work, tillgänglighetskontroller och förmågekataloger. Den hindrar en anpassad slutpunkt eller ett anpassat manifest från tiden före uppgraderingen från att ta emot en operatörshanterad hemlighet.

Användarlagrade autentiseringsuppgifter binds till den faktiska definitionskällan, definitionens fullständiga hash, autentiseringskontraktet, förmågeslutpunkterna och väljarna samt de faktiska dirigeringsvärdena när användaren sparar dem. Om en rutt eller definition ändras blir den gamla autentiseringsuppgiften otillgänglig tills användaren har granskat det nya målet och sparat uppgiften igen. Äldre autentiseringsuppgifter utan bindning godtas endast på en exakt förankrad medföljande rutt. Vid den första lyckade användningen skrivs bindningen innan den dekrypterade nyckeln returneras.

OpenAI-kompatibla leverantörer

Många leverantörer tillhandahåller ett OpenAI-kompatibelt API. Ett plugin kan definiera:

• fullständig URL till API-slutpunkten
• miljövariabel för API-nyckeln
• beteende för chattslutpunkten
• stöd för inbäddningar
• beteende för modellidentifiering
• valfri modellmappning som reserv

Om en leverantör inte stöder direkt modellidentifiering använder Libre WebUI den konfigurerade modellmappningen. Importerad plugin-JSON konfigurerar leverantörer som redan använder något av Libre WebUIs stödda protokollformat: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages eller Gemini. Enbart JSON kan inte översätta ett godtyckligt proprietärt protokoll. En leverantör med ett annat format för förfrågningar, strömning, verktygsanrop eller svar behöver en liten backend-adapter.

OpenAI-bildgenerering

Den medföljande OpenAI-leverantören tillhandahåller Image API på https://api.openai.com/v1/images/generations. gpt-image-2 är den aktuella modellen. För befintliga kompatibla driftsättningar behåller katalogen även de utfasade ID:na gpt-image-1.5, gpt-image-1 och gpt-image-1-mini. Nya konfigurationer bör välja gpt-image-2.

Bildgenerering använder samma faktiska OpenAI-autentiseringsuppgift som Chat: den aktuella användarens sparade nyckel eller den betrodda medföljande leverantörens reservvärde från miljön. Den har en separat, valfri åsidosättning image_endpoint, så att en anpassad Chat-slutpunkt inte av misstag kan ta emot bildförfrågningar. Lämna image_endpoint tom för att ärva den medföljande Image API-slutpunkten.

Bildval är leverantörskvalificerade. När två bildplugin tillhandahåller samma modell-ID skickar Libre WebUI endast förfrågan till den leverantör som har valts i bildpanelen. GPT Image-svar använder base64-kodade bilddata. Libre WebUI omvandlar dessa data till en bild i appen och sparar den i den aktuella användarens galleri. Image API-rutter kräver autentisering, och direkta genereringsförfrågningar måste innehålla både pluginId och model. De får ange n till ett JSON-heltal från 1 till 10. Numeriska strängar och decimaltal avvisas innan de når leverantören.

API-lägena Chat Completions och Responses

OpenAI-kompatibla kompletteringsplugin kan använda antingen chat_completions- eller responses-semantik för förfrågningar. Det medföljande OpenAI-pluginet visar detta val under Settings → Plugins.

Anslutningsinställningarna fastställs i följande ordning:

1. En fullständig åsidosättning i endpoint, om den är konfigurerad.
2. base_url samt eventuellt api_path.
3. Pluginets äldre endpoint.

Ett slutpunktsvärde som exakt motsvarar slutpunkten i pluginmanifestet behandlas som manifestets standardvärde, inte som en åsidosättning. Därmed kan äldre sparade standardvärden inte överskugga en ny Base URL efter en uppgradering. En faktiskt anpassad fullständig slutpunkt har fortfarande högst prioritet.

Standardsökvägen är /chat/completions i läget Chat Completions och /responses i läget Responses. base_url bör vara API-roten, till exempel https://api.example.com/v1. Använd api_path när en kompatibel leverantör tillhandahåller operationen på en annan relativ sökväg. En fullständig slutpunkt måste innehålla hela operationssökvägen och har företräde framför båda fälten. Ett känt suffix som /chat/completions, /completions eller /responses är bestämmande för förfrågningssemantiken. Anpassade slutpunktssökvägar behåller valt api_mode.

Importerad plugin-JSON kan ange samma standardvärden:

{
  "endpoint": "https://api.example.com/v1/chat/completions",
  "api_mode": "responses",
  "base_url": "https://api.example.com/v1",
  "api_path": "/responses"
}

Responses-förfrågningar använder input, max_output_tokens, funktionsverktyg med platt struktur och store: false, samt begär krypterat resonemangsinnehåll för tillståndslös fortsättning. Slutförda och strömmade Responses-utdata normaliseras tillbaka till Libre WebUIs händelseformat för Chat och Work. Uppspelningstillstånd behålls endast när den fullständiga ordnade Item-matrisen med utdata innehåller högst 64 Items och är högst 90 KB. Items bevaras exakt och deras fält trunkeras aldrig. Items som kan spelas upp måste ha unika, ifyllda ID:n och typer, och strukturer för meddelanden, resonemang och funktionsanrop valideras innan något verktygsanrop skickas. För stora Chat-tillstånd återgår till normaliserad synlig historik. Chat kasserar också obehandlade Items för funktionsanrop eftersom Chat inte sparar motsvarande verktygsresultat. Work-svar med verktyg men utan ett exakt, begränsat uppspelningstillstånd avvisas innan någon sidoeffekt från ett verktyg kan inträffa.

SQLite-baserad Chat-lagring krypterar det bevarade leverantörstillståndet tillsammans med meddelandet. Work lagrar tillstånd som enbart gäller verktyg i dolda kontextrader som inte returneras av meddelande-API:er. Ett hashat omfång binder uppspelningen till samma leverantör, modell, Responses-läge, slutligt konfigurerade slutpunkt och ett ogenomskinligt envägsfingeravtryck av den valda autentiseringsuppgiften. När omfånget ändras, även efter rotation av API-nyckeln, återgår Libre WebUI till normaliserad meddelandehistorik i stället för att skicka leverantörsspecifika Items över en autentiseringsgräns. En aktiv Work-körning skapar också fingeravtryck av sin dirigering och autentiseringsuppgift och validerar dem på nytt omedelbart före varje leverantörsomgång. Om läget, slutpunkten eller API-nyckeln ändras stoppas körningen innan en ny förfrågan kan ta emot tidigare verktygstillstånd. Ett tillstånd som innehåller verktyg måste rymmas både inom uppspelningsgränsen och i det fullständiga beständiga metadataomslaget på 100 KB innan Work utför en sidoeffekt. Om en beständig Work-batch avbröts återställs varje saknat verktygsresultat med sitt exakta anrops-ID och en varning om att utfallet är okänt. Leverantören kan då inspektera arbetsytan i stället för att blint upprepa en möjlig sidoeffekt. Ett ofullständigt Responses-resultat behandlas inte som en lyckad Chat- eller Work-tur. Dess incomplete_details.reason behålls och visas för anroparen.

Vid modellidentifiering härleds /models från endera operationssökvägen. Till exempel identifierar https://api.example.com/v1/responses modeller via https://api.example.com/v1/models. Leverantörer utan en kompatibel slutpunkt för modellistan kan fortfarande använda en manuell model_map. Identifieringen avgränsas till den aktuella användarens variabler och autentiseringsuppgifter. Resultaten sparas per användare i stället för att skrivas till det delade pluginmanifestet. Identifieringen körs efter aktivering, uttrycklig uppdatering, ändringar av API-nyckeln eller anslutningsvariabler och återställningar av variabler. När orelaterade genereringsvariabler sparas görs ingen nätverksförfrågan.

Identifieringen körs också automatiskt. När pluginlistan läses in identifieras modeller på nytt för varje aktiv kompletteringsleverantör vars katalog saknas eller är äldre än PLUGIN_MODEL_DISCOVERY_TTL_MS. När applikationen läses in på nytt visas därför leverantörens aktuella modeller i stället för katalogen från aktiveringen. En återhämtningsfördröjning per leverantör hindrar en onåbar leverantör från att kontrolleras vid varje förfrågan, och en tidsgräns hindrar en långsam leverantör från att fördröja svaret. Resultatet av en uppdatering som överskrider tidsgränsen levereras vid nästa förfrågan. Den slutliga härledda URL:en för identifiering kontrolleras innan användarens autentiseringsuppgift läses eller ett Authorization-huvud skapas, även när URL:en kommer från ett importerat pluginmanifest. Förfrågningar för identifiering och leverantörsförmågor följer inte HTTP-omdirigeringar. Konfigurera den slutliga slutpunkten för Chat, Work, modellistan, bilder, inbäddningar, transkribering, tal, röstkloning, ljud eller video direkt. Därmed kan autentiseringsuppgifter inte vidarebefordras från en validerad URL till ett omdirigeringsmål som inte har validerats.

Leverantörsslutpunkter får använda HTTP eller HTTPS. HTTP skickar API-nycklar, promptar, verktygsresultat och genererat innehåll utan transportkryptering. Använd det därför endast för en egen driftad gateway i ett nätverk du litar på, och föredra HTTPS när gatewayen stöder TLS. Förfrågningarna kommer från backend. I containerdriftsättningar innebär det en tjänste-URL som http://ai-gateway:8080/v1, medan localhost avser själva Libre WebUI-containern. Pluginens förmågerutter, inklusive bildgenerering, fastställer slutpunktsvariabler och autentiseringsuppgifter för det autentiserade konto som gör förfrågan. Libre WebUI har inget oautentiserat enanvändarläge.

Förmågespecifika slutpunkter

Åsidosättningar av Chat-slutpunkten hålls åtskilda från förmågorna för bilder, inbäddningar, transkribering, text-till-tal, ljud och video. Plugin med flera förmågor kan tillhandahålla image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint eller en annan variabel som anges av config.endpoint_variable. Rutter för röstkloning kan på samma sätt ange config.voice_clone_endpoint_variable. När dessa fält lämnas tomma används förmågeslutpunkten som deklareras av pluginet. En allmän Chat-endpoint används aldrig som åsidosättning för en förmåga.

Det medföljande GitHub Models-pluginet ärver sin aktuella slutpunkt models.github.ai/inference/chat/completions när den valfria åsidosättningen är tom. Hugging Face-pluginet använder uppgiftsspecifika rutter och nyttolaster på hf-inference/models/{model} för inbäddningar, bilder och text-till-tal i stället för att skicka dessa förfrågningar till sin Chat-slutpunkt.

Endpointåsidosättningar

Variabeln endpoint är den fullständiga URL:en för förfrågan, inklusive operationssökvägen. Ett OpenAI-kompatibelt chattplugin använder till exempel normalt en URL som https://provider.example/v1/chat/completions, inte bara https://provider.example. Äldre importerade pluginkonfigurationer kan kalla variabeln api_url. Libre WebUI godtar detta alias, men en ifylld endpoint har alltid företräde när båda finns.

Absoluta URL:er för HTTP- och HTTPS-slutpunkter godtas. Andra protokoll avvisas. HTTP är avsett för egna driftade gatewayar i betrodda nätverk, eftersom det skickar autentiseringsuppgifter och innehållet i förfrågningar utan transportkryptering. Föredra HTTPS för varje rutt som lämnar gränsen för en privat driftsättning. Om åsidosättningen lämnas tom används den fullständiga slutpunkten från plugindefinitionen. En uttryckligen ogiltig åsidosättning avvisas i stället för att tyst dirigeras till standardvärdet.

Leverantörsförfrågningar följer inte omdirigeringar. Konfigurera den slutliga validerade operations-URL:en direkt. Ett omdirigeringssvar rapporteras som ett leverantörsfel i stället för att autentiseringsuppgifter eller innehåll i förfrågan vidarebefordras till nästa hopp.

Kom ihåg att förfrågningar kommer från Libre WebUIs backend. I en container avser localhost själva containern, inte automatiskt containervärden eller en annan tjänst. Använd gatewayens tjänstenamn i containernätverket eller ett namn som kan nås från värden, till exempel host.docker.internal där containerns körmiljö tillhandahåller det.

Modellidentifiering

Under Settings → Plugins finns arbetsytan Provider connections för detta flöde. Sök efter en leverantör i den vänstra panelen, välj den och använd den högra panelen för att granska dess aktiva tillstånd och faktiska modellkatalog. Leverantörskonfigurationen förblir infälld tills Configure väljs. Därmed visas inte kontroller för slutpunkt, autentiseringsuppgift och avancerad generering i standardvyn.

För chatt- och kompletteringsleverantörer kör Refresh models identifiering för den valda leverantören och läser sedan in både pluginkatalogen och Chats modellista på nytt. Katalogen är skrivskyddad. Dess rader kommer från ID:n som identifierats för den aktuella användaren samt plugindefinitionens förmågespecifika modellmappningar. Förmågeetiketterna beskriver vilken pluginrutt som listar en modell. De är inte hälsokontroller. Lägg till modell-ID:n som reserv eller underhålls manuellt via model_map i plugin-JSON, inte genom att redigera en identifierad rad.

När ett plugin aktiveras försöker Libre WebUI identifiera modeller med kontots faktiska slutpunkt och autentiseringsuppgift. En administratörs anpassade rutt kräver en autentiseringsuppgift som har sparats av samma konto. Ett reservvärde från miljön används endast med den betrodda manifestrutten. För kompatibla API:er härleder Libre WebUI modellistans URL från den fullständiga slutpunkten:

• en URL som slutar med /models används utan ändring
• kända operationssuffix som /chat/completions, /completions, /responses, /embeddings eller /messages ersätts med /models
• i övriga fall läggs /models till i sökvägen.

Plugin som inte kan använda den härledda URL:en kan tillhandahålla models_endpoint som en uttrycklig fullständig URL för modellistan. Den har företräde framför härledning, omfattas av samma policy för utgående URL:er och begärs utan att omdirigeringar följs. När endpoint, api_url, models_endpoint, base_url, api_path eller api_mode sparas eller återställs rensas och uppdateras den aktuella användarens identifierade katalog innan gränssnittet läser in den på nytt.

Alla anpassade rutter slås upp och valideras innan autentiseringsuppgiften väljs. Policyn för autentiseringsuppgifter får inte falla tillbaka på en miljönyckel från servern för en sparad anpassad rutt. Konfigurera i stället en nyckel per användare för den rutten. Reservvärdet från miljön är förbehållet den slutpunkt som tillhandahålls av den betrodda plugindefinitionen.

Identifieringen förväntar sig ett OpenAI-kompatibelt svar med modell-ID:n i en data-matris. Aktiveringen väntar på försöket innan den returnerar, så den identifierade katalogen kan ingå redan när pluginlistan uppdateras första gången. Lyckade resultat lagras per användare och läggs ovanpå användarens pluginvy. Libre WebUI skriver inte om den delade plugin-JSON-filen och visar inte en användares identifierade modell-ID:n för ett annat konto. Om leverantören saknar en kompatibel slutpunkt för modellistan, inte kan nås eller returnerar ett annat svarsformat behåller en vanlig aktivering användarens tidigare identifieringsresultat. En avsiktlig ändring av ett anslutningsfält rensar först den inaktuella katalogen och använder därför pluginets reservvärde model_map när modeller inte kan identifieras på den nya rutten.

När anslutningsdirigeringen sparas eller återställs rensas kontots tidigare identifierade katalog före nästa identifieringsförsök. Modeller som har hittats på ett mål kan därför inte förbli valbara efter att rutten har ändrats.

Pluginstatus, Works tillgänglighet, modellkataloger och förmågerutter använder samma användarkontext och autentiseringsgräns. Exempelvis fastställs bildmodellernas tillgänglighet, slutpunktsvariabler och autentiseringsuppgifter för den användare som gör förfrågan.

Exakt leverantörsval i Chatt

Modell-ID:n är inte globalt unika. En Ollama-modell och flera aktiva plugin kan alla tillhandahålla en modell med namnet example-model. Chat lagrar därför det ursprungliga modell-ID:t tillsammans med en valfri leverantörsidentitet:

• providerType: "ollama" identifierar den lokala eller konfigurerade Ollama-rutten
• providerType: "plugin" tillsammans med providerId identifierar ett exakt plugin.

Leverantörskvalificerade och URL-kodade värden används endast som kollisionssäkra nycklar i modellväljare. Förfrågningar fortsätter att skicka leverantörens ursprungliga modell-ID. Dubbletter av modellnamn mellan Ollama och plugin eller mellan plugin förblir separata val, och när en chatt öppnas igen återställs exakt det val som sparades.

En uttrycklig leverantörsidentitet stängs säkert vid fel. Om ett valt plugin inaktiveras, tas bort eller inte längre annonserar modellen håller Libre WebUI det sparade valet synligt som otillgängligt och byter inte tyst till en annan leverantör med samma modellnamn. Aktivera leverantören igen eller välj uttryckligen en annan modell innan du genererar på nytt.

Sessioner och inställningar som skapades innan leverantörsidentiteten började sparas kan ha providerType och providerId utan värde eller med värdet null. För kompatibilitet behåller dessa äldre poster sin historiska dirigering som enbart bygger på namn, eftersom den ursprungliga leverantören inte kan återskapas på ett tillförlitligt sätt. Väljaren visar posterna som "provider not recorded" i stället för att gissa en Ollama- eller pluginetikett. När en konkret leverantörspost väljs registreras en exakt leverantör för senare förfrågningar. Nya personaval behåller gränssnittsidentiteten persona:<id> och registreras med Ollama som bakomliggande leverantör.

Leverantörsinställningar och arv

Öppna Settings → Plugins och välj Configure för en leverantör. Leverantörspanelerna är stängda som standard. Administratörer kan hantera delade definitioner och värden för anslutningsdirigering. Andra autentiserade användare kan aktivera leverantörer, spara sina egna API-nycklar och ändra sina egna genereringskontroller, men gränssnittet visar inga kontroller för att ladda upp, installera, exportera, ta bort eller dirigera plugin för dem.

För administratörer visas åsidosättningar av anslutningen först. Sampling och andra specialistkontroller finns fortsatt under Advanced parameters, som också är stängt som standard. Ärvda anslutnings- och genereringsvärden visas som tomma inmatningsfält med en hänvisning till leverantörens standardvärde. Libre WebUI kopierar inte manifestets standardvärden till ett kontos sparade inställningar enbart för att panelen öppnades.

Vid sparning skickas endast fält som har ändrats under den aktuella redigeringssessionen. Om ett sparat, icke-känsligt värde töms tas kontots åsidosättning bort och leverantörens standardvärde återställs. Ett tomt, maskerat känsligt fält lämnas oförändrat. Reset to Defaults tar bort varje variabelåsidosättning som kontot har behörighet att hantera. Om en sparning eller återställning misslyckas behåller redigeraren de osparade värdena synliga, så att användaren kan försöka igen.

Skillnaden är viktig för anpassade slutpunkter: en administratör lämnar slutpunkten tom för att ärva pluginets medföljande URL eller anger en fullständig kompatibel URL för att åsidosätta den i administratörens leverantörsanslutning.

Plugin i Work

Work kan använda aktiva completion- och chat-plugin utöver Ollama och Ollama Cloud. En pluginbaserad Work-körning godtas endast när:

• pluginet är aktivt
• dess modell finns i den aktuella användarens identifierade katalog eller i pluginets konfigurerade modellmappning
• autentiseringsuppgifter är tillgängliga för den aktuella administratören.

Work sparar den valda leverantörstypen och plugin-ID:t tillsammans med både uppgiften och varje körning. Dirigeringen bygger därför på exakt vilken leverantör som har sparats, inte enbart på modellnamnet. När ett plugin vars modellnamn motsvarar en Ollama-modell aktiveras kan det inte tyst dirigera om en befintlig uppgift.

Work anpassar verktygsanrop via de inbyggda OpenAI-kompatibla, Anthropic- och Gemini-formaten för förfrågningar och svar. Den valda modellen måste stödja verktygsanrop även om leverantören erbjuder vanliga chattkompletteringar. Om leverantören avvisar verktyg eller returnerar ett inkompatibelt svar misslyckas körningen utan att falla tillbaka på en annan leverantör.

En Work-fjärrkörning kan göra flera leverantörsförfrågningar. Leverantören tar emot Works systemprompt, konversationskontext, verktygsdefinitioner och begärda verktygsresultat. Verktygsresultat kan innehålla källfiler, kataloglistningar eller kommandoutdata. I Work visar Libre WebUI ett användarspecifikt meddelande om fjärrleverantören som kan stängas. Operatörer bör ändå granska leverantörens priser och policyer för lagring och träning innan en tjänst aktiveras för känsliga projekt.

Embeddings

Plugin med stöd för inbäddningar kan visas i dokumentens inbäddningsinställningar. Libre WebUI identifierar även sannolika Ollama-inbäddningsmodeller, till exempel nomic-embed-text, bge, e5, gte och liknande modellnamn.

När ingen inbäddningsmodell hittas använder gränssnittet nomic-embed-text som lokal standardkandidat.

Anmärkningar om pluginutveckling

En plugindefinition bör beskriva förmågan tydligt och inte påstå att en leverantör stöder funktioner som den inte tillhandahåller. Håll modellmappningarna tillräckligt små för att fungera som användbara reservvärden och föredra identifiering för leverantörer med snabba, tillförlitliga API:er för modellistor.

När du lägger till en leverantör:

1. Lägg till plugindefinitionen.
2. Definiera nyckeln för autentiseringsuppgifter eller fälten för användarens autentiseringsuppgifter.
3. Implementera modellidentifiering om leverantören erbjuder en slutpunkt för modellistan.
4. Lägg till förfrågningsmappning för chatt, inbäddningar, bilder, TTS eller STT.
5. Testa tillstånden för saknad nyckel, felaktig nyckel och leverantörsfel.

Relaterad dokumentation

• Miljövariabler
• Arbeta med modeller
• Work: Isolerade arbetsytor
• Kimi Code
• MLX LM på Apple Silicon