Server llama.cpp umí nástroje oddělit do Dockeru, výchozí kontejner jim ale nechává síť

Server llama.cpp dostal 8. srpna do hlavní větve první podporu odděleného běhu nástrojů přes Docker. Agent tak může číst a zapisovat soubory nebo pouštět příkazy uvnitř kontejneru místo přímo v počítači, na kterém běží model. Funkce je označená jako experimentální.

Nová volba --tools-runtime přijímá dva způsoby spuštění. Zápis docker:<image> založí nový kontejner z vybraného obrazu a používá ho pro další volání. Varianta docker-container:<id> připojí server k už běžícímu kontejneru, který si správce připravil sám.

Bez této volby se chování nemění: nástroje běží na hostitelském systému. Dokumentace navíc dál varuje, že vestavěné nástroje se nemají zapínat v nedůvěryhodném prostředí. Samotné přesunutí do Dockeru totiž ještě neurčuje, kam smí příkaz po síti ani kolik prostředků může spotřebovat.

Server ovládá jeden kontejner přes docker exec

Zdrojový kód llama.cpp při volbě nového obrazu spustí docker run --rm -i, uloží si identifikátor kontejneru a uvnitř otevře shell. Každou další operaci předá přes docker exec. Při ukončení serveru zavře vstup kontejneru a Docker ho díky volbě --rm odstraní.

Oddělení se týká všech vestavěných operací nad soubory i příkazového nástroje. Kontejner má vlastní souborový systém a spouštěcí příkaz nepřipojuje žádný adresář hostitele. Když nástroj potřebuje zapsat obsah, server ho do kontejneru přenese přes docker cp. Zadaný obraz musí obsahovat prostředí POSIX a běžné příkazy jako sh, cat, find či timeout.

Jiná pravidla platí pro již existující kontejner. llama.cpp ho nevytváří ani při ukončení nezastavuje. Pokud zmizí, požadavek skončí chybou. U kontejneru založeného serverem naopak kód počítá s novým spuštěním, když předchozí instance nečekaně skončí.

Výchozí spuštění nezakáže síť ani spotřebu

Příkaz, který llama.cpp skládá, nepoužívá --network none. Docker proto kontejner připojí k běžné výchozí síti, ze které může navazovat odchozí spojení. Režim bez sítě je v Dockeru samostatná volba; ponechá uvnitř jen místní rozhraní loopback. Nová funkce llama.cpp ji sama nepřidává.

Stejné je to s prostředky. Dokumentace Dockeru uvádí, že kontejner bez omezení nemá výchozí strop pro paměť a může využívat procesor hostitele podle možností plánovače. Spouštěcí kód llama.cpp nepředává --memory ani --cpus. Chybí v něm také režim souborového systému pouze pro čtení, volba neprivilegovaného uživatele a odebrání schopností procesu.

To neznamená, že nový režim nic neoddělí. Příkaz agenta se nedostane přímo do souborového systému hostitele a neběží mezi jeho běžnými procesy. Pokud však získá citlivá data uvnitř kontejneru, výchozí síť mu sama o sobě nebrání poslat je ven. Neomezená spotřeba zase dovoluje chybnému příkazu zatížit paměť nebo procesor celého počítače.

Připravený kontejner dává správci víc kontroly

Pro přísnější provoz je podstatná druhá varianta, docker-container:<id>. Správce může kontejner založit předem bez sítě, s limity paměti a procesoru, souborovým systémem pouze pro čtení nebo s neprivilegovaným uživatelem. llama.cpp se pak jen připojí k jeho identifikátoru. Konkrétní kombinaci musí určit podle nástrojů, které chce agentovi povolit; například zápis souboru se s plně uzamčeným souborovým systémem neslučuje.

Rozhraní dovoluje vybrat už běžící kontejner také hlavičkou x-tool-runtime pro konkrétní požadavek. V této podobě zatím přijímá jen schéma docker-container:. Neznámý typ běhového prostředí skončí chybou, takže se požadavek tiše nepřepne zpět na hostitele.

Sloučený návrh změny sám používá slovo „initial“, tedy počáteční podpora. V diskusi padly i náměty na Podman nebo vzdálené spuštění přes SSH, do této změny se ale nedostaly. Současný automaticky založený kontejner je užší hranice než přímý běh na hostiteli, nikoli hotové bezpečné prostředí pro libovolný cizí příkaz.