thinking stream starts immediately — it is just not addressed to the user

Ինչ եք տեսնում

Reasoning-մոդել՝ հոսքային չաթ endpoint-ի հետևում։ Առաջին թոքենը գալիս է անմիջապես, միայն թե հոսում է ոչ թե պատասխանը, այլ reasoning-բլոկը։ Պատասխանը սկսվում է շատ ավելի ուշ. փոքր թոքենային բյուջեի դեպքում այն հաճախ ընդհանրապես չի սկսվում, և հարցումն ավարտվում է հաջողության ստատուսով ու դատարկ պատասխանի դաշտով։ Երկու հաշվետվություններն էլ ախտանիշը երեք նախադասության մեջ են տեղավորում.

thinking stream starts immediately — it is just not addressed to the user
The user watches tokens stream for that entire time — they are the model thinking out loud, not the reply.
the caller gets HTTP 200 and an empty string

Որտեղ ենք հանդիպել

• Beelink GTR9 Pro (Ryzen AI Max+ 395, Radeon 8060S / gfx1151, 128 GB unified); llama.cpp server-vulkan-b9049՝ ամրագրված image digest-ով; Qwen3.6-35B-A3B Q4_K_M ggml-org-ից՝ հեշով ստուգված։
• Workload interactive-assistant-v1 @ 2026-08-02, սառեցված EN և RU պրոմպտներ; զուգահեռություն 1, կոնտեքստ 8192, temperature 0, prompt cache-ն անջատած։
• Երեք ռեժիմ. reasoning-ը միացրած՝ 1024 թոքենի բյուջեով, միացրած՝ 4096-ով, անջատած chat template-ի միջոցով՝ 1024-ով։ Չափումը կլիենտային կողմում է. սերվերային timing-ներն էֆեկտը կթաքցնեին։
• Reasoning-ի գնի հաշվետվությունը հրապարակվել է 2026-08-20. երկրորդ ինտերակտիվ կորպուս և խիստ JSON workload, նույն սարքաշարը, runtime-ը և արտեֆակտը. runtime-ի ճշգրիտ build-ը, մոդելի digest-ը և յունիթների քանակը նրա հղած claim-էջերում են։

Պատճառ

Մոդելը reasoning-բլոկը գրում է պատասխանից առաջ, և հոսքը սկսվում է հենց դրանով, ուստի առաջին թոքենը, ինչ էլ այն լինի, նույն պահին է հասնում՝ անկախ նրանից՝ տուփն անմիջապես է պատասխանում, թե ընդհանրապես չի պատասխանում։ Պատասխանի առաջին թոքենը գալիս է միայն բլոկի ավարտից հետո։ Երբ բյուջեն reasoning-անցման պահանջածից պակաս է, անցումն ուտում է ամբողջ բյուջեն դեռ պատասխանի սկսվելուց առաջ, endpoint-ը վերադարձնում է հաջողություն դատարկ պատասխանով, և ստատուս-կոդի ստուգումը դա գրանցում է որպես հաջողություն։ Սերվերային կողմի չափումն այս ամենը թաքցնում է։

Լուծում

Չափեք ժամանակը մինչև պատասխանի առաջին թոքենը՝ կլիենտային կողմում։ Ժամանակը մինչև առաջին թոքենը, ինչ էլ այն լինի, reasoning-մոդելի համար պիտանի թիվ չէ։

Դատարկ պատասխանները հաշվեք որպես ձախողում՝ և՛ սխալների բաժնում, և՛ հապաղման յուրաքանչյուր վիճակագրության հայտարարում։ Թոքենային բյուջեն կոռեկտության կարգավորում է. եթե reasoning-ը մնում է միացրած, անցման համար բյուջե նախատեսեք։

Reasoning-ն անջատեք այնտեղ, որտեղ workload-ը թույլ է տալիս։ Մեր տուփի վրա այն անջատված էր chat template-ի միջոցով. սկզբնաղբյուր էջերը նշում են կարգավորումը, ոչ թե դրոշը։ Ստուգեք աշխատող սերվերի վրա, ոչ թե փաստաթղթերով. հարցրեք նրան, թե ինչ template և կարգավորումներ է փաստացի կիրառել, հետո ուղարկեք մեկ հարցում և նայեք՝ reasoning-բլոկ հայտնվո՞ւմ է։ Անջատած reasoning-ով պատասխանը սկսվում էր հոսքի հետ միասին և այնուամենայնիվ անցնում էր լեզվի ու կրկնությունների gate-երը. բառերի բյուջեի gate-ը ձախողվում էր ամեն ռեժիմում՝ միացրած թե անջատած, ինչը հաշվետվությունը վերագրում է մոդելի շատախոսությանը, ոչ թե փոխարկիչին։ Առօրյա չաթի և խիստ JSON ավտոմատացման վրա reasoning-ը ոչինչ չգնեց, որ մեր gate-երը կարողանային նկատել. բարդ բազմաքայլ խնդիրները մեր կորպուսներից դուրս են՝ մեր կողմից չփորձարկված։

Բա՞ց է դեռ upstream-ում

Մենք չենք հետևում։ Սկզբնաղբյուր էջերը upstream issue չեն նշում. թերությունը մետրիկայի մեջ է, ոչ թե runtime-ում։

Ապացույցներ

• Time-to-first-token-ը ոչինչ չի ասում մտածող մոդելի մասին — կլիենտային չափում, հարցում առ հարցում գրառումներ։
• Անջատե՞լ thinking-ը — միացրած/անջատած փոխզիջումը և ստուգման քայլը։
• Thinking-ն ընդդեմ no-thinking-ի, կողք կողքի — նրան հղում է երկրորդ հաշվետվությունը։
• Run-փաթեթներ. botAGI/agmind-lab; արժեքները վերաարտածվում են claim-երի ռեեստրի հարցումներով։