--- title: 'Otthoni AI Labor Kialakítása Linux Alapokon' url: 'https://blog.had3sz.com/hu/otthoni-ai-labor-kialakitasa-linux-alapokon' markdown: 'https://blog.had3sz.com/hu/otthoni-ai-labor-kialakitasa-linux-alapokon.md' lang: hu date: '2026-07-16' description: 'Ha valaki évekkel ezelőtt, 2007 környékén azt mondta volna nekem, hogy egyszer a nappalimban fogok egy olyan szervert üzemeltetni, ami természetes nyelven válaszol a kérdéseimre, képeket generál és saját keresőmotort futtat, valószínűleg elküldtem volna a melegebb éghajlatra. Akkor azt sem gondolta…' taxonomy: category: - cikk tag: - AI --- $ cat otthoni-ai-labor-kialakitasa-linux-alapokon.md # Otthoni AI Labor Kialakítása Linux Alapokon Ha valaki évekkel ezelőtt, 2007 környékén azt mondta volna nekem, hogy egyszer a nappalimban fogok egy olyan szervert üzemeltetni, ami természetes nyelven válaszol a kérdéseimre, képeket generál és saját keresőmotort futtat, valószínűleg elküldtem volna a melegebb éghajlatra. Akkor azt sem gondoltam hogy az okostelefonok olyan dolgok lesznek amik megváltoztatják a világot. Dehát sokszor tévedtem.. Aztán sok idő és sokminden megváltozott és jött a Docker, a nagy nyelvi modellek (LLM) forradalma, és hirtelen az embernek az a "bányászati" alaplapja, ami a garázsban porosodott (ASRock Q270 Pro BTC+), új értelmet nyer. Ebben a cikkben leírom, hogyan építettem fel egy komplett AI ökoszisztémát AlmaLinux 9-re, natív systemd szolgáltatásokkal és konténerekkel vegyesen, egy i7-7700-as processzor és egy RTX 2060-as grafikus kártya társaságában. ###### A Filozófia: Miért Nem a Cloud? Először is tisztázzuk: miért ne az OpenAI API-ját használnám? Egyszerűen azért, mert a saját adataimért felelősséget vállalok, és mert a kísérletezéshez nem akarok dollárcenteket számolgatni minden token után. Egy helyi laborban az ember azt tölti fel, amit akar, azt futtat, amit akar, és ha elszáll a Python környezet (mert elszáll), az csak az én hibám. Az AlmaLinux választása sem véletlen: a RHEL örökség stabilitása kell ahhoz, hogy ez a cucc hónapokig menjen újraindítás nélkül, miközben a Docker csak ott szerepel, ahol tényleg indokolt – jelen esetben az OpenWebUI-nál, ami elegánsan van becsomagolva. ###### A Hardver Realitása Ne áltassuk magunkat: egy i7-7700 (4 mag, 8 szál) és 32GB RAM nem mai darab. A 12GB VRAM az RTX 2060-on pedig szigorúan korlátoz. Ez azt jelenti, hogy a Gemma 4 12B modell már éppen hogy elfér int8 quantizálással, de a nagyobb modellekhez vagy a cloud Ollama instance-okhoz kell nyúlnunk. A 32GB rendszermemóriát viszont okosan kell elosztani: Qdrant (vektor adatbázis), Valkey (cache/session), SearXNG (Python alapú kereső), ComfyUI (PyTorch) és maga az Ollama mind-mind éhesek. Szerencsére a Q270 Pro BTC+ alaplap tudja a dolgát, bár a PCIe slotokat most nem bányászatra használjuk. ###### Az Architektúra Nagyképe Mielőtt belemennénk a parancsokba, nézzük meg, mi hogyan kapcsolódik egymáshoz: 1. Ollama – Natív systemd szolgáltatásként fut, port 11434-en. Ez a "agy", ami a helyi Gemma modelleket és a távoli API-kat is kezeli 2. Valkey – A Redis forkja, szintén natív. Session-öket és cache-t tárol az OpenWebUI számára, Unix socketen keresztül kommunikálva a gyorsaság kedvéért 3. SearXNG – Python virtuális környezetben, systemd alatt. A saját meta-keresőnk, amit az OpenWebUI webes kereséshez használ 4. Qdrant – Vektor adatbázis a RAG (Retrieval Augmented Generation) pipeline-hoz. Itt tárolódnak a dokumentumok embedding-jei 5. ComfyUI – A képgeneráló műhely, szintén systemd szolgáltatásként, hogy ne egy Docker rétegen keresztül kelljen a GPU-t megszólítani 6. OpenWebUI – Docker konténerben, ez a "frontend", ami összefogja a fenti komponenseket 7. Nginx – Reverse proxy, SSL terminálás, WebSocket támogatás ###### Telepítés: Lépésről Lépésre **1. AlmaLinux Alapok és NVIDIA Driver** Először is felrakjuk az AlmaLinux 9-et, beállítjuk a hostname-et (nevezzük ai-lab-nak például), és telepítjük az EPEL repót. Az RTX 2060-hoz szükségünk van az NVIDIA proprietary driverre és a CUDA toolkitre: \_sudo dnf config-manager --add-repo [https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86\_64/cuda-rhel9.repo](https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo)~~~~ sudo dnf install cuda-drivers\_ Ellenőrizzük az nvidia-smi kimenetét – ha látjuk a 2060-ast, jöhetnek a következő lépések. **2. Ollama Telepítése (Natív)** A Docker itt felesleges overhead. Töltsük le az Ollama binárist: *curl -fsSL | sh* Ez létrehozza az ollama felhasználót és a systemd service-t . Fontos, hogy a service file-ban (/etc/systemd/system/ollama.service) a User=ollama és Group=ollama beállítás szerepeljen, és a PATH tartalmazza az Ollama bináris helyét. Indítás után töltsük le a modelleket: *ollama pull gemma4:12b* A 12B modellnél figyeljünk: 12GB VRAM mellett ez épp hogy bele fér, de működik. **3. Valkey Beállítása (Redis Helyett)** Mióta a Redis licencet váltott, én a Valkey-t használom (a Redis forkja, nyílt forráskódú). Telepítés után a konfigurációs fájl (/etc/valkey/valkey.conf) kulcsfontosságú pontjai: *bind 127.0.0.1 10.0.0.x – csak a localhost és a belső hálózat érheti el* protected-mode yes – alapvető védelem unixsocket /run/valkey/valkey.sock – helyi socket a gyorsabb kommunikációhoz lazyfree-lazy-eviction yes – a háttérben takarít, ne blokkolja a főszálat A Sentinel mód most nem kell, egyszerű standalone instance-t futtatunk. *4. SearXNG Meta-Kereső* Ez a komponens adja a "webes tudásunkat" az AI-nak. Python virtuális környezetben futtatjuk: *sudo useradd -r -s /bin/false searxng sudo mkdir -p /usr/local/searxng cd /usr/local/searxng python3 -m venv searx-pyenv source searx-pyenv/bin/activate pip install searxng* A systemd service file (/etc/systemd/system/searx.service) pontosan úgy néz ki, mint a kontextusban látható: a webapp.py fut a virtuális környezet Pythonjával, a SEARXNG\_SETTINGS\_PATH mutat a konfigra A /etc/searxng/settings.yml fájlban állítsuk be a nyelvet (locale: hu\_HU), a motorokat (Google, Bing, DuckDuckGo, Wikipedia, Arxiv, PubMed), és a limiter: false értéket ha belső hálózaton használjuk. A limiter.toml-ban pedig a trusted\_proxies résznél adjuk meg a belső hálózatunk CIDR-ét (pl. 10.0.0.0/8) **5. Qdrant – A Vektor Adatbázis** A RAG működéséhez kell egy vektor adatbázis. A Qdrant natív futtatása egyszerű: letöltjük a binárist, és a config.yaml-t átírjuk. Fontos beállítások: storage\_path: ./storage – ahol az adatok lesznek on\_disk\_payload: true – mivel csak 32GB RAM-unk van, a payloadokat inkább diszken tároljuk hnsw\_index résznél az m: 16 és ef\_construct: 100 értékek jók kezdésnek Indítás systemd service-ként (a config alapján készítsünk saját service file-t). **6. ComfyUI – A Kreatív Rész** A képgeneráláshoz a ComfyUI-t használjuk, natív Python környezetben (conda ajánlott). A systemd service filet csináljunk hozzá: *ExecStart=/srv/ComfyUI/comfy.sh WorkingDirectory=/srv/ComfyUI Restart=always RestartSec=3 Environment="PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin:/srv/ComfyUI:/root/.conda/envs/comfy/bin"* hogy a /srv/ComfyUI könyvtárból induljon, dedikált shell scripttel (comfy.sh). *\#!/bin/bash cd /srv/ComfyUI conda activate comfy /root/.conda/envs/comfy/bin/python main.py --listen 0.0.0.0 --lowvram* Fontos, hogy a service User=root helyett inkább egy comfy felhasználóval fusson (biztonsági okokból). **7. OpenWebUI – Docker Konténerben** Itt térünk át a konténerizációra. A docker-compose\_openwebui.yaml \_version: "3.8" services: open-webui: image: ghcr.io/open-webui/open-webui:main ports: - "3000:8080" volumes: - /app/backend/data:/app/backend/data env\_file: - /app/backend/data/.env logging: driver: "json-file" options: max-size: "10m" max-file: "3" restart: always volumes: open-webui: \_ egyszerű: mountoljuk a /app/backend/data-t, és külső .env fájlból olvasunk beállításokat. A .env fájl kritikus elemei: \_OLLAMA\_BASE\_URL= – a host gépen futó Ollama elérése (ne localhost, mert a konténerből az a saját loopbackje lenne) VECTOR\_DB=qdrant és QDRANT\_URI= – a vektor adatbázis elérése RAG\_EMBEDDING\_MODEL=sentence-transformers/all-MiniLM-L6-v2 – kis méretű, gyors embedding modell HF\_HUB\_OFFLINE=1 – ha nem akarunk függeni a HuggingFace elérhetőségétől minden induláskor ENABLE\_RAG\_WEB*SEARCH=False – ha a SearXNG-et külön plugin-ként akarjuk használni, nem a beépített web search-ként* A konténer portja 8080, amit a hoston 3000-re mapolunk **8. Nginx – A Kapuőr** Az openwebui konfigurációja nginx -en, kulcsfontosságú részek: WebSocket támogatás: proxy\_http\_version 1.1; proxy\_set\_header Upgrade $http\_upgrade; proxy\_set\_header Connection "upgrade"; – ez nélkül az OpenWebUI valós idejű frissítései nem működnek Időtúllépések: proxy\_read\_timeout 1000s; – mert egy LLM válasz lassan érkezhet Buffering kikapcsolása: proxy\_buffering off; – hogy a streamelés azonnal megjelenjen a böngészőben SSL: Let's Encrypt tanúsítványokkal, HSTS headerrel ###### Integráció és Finomhangolás Most, hogy minden komponens fut, jön a varázslat: OpenWebUI → Ollama: A konténerből a host IP-jén keresztül érjük el az Ollama-t (ne localhost-on!). Az OpenWebUI beállításaiban adjuk meg a címet. RAG Pipeline: Az OpenWebUI feltöltött dokumentumait a Qdrant-ba tölti (a VECTOR\_DB=qdrant beállítással), és az embedding-eket onnan keresi vissza kérdések esetén. Web Keresés: Az OpenWebUI plugin rendszerében engedélyezzük a SearXNG integrációt. A SearXNG JSON API-ját használva (ami a mi esetünkben a címen érhető el az AI valós időben kereshet a neten. Képgenerálás: A ComfyUI API-ját integrálva az OpenWebUI-ban (Tools menüben) workflow-kat indíthatunk az RTX 2060-on. ###### Biztonsági Megfontolások Egy ilyen rendszer nem tartozik a nyílt internetre. A Nginx mögött csak a 443-as port legyen elérhető kívülről, a belső szolgáltatások (Ollama, Qdrant, Valkey) csak localhostról vagy a belső hálózatról. A SearXNG limiter funkcióját érdemes bekapcsolni (limiter: true), ha publikus elérést adunk neki, de jobb azt is belső hálón tartani... ###### Teljesítményoptimalizálás a Korlátozott Hardveren VRAM menedzsment: Az Ollama automatikusan offloadol a RAM-ba, ha tele a VRAM, de ez lassú. Tartsunk egyszerre csak egy modellt memóriában. Valkey: A lazyfree beállításokkal elkerüljük a nagy törlési műveletek miatti akadozást. Qdrant: Az on\_disk\_payload: true beállítással nem fogyasztjuk el a RAM-ot a metaadatokkal. ComfyUI: A --lowvram vagy --normalvram flag-ek használata az RTX 2060-hoz, mert ez csak szórakozásra jó. Ha komoly dologra kéne használni jobb átdobni egy nagyobb gépre különálló entitásként.. ###### Záró Gondolatok Mielőtt végleg lezárnám ezt a témát, hadd fűzzek még néhány gyakorlati megjegyzést a rendszer működéséhez, amiket a napi használat során tapasztaltam meg. Az első és legfontosabb: ne féljünk a hibrid megközelítéstől. A fenti architektúra nem azt diktálja, hogy mindent lokálisan kell futtatni. Az Ollama cloud modelljei jóval gyorsabbak, és ami különösen fontos – ott csak a GPU időért fizetünk, nem pedig tokenenként. Ez a különbség havi szinten komoly összegeket jelenthet, ha intenzíven használjuk a rendszert. Ráadásul az adatainkért valós garanciát kapunk: garantáltan nem nézik át, nem tárolják el, nem elemezik ki marketing célokra. Erről lehetne filozófálni, de valójában valószínűleg senkinek nem éri meg átbogarászni egy random geek kódjait és dokumentumait. És egyébként sem látnak mindent, mert a keresés lokálisan megy, a RAG itt van helyben, a system prompt és a modell beállítás is.. (eltekintve pár paramétertől amit előre beállítottak) A munkahelyi használatról is szóljunk: ez a rendszer nem csak játék. A napi rutin során valóban képes ezernyi sort kódot írni, problémákat megoldani, refaktoringolni. A lokális Gemma 12B modellünk okos – ne becsüljük le –, de a felhős változat egyszerűen más sebességkategória. És itt jön be a RAG (Retrieval Augmented Generation) varázsa: a feltöltött dokumentumokból, saját kódbázisunkból a "buta" 12B modell is kiválóan válaszol, mert nem próbál meg máshonnan adatokat "lopni" vagy hallucinálni. A kontextus ott van előtte, pontosan abból dolgozik. A netes keresés integrációja (SearXNG-en keresztül) pedig ugyanúgy kiegészíti a modell tudását, ahogy a Gemini is aktívan keres, ha kell, és nem felejti el ezt a képességet. A különbség csak annyi, hogy mi kontrolláljuk, mikor és mit keres meg, milyen forrásokból. Ez a rendszer ezért is tud tárgyilagosabb, jobb lenni: saját system prompttal, saját beállításokkal, saját kurált tudásbázissal. A lényeg: nem kell választani a lokális és a felhős megoldás között. A jól konfigurált rendszer – AlmaLinuxon natív szolgáltatásokkal, Dockerrel csak ott, ahol muszáj – mindkettőt tudja. A helyi RTX 2060-asunk szolgálja ki a privát, érzékeny adatokat igénylő feladatokat, a cloud pedig a nagyobb teljesítményt kívánó, de kevésbé kritikus műveleteket. És mindezt egyetlen interfészen keresztül, az OpenWebUI-ban, egy helyen kezeljük. Így lesz ez egy valódi, személyre szabott AI laboratórium – nem egy külső szolgáltatás kiszolgáltja, hanem mi vagyunk a gazdái. Last modified: 2026-07-16 15:40:39 | Size: 13627 bytes --- ## Navigation - Previous: [Házi LLM Gateway építése AlmaLinuxon](https://blog.had3sz.com/hu/hazi-llm-gateway-epitese-almalinuxon.md)