Claude Fable 5 Hibrid Következtetés: Gondolkodási vs. Sebességmód

Az Anthropic új Claude Fable 5 következtető (reasoning) motorja minden kérésnél bekapcsolva tartja a mély gondolkodást, és ehelyett azt engedi a fejlesztőknek, hogy a következtetés mélységét feljebb vagy lejjebb állítsák. Korábban a nagy nyelvi modellek (LLM-ek) rögzített számítási paraméterekkel működtek, és a lekérdezés komplexitásától függetlenül egyenletes sebességgel generálták a tokeneket. Egy egyszerű üdvözlet ugyanannyi feldolgozási energiát fogyasztott, mint egy fejlett matematikai bizonyítás. A Fable 5-tel az Anthropic egy olyan hibrid következtetési keretrendszert vezet be, amelyben a gondolkodás mindig aktív, Ön pedig egyetlen effort (erőfeszítés) beállítással szabályozza, hogy a modell mennyire dolgozzon keményen. Ez a leírás bemutatja az API működését, az erőfeszítési szint kiválasztását és az architektúra megvalósítását éles rendszerekben.

[!WARNING] API korlátozási figyelmeztetés: A Fable 5-nél a gondolkodás mindig be van kapcsolva, így nem tudja kikapcsolni. A thinking: {type: "enabled"} vagy a thinking: {type: "disabled"} átadása, illetve bármilyen budget_tokens érték megadása HTTP 400-as hibát ad vissza – ezeket a paramétereket eltávolították. A következtetés mélységét ehelyett az output_config: {effort: "..."} beállítással szabályozza, és magasabb erőfeszítési szinteknél hagyjon elegendő max_tokens keretet a végső válaszra.

Fő tanulságok:

• Erőfeszítést állítson, ne kapcsolókat: Állítsa az output_config.effort értékét low, medium, high, xhigh vagy max szintre – nincs be- és kikapcsoló.
• A gondolkodás automatikus: Hagyja el a thinking blokkot, vagy adjon át {type: "adaptive"} értéket; az adaptív gondolkodás minden kérésnél lefut.
• Elemezze az adatfolyamokat: Kezelje a thinking tartalomblokkokat a thinking_delta részletekkel a valós idejű szerver-streamekben.
• Kezelje a számlázást: A rendszer-promptek gyorsítótárazása csökkenti a felesleges gondolkodási feldolgozási ciklusokat.

A Claude hibrid következtető motorjának működése

A Fable 5 legfontosabb újítása az a képesség, hogy még a végső válasz kiadása előtt végiggondolja a problémát. Ez azt jelenti, hogy a modell belsőleg kidolgozza a megoldás logikai vázlatát, mielőtt válaszolna a kliens kéréseire. A lényeg, hogy ez a gondolkodási fázis mindig aktív – nem kapcsolható ki, és nincs külön „sebességmód”, amelyre átválthatna.

Ha összetett kérdést küld be, a modell nem próbálja meg azonnal kitalálni a következő szót. Ehelyett belső gondolkodási tokeneket generál, szimulálva egy lépésről lépésre haladó logikai folyamatot. Ez a felépítés drasztikusan javítja a pontosságot a matematikai, kódolási és logikai kiértékelési feladatok során.

A különböző vállalati igények támogatása érdekében az Anthropic lehetővé teszi a fejlesztők számára, hogy egyetlen effort (erőfeszítés) beállítással igény szerint skálázzák ennek a gondolkodásnak a mélységét. Alacsony (low) erőfeszítésnél a modell röviden gondolkodik és gyorsan válaszol, alacsonyan tartva a késleltetést és a token-fogyasztást. Magas (high) vagy maximális (max) erőfeszítésnél sokkal mélyebben következtet, ráfordítva a nehéz matematikához, a több lépéses logikához és az összetett kódhoz szükséges extra számítási teljesítményt. A sebesség és a mélység közötti kompromisszumot teljes egészében ez az erőfeszítési szint fejezi ki, nem pedig egy be- és kikapcsoló.

A Fable 5 API paramétereinek konfigurálása

Ahhoz, hogy ezeket a funkciókat megvalósítsa szoftverében, a frissített Anthropic API sémát kell használnia. Ez a séma biztosítja, hogy a kliens alkalmazások a megfelelő modellnevet és végrehajtási paramétereket adják meg.

A következtetés mélységét egy output_config blokkon keresztül állítja be. Ezen belül az effort mező a "low", "medium", "high", "xhigh" vagy "max" értékek egyikét fogadja el, és ez az egyetlen érték váltja fel a régi token-keret szabályozót. Az egyszerű esetben egyáltalán nem ad át thinking blokkot – az adaptív gondolkodás automatikusan lefut. Az alábbi JavaScript integráció bemutatja a kérés felépítését:

 1import Anthropic from "@anthropic-ai/sdk";
 2
 3export default {
 4  async fetch(request, env) {
 5    const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
 6
 7    try {
 8      const response = await anthropic.messages.create({
 9        model: "claude-fable-5",
10        max_tokens: 8192,
11        // Thinking is always on for Fable 5; dial reasoning depth with effort:
12        output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13        messages: [
14          {
15            role: "user",
16            content: "Generate an optimised database migration script for 10 million records."
17          }
18        ]
19      });
20
21      return Response.json(response);
22    } catch (err) {
23      return Response.json({ error: err.message }, { status: 500 });
24    }
25  }
26};

Ne próbálja kikapcsolni a gondolkodást, és ne adjon át budget_tokens értéket: a thinking: {type: "disabled"}, a thinking: {type: "enabled"} és bármilyen budget_tokens mező egyaránt HTTP 400-as hibát ad vissza a Fable 5-nél, mert ezeket a paramétereket eltávolították ezen a modellen (valamint az Opus 4.7 és 4.8 modelleken). A sebességhez válasszon alacsonyabb erőfeszítési szintet, a mélységhez magasabbat, és amikor feljebb tolja az erőfeszítést, hagyjon elegendő tartalékot a max_tokens keretben a végső válaszra. A szerver nélküli architektúrákról bővebben a szerver nélküli API építése Cloudflare Workers segítségével útmutatónkban olvashat.

Gondolkodási tokenek kezelése streamelt válaszokban

A valós idejű alkalmazásokhoz, például a csevegőfelületekhez, elengedhetetlen a válaszok streamelése. A Fable 5 mind a gondolkodási lépéseket, mind a végső tartalmat SSE (Server-Sent Events) csatornákon keresztül küldi el.

A stream során a gondolkodás thinking tartalomblokkokként érkezik, amelyeket olyan content_block_delta események szállítanak, amelyek delta.type mezője "thinking_delta". A szöveget a delta.thinking mezőből olvassa ki, a végső választ pedig a szokásos text_delta részletekből. A nyers gondolatmenetet a rendszer soha nem adja vissza – olvasható összefoglaló csak akkor érkezik, ha ezt a thinking: {type: "adaptive", display: "summarized"} beállítással kifejezetten kéri; az alapértelmezett "omitted" üres gondolkodási szöveget streamel. Egy minimális kezelő így néz ki:

 1const stream = await anthropic.messages.stream({
 2  model: "claude-fable-5",
 3  max_tokens: 8192,
 4  output_config: { effort: "high" },
 5  thinking: { type: "adaptive", display: "summarized" },
 6  messages: [{ role: "user", content: prompt }]
 7});
 8
 9for await (const event of stream) {
10  if (event.type === "content_block_delta") {
11    if (event.delta.type === "thinking_delta") {
12      process.stdout.write(event.delta.thinking); // summarised reasoning
13    } else if (event.delta.type === "text_delta") {
14      process.stdout.write(event.delta.text);      // final answer
15    }
16  }
17}

Ezeket a thinking_delta darabokat betáplálhatja egy lenyitható „Thinking…” panelbe, vagy elvetheti őket, és csak a választ jelenítheti meg. Az Anthropic integrációk részletes leírását közvetlenül az Anthropic Fejlesztői Dokumentációban találja.

Kísérje figyelemmel a token-elszámolást. A gondolkodási tokenek az API kimeneti (output) számlázásába számítanak bele. Ezért alkalmazzon agresszív prompt-gyorsítótárazást, hogy azonos bemenetek esetén elkerülje a következtetési ciklusok újrafuttatását. Éles környezet tervezésekor a metrikák nyomon követése egy edge telemetriai rétegen keresztül segít azonosítani, hol haladja meg a gondolkodási tokenek használata a szokásos szintet.

Lépésről lépésre: API integrációs munkafolyamat

A következtető motor alkalmazásokba történő integrálásához először frissítse a helyi csomagokat a Fable 5 specifikációknak megfelelően. A régebbi SDK-verziók továbbra is elküldik a budget_tokens értéket, ami mostantól HTTP 400-as sémahibát vált ki az API-szerializáció során.

Ezt követően határozzon meg egyértelmű késleltetési küszöbértékeket. Egyszerű beszélgetésekhez vagy üdvözlésekhez állítson be alacsony (low) erőfeszítési szintet a késleltetés alacsonyan tartásához. A magas (high) vagy maximális (max) erőfeszítést tartsa fenn az olyan feladatokra, mint a kódgenerálás vagy a matematika.

Ezenkívül tárolja biztonságosan API-hitelesítő adatait a szerver nélküli környezet paraméterei között olyan eszközökkel, mint a Wrangler. A stream-kimeneti események kezelése során írjon robusztus frontend-kezelőket a thinking_delta csomagok kiszűrésére. Erre akkor van szükség, ha nem szándékozik közvetlenül megjeleníteni a modell gondolkodási lépéseit. Végül ellenőrizze a prompt-gyorsítótár találati arányait, hogy megbizonyosodjon arról, a gyorsítótárazás minimalizálja a token-fogyasztási többletterhet. Az edge API-tervezésről további információkat a Cloudflare Workers AI útmutatónkban találhat.

Alacsony vs. magas erőfeszítés – áttekintés

Az erőfeszítési szint kiválasztása a késleltetés, a költség és a válaszminőség közötti kompromisszum. Az alábbi táblázat összehasonlítja azokat a dimenziókat, amelyek a legfontosabbak egy kérés méretezésekor. A késleltetési és átviteli adatok tájékoztató jellegűek, és a prompt hosszától, a terheléstől és a régiótól függően változnak, de a köztük lévő arányok megmaradnak.

A lényeg az, hogy a gondolkodási tokenek valós kimeneti tokenek. Egy alacsony erőfeszítésű kérés röviden gondolkodik, és többnyire csak a leírt válaszért fizet; egy magas vagy maximális erőfeszítésű kérés nagy mennyiségű gondolkodási tokent generálhat, mielőtt a válasz első szava egyáltalán megjelenne. A gondolkodás soha nincs kikapcsolva – Ön csak azt választja meg, mennyit fordít rá.

Mikor melyik erőfeszítési szintet használjuk?

A gyakorlati megközelítés az, hogy minden feladattípushoz hozzárendelünk egy alapértelmezett erőfeszítési szintet, és csak akkor írjuk felül, ha egy adott kérésnek egyértelműen több tartalékra van szüksége. A magas és maximális erőfeszítést azokra a problémákra tartsa fenn, ahol egy hibás válasz utólagos kiszűrése költséges.

Válasszon alacsony erőfeszítési szintet, ha a válasz rövid és nagyrészt determinisztikus, ha az első tokenig eltelt idő határozza meg a felhasználói élményt (élő chat, automatikus kiegészítés, űrlapasszisztensek), vagy ha nagy volumenű, alacsony árrésű munkaterhelést futtat, ahol minden plusz kimeneti token milliószoros szorzót jelent az összes hívásra vetítve.

Válasszon magas vagy maximális erőfeszítési szintet, ha egyetlen hibás válasznak is valós költsége van – például egy hibás migrációs szkript, egy rosszul kiszámított árajánlat, egy nem biztonságos kódrészlet –, vagy ha a feladat több összefüggő lépést foglal magában, amelyeket a modellnek egyben kell tartania. Ezek azok a munkaterhelések, ahol néhány másodpercnyi extra késleltetés jelentős megbízhatóság-növekedést vásárol.

Gyakorlati példa: Látencia és költség kompromisszumok

Vegyünk egy ügyfélszolgálati asszisztenst, amely napi 50 000 kérést kezel. Tegyük fel, hogy minden végső válasz körülbelül 250 token, hogy az alacsony (low) erőfeszítési szint csak néhány gondolkodási tokent ad hozzá, és hogy a magas (high) erőfeszítési szint egy tipikus nehéz lekérdezésnél nagyjából 1500 gondolkodási tokent fogyaszt. Az alábbi token-árak mind tájékoztató jellegűek – tekintse modellezési gyakorlatnak, nem árajánlatnak –, és vegyünk alapul millió kimeneti tokenenként 15 dolláros árat.

Ha minden kérést alacsony erőfeszítéssel futtatunk, az nagyjából napi 50 000 × 250 = 12,5 millió kimeneti tokent jelent, ami a tájékoztató áron körülbelül napi 188 dollár. Ha ehelyett minden kérést magas erőfeszítéssel futtatunk, az napi 50 000 × (1500 + 250) = 87,5 millió tokent számláz, nagyjából napi 1313 dollárt – ez hétszer több, aminek nagy részét olyan lekérdezések átgondolására költjük, amelyeknek soha nem volt szükségük a plusz mélységre.

Most alkalmazzunk szelektív irányítást. Tegyük fel, hogy egy olcsó, alacsony erőfeszítésű osztályozó megállapítja, hogy a forgalomnak csak a 15%-a valóban összetett. Ha 7500 kérést küldünk magas erőfeszítésre és 42 500-at alacsonyra, az napi 13,1 millió + 10,6 millió ≈ 23,7 millió tokent eredményez, ami körülbelül napi 356 dollár – ez ~73%-os megtakarítás ahhoz képest, mintha mindent magas erőfeszítéssel futtatnánk, miközben a mély következtetést továbbra is ott alkalmazzuk, ahol megtérül.

A késleltetés képe ezt tükrözi. Alacsony erőfeszítésnél az első token jellemzően jóval egy másodpercen belül megjelenik. Magas erőfeszítésnél a modell sokkal nagyobb következtetési vázlatot generál, mielőtt a válasz elkezdődne, így egy 1500 tokenes belső vázlat egy tájékoztató jellegű, másodpercenkénti 60 tokenes sebesség mellett nagyjából 25 másodperccel késlelteti a látható választ. A thinking_delta blokkok streamelése egy lenyitható „Thinking…” panelbe teszi ezt a várakozást elviselhetővé a végfelhasználó számára.

Migráció és üzemeltetési költségek (TCO)

Ha rögzített számítási teljesítményű modellről vált, a legnagyobb változás az, hogy a következtetés mélysége mostantól egy kérésenként beállítható szabályozó, nem pedig egy fix díj, amit minden hívásért kifizet. A számlájára a legnagyobb hatással nem egyetlen hívás effort szintje van, hanem az az irányítási réteg (routing), amely eldönti, hogy mely kérések érdemelnek egyáltalán magas erőfeszítési szintet. Egy könnyű, alacsony erőfeszítésű osztályozó hívás – néhány száz token –, amely megszűri a drága, magas erőfeszítésű hívást, szinte mindig kifizetődik.

Két szokás segít kiszámíthatóvá tenni az üzemeltetési költséget. Elsőként: minden feladatosztályhoz azt a legalacsonyabb erőfeszítési szintet állítsa be, amely megbízhatóan megoldja azt, ahelyett, hogy egy nagyvonalú globális alapértelmezést használna; a mindenhol alkalmazott max erőfeszítési szint a meglepetésszerű számlák leggyakoribb oka. Másodszor: gyorsítótárazza a stabil rendszer-prompteket, hogy az ismétlődő kontextust ne kelljen minden gondolkodási ciklusban újra kiszámlázni. A kérésenkénti irányítás és a prompt-gyorsítótárazás együttesen a kiadások döntő részét a kérések azon kisebbségére irányítja, amely valóban profitál belőle.

Legfontosabb tanulságok

• A Fable 5 (claude-fable-5, 1M tokenes kontextus, 128K maximális kimenet) a gondolkodást mindig bekapcsolva tartja; a mélységét skálázza, nem pedig ki- vagy bekapcsolja.
• A következtetés mélységét az output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"} beállítással konfigurálja; a budget_tokens, valamint a thinking.type „enabled”/„disabled” értéke mostantól HTTP 400-at ad vissza.
• Streamelje a gondolkodást thinking tartalomblokkokon keresztül (thinking_delta részletekkel), hogy megjelenítse a modell lépéseit a végfelhasználóknak, olvasható összefoglalóért pedig kérje a thinking: {type: "adaptive", display: "summarized"} beállítást.
• Szabályozza az API számlázási költségeit azzal, hogy a legalacsonyabb működőképes erőfeszítési szintet választja, és gyorsítótárazza a gyakran használt prompteket.
• Telepítse az API-köztesszoftvert szerver nélküli edge hálózatokra a hálózati késleltetés csökkentése érdekében.

Gyakran ismételt kérdések (GYIK)

Mi az a Claude Fable 5 következtetés (reasoning)? A Claude Fable 5 következtetés egy mindig aktív képesség, amelyben a modell belső gondolkodási tokeneket generál összetett logikai feladatok megoldásához, mielőtt kiadná a végső választ. Ahelyett, hogy azonnal megpróbálná kitalálni a következő szót, a hálózat egy lépésről lépésre haladó gondolkodási folyamatot szimulál az architekturális, matematikai és kódolási hibák megoldásához, Ön pedig az effort beállítással skálázza, hogy milyen mélyen gondolkodjon.

Hogyan állíthatom be a következtetési erőfeszítést az API-ban? A következtetés mélységét úgy állítja be, hogy az API-kérés törzsében átadja az output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" } értéket. Az alacsonyabb erőfeszítési szint röviden gondolkodik, és kevesebb tokennel, gyorsabban válaszol, míg a magasabb szint mélyebben következtet. A régi budget_tokens paramétert eltávolították, és mostantól HTTP 400-as hibát ad vissza a Fable 5-nél.

Másképp számlázzák a gondolkodási tokeneket? Nem, a gondolkodási tokeneket a modell standard kimeneti (output) token árával számlázzák. Mivel ezek a tokenek kimeneti számítást képviselnek, közvetlenül beleszámítanak az API számlájába, így a promptek gyorsítótárazása és az ésszerű erőfeszítési szint elengedhetetlen a szoftver költségeinek szabályozásához.

Hogyan érhetem el, hogy a Fable 5 gyorsabban válaszoljon? A következtetést nem kapcsolhatja ki – a Fable 5-nél a gondolkodás mindig be van kapcsolva, és a thinking: {type: "disabled"} átadása HTTP 400-as hibát ad vissza. A késleltetés csökkentéséhez állítsa lejjebb az erőfeszítési szintet az output_config: { effort: "low" } beállítással, ami lerövidíti a gondolkodási fázist, és minimalizálja az első tokenig eltelt időt az egyszerű beszélgetési feladatoknál.

Hogyan nyerhetem ki a gondolkodási tokeneket egy SSE streamből valós időben? A szerver nélküli SSE streamelés során a gondolkodás thinking tartalomblokkokként érkezik olyan content_block_delta eseményeken keresztül, amelyek delta.type mezője thinking_delta; a szöveget a delta.thinking mezőből olvassa ki, a szokásos text_delta kimenettől elkülönítve. Olvasható összefoglalóért kérje a thinking: {type: "adaptive", display: "summarized"} beállítást, majd a frontend UI igényei szerint jelenítse meg vagy vesse el ezeket a tokeneket.