Avagy hogyan futtass több száz millió paraméteres nyelvi modellt úgy, hogy közben nem veszíted el az eszed – és a konténereid sem eszik meg az összes RAM-ot

Tizenhét évvel ezelőtt, amikor még a CentOS 5-öt pakoltuk fel a Dell PowerEdge-ekre, senki sem gondolta volna, hogy egyszer majd otthoni gépen fogunk futtatni olyan neurális hálózatokat, amelyekkel akár kódot is írathatunk magunk helyett. De itt vagyunk, 2026-ban, és a mesterséges intelligencia már nem csak a nagyfelhős cégek privilégiuma. Az alábbiakban leírom, hogyan építettem fel egy teljesen container-mentes, systemd-alapú LLM infrastruktúrát AlmaLinux 9-re, amely a LiteLLM proxyt, az OpenCode fejlesztői környezetet és az oh-my-openagent multi-agent rendszert egyesíti egyetlen, költséghatékony, mégis brutálisan rugalmas platformban.

Miért pont AlmaLinux, és miért nélkülözzük a Dockert?

Először is tisztázzuk: nem vagyok konténer-ellenes. Sőt, éles környezetben gyakran használom. De amikor a saját gépeden, egy NVMe-n futtatod a dolgokat, és minden egyes gigabájt számít, akkor a Docker rétegei és a containerd overhead felesleges luxusnak tűnik. AlmaLinuxot választottam, mert a CentOS Stream utáni káoszban ez az egyetlen olyan RHEL-kompatibilis disztribúció, amelyre még lehet építeni anélkül, hogy félned kellene, hogy holnap átírják a csomagkezelési filozófiát.

Az architektúra: Fordító, Frontend és Az Agy

A rendszer három pilléren áll. Az első a LiteLLM Proxy, ami egy nyílt forráskódú AI Gateway. Képzeld el úgy, mint egy reverse proxyt, csak éppen nem HTTP végpontokat, hanem LLM providereket (OpenAI, Anthropic, helyi Ollama instance-ok) egyesít egyetlen OpenAI-kompatibilis API alá. A második az OpenCode, egy terminál-alapú AI kódoló asszisztens, ami a Cursor és a Claude Code nyílt alternatívája. A harmadik pedig az oh-my-openagent (OMO), egy plugin, ami az OpenCode-ot egy többágensű, szerepkör-alapú rendszerré alakítja át.

A lényeg: a LiteLLM kezeli a modellek elérhetőségét, a fallback láncokat és a költségvetést, az OpenCode a felhasználói interfész, az OMO pedig eldönti, hogy éppen melyik "szakértő" modell válaszoljon a kérdésedre – és mindezt úgy, hogy közben te csak egyetlen konfigurációs fájlt piszkálsz.

Telepítés: A venv-korszak művészete

Mivel Docker nincs, Python környezetet kell teremtenünk. A rendszer Python 3.9+ környezetet igényel, de AlmaLinux 9-en ez alapból adott. A LiteLLM telepítésekor én egy dedikált virtuális környezetet hoztam létre a /opt/litellm-proxy alatt:

python3 -m venv /opt/litellm-proxy
source /opt/litellm-proxy/bin/activate
pip install "litellm[proxy]"

Itt fontos megjegyezni, hogy a [proxy] extra telepíti a Prisma ORM-et is, ami a kulcsok, költések és felhasználók adatbázis-kezeléséért felel. Ha ezt kihagyod, később furcsa hibákat kapsz a prisma generate hiányára.

A LiteLLM konfigurációját egy config.yaml fájlban tároljuk. Itt definiáljuk a modellek listáját és a fallback láncokat. A konfiguráció lényege, hogy minden modellnek legyen egy "felhős" verziója (ami esetleg egy távoli Ollama instance-t használ), egy "fallback" verziója (pl. DeepSeek API), egy "openrouter-free" verziója (ingyenes tier), és egy "local-emergency" verziója (ami a saját gépeden futó kisebb modell, pl. egy Gemma 4B).

A fallback láncokat így definiáljuk:

fallbacks:
  - deepseek-v4-flash:cloud: 
      ["deepseek-v4-flash:cloud-fallback", "deepseek-v4-flash:openrouter-free", "deepseek-v4-flash:local-emergency"]

Ez azt jelenti, hogy ha a felhős instance nem válaszol, automatikusan ugrik a következőre, és így tovább, egészen addig, amíg a helyi vésztartalék meg nem menti a helyzetet. A router_settings résznél érdemes beállítani a simple-shuffle stratégiát és a cooldown időt, hogy ne floodold a halott node-okat:

router_settings:
  routing_strategy: "simple-shuffle"
  allowed_fails: 1
  cooldown_time: 5

A systemd szolgáltatás: Amikor a háttérben kell dolgoznia

Mivel nincs Docker, a LiteLLM-et systemd service-ként futtatjuk. Hozz létre egy /etc/systemd/system/litellm-proxy.service fájlt:

[Unit]
Description=LiteLLM Proxy Service
After=network.target

[Service]
Type=simple
User=litellm
Group=litellm
WorkingDirectory=/opt/litellm-proxy
Environment="PATH=/opt/litellm-proxy/bin"
Environment="DATABASE_URL=postgresql://litellm:*****@localhost:5432/litellm"
ExecStart=/opt/litellm-proxy/bin/litellm --config /etc/litellm/config.yaml --port 4000
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Itt fontos, hogy a DATABASE_URL környezeti változót beállítsd, ha használsz kulcskezelést és költés-nyomon követést. A PostgreSQL telepítése AlmaLinuxon egy dnf install postgresql-server paranccsal megoldható, de ez már egy másik történet.

OpenCode és az oh-my-openagent: A multi-agent káosz rendezése

Az OpenCode telepítése egyszerű – a hivatalos install scriptet futtatva megkapod a binárist a ~/.opencode/bin alá. De a varázslat akkor kezdődik, amikor telepíted az oh-my-openagent plugint. Ez a rendszer transzformálja az OpenCode-ot egy "virtuális csapattá", ahol különböző szerepkörökre optimalizált modellek dolgoznak párhuzamosan.

A konfigurációt az ~/.config/opencode/oh-my-openagent.json fájlban tároljuk. Itt definiálhatod az ágenseket:

• Prometheus: A vezérágens, stratégiai tervezésre
• Metis: A kódolási feladatok specialistája
• Sisyphus: A "kódgyúró", aki a repetitív feladatokat végzi
• Oracle: A minőségellenőrzésért felelős
• Hephaestus: A tesztelő és javító

Minden ágenshez hozzárendelhetsz egy modellt a LiteLLM proxyból. Például:

{
  "agents": {
    "prometheus": {
      "model": "localollama1/deepseek-v4-flash:cloud",
      "variant": "high"
    },
    "metis": {
      "model": "localollama1/qwen3-coder:480b-cloud",
      "variant": "high"
    }
  }
}

A localollama1 itt a provider neve, amit az OpenCode opencode.jsonc konfigjában definiálsz, és ami a LiteLLM proxydra mutat (pl. http://10.0.0.1:4000/v1).

A shell stratégia: Amikor nincs TTY, és nem is kell

Az egyik legnagyobb kihívás az OpenCode használatában a nem-interaktív környezet kezelése. Mivel az OMO plugin háttérben futó feladatokat is indíthat, a shell környezetnek teljesen non-interaktívnak kell lennie. Ez azt jelenti, hogy nincs vim, nincs less, és minden parancsnak meg kell kapnia a -y vagy --non-interactive flag-et.

A shell stratégiát egy külön fájlban (shell_strategy.md) definiáljuk, és az OpenCode konfigjában hivatkozunk rá. A lényeg, hogy beállítjuk a környezeti változókat:

export CI=true
export DEBIAN_FRONTEND=noninteractive
export GIT_TERMINAL_PROMPT=0
export PAGER=cat

És betartjuk a "BAD vs GOOD" paradigmát: soha ne használj git commit-ot interaktív módban, hanem mindig git commit -m "üzenet" formában. Ha egy script kérdezne valamit, használj yes | script.sh konstrukciót, vagy heredoc-ot.

Modellek és token-gazdálkodás: A VRAM védelme

A konfigurációban figyelj a max_tokens és num_ctx (context window) beállításokra. A LiteLLM litellm_settings szekciójában érdemes beállítani a globális max_input_tokens értéket, hogy véletlenül se küldj 100k tokennyi kontextust egy olyan modellnek, ami csak 32k-t bír el:

litellm_settings:
  max_input_tokens: 32768
  truncation: true
  tokenizer_backend: "huggingface"

A fallback láncoknál ügyelj arra, hogy a "local-emergency" modellek kisebb kontextusablakkal rendelkezzenek, de stabilak legyenek akkor is, amikor a felhős instance-ok éppen sztrájkolnak.

Üzemeltetés és naplózás: A journalctl barátsága

Mivel systemd service-eket használunk, a naplózás egyszerű:

journalctl -u litellm-proxy -f

A LiteLLM admin felülete (ha engedélyezed) a 4000-es porton érhető el, de élesben érdemes egy Nginx reverse proxy mögé tenni SSL-lel. Az oh-my-openagent által generált kulcsokat és a költési adatokat a PostgreSQL tárolja, amit időnként érdemes backup-olni.

Záró gondolatok: A jövő a saját gépeden

Tizenhét évvel ezelőtt még arról álmodtunk, hogy egyszer majd a saját szervertermünkben futtathatunk "nagy gépeket". Ma már egy RTX 4090-es mellett (vagy akár egy 2060-on is felhős modellel), egy AlmaLinux szerveren, systemd service-ekkel menedzselhetünk egy olyan AI infrastruktúrát, ami vetekszik a kereskedelmi szolgáltatásokkal – anélkül, hogy havi százezreket kellene költenünk API hívásokra.

A container-mentes megközelítés talán "öreg iskolásnak" tűnik, de a kontroll és az átláthatóság megéri a plusz konfigurálást. Amikor hajnali háromkor elszáll egy modell, és te pontosan tudod, hogy a systemd logban hol keresd a hibát, anélkül hogy Docker exec parancsokat kellene fabrikálnod – akkor érzed igazán azt a bizonyos rendszergazdai flow-t.

És emlékezz: a fallback lánc mindig legyen három szint mély. Mert ahogy a nagy könyvben meg van írva: "A felhő csak mások számítógépe, és néha az is leáll."