Ollama teszt: a barátságos út a nyílt modellekhez

Az Ollama helyi futtatókörnyezet. Letölti a nyílt súlyú modelleket, elhelyezi a rendelkezésre álló GPU-n vagy CPU-n, és egyetlen HTTP API-n keresztül szolgálja ki őket a 11434-es porton. A gyártó havi kilencmilliónál több telepítést, egymilliárdnál több modellletöltést és 182 000 GitHub-csillagot jelent – és ez a hatóereje megmagyarázható: ez a legkevesebb húzással járó út, hogy egy nyílt modell válaszoljon. A csere ugyanebben a számokban van. Az Ollama egy modell elindítására optimalizál, nem egy GPU-ből kinyerhető tokenekre, és aki termelési inferenciakiszolgálónak tekinti, az ezt meg fogja érezni.

A stackben modellkiszolgáló, nem keretrendszer. Helyettesíti a llama.cpp saját szerverét, az LM Studio futtatókörnyezetét és egy kézzel összerakott Docker image-et – és a vLLM-mel csak a lehető leglazább értelemben verseng. fölötte LangChain, LlamaIndex, a kódoló ügynökök és a saját hosztolású csevegőfelületek találhatók; az, hogy Ollama mindegyikkel felcserélhető, az API-jának alakjából ered, nem abból, ami a belsejében történik. Amit nem nyújt: orkestrálás, folyamatos batching, autoskálázás vagy több csomópontos tenzorparalellizmus. Azok továbbra is a vLLM vagy az SGLang területe.

Mi ez valójában

Az Ollama egy Go nyelvű szerver egy beépített modellkezelővel, nem maga a modell. Egyetlen binárisfájlként, egy CLI-vel és egy Docker image-ként érkezik, és a CLI az a teljes felület, amelyet az emberek többsége valaha érint. Az alatta futó engine-ek a llama.cpp CUDA, ROCm, Vulkan és CPU módokra, valamint – a v0.40.0 óta – az MLX Apple Siliconon alapértelmezés szerint a támogatott architektúrákra. minden más ezek köré csomagolás, és pont ezért érdemes tudni, hol húzódik a határ.

• Licenc: MIT a szoftverre, használati korlátozás, felhasználói küszöb és kiegészítő záradek nélkül.
• Jelenlegi kiadás: v0.40.0, platformbinárisokkal és Docker image-mel. A tempó gyors, de a számok ugranak: a v0.34.4 után jött a v0.35.1, majd egyenesen a v0.40.0.
• API-k: natív REST felület az /api alatt, OpenAI-kompatibilis felület a /v1 alatt és Anthropic-kompatibilis alap-URL, a helyi kiszolgálón és az Ollama Cloudon egyaránt.
• Engine-ek: llama.cpp CUDA, ROCm, Vulkan és CPU módokra, plusz MLX Apple Siliconon a v0.40.0-tól. Az Nvidia 5.0 vagy újabb compute capabilityt, az AMD Linuxon ROCm v7 illesztőprogramot igényel.
• Modellformátum: GGUF a llama.cpp modellekhez, safetensors az MLX-hez. A v0.34.1 óta a GGUF-konverziót llama.cpp eszközökkel kell elvégezni, nem Ollamán belül.
• Testreszabás: egy Modelfile FROM, PARAMETER, TEMPLATE, SYSTEM, MESSAGE, LICENSE, REQUIRES és CAPABILITY kulcsokkal, így egy finomított modell átnézhető szövegfájl.
• A csomagban továbbá: strukturált kimenet JSON-sémához, eszközhívás, látvány, beágyazások, webes keresés, kísérleti képgenerálás macOS-en, illetve döntési modellek, amelyek szöveg helyett valószínűségeket adnak vissza.

Hogyan működik

A középpontban egy HTTP-kiszolgáló áll, amely egy modellkönyvtárat és VRAM-tudatos ütemezőt birtokol. A kérés megnevez egy modell-címkét; ha a súlyok még nincsenek betöltve, a kiszolgáló betölti őket, ha pedig nem férnek a már betöltött mellé, a kérés sorba áll, miközben egy üresen álló modell kilép. A betöltött modellek az utolsó kérés után öt percen át maradnak bent, a kontextushosszt a gép VRAM-osztálya határozza meg, és az egy modellre érkező párhuzamos kérések megosztják annak kontextusát, ahelyett hogy mindegyik sajátot kapna.

Ennek a kialakításnak van egy következménye, amely meglep: a modell az ütemezés és a költség egysége. A címke váltása terhelés alatt egy betöltést, egy VRAM-ellenőrzést jelent, és egyetlen GPU-s gépen akár azt is, hogy kilép az, ami épp mindenkinek válaszolt. Az Ollama válasza az OLLAMA_MAX_LOADED_MODELS és az OLLAMA_NUM_PARALLEL, és mindkettőt memóriával fizetjük, nem számítási kapacitással.

Első lépések

A telepítés egy shell-szkript, egy asztali alkalmazás vagy egy Docker image. Az API egyetlen POST, és a helyi kiszolgálóhoz sem kulcs, sem konfigurációs fájl nem kell. Az alábbi részlet a legkisebb, amit productionben érdemes leírni: egy streamelt hívás explicit kontextusablakkal, egy hívások között rezidensen tartott modellel, és azokkal az időzítési mezőkkel, amelyeket a kiszolgáló eleve kiszámít.

import json, urllib.request, time

URL = "http://localhost:11434/api/chat"
BODY = {
    "model": "gemma4",
    "messages": [{"role": "user", "content": "Summarise this ticket in one line."}],
    "stream": True,
    "keep_alive": "30m",              # keep the weights resident between calls
    "options": {"num_ctx": 8192, "temperature": 0},
}

request = urllib.request.Request(
    URL, data=json.dumps(BODY).encode(), headers={"Content-Type": "application/json"})

chunks = []
with urllib.request.urlopen(request) as response:
    for line in response:                       # newline-delimited JSON events
        event = json.loads(line)
        if "message" in event:
            chunks.append(event["message"].get("content", ""))
        if event.get("done"):
            seconds = event["eval_duration"] / 1e9   # nanoseconds
            print(f"{event['eval_count']} tokens in {seconds:.1f}s"
                  f" -> {event['eval_count'] / seconds:.1f} tok/s")
            print(f"prompt tokens {event['prompt_eval_count']}, cached"
                  f" {event.get('prompt_eval_cached_count', 0)},"
                  f" load {event['load_duration'] / 1e9:.1f}s")

print("".join(chunks))

Két mezőt érdemes egy dashboardra kötni: az eval_count és az eval_duration hányadosát a generálási sebességhez, a load_duration értékét a hidegindítási büntetéshez. A prompt_eval_cached_count jelzi, hány prompt-token jött a gyorsítótárból – ez az Ollama egyetlen ingyenes gyorsítása. A prompt stabil prefixét tegye előre, a változó részt hátra, és a közös rendszerprompt nem értékelődik ki újra minden hívásnál.

A licenc – és a záradek, ami nincs benne

Az Ollama szoftvere MIT-licencelt, minden további nélkül. Az ollama/ollama repository LICENSE fájlja a módosítatlan MIT-szöveg: nincs kiegészítő záradek, nincs felhasználói küszöb, nincs használati korlátozás. Nincs benne OpenAI-záradek, és nincs benne 700 millió havi aktív felhasználói határ sem – és ezt érdemes is kimondani, mert az állítás széles körben elterjedt. A 700 milliós küszöb a Meta Llama Community Licence-éhez tartozik, és a Llama súlyokra vonatkozik, nem arra a futtatókörnyezetre, amely kiszolgálja őket. Az Ollama fizetett felhőcsomagokból is bevételt szerez, és 2026 júliusában 65 millió dolláros befektetési kört is kapott, és egyik sem tesz záradékot a forráslicencbe.

Az MIT-engedély a szerver bináris fájljára vonatkozik. Arról, hogy milyen modelleket futtatnak rajta, semmit nem mond, és épp itt van a valódi licenckitettség. A könyvtár egy tucat kiadótól származó súlyokat szolgál ki egy tucat feltétellel – a kötő erejű licenc a modellkártyán áll, nem a futtatókörnyezeten. Egy Modelfile a súlyok mellett egy LICENSE utasítást is tárol, és az ollama show --modelfile kiírja – ez a karakterlánc, modellverenként, az aartefaktum, amelyet a megfelelési nyilvántartásban kell tartani.

• MIT a futtatókörnyezeten. Használható üzleti célra, forkolható, beágyazható egy termékbe. A szerzői jogi megjegyzés megtartásán túl nincs megnevezési kötelezettség, nincs bevételi küszöb, nincs felhasználói küszöb, nincs telemetriai kötelezettség.
• A modelllicenc különálló. A Meta Llama Community Licence 700 millió havi aktív felhasználó felett külön licencet kér a Metától, más családok saját bevételi vagy felhasználói plafont írnak elő. Egyes modellek nem kereskedelmi feltételekkel érkeznek. Olvassa el a modellkártyát.
• Az ollama.com maga nem MIT. A hosztolt felhő, a könyvtárfiókok és a fizetős csomagok a Felhasználási feltételek hatálya alá tartoznak, utoljára 2026 májusában frissítve: kötelező arbitráció San Franciscóban, kaliforniai jog, felelősségi korlát az előző tizenkét hónapban fizetett összegek mértékéig, valamint egy záradek, amely megtiltja a szolgáltatás használatát versenytárs termékek fejlesztésére.

Üzemeltetés productionben

A párhuzamosság az a pont, ahol a helyi futtatókörnyezetek őszinték a korlátaikról. Az Ollama modellenként egy kérést dolgoz fel alapértelmezés szerint, és a párhuzamos kérések megosztják a kontextust ahelyett, hogy függetlenül batchingelnének: ezt a dokumentáció ki is mondja, egy 2000 tokenes kontextus négy párhuzamos kéréssel úgy viselkedik, mint egy 8000 tokenes, és a szükséges RAM párhuzamos kérések száma szorozva a kontextushosszal nő. Ez interaktív használatra meglevő csere, batch munkára rossz.

A kiszolgálónak nincs hitelesítése. Alapértelmezés szerint a 127.0.0.1 címre köt, és az OpenAI-kompatibilis végpont megköveteli az API-kulcs értékét, majd figyelmen kívül hagyja – ez pontosan kimondja, mennyire bízik a helyi felület. Ami az OLLAMA_HOST értékét útvonalozható címre állítja, hitelesítés nélküli inferenciavégpontot tesz közzé. 2026 januárjában kutatók mintegy 175 000 nyilvánosan elérhető Ollama-kiszolgálóról számoltak be 130 országból, ezek többsége a 0.0.0.0 címre kötés miatt volt kitett.

• Hagyja a kötési címet a 127.0.0.1 címen. Nincs konfigurálható hitelesítés, így az egyetlen elérhető hozzáférés-szabályozás a TLS-t használó visszaforduló proxy valódi hozzáférési ellenőrzéssel.
• Állítsa be az OLLAMA_ORIGINS értékét, ha böngészős kliens kell hozzá. A loopback eredetek alapértelmezés szerint engedélyezettek, tehát a helyi eszközökhöz jó az alapérték, a megosztott használathoz rossz.
• Azokon a gépeken, amelyek egyáltalán nem érhetik el az ollama.com-ot, állítsa be az OLLAMA_NO_CLOUD=1 értéket vagy a disable_ollama_cloud mezőt a ~/.ollama/server.json fájlban, indítsa újra, és ellenőrizze az Ollama cloud disabled: true naplósort.
• Tartsa szem előtt, hogy az asztali alkalmazás macOS-en és Windowson belépési elemként regisztrálja magát, tehát a 11434-es port már rendszerindításkor szolgál, függetlenül attól, kérte-e valaki.

Hol csúszik meg

A gyengeségei valósak, és egy helyen csoportosulnak: az egy GPU-ra jutó átviteli sebesség. Alapértelmezés szerint egy kérés modellenként, nincs a párhuzamos kérések független batchingje, nincs több csomópontos párhuzamosság és nincs tenzorparalell kiszolgálási út. Egy interaktív végpontnál néhány felhasználóval ez láthatatlan. Bármihez, aminek van sora, batch feladata vagy költségcélja, már nem: ugyanaz a GPU a vLLM eredményének töredékét adja ugyanazzal a modellel, és ez a rés nem konfigurációs probléma. Ez a design.

Az LM Studio-hoz képesti összehasonlítás szoros, és valójában csomagolási kérdés: az LM Studióban van GUI és modellböngésző, az Ollamában CLI, Docker image és első osztályú headless használat, és az Ollama API-alakja körül nőtt fel az Open WebUI ökoszisztémája. A llama.cpp saját szerveréhez képest a különbség a modellkezelő és az ütemező, ami egy csapatnak sokat ér, annak aki már ismeri a llama.cpp-t semmit. A vLLM-hez képest a különbség maga az üzleti érvelés: ha a kérdés az, hogyan szolgáljuk ki ezt kiszámítható költséggel, akkor a vLLM vagy az SGLang az eszköz, az Ollama pedig az a fejlesztői környezet, amelyben prototípus készül.

A másik mérlegelendő szempont az irány. Az Ollama Cloud ma Pro, Max és Team csomagokat, tokenenkénti modellárazást és vállalatoknak szánt modell-hozzáférés-szabályozást kínál, vagyis a projekt a futtatókörnyezet mellett kereskedelmi inferenciaszolgáltató is. Ez finanszírozza a kiadási tempót, és nem minőségi észrevétel. De azt jelenti, hogy a súlypont eltolódik attól, hogy egy modellt a saját gépén futtat, afelé, hogy bejelentkezik és egy nagyobbat használ – és az a csapat, amely a helyi inferenciára támaszkodik, birtokolja a verziót, a modell-pin-eket és az artefaktumokat, ne pedig feltételezze, hogy a felület marad, ahol van.

Ítélet

Az Ollama a legjobb alapértelmezett válasz arra, hogyan futtassunk egy nyílt modellt anélkül, hogy fel kellene vennünk valakit, aki a llama.cpp-t üzemelteti. MIT-licencelt, egyetlen parancsból indul, az API-ja az a kompatibilitási réteg, amelyet szinte minden ügynökkeretrendszer már beszél, és két környezeti változó mögé rejt egy hatalmas mennyiségű GPU-ütemezést. Ami nem, az egy skálázható inferenciaplatforma – és amikor egy kéréssor megjelenik egy dashboardon, ez a jelzése annak, hogy válts, ne hogy hangolj.

1. Használja helyi fejlesztéshez, értékelési tesztkörnyezetekhez, CI fixture-ökhöz, olyan on-prem telepítésekhez, ahol néhányan osztoznak egy munkaállomáson, és olyan munkaterhelésekhez, ahol a promptoknak nem szabad elhagyniuk az épületet.
2. Használja helyi vagy saját hosztolású végpont bekötéséhez egy ügynökkeretrendszerbe, mert az OpenAI-kompatibilis felület feleslegessé teszi a szolgáltató-specifikus klienst.
3. Használja arra, hogy egy csapat egy délután alatt működő nyílt modell-prototípushoz jusson. Ez valódi üzemeltetési előny, és a legtöbb felhasználó emiatt nem megy el soha.
4. Ne használja terhelés alatti többfelhasználós kiszolgálásra, batch generálásra, vagy bármire, ahol a GPU-nkénti másodpercenkénti tokenek számítanak a projekt értékelésében.
5. Ne használja olyan szabályozott környezetekben, amelyek hitelesítést, auditnaplózást vagy az inferenciaréteg alatti ütemezőt igényelnek. Tegyen elé proxyt, vagy használjon másik futtatókörnyezetet.

Források

1. Ollama API documentation
2. Ollama on GitHub, with the MIT LICENSE file
3. Ollama terms of service, last updated May 2026
4. Ollama pricing, cloud plans and per-token model rates
5. Hardware support: Nvidia, AMD, Metal and Vulkan
6. OpenAI compatibility, including what is not supported