---
title: 'Házi LLM Gateway építése AlmaLinuxon'
url: 'https://blog.had3sz.com/hu/hazi-llm-gateway-epitese-almalinuxon'
markdown: 'https://blog.had3sz.com/hu/hazi-llm-gateway-epitese-almalinuxon.md'
lang: hu
date: '2026-07-16'
description: '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…'
taxonomy:
  category:
    - cikk
  tag:
    - AI
---

$ cat hazi-llm-gateway-epitese-almalinuxon.md 

# Házi LLM Gateway építése AlmaLinuxon

*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:

```bash
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:

```yaml
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:

```yaml
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:

```ini
[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:

```json
{
  "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:

```bash
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:

```yaml
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ű:

```bash
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."

 Last modified: 2026-07-16 15:40:39 | Size: 9835 bytes

---

## Navigation

- Previous: [About](https://blog.had3sz.com/hu/about.md)
- Next: [Otthoni AI Labor Kialakítása Linux Alapokon](https://blog.had3sz.com/hu/otthoni-ai-labor-kialakitasa-linux-alapokon.md)