Lokální jazykový model lze rychle vyzkoušet. Sdílený AI asistent navíc potřebuje řízený přístup, jasné datové toky a někoho, kdo převezme provoz. Ollama a Open WebUI mohou spolupracovat: jedna součást spouští modely, druhá poskytuje rozhraní pro každodenní práci.
Ve firmě plánování začíná konkrétním úkolem: návrhy textů ze schválených podkladů, zpracování interních poznámek nebo pomoc s technickými dotazy. Před výběrem hardwaru je třeba určit povolené vstupy, kontrolu výsledků a vhodné doby odezvy.
Dvě součásti s odlišnými úkoly
Ollama poskytuje běhové prostředí a API pro jazykové modely. Open WebUI doplňuje spravovatelné webové rozhraní. Lokálně nainstalované rozhraní ale neříká, kde počítá každý připojený model. Cloudové modely, webové vyhledávání a další nástroje mohou používat jiné datové cesty.
V tomto provozním konceptu zaměstnanci přistupují k rozhraní schválenou cestou. Open WebUI se interně připojuje k Ollama. API modelu je omezené na služby, které ho skutečně potřebují. Propojení oddělených kontejnerů nebo serverů je nutné výslovně naplánovat: localhost označuje vlastní síťové prostředí každé součásti.
Od jedné pracovní stanice ke sdílené službě
Rozdíl je hlavně v tom, co následuje po prvním úspěšném chatu. Srovnání popisuje možný rozvoj pro malou firmu; je plánovací pomůckou, nikoli dokumentovaným zákaznickým projektem.
| Oblast | Individuální test | Sdílené používání |
|---|---|---|
| Přístup | Jedna osoba testuje na vlastním počítači. | Vlastní účty, definované role a řízené odebrání přístupu. |
| Data | Necitlivá ukázková data. | Schválené typy dat, uchování a doložitelná práva ke zdrojům. |
| Dostupnost | Počítač je během testu zapnutý. | Dohodnuté časy používání a dokumentovaná obnova provozu. |
| Kapacita | Jeden požadavek poskytne použitelnou odpověď. | Měří se souběžné úkoly, čekání a delší vstupy. |
| Změny | Model a software se zkoušejí. | Ověřené verze, záloha před změnami a spolehlivá cesta zpět. |
Přístup a API modelu zabezpečit odděleně
Lokální API Ollama podle výrobce nevyžaduje vlastní autentizaci. Zpřístupnění v síti proto nenahrazuje řízení přístupu. Pro firemní službu má být API modelu dostupné jen potřebnými interními spojeními. Port přístupný všem pracovním stanicím či internetu není vhodným výchozím bodem. Ollama: autentizace (externí odkaz).
Přihlášení, schvalování uživatelů a administrátorská oprávnění rozhraní nastavte vědomě. Stávající služba identit může být vhodnou integrací; konkrétní napojení závisí na prostředí. Proxy smí předávat přihlášenou identitu jen důvěryhodnými informacemi, které sama nastavuje. Open WebUI: přístup a oprávnění (externí odkaz).
HTTPS chrání spojení prohlížeče s přístupovým bodem. Při zapojení více systémů se podle potřeb ochrany šifruje a omezuje i další cesta k backendu. Certifikáty, přesměrování a spojení potřebná pro rozhraní se testují společně. Open WebUI: HTTPS a reverzní proxy (externí odkaz).
„Lokální“ ověřit podle skutečného toku dat
Pro výhradně lokální volání modelu nabízí Ollama režim bez svých cloudových funkcí. Ten nenahrazuje kontrolu dalších spojení v Open WebUI nebo přidaných nástrojích. Také stahování modelů a aktualizace potřebují plánovanou cestu získávání. Ollama: lokální použití a cloudové funkce (externí odkaz).
- Model: Která přesná verze zpracovává požadavek a kde běží?
- Dokumenty: Kde se ukládají nahrané soubory, extrahované texty, vyhledávací indexy a zálohy?
- Doplňkové služby: Využívají se další poskytovatelé pro hledání, rozpoznávání textu, hlas nebo embeddingy?
- Nástroje: Které spojení smí číst data nebo spouštět akce a s čími oprávněními?
Cloud a hybridní řešení mohou být vhodným doplňkem. Pak se výslovně určí poskytovatelé, typy dat a povolení. Přechod k externí službě nemá proběhnout nepozorovaně jen proto, že lokální model je právě vytížený.
Firemní znalosti vyžadují konkrétní oprávnění
Přihlášení nejprve určuje, kdo používá rozhraní. Automaticky neuděluje právo vidět všechny nahrané dokumenty. V příkladu může být schválená příručka dostupná všem pilotním uživatelům, zatímco personální dokumenty zůstanou zcela mimo pilot.
Při pozdějším připojování dalších zdrojů ověřte práva pro každou kolekci, dokument a uživatele. Informace mohou odhalit i výsledky hledání, citace, sdílené chaty a uložené odpovědi. Změny skupin nebo zdrojových oprávnění se musejí projevit ve znalostním řešení. Více na odborných stránkách Firemní znalosti a RAG a Bezpečnost AI a oprávnění.
Zálohy a aktualizace patří do konceptu
Zálohují se skutečně používaná data: databáze, nahrané soubory a konfigurace i klíče potřebné k obnově. Dokumentuje se název a přesná verze modelu, také upravené modely a vlastní doplňky. Záloha se uchovává odděleně od běžícího systému s chráněným přístupem.
Před aktualizací je třeba obnovitelná záloha, kontrola poznámek k vydání a test mimo produkční službu. Starý obraz kontejneru sám po migraci databáze nemusí obnovit předchozí stav. Open WebUI: aktualizace, záloha a návrat (externí odkaz).
Smysluplný test obnovy začíná v odděleném prostředí. Tam se ověří přihlášení, spojení s modelem, necitlivý testovací úkol a očekávaná oprávnění. Teprve potom lze odhadnout skutečnou délku výpadku. Běžící VM nebo existující adresář záloh samy o sobě nestačí.
Běžící rozhraní ještě neznamená fungující model
Monitoring má rozlišovat dostupnost rozhraní, připravenost vybraného modelu a funkčnost úplného požadavku. Tyto úrovně odděluje také dokumentace Open WebUI. Open WebUI: funkční monitoring (externí odkaz).
Pro dohodnutý provoz se sleduje i obsazení úložiště, dostupná kapacita, chybovost a čekací doby. Testovací požadavky neobsahují důvěrné informace. Logy mají stačit k diagnostice, nikoli plošně duplikovat všechny rozhovory. Před širším nasazením se určí, kdo reaguje na incidenty a kdo schvaluje aktualizace.
Přehledná akceptace před spuštěním
- Ověřit přístup: Schválený uživatel se dostane dovnitř; neschválený uživatel a nepovolená část sítě zůstanou vyloučeni.
- Ověřit datové toky: Model, rozhraní a všechny doplňkové služby používají pouze dohodnutá spojení.
- Ověřit oprávnění: Dvě testovací role získají pouze své povolené obsahy. Odebrání přístupu se projeví i po dříve úspěšném hledání.
- Ověřit zatížení: Typické úkoly běží samostatně i souběžně; zaznamenají se přijatelné čekací doby a limity.
- Ověřit obnovu provozu: Zálohu lze obnovit odděleně; odpovědnosti a cesta zpět jsou zdokumentované.
Potřebný hardware závisí na modelu, délce kontextu, souběžném používání a cílové kvalitě. Z architektury proto nelze odvodit univerzální počet současně obsluhovaných osob. Stávající článek Testování lokální AI: pilot s vypovídající zátěží toto ověření kapacity rozvádí.
Začít smysluplně s omezeným úkolem
DAXS může posoudit stávající infrastrukturu, naplánovat datové toky a přístupy a začlenit řešení do dohodnutého provozu. Dobrým prvním krokem je ohraničený případ použití s ověřitelným přínosem. Z něj vyplyne, zda ekonomicky a organizačně vyhovuje lokální služba, cloudové napojení nebo kombinace.
Lokální LLM a infrastruktura · MCP a rozhraní · Poptat AI poradenství a automatizaci
Zdroje: příklad popisuje možnou architekturu a postup ověření, nikoli univerzální instalační návod. Funkce produktů, licence modelů a skutečná kompatibilita se ověřují pro použité verze.
