Լոկալ reasoning-մոդելներում կա խափանման ռեժիմ, որը հասանելիության ոչ մի դաշբորդ ձեզ երբեք ցույց չի տա։ Սերվերն ընդունում է հարցումը, հոսքով տալիս է թոքեններ, վերադարձնում է HTTP 200 — իսկ օգտատերը ոչինչ չի ստանում, որովհետև մոդելի արտադրած ամեն թոքեն մտորում էր, և բյուջեն սպառվեց բուն պատասխանի առաջին նիշից առաջ։ Այսպես ավարտված հարցումն անվանում ենք answerless-հարցում և չափում ենք որպես լիարժեք ելք. դատարկ պատասխանը ձախողում է, որը մնում է հայտարարի մեջ։
Որքան հաճախ է դա իրականում պատահում
Qwen3.6-35B-A3B-ի վրա միացրած reasoning-ով և 1024 թոքեն ավարտման բյուջեով answerless վերադարձած առօրյա հարցումների բաժինը կազմեց 58.3հարցումների %unit_replicated մարդկային խնդիրների կորպուսի վրա — հաղորդագրություններ, նամակներ, բացատրություններ, պլաններ։ Հին ինքնահղումային բենչմարք-կորպուսի վրա նույն բջիջը տվեց 75.0հարցումների %repeated։ Սովորական հարցումների կեսից ավելին՝ լուռ առանց պատասխանի, մինչ սերվերը դրանցից ամեն մեկի վրա հաջողություն էր հաղորդում։
Մոդելների երկրորդ ընտանիքը վերարտադրում է մեխանիզմը։ Gemma-4-26B-ն իր լռելյայն աշխատանքային ռեժիմում answerless վերադարձրեց հարցումների 8.3հարցումների %repeated-ը — շատ ավելի ցածր ցուցանիշ, բայց ոչ զրո, մի մոդելի վրա, որի chat-template-ը reasoning-ի փոխանջատիչ անգամ դուրս չի հանում։ Սա մեկ մոդելի քմահաճույք չէ. սա այն է, ինչ պատահում է ամեն անգամ, երբ մտորման անցումն ու թոքեն-բյուջեն կիսում են գեներացիայի մեկ պատուհան։
Ինչու է դաշբորդն ասում, որ ամեն ինչ կարգին է
Մինչ սա տեղի է ունենում, ամեն սովորական serving-մետրիկա առողջ տեսք ունի.
- HTTP ստատուսը 200 է — հարցումն ավարտվել է։
- TTFT-ն գերազանց է. Gemma-4-ի ցանկացած ելքի առաջին թոքենը գալիս էր 282մվrepeated մեդիանով։ Բայց դա մտորման թոքեն է, ոչ թե պատասխանի — բուն պատասխանի առաջին թոքենը գալիս էր 10768մվrepeated-ում, իսկ answerless բաժնի վրա ընդհանրապես չէր գալիս։
- Գեներացված թոքենները շատ են — մոդելը ջանասիրաբար աշխատել է։ Պարզապես ամբողջ բյուջեն գնաց տեքստի վրա, որը կարդալ օգտատերը չէր խնդրել։
Սա բռնում է միակ մետրիկան, որը գրեթե ոչ ոք չի հավաքում. պատասխանի թոքենները — թոքենները reasoning-բլոկի փակվելուց հետո։ Հենց դրա համար մեր harness-ը TTFA-ն հաշվում է TTFT-ից առանձին և դատարկ պատասխանը դիտում որպես ձախողված հարցում, նույնիսկ երբ տրանսպորտը հաջող է աշխատել։
Ինչ անել սրա հետ
- Բյուջե դրեք մտորման համար, ոչ միայն պատասխանի։ 1024 թոքենանոց պատուհանը, որտեղ կտեղավորվեր մեր կորպուսի ցանկացած պատասխան, «մտորում + պատասխան» զույգերից գրեթե ոչ մեկը չի տեղավորում։ Խափանումների կորը բյուջետային քաղցի կոր է, ոչ թե մոդելի դեֆեկտ։
- Կամ անջատեք reasoning-ն առօրյա տրաֆիկի համար։ Նույն մեքենայի վրա մտորման բլոկի անջատումն առաջին պատասխանի սպասումը տասնյակ վայրկյաններից իջեցրեց մինչև 210մվunit_replicated՝ այս workload-ների վրա խնդիրների անփոփոխ հաջողությամբ — տես reasoning-ի գնի համեմատությունը։
- Հետևեք պատասխանի թոքեններին։ Եթե ձեր serving-ստեկը մտորման թոքենները
պատասխանի թոքեններից չի տարբերում, այս խափանումը ձեզ համար անտեսանելի է։
usageդաշտերը, որոնք դրանք միաձուլում են, թաքցնում են այն։
Սահմանափակումներ
- Մոդելների երկու ընտանիք, մեկ մեքենա (Strix Halo, llama.cpp Vulkan՝ ամրագրված digest-ով), սառեցված կորպուսներ, մեկ հոսք։ Ցուցանիշները մոդել × բյուջե × կորպուս բջջի հատկություններ են, ոչ թե ունիվերսալ հաստատուններ։
- Մեխանիզմի պնդումը — մտորումը սպառում է ընդհանուր բյուջեն պատասխանի առաջին թոքենից առաջ — ստուգվում է հարցում առ հարցում հրապարակային որակի գրառումներում. ամեն answerless-հարցում ցույց է տալիս մտորման ոչ զրո նիշեր և պատասխանի զրո նիշ։
- Վենդորների հոսթինգով API-ները չենք չափել; նրանց մոտ բյուջեների հետ վարվելն այլ է։
Վերևի ամեն թիվ ունի մշտական էջ՝ scope-ով, սահմանափակումներով և կնքված գործարկման ապացույցներով — claim-երի ռեեստրը։ Տերմինը սահմանված է բառարանում։