Plugins

Libre WebUI bruger plugins til at forbinde eksterne AI-udbydere og modelfunktioner sammen med lokal Ollama.

Plugintyper

Type	Formål
Chat/completion	Tekst- og chatmodeller fra udbyder-API'er
Embeddings	Vektor-embeddings til dokumentsøgning og hukommelse
Billedgenerering	Billedmodeller og ComfyUI-lignende backends
Tekst-til-tale	Udbydere af stemmesyntese
Tale-til-tekst	Udbydere af transskription
Lydgenerering	Udbydere af lyd og lydgenerering
Videogenerering	Udbydere af asynkron videogenerering

Plugins kan udstille statiske modelkort og, hvor det understøttes, opdatere tilgængelige modeller fra udbyder-API'er.

Indbyggede udbyderfamilier

Libre WebUI indeholder udbyderdefinitioner til almindelige tjenester:

• OpenAI og OpenAI-kompatible API'er
• Anthropic
• Google Gemini
• Groq
• Kimi Code fra Moonshot AI
• Mistral
• OpenRouter
• Hugging Face
• GitHub Models
• MLX LM til lokal inferens på Apple Silicon
• ComfyUI
• ElevenLabs

Udbyderkataloger ændres ofte. Når et plugin understøtter aktuel modelsøgning, skal brugergrænsefladen betragtes som sandhedskilden.

Ejerskab og godkendelse

Plugindefinitioner er fælles instanskonfiguration. Alle /api/plugins-ruter kræver godkendelse, og kun administratorer kan uploade, installere, opdatere eller slette en definition. Aktivering er anderledes: Hver godkendt bruger kan kun aktivere eller deaktivere et fælles plugin for sin egen konto. Tilstanden gemmes i SQLite og overlever genstart af backend uden at påvirke en anden brugers aktive udbydere.

Under opgradering kopieres den ældre globale aktiveringsliste i .status.json én gang til eksisterende konti, men kun for definitioner, der præcist matcher Libre WebUI's kompilerede tillidsankre. Ældre tilpassede eller overskyggende definitioner forbliver i karantæne og inaktive. Konti, der oprettes efter migreringen, starter uden aktive plugins.

Medfølgende definitioner betros kun, når deres normaliserede indhold matcher en hash, der er kompileret ind i backend. Skrivbare definitioner godkendes i SQLite ud fra normaliseret kildesti og fuld definitionshash. Installation, opdatering eller genimport som administrator registrerer godkendelsen; direkte filændringer ugyldiggør den. Godkendelse og opdatering rydder alle kontis aktivering, før filen erstattes, så hver bruger skal genaktivere den gennemgåede definition. Tilpassede definitioner fra før opgraderingen skal genimporteres af en administrator, før de kan vises i kataloger, registrere modeller, modtage legitimationsoplysninger eller udføre en funktion.

Pluginvariabler opdeles efter formål. Kun administratorer kan gemme kendte variabler til forbindelsesrouting:

endpoint, base_url, api_path, models_endpoint, api_url, image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint, voice_clone_endpoint, api_mode, model og model_id. En funktions erklærede config.endpoint_variable, config.models_endpoint_variable eller config.voice_clone_endpoint_variable regnes også som forbindelsesrouting, selv når den bruger et andet navn.

Ikke-administratorer kan fortsat gemme genereringskontroller som temperature og streamingpræferencer. Gamle routingrækker, der tilhører en ikke-administrator, ignoreres, returneres ikke som konfigurerede værdier og fjernes ved kontoens fulde nulstilling af pluginvariabler. Det forhindrer en senere rolleforfremmelse i lydløst at genoplive en inaktiv rute.

Legitimationsoplysninger

Legitimationsoplysninger kan komme fra miljøvariabler eller brugerindstillinger.

Eksempler 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=...

I delte installationer er legitimationsoplysninger på brugerniveau normalt bedst, fordi hver bruger styrer sin egen udbyderfakturering og sine grænser. Miljønøgler er nyttige til enkeltbrugerinstallationer, demoer eller administrerede installationer.

En miljønøgle er kun fallback, mens anmodningen bruger routing- og godkendelsesprojektionen fra en ikke-overskygget medfølgende plugindefinition. En importeret definition, en skrivbar definition, der overskygger et medfølgende ID, eller en administratorgemt override af forbindelsesrouting kræver legitimationsoplysninger gemt af samme konto. Libre WebUI sammenligner rodslutpunktet, godkendelsesfelter, funktionsslutpunkter og vælgere af slutpunktsvariabler samt kendte definitioner og standarder for routingvariabler, før miljøfallback tillades. Den kompilerede manifesthash er stadig autoritativ, selv når mapperne til ældre og medfølgende plugins deler en sti som i standardcontainerlayoutet. Et overskrevet pakkemanifest kan ikke etablere sin egen tillid.

Reglen gælder for søgning, Chat, Work, tilgængelighedstjek og funktionskataloger. Den forhindrer et tilpasset slutpunkt eller et tilpasset manifest fra før opgraderingen i at modtage en operatørstyret hemmelighed.

Brugergemte legitimationsoplysninger bindes til den effektive definitionskilde, fulde definitionshash, godkendelseskontrakt, funktionsslutpunkter og -vælgere samt effektive routingværdier på gemmetidspunktet. En ændring af ruten eller definitionen gør de gamle legitimationsoplysninger utilgængelige, indtil brugeren gennemgår den nye destination og gemmer dem igen. Ældre legitimationsoplysninger uden binding accepteres kun på en nøjagtigt forankret medfølgende rute. Ved første vellykkede brug skrives bindingen, før den dekrypterede nøgle returneres.

OpenAI-kompatible udbydere

Mange udbydere udstiller et OpenAI-kompatibelt API. Et plugin kan definere:

• Fuld URL til API-slutpunkt
• Miljøvariabel til API-nøgle
• Adfærd for Chat-slutpunkt
• Understøttelse af embeddings
• Adfærd for modelsøgning
• Valgfrit fallback-modelkort

Hvis en udbyder ikke understøtter aktuel modelsøgning, bruger Libre WebUI det konfigurerede modelkort. Importeret plugin-JSON konfigurerer udbydere, der allerede bruger et af Libre WebUI's understøttede wire-formater: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages eller Gemini. JSON alene oversætter ikke en vilkårlig proprietær protokol. En udbyder med en anden struktur for anmodning, streaming, værktøjskald eller svar kræver en lille backendadapter.

OpenAI-billedgenerering

Den medfølgende OpenAI-udbyder udstiller Image API på https://api.openai.com/v1/images/generations. gpt-image-2 er den aktuelle model. Kataloget beholder også ID'erne gpt-image-1.5, gpt-image-1 og gpt-image-1-mini, som ikke længere anbefales, til eksisterende kompatible installationer. Nye konfigurationer bør vælge gpt-image-2.

Billedgenerering bruger de samme effektive OpenAI-legitimationsoplysninger som Chat: den aktuelle brugers gemte nøgle eller den betroede medfølgende udbyders miljøfallback. En separat valgfri image_endpoint-override forhindrer, at et tilpasset Chat-slutpunkt ved en fejl modtager billedanmodninger. Lad image_endpoint være tom for at arve det medfølgende Image API-slutpunkt.

Billedvalg er knyttet til udbyderen. Når to billedplugins udstiller samme model-ID, sender Libre WebUI kun anmodningen til den udbyder, der er valgt i billedpanelet. GPT Image-svar bruger base64-billeddata. Libre WebUI konverterer dataene til et billede i appen og gemmer det i den aktuelle brugers galleri. Image API-ruter kræver godkendelse, og direkte genereringsanmodninger skal indeholde både pluginId og model. De kan sætte n til et JSON-heltal fra 1 til 10. Numeriske strenge og brøkværdier afvises, før de når udbyderen.

API-tilstande for Chat Completions og Responses

OpenAI-kompatible completionplugins kan bruge anmodningssemantikken chat_completions eller responses. Det medfølgende OpenAI-plugin viser valget i Settings → Plugins.

Forbindelsesindstillinger bestemmes i denne rækkefølge:

1. En fuld endpoint-override, når den er konfigureret.
2. base_url plus en valgfri api_path.
3. Pluginets ældre endpoint.

En slutpunktsværdi, der præcist matcher slutpunktet i pluginmanifestet, behandles som manifestets standard og ikke som en override. Det forhindrer gamle gemte standarder i at overskygge en ny Base URL efter en opgradering. Et reelt tilpasset fuldt slutpunkt har stadig højeste prioritet.

Standardstien er /chat/completions i Chat Completions-tilstand og /responses i Responses-tilstand. base_url bør være API-roden, for eksempel https://api.example.com/v1. Brug api_path, når en kompatibel udbyder udstiller operationen på en anden relativ sti. Et fuldt slutpunkt skal indeholde hele operationsstien og har forrang for begge felter. Et kendt suffiks /chat/completions, /completions eller /responses bestemmer anmodningssemantikken. Tilpassede slutpunktsstier beholder den valgte api_mode.

Importeret plugin-JSON kan angive de samme standarder:

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

Responses-anmodninger bruger input, max_output_tokens, fladgjorte funktionsværktøjer og store: false samt anmoder om krypteret ræsonneringsindhold til tilstandsløs fortsættelse. Færdigt og streamet Responses-output normaliseres tilbage til Libre WebUI's hændelsesformater for Chat og Work. Replay-tilstand bevares kun, når det komplette sorterede output-Item-array er på højst 64 Items og 90 KB. Items bevares nøjagtigt og afkortes aldrig pr. felt. Items, der kan afspilles igen, kræver unikke, ikke-tomme ID'er og typer. Strukturer for beskeder, ræsonnering og funktionskald valideres, før et værktøjskald udsendes. For stor Chat-tilstand falder tilbage til normaliseret synlig historik. Chat kasserer også rå Items med funktionskald, fordi Chat ikke bevarer de tilsvarende værktøjsresultater. Work-svar med værktøjer, men uden en afgrænset og nøjagtig replay-tilstand, afvises før enhver værktøjsbivirkning.

SQLite-baseret Chat-lagring krypterer den bevarede udbydertilstand sammen med beskeden. Work gemmer tilstand, der kun vedrører værktøjer, i skjulte kontekstrækker, som besked-API'er ikke returnerer. Et hashet scope binder replay til samme udbyder, model, Responses-tilstand, endeligt konfigureret slutpunkt og et uigennemsigtigt envejsfingeraftryk af de valgte legitimationsoplysninger. Når scopet ændres, herunder efter rotation af API-nøglen, falder Libre WebUI tilbage til normaliseret beskedhistorik i stedet for at sende udbyderspecifikke Items over en godkendelsesgrænse. En aktiv Work-kørsel danner også fingeraftryk af routing og legitimationsoplysninger og genvaliderer dem umiddelbart før hver udbyderrunde. Ændring af tilstand, slutpunkt eller API-nøgle stopper kørslen, før en ny anmodning kan modtage tidligere værktøjstilstand.

Tilstand med værktøjer skal passe både inden for replay-grænsen og den komplette vedvarende metadataindpakning på 100 KB, før Work udfører en bivirkning. Hvis en vedvarende Work-batch blev afbrudt, gendannes hvert manglende værktøjsresultat med sit præcise kald-ID og en advarsel om ukendt resultat, så udbyderen kan undersøge arbejdsområdet i stedet for blindt at gentage en mulig bivirkning. Et ufuldstændigt Responses-resultat behandles ikke som en vellykket Chat- eller Work-tur. incomplete_details.reason bevares og vises for kalderen.

Modelsøgning afleder /models fra begge operationsstier. For eksempel søger https://api.example.com/v1/responses fra https://api.example.com/v1/models. Udbydere uden et kompatibelt slutpunkt til modellisten kan stadig bruge et manuelt model_map. Søgning afgrænses til den aktuelle brugers variabler og legitimationsoplysninger. Resultater bevares pr. bruger i stedet for at blive skrevet i det fælles pluginmanifest. Søgning kører efter aktivering, eksplicit opdatering, ændring af API-nøgle, ændring af forbindelsesvariabler og nulstilling af variabler. Gemning af ikke-relaterede genereringsvariabler udløser ikke en netværksanmodning.

Søgning kører også automatisk. Når pluginlisten læses, søges alle aktive completionudbydere igen, hvis katalog mangler eller er ældre end PLUGIN_MODEL_DISCOVERY_TTL_MS. En genindlæsning af programmet afspejler derfor udbyderens aktuelle modeller i stedet for kataloget fra aktiveringstidspunktet. En backoff pr. udbyder forhindrer, at en utilgængelig udbyder probes ved hver anmodning, og en deadline forhindrer en langsom udbyder i at forsinke svaret. En opdatering, der varer længere, leveres ved den næste anmodning.

Den endelige afledte søge-URL kontrolleres, før brugerens legitimationsoplysninger læses eller en godkendelsesheader bygges, også når URL'en kommer fra et importeret pluginmanifest. Søgning og anmodninger om udbyderfunktioner følger ikke HTTP-omdirigeringer. Konfigurer det endelige slutpunkt til Chat, Work, modelliste, billede, embedding, transskription, tale, stemmekloning, lyd eller video direkte. Det forhindrer videresendelse af legitimationsoplysninger fra en valideret URL til en ikke-valideret omdirigeringsdestination.

Udbyderslutpunkter kan bruge HTTP eller HTTPS. HTTP sender API-nøgler, prompter, værktøjsresultater og genereret indhold uden transportkryptering, så brug det kun til en selvhostet gateway på et betroet netværk, og foretræk HTTPS, når gatewayen understøtter TLS. Anmodninger kommer fra backend. I containerinstallationer betyder det en service-URL som http://ai-gateway:8080/v1, mens localhost identificerer selve Libre WebUI-containeren. Pluginruter til funktioner, herunder billedgenerering, vælger slutpunktsvariabler og legitimationsoplysninger for den godkendte konto, der sender anmodningen. Libre WebUI har ingen enkeltbrugertilstand uden godkendelse.

Funktionsspecifikke slutpunkter

Overrides af Chat-slutpunkter er adskilt fra funktionerne til billeder, embeddings, transskription, tekst-til-tale, lyd og video. Plugins med flere funktioner kan udstille image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint eller en anden variabel navngivet af config.endpoint_variable. Ruter til stemmekloning kan på samme måde navngive config.voice_clone_endpoint_variable. Tomme felter bruger det funktionsslutpunkt, pluginet erklærer. Et generelt Chat-endpoint bruges aldrig som funktionsoverride.

Det medfølgende GitHub Models-plugin arver sit aktuelle slutpunkt models.github.ai/inference/chat/completions, når den valgfrie override er tom. Hugging Face-pluginet bruger opgavespecifikke ruter og payloads på hf-inference/models/{model} til embeddings, billeder og tekst-til-tale i stedet for at sende anmodningerne til sit Chat-slutpunkt.

Tilsidesættelse af slutpunkter

Variablen endpoint er den komplette anmodnings-URL inklusive operationsstien. Et OpenAI-kompatibelt chatplugin bruger for eksempel normalt en URL som https://provider.example/v1/chat/completions, ikke kun https://provider.example. Importerede ældre pluginkonfigurationer kan kalde variablen api_url. Libre WebUI accepterer dette alias, men en ikke-tom endpoint har altid forrang, når begge findes.

Absolutte HTTP- og HTTPS-URL'er til slutpunkter accepteres; andre protokoller afvises. HTTP er beregnet til selvhostede gateways på betroede netværk, fordi det sender legitimationsoplysninger og anmodningsindhold uden transportkryptering. Foretræk HTTPS til alle ruter, der forlader en privat installationsgrænse. En tom override bruger det fulde slutpunkt fra plugindefinitionen. En eksplicit ugyldig override afvises i stedet for lydløst at route til standarden.

Udbyderanmodninger følger ikke omdirigeringer. Konfigurer den endelige validerede operations-URL direkte. Et omdirigeringssvar rapporteres som en udbyderfejl i stedet for at videresende legitimationsoplysninger eller anmodningsindhold til endnu et hop.

Husk, at anmodninger kommer fra Libre WebUI-backend. I en container identificerer localhost selve containeren, ikke automatisk containerværten eller en anden tjeneste. Brug gatewayens containerservicenavn eller et navn, der kan nå værten, som host.docker.internal, når containerkørselstiden leverer det.

Modelsøgning

Settings → Plugins indeholder arbejdsområdet Provider connections til dette flow. Søg efter en udbyder i venstre panel, vælg den, og brug højre panel til at gennemgå dens aktive tilstand og effektive modelkatalog. Udbyderkonfigurationen forbliver sammenklappet, indtil Configure vælges. Det holder slutpunkt, legitimationsoplysninger og avancerede genereringskontroller ude af standardvisningen.

For chat- og completionudbydere kører Refresh models søgning for den valgte udbyder og genindlæser derefter både pluginkataloget og Chats modelliste. Kataloget er skrivebeskyttet. Rækkerne kommer fra den aktuelle brugers registrerede ID'er samt modelkort for funktioner i plugindefinitionen. Funktionslabels beskriver, hvilken pluginrute der viser en model; de er ikke sundhedstjek. Tilføj fallback-model-ID'er eller manuelt vedligeholdte model-ID'er gennem model_map i plugin-JSON, ikke ved at redigere en registreret række.

Når et plugin aktiveres, forsøger Libre WebUI modelsøgning med kontoens effektive slutpunkt og legitimationsoplysninger. En administrators tilpassede rute kræver legitimationsoplysninger gemt af samme konto. Miljøfallback bruges kun med den betroede manifestrute. Til kompatible API'er afleder Libre WebUI en URL til modellisten fra det fulde slutpunkt:

• en URL, der ender med /models, bruges uændret;
• kendte operationssuffikser som /chat/completions, /completions, /responses, /embeddings eller /messages erstattes med /models;
• ellers føjes /models til stien.

Plugins, der ikke kan bruge den afledte URL, kan udstille models_endpoint som en eksplicit fuld URL til modellisten. Den har forrang for afledningen, er underlagt samme politik for udgående URL'er og anmodes uden at følge omdirigeringer. Gemning eller nulstilling af endpoint, api_url, models_endpoint, base_url, api_path eller api_mode rydder og opdaterer den aktuelle brugers registrerede katalog, før UI genindlæser det.

Alle tilpassede ruter opløses og valideres før valg af legitimationsoplysninger. Politikken må ikke falde tilbage til en miljønøgle på serveren for en gemt tilpasset rute. Konfigurer i stedet en nøgle pr. bruger til ruten. Miljøfallback er forbeholdt det slutpunkt, den betroede plugindefinition leverer.

Søgning forventer et OpenAI-kompatibelt svar med model-ID'er i et data-array. Aktivering venter på forsøget før retur, så den første opdatering af pluginlisten kan indeholde det registrerede katalog. Vellykkede resultater gemmes pr. bruger og lægges oven på brugerens pluginvisning. Libre WebUI omskriver ikke den fælles plugin-JSON og udstiller ikke én brugers registrerede model-ID'er til en anden konto. Hvis udbyderen ikke har et kompatibelt modellisteslutpunkt, ikke kan nås eller returnerer en anden svarstruktur, bevarer en almindelig aktivering brugerens tidligere søgeresultat. En bevidst ændring af et forbindelsesfelt rydder først det forældede katalog og bruger derfor pluginets fallback model_map, når den nye rute ikke kan registreres.

Gemning eller nulstilling af forbindelsesrouting rydder kontoens tidligere registrerede katalog før næste søgeforsøg, så modeller fra én destination ikke forbliver valgbare efter en ruteændring.

Pluginstatus, Work-tilgængelighed, modelkataloger og funktionsruter bruger samme brugerkontekst og grænse for legitimationsoplysninger. Tilgængelighed af billedmodeller, slutpunktsvariabler og legitimationsoplysninger vælges for eksempel for den bruger, der sender anmodningen.

Præcist udbydervalg i Chat

Model-ID'er er ikke globalt unikke. En Ollama-model og flere aktive plugins kan alle udstille en model med navnet example-model. Chat gemmer derfor det rå model-ID sammen med en valgfri udbyderidentitet:

• providerType: "ollama" identificerer den lokale eller konfigurerede Ollama-rute;
• providerType: "plugin" plus providerId identificerer ét præcist plugin.

Udbyderkvalificerede, URL-kodede værdier bruges kun som kollisionssikre nøgler i modelvælgere. Anmodninger sender fortsat udbyderens rå model-ID. Dublerede modelnavne for Ollama/plugin og plugin/plugin forbliver separate valg, og genåbning af en chat gendanner det præcise gemte valg.

Eksplicit udbyderidentitet fejler lukket. Hvis et valgt plugin deaktiveres, fjernes eller ikke længere annoncerer modellen, beholder Libre WebUI det gemte valg synligt som utilgængeligt og skifter ikke lydløst til en anden udbyder med samme modelnavn. Genaktivér udbyderen, eller vælg eksplicit en anden model før næste generering.

Sessioner og præferencer oprettet før lagring af udbyderidentitet kan have providerType og providerId uindstillet eller null. Disse ældre poster bevarer deres historiske routing kun efter navn af hensyn til kompatibilitet, fordi den oprindelige udbyder ikke kan rekonstrueres pålideligt. Vælgeren viser posterne som "provider not recorded" i stedet for at gætte en Ollama- eller pluginlabel. Valg af en konkret udbyderpost registrerer en præcis udbyder til efterfølgende anmodninger. Nye personavalg bevarer deres UI-identitet persona:<id> og registreres som Ollama-baserede.

Udbyderindstillinger og nedarvning

Åbn Settings → Plugins, og vælg Configure for en udbyder. Udbyderpaneler er lukket som standard. Administratorer kan administrere fælles definitioner og værdier til forbindelsesrouting. Andre godkendte brugere kan aktivere udbydere, gemme egne API-nøgler og ændre egne genereringskontroller, men brugergrænsefladen viser ikke kontroller til upload, installation, eksport, sletning eller routing af plugins for dem.

For administratorer vises forbindelsesoverrides først. Sampling og andre specialkontroller forbliver under Advanced parameters, som også er lukket som standard. Nedarvede forbindelses- og genereringsværdier gengives som tomme inputfelter med et hint om udbyderens standard. Libre WebUI kopierer ikke manifeststandarder til en kontos gemte indstillinger, blot fordi panelet blev åbnet.

Gemning sender kun felter, der er ændret i den aktuelle editorsession. Rydning af en gemt, ikke-følsom værdi fjerner kontoens override og gendanner udbyderens standard. Et tomt maskeret følsomt felt forbliver uændret. Reset to Defaults fjerner alle variabeloverrides, som kontoen må administrere. Hvis gemning eller nulstilling mislykkes, beholder editoren de ikke-gemte værdier synlige, så brugeren kan prøve igen.

Denne forskel er vigtig for tilpassede slutpunkter: En administrator lader slutpunktet være tomt for at arve pluginets medfølgende URL eller angiver en komplet kompatibel URL for at tilsidesætte den for administratorens udbyderforbindelse.

Plugins i Work

Work kan bruge aktive completion- og chat-plugins ud over Ollama og Ollama Cloud. En pluginbaseret Work-kørsel accepteres kun, når:

• pluginet er aktivt;
• modellen findes i den aktuelle brugers registrerede katalog eller pluginets konfigurerede modelkort; og
• legitimationsoplysninger er tilgængelige for den aktuelle administrator.

Work gemmer den valgte udbydertype og plugin-ID både med opgaven og hver kørsel. Routing baseres derfor på den præcist gemte udbyder, ikke kun modelnavnet. Aktivering af et plugin, hvis modelnavn matcher en Ollama-model, kan ikke lydløst omdirigere en eksisterende opgave.

Work tilpasser værktøjskald gennem indbyggede OpenAI-kompatible, Anthropic- og Gemini-formater til anmodning/svar. Den valgte model skal understøtte værktøjskald, selv hvis udbyderen tilbyder almindelige chat completions. Hvis udbyderen afviser værktøjer eller returnerer et inkompatibelt svar, mislykkes kørslen uden fallback til en anden udbyder.

En ekstern Work-kørsel kan foretage flere udbyderanmodninger. Udbyderen modtager Works systemprompt, samtalekontekst, værktøjsdefinitioner og de ønskede værktøjsresultater. Værktøjsresultater kan indeholde kildefiler, mappelister eller kommandooutput. Libre WebUI viser en meddelelse pr. bruger om den eksterne udbyder i Work, som kan afvises. Operatører bør stadig gennemgå udbyderens priser samt politikker for opbevaring og træning, før en tjeneste aktiveres til følsomme projekter.

Embeddings

Plugins med embeddingfunktioner kan vises i dokumenternes embeddingindstillinger. Libre WebUI registrerer også sandsynlige Ollama-embeddingmodeller som nomic-embed-text, bge, e5, gte og lignende modelnavne.

Når ingen embeddingmodel registreres, bruger UI nomic-embed-text som lokal standardkandidat.

Bemærkninger om pluginudvikling

En plugindefinition bør beskrive funktionen tydeligt og ikke foregive, at en udbyder understøtter funktioner, den ikke udstiller. Hold modelkort små nok til at være nyttige som fallback, og foretræk søgning for udbydere med hurtige, pålidelige API'er til modellister.

Når en udbyder tilføjes:

1. Tilføj plugindefinitionen.
2. Definer nøglen til legitimationsoplysninger eller brugerens legitimationsfelter.
3. Implementer modelsøgning, hvis udbyderen tilbyder et slutpunkt til modellisten.
4. Tilføj anmodningsmapping til chat, embeddings, billede, TTS eller STT.
5. Test tilstande med manglende nøgle, ugyldig nøgle og udbyderfejl.

Relateret dokumentation

• Miljøvariabler
• Arbejde med modeller
• Work: Isolerede arbejdsområder
• Kimi Code
• MLX LM på Apple Silicon