Húsz nap vagy hat hónap: mennyi időd van, ha kivezetnek egy modellt

Mi történt az elmúlt két hétben

Három bejelentés, mindegyik a gyártó saját kivezetési oldalán, egyik sem kapott sajtóvisszhangot magyarul vagy spanyolul:

• Szeptember 11. Az OpenAI kivezetésre jelölte a gpt-5.4-cyber modellt. A leállítás dátuma 2026. október 1. Ez a bejelentéstől számítva húsz nap. Az utód a gpt-5.6-cyber.
• Szeptember 24. Leáll a Videos API és a Sora 2 modellváltozatok. Ezt még március 24-én bejelentették, tehát itt hat hónap volt — de utódmodell nincs megnevezve. A böngészős és mobilos felület már április 26-án megszűnt.
• Augusztus 26. Négy transzkripciós modell (whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, gpt-4o-transcribe-diarize) kivezetésre került, leállítás 2027. február 26. Itt hat hónapod van, és van kijelölt utód is.

A minta nem az, hogy „néha megszűnik valami". A minta az, hogy a felmondási idő ugyanannál a szolgáltatónál is húsz nap és hat hónap között mozog, és nem lehet megjósolni, melyiket kapod.

SZEPT 24  Videos API + Sora 2 leáll
          utódmodell nincs megnevezve
          bejelentve márc 24.  -> 6 hónap

OKT 1     gpt-5.4-cyber leáll
          utód: gpt-5.6-cyber
          bejelentve szept 11. -> 20 NAP

NOV 2     grok-imagine-image-quality
          átirányítva, quality=low
          bejelentve szept 2.  -> 61 nap

DEC 11    gpt-5 és o3 snapshotok leállnak
          utód: gpt-5.6 változatok
          bejelentve jún 11.   -> 6 hónap

Mit vállal írásban a hat szolgáltató

Ez a cikk gerince. Minden sor a gyártó saját dokumentációjából van, 2026. szeptember 12-i állapot szerint:

A tanulság nem az, hogy melyik szolgáltató a „jobb". Az, hogy a felmondási idő nem iparági szokás, hanem szolgáltatónként és szintenként (GA vagy preview) külön vállalás — és ha nem olvastad el, akkor nem tudod, mennyi időd lesz.

Három csapda, ami a felmondási időnél is fontosabb

1. A modell nem leáll, hanem megváltozik alattad. Ez a nehezebb eset, mert nem kapsz hibát. A Microsoft Foundry Standard típusú telepítéseit a kivezetésnél automatikusan frissítik, régióról régióra. A Google latest aliasa mögött két hét értesítéssel új verzió jelenik meg. A Grok képgeneráló minőségi változatánál a kéréseket nem elutasítják, hanem átirányítják a 2.0-ra quality=low beállítással, alacsonyabb képenkénti áron. Mindhárom esetben a kód fut tovább — csak más eredményt ad.

2. A lefoglalt kapacitás nem frissül magától. Ugyanott, ahol a Standard telepítés automatikusan átáll, a Provisioned telepítést nem frissítik: azt kézzel kell migrálni, és a határidő után minden kérés 410 Gone hibát ad. Vagyis aki fizetett a garantált kapacitásért, az több munkát kap, nem kevesebbet. Preview modellnél pedig nincs harmadik út: vagy felfrissítik, vagy megszüntetik — maradni nem lehet.

3. Nem csak a modell mehet el, hanem az adat is. A szeptember 24-én leálló videószolgáltatás esetében a gyártó saját súgója azt írja, hogy az export-ablak lezárása után véglegesen törlik a szolgáltatás használatához kapcsolódó adatokat, és azt javasolja, hogy az exportot mielőbb végezd el. Ha egy eszközben hónapok munkája gyűlt össze, ez az a határidő, ami után nincs visszaút.

Mit tegyél most

Ez négy lépés, és összesen néhány óra:

1. Írd össze, melyik modellazonosító szerepel a rendszereidben. Ne csak a kódban: az automatizálásokban, a no-code folyamatokban, a táblázatokba épített hívásokban és a csapat által használt eszközök beállításaiban is. Amiről nem tudod, hogy melyik modellen fut, arról nem fogod észrevenni, hogy kivezették.
2. Verziózott azonosítót használj, ne latest típusú aliast — legalább ott, ahol a kimenet stabilitása számít. A trade-off valódi: a verziózott azonosítót neked kell léptetni, viszont nem változik meg alattad egy e-mail után. Az alias kényelmes, de két hét alatt átfordulhat.
3. Jelölj ki utódot minden modellhez, még mielőtt kellene. Nem elég tudni, mi a gyártó által ajánlott utód: azt is tudni kell, hogy a te feladatodon hogyan teljesít. Erre jó a kétheti összemérés, amiről a modell-verseny receptje szól részletesen.
4. Nézd meg a szolgáltatód kivezetési oldalát, és tedd naptárba. Az egyetlen dátum, ami igazán számít, a sajátod: mikor kell nálad lezárni a migrációt. A gyártó határideje nem a te határidőd.

Két szerkezeti megoldás csökkenti a kitettséget. A model router egy kulcs mögé teszi több szolgáltató modelljeit, így a váltás konfigurációs kérdés lesz, nem fejlesztési projekt. Az open-weight modellek esetében pedig, amit letöltöttél, azt nem lehet kivezetni alólad — a súlyok nálad vannak. Egyik sem ingyen van: a router egy újabb közvetítő, a helyi futtatás pedig hardvert és üzemeltetést kér. (Bővebben: havi Care — migrálunk, mielőtt kivezetik a modellt.)

Hogyan vedd észre időben

Itt van a rendszerszintű gond: a kivezetési oldalak alatt egyetlen nagy szolgáltatónál sincs RSS. Sem az OpenAI-nál, sem az Anthropicnál, sem a Google-nél, sem a Microsoftnál, sem az AWS-nél. A gyártói blog feedjén a bejelentések mennek, a kivezetés nem — és a napi AI-hírlevelek ezt a hírtípust rendszeresen kihagyják, mert nem elég izgalmas.

Marad két módszer. Vagy naptárba vett heti öt perc, amikor végigkattintod a téged érintő két-három kivezetési oldalt. Vagy automatikus oldalfigyelés: egy változásfigyelő szolgáltatás ingyenes szinten is elég erre, és arra is jó, hogy a változás tartalmát lásd, ne csak azt, hogy változott valami. Egyetlen összevont kivételt találtunk: a Microsoft Foundry kivezetési ütemterve egy lapon listázza tíz szolgáltató modelljeit, dátummal — ez akkor is hasznos áttekintés, ha nem az Azure-t használod.

Tipikus félreértések

• „Majd szólnak e-mailben." Értesítést jellemzően az kap, akinek az adott modellen aktív használata van, és arra a címre, ami a fejlesztői vagy számlázási kapcsolattartó — nem feltétlenül arra, aki a folyamatot üzemelteti.
• „A nagy szolgáltatók egységesen hat hónapot adnak." Ugyanaz a szolgáltató adott húsz napot és hat hónapot is, egy hónapon belül. A 15 napos vállalás sem elméleti: ki van írva.
• „A preview modell is jó éles használatra." Kettő közülük kifejezetten két, illetve harminc nap értesítést vállal, és a preview telepítésnél nincs „maradok a régin" opció. Ha egy éles folyamat preview modellen fut, az nem költségoptimalizálás, hanem kitettség.
• „Engem nem érint, mert nem API-t használok." A felületek modelljei is cserélődnek, csak nem kapsz róla 410-es hibát — csak más lesz a kimenet.
• „Ha kivezetik, az utód biztosan jobb." Az utód más. A promptjaid, a hőmérséklet-beállításod és a kimenet formátumára épülő feldolgozásod a régire volt hangolva. Ezért kell összemérés a váltás előtt, nem utána.

Amit érdemes elvinni

A modellkivezetés nem hiba, hanem a szolgáltatás normál üzemmenete: ahol 18 hónapos életciklus van kiírva, ott másfél évente minden modell kicserélődik — és ez a kiírt maximum, nem az átlag. Amit kézben tudsz tartani, az három dolog: tudod-e, melyik modellen mi fut, verziózott azonosítót használsz-e ott, ahol a stabilitás számít, és megnézed-e hetente egyszer a rád vonatkozó kivezetési oldalt. A többi a szolgáltató dolga — és a felmondási idejét érdemes elolvasni, mielőtt a folyamatod ráépül.