A kapcsolódó cikk azt mutatja be, mit nyújt a pipeline az ügyfeleknek. Ez a cikk arról szól, hogyan épül fel, mely döntések tették éles munkára alkalmas eszközzé egy puszta demó helyett, és mit változtatott a felépítésén a több hónapnyi napi használat. A változtatások egy része korábbi döntések visszavonása volt.
Az ArchUpgrade munkaközi renderekből fotorealisztikus, minőségi pontszámmal ellátott képsorozatokat készít. 2026 eleje óta napi szinten használom éles munkákon. A szeptemberi állapot: nagyjából 200 000 sor kód, 91 munkafolyamat-gráf, mintegy 750 backend- és 560 frontendteszt. Minden helyben fut: a modellek, a GPU-k és a minőségellenőrző is. Ügyfélkép nem hagyja el a hálózatot.
- Backend: Python 3.11 / FastAPI aszinkron SQLite-adatbázissal. Egyetlen folyamat vezényli a feladatsorokat, a renderek kiosztását, a fájlkezelést, a leszállítási csomagok összeállítását és a WebSocket-streamet, amelyet a felületek figyelnek.
- Frontendek: három Vite/React-alkalmazás: az operátori felület számozott munkafolyamattal (Betöltés → Beállítás → Sorba állítás → Átnézés → Felskálázás → Leszállítás, plusz eszközoldalak), egy ügyfélrendelési portál és egy adminportál.
- Renderelés: a GPU-node-okon SwarmUI-példányok vezérlik a ComfyUI-t. A kép-kép feljavítás a Qwen image-edit modellcsaládra épül, saját fotorealizmus-LoRA-val; további gráfok kezelik a szövegből képgenerálást, a több referenciaképes szerkesztést, hét felskálázót, öt világítási eszközt, a kameraszög-meneteket, az in- és outpaintinget, a mesh- és Gaussian-splat-generálást, valamint a videót, a beszédet és a zenét.
- Minőségellenőrzés: egy helyi vision LLM az Ollamán keresztül pontoz minden generált képet. Nincs API-kulcs, nincs képenkénti felhőköltség.
- Hardver: saját GPU-node-okból álló kis farm: 16 GB-os kártyák a feljavító kötegekhez, egy 48 GB-os kártya a nehéz felskálázásokhoz és a videóhoz. Éjszaka ugyanez a farm renderfarmként dolgozik; egy külön eszköz váltja a node-okat a két feladat között.
A központi képernyő a Verziózás: balra a forrásképek, középen az iterációs paraméterek, jobbra a pontos strukturált prompt élő előnézete.
A képszerkesztő modellek sokkal jobban reagálnak a tömör, kulcsokba rendezett utasításokra, mint a hosszú szövegfalakra. Ezt úgy tanultam meg, hogy előbb én is szövegfalakat írtam. Az összeállító egyetlen, determinisztikus sorrendű strukturált csomaggá fésüli össze a képenkénti jegyzeteket, a mappánkénti kontextust, az újrahasznosítható preset-kártyákat és az olyan paraméterkategóriákat, mint az évszak vagy a költségszint. Ugyanaz a bemenet mindig ugyanazt a promptot adja. Minden verzió a ténylegesen elküldött promptot tárolja, karakterre pontosan – sosem utólag, sablonokból visszafejtve.
A paraméterek iterációs tengelyekbe rendeződnek. Két fényhangulat, három berendezési stílus, öt seed: a tervezőmodul ezek Descartes-szorzatát harminc verzióvá bontja ki, és mindegyikre pontosan ráírja, hogyan készült.
Minden kimenet egy g03_i_s02_e01-hez hasonló címkét kap: 3. generáció, iterációs kód, 2. seed, 1. szerkesztés. Az újrapróbálkozások, mutációk, kézi szerkesztések, felskálázások, kivágások, újravilágítások és kameramozgatások mind saját betűt fűznek hozzá, így bármely kép származása leolvasható a fájlnevéből. Újbóli sorba állításkor nő a generációszám. A lemezen soha semmi nem íródik felül.
Az átnézés képernyője ezt faként jeleníti meg: a gyökérben a forrásrender, alatta gyermekként a generációk, és minden származtatott művelet ezekből ágazik tovább.
Ez puszta adminisztrációnak tűnik – egészen addig, amíg egy ügyfél meg nem kérdezi: „A múlt havi harmadik változat tetszett, megnézhetnénk esti fényben?” Ilyenkor egyszerűen abból a csomópontból ágazom tovább, ahelyett hogy emlékezetből próbálnám visszaállítani a beállításokat.
Minden elkészült rendert egy helyi vision LLM értékel, a forrásképhez és a prompthoz mérve. Öt független, 0–10-es pontszám (esztétika, hűség, promptkövetés, technikai minőség, stílusegyezés), szöveges megjegyzések és a hiányzó elemek listája. Egy kép csak akkor megy át, ha minden szempontból eléri a küszöböt; a megbukott képeket a rendszer újra lefuttatja, a javítási megjegyzéseket pedig visszatáplálja a promptba.
A pontszámok csak tanácsadó jellegűek, a választás továbbra is emberi döntés. Az átnézés gazdaságtanát viszont megfordítják: 300 kép helyett csak azt a 40-et nézem át, amelyik átment, pontszám szerint sorba rendezve. Egy nemrégiben készült, 18 nézetes belsőépítészeti projektnél a rendszer több mint 300 verziót generált, az LLM szűrt, én pedig kiválasztottam a 18 végleges képet.
Két szabály, amelyet drágán tanultam meg, és ma már a rendszer minden bírálómodelljében érvényes: a meglétére kell rákérdezni, nem a hiányára (a „Van látható hiba?” kérdésre sokkal megbízhatóbb a válasz, mint a „Jó ez?”-re), és fix formátumú válaszoknál ki kell kapcsolni a modell gondolkodó módját – ezzel egy ítélet huszonöt másodpercről egy másodperc alá gyorsult.
A feljavítás csak egy gráf a sok közül. Ha kiválasztottam egy verziót, célzott menetek futnak rajta, anélkül hogy vissza kellene térni a 3D-jelenethez: öt világítási eszköz (jelenethez rögzített napszakváltó újravilágítás, fényátvitel referenciafotóról, több szögből állítható főfény, stúdiós fényeltávolítás, fény-helyreállítás), égboltcsere és anyagcsere, generatív kibővítés, felskálázás, valamint egy kameraszög-menet kissé eltérő nézőponthoz. Mindegyik saját betűt kap a fában, és saját tételt a feldolgozási sorban.
Ez az újravilágítás egy nyolcéves archív renderből készült a farmon, ugyanazon az API-n keresztül, amelyet az automatizálásom is használ – a modell betöltése után nagyjából fél perc alatt. Az eszköz által összeállított prompt egy jelenetrögzítő záradékkal kezdődik, amely már azelőtt rögzíti a nézőpontot, hogy egyetlen szó esne a fényről. Ez a záradék – egy tucat elcsúszott kimenet tanulsága – adja a mérnöki munka nagyobbik részét.
A kiosztás súlyozott round-robin elven fut a SwarmUI/ComfyUI-backendek között. Minden gép megadja a szerepköreit (képszerkesztés, szövegből kép, felskálázás, 3D, videó), szerepkörönkénti súlyokkal, így a 48 GB-os kártya kapja a nehéz felskálázásokat, a kisebb kártyák pedig a feljavító kötegeket darálják. Az állapotellenőrzés kizárja a körforgásból az offline gépeket; az induláskori összeomlás-helyreállításnak köszönhetően egy pillanatnyi áramkimaradás sem hagyja sérült állapotban a sort. Nyolc futtató követi ugyanazt a szabályt: a GPU-szemafort azelőtt kell megszerezni, hogy a feladat lekerülne a sorról, így a „függőben” számláló mindig a valóságot mutatja.
Minden modell, LoRA, checkpoint és külső eszköz licencosztályba tartozik (megengedő, copyleft, nem kereskedelmi, licenc nélküli), amelyet egyszer, a konfigurációban adok meg. Minden előállított fájl rögzíti a rajta dolgozó eszközök közül a legkorlátozóbb licencosztályt, valamint az eszközök listáját – az adatbázissorban és a fájl melletti JSON-sidecarban is. Egyetlen telepítési kapcsoló, az allow_noncommercial elrejti a felületről az összes nem megengedő licencű backendet, és az API-n is elutasítja őket. Kikapcsolt állapotban a rendszer fizikailag képtelen olyan képet kiadni, amely csak kutatási célra engedélyezett modellel készült. A leglenyűgözőbb nyílt modellek közül több is nem kereskedelmi licencű; az átvilágító adatbázis azért létezik, hogy ezt még azelőtt kiszűrje, hogy egy modell bekerülne ebbe a pipeline-ba.
A több hónapnyi napi használat hozta el azt a gépezetet, amelytől egy eszköz infrastruktúrává válik:
- Megfigyelhetőség. Minden lezárult renderkísérletről egyetlen, utólag nem módosítható sor, minden futtató
finally:blokkjából; VRAM- és sorhossz-minták minden node-ról ötpercenként; node-onkénti összesítések, és egy „Minden biztonságos okból elbukott feladat újrapróbálása” gomb. - Megőrzés és mentés. A megőrzési időablaknál régebbi sandbox-kimeneteket a rendszer próbafuttatás → ellenőrzött lista → végrehajtás lépésekben egyezteti és törli, és az a szabály, hogy „a leszállítási fa nem érhető el”, a kódban van rögzítve, nem a konfigurációban. Az adatbázist az SQLite online backup API-jával mentem, és integritásellenőrzést futtatok rajta – sosem egyszerű fájlmásolással.
- Lemezőr minden futtató sorba állítási pontján: a szabad hely alsó határa alatt inkább visszautasítja az új rendereket, mint hogy félúton tönkretegyen egy köteget.
- Hitelesítés és ügyfél-visszacsatolás. Szereplők és szerepkörök (tulajdonos, stúdió, szolgáltatás, ügyfél), bearer tokenek az automatizáláshoz, rendelésenkénti linkek az ügyfeleknek, vízjeles előnézetek, rendelésenként egy nyitott revízió, a képhez normalizált, pontra tűzött megjegyzések, és olyan ügyfél-zip, amelyben nincsenek stúdiós elérési utak. A helyi hálózat hitelesítés nélküli gépe továbbra is tulajdonosnak számít, így a bizalmi modell nem változott; a hitelesítés bevezetésekor minden meglévő teszt változtatás nélkül átment.
- Közös renderfelület. Egyetlen API, amely elérési utat kap és elérési utat ad vissza, és amelyen keresztül a stúdió minden más folyamata renderel (ütemezett ügynökök, szkriptek, más kódtárak), adatbázissorok és UI-állapot nélkül. Ennek a határnak köszönhető, hogy az ügynökök önálló projektbe költözhettek anélkül, hogy egyetlen sort is importálniuk kellett volna ebből.
- Két gép. A fejlesztői gépen a
mainfut; a produkciós szerver egystableágat futtat, közös kimeneti tárolóval. Az élesítés deploy-szkripttel történik, nem egygit pull-lal azon a gépen, amelyre az ügyfelek támaszkodnak.
Az utolsó lépés tiszta, sorszámozott fájlnevekkel csomagolja a kiválasztott verziókat, egy metaadatfájl pedig megőrzi a belső címkéket, a generálási paramétereket és a származási adatokat. A kategóriánkénti kvótákat („15 külső, 3 belső”) a rendszer még a csomag kiküldése előtt ellenőrzi és betartatja.
- A determinizmus maga a lényeg. Seedelt generálás, a sorba állítás pillanatában rögzített konfiguráció, a származást kódoló címkék. Ettől lesz produkciós eszköz, és nem félkarú rabló.
- A pontozást helyi modell végezze. A minőségellenőrzés a rendszer legnagyobb volumenű LLM-hívása. Helyben futtatva a képenkénti költség nulla, így soha nem kell spórolni az átnézéssel.
- Mindenhol számolni kell a hibával. A GPU-k kiesnek, a folyamatok egy köteg közepén újraindulnak, a JSON-fájlok a lehető legrosszabb pillanatban sérülnek meg. Atomi írás, cellánkénti hibaelszigetelés, a hibás feladat megjelölése automatikus újrapróbálás helyett. Nem látványos, de nélkülözhetetlen.
- A licenc sémamező. Ha a licencosztály nincs rajta a soron, a leszállításban sem lesz ott – és valaki csak a prospektus kinyomtatása után jön rá.
- Valódi hardveren kell ellenőrizni. A mock mód csak a UI → sor → adatbázis kört igazolja, a renderről semmit sem mond. Hat már kész funkciónak nem volt felülete, amíg egy audit rájuk nem bukkant, egy generatív kibővítő eszköz pedig két hónapig nem működött, mert rossz gráfnak küldte a maszkot. Mindkettőre a valódi útvonal lefuttatása és a kép megnézése derített fényt.
- A modell talán a rendszer ötöde. A többi verziókezelés, promptösszeállítás, sorkezelés, átnézési UX, leszállítás, licencek, megfigyelhetőség. Ez a gépezet teszi a nagyszerű demót olyan eszközzé, amelyet egy stúdió minden nap használ.
Az ArchUpgrade belső eszköz, nem termék, bár az utómunka-menete ma már más stúdiók renderjein is fut, az ai.visiongraphics.eu oldalon keresztül. A más stúdióknak végzett pipeline-auditok és automatizálás is ennek a fejlesztéséből nőtt ki. Ha ön is valódi produkciós pipeline-ba építi be az AI-t, és szívesen összevetné a tapasztalatainkat, írjon nekem.