Կարճ, չափված պատասխանը. այս տուփի վրա խիստ JSON-ի հուսալիությունը քվանտավորման, backend-ի կամ reasoning ռեժիմի ֆունկցիա չէր — այդ փոխարինումներից ոչ մեկը խնդրի հաջողությունը չշարժեց։ Այն մոդելի ֆունկցիա էր։ Մի ընտանիքը մեր գործարկած բոլոր կոնֆիգուրացիաներում անթերի անցավ; մյուսը նույն խնդիրների վրա պատասխաններ էր կորցնում։ Եթե ձեր pipeline-ը կախված է պարսվող ելքից, բենչմարքեք մոդելը, ոչ թե կարգավորումները։
Ամեն թվի հետևում կանգնած workload-ը. դետերմինիստական կարճ ավտոմատացման խնդիրներ՝ փակ պիտակների բազմություններով, գնահատված end-to-end — ելքը պետք է պարսվի որպես JSON և ամեն բանալիով համընկնի ground truth-ի հետ։ Ձախողված հարցումները մնում են հայտարարում։ Մեկ Ryzen AI Max+ 395 տուփ, llama.cpp-ն ամրագրված digest-ով, երեքական կրկնված անցում ամեն բջիջի համար։
Քվանտավորումը կոտրո՞ւմ է JSON ելքը
Ոչ — ոչ այս երկու քվանտների միջև, այս մոդելի վրա։ Q4_K_M-ն անցավ 100.0հարցումների %repeated-ով, Q8_0-ն նույն խնդիրների վրա՝ 100.0հարցումների %repeated-ով։ Տարածված վախը, թե ավելի փոքր քվանտն է այն տեղը, որտեղ ձեր JSON-ը սկսում է կոտրվել, այստեղ հենարան չգտավ — իսկ քանի որ փոքր քվանտը նաև ավելի արագ է դեկոդում, հուսալիությունն այս workload-ի վրա Q8_0-ի համար վճարելու պատճառ չէ։
Backend-ը նշանակություն ունի՞
Ոչ։ ROCm build-ն անցավ 100.0հարցումների %repeated-ով նույն խնդիրների վրա, որտեղ Vulkan build-ն անթերի էր անցել։ Backend-ները շարժում են արագությունը, ոչ թե ճշտությունը — այս կոնֆիգուրացիայում դրանք կատարման ուղիներ են, ոչ թե տարբեր ուղեղներ։
Thinking ռեժիմն օգնո՞ւմ է
Ոչ՝ կոշտ ճիշտ պատասխան ունեցող խնդիրների վրա։ Reasoning-ը միացրած՝ արդյունքը 100.0հարցումների %repeated էր՝ ընդդեմ նույն անթերի արդյունքի reasoning-ն անջատած — մեծության կարգի ժամանակային գնով։ Կառուցվածքային ավտոմատացման համար thinking-բլոկը մաքուր ուշացում է։
Փոփոխականը, որն իրոք շարժվեց. մոդելը
Նույն տուփը, նույն runtime-կարգապահությունը, նույն workload-պայմանագիրը. gemma-4-26B-A4B-ն անցավ 93.8հարցումների %repeated-ով այնտեղ, որտեղ Qwen3.6-35B-A3B-ն վերևի բոլոր կոնֆիգուրացիաներում անթերի հաշիվ էր պահում։ Աղետալի ձախողում չէ — հարցումների մեծ մասը նորմալ պարսվում է — բայց առանց հսկողության աշխատող pipeline-ի համար «ամեն պատասխան պարսվում է»-ի և «պատասխանների մեծ մասը պարսվում է»-ի տարբերությունը cron job-ի և pager-ի տարբերությունն է։ Մոդելի փոխարինման ամբողջ պատկերը, ներառյալ թե որտեղ է gemma-ն այլուր հաղթում, փոխարինումների հաշվետվության մեջ է։
Որքա՞ն արագ է հուսալի JSON պատասխանը
Reasoning-ն անջատած՝ end-to-end մինչև ամբողջական, ստուգված պատասխան. 844մվrepeated։ Բավական արագ, որ մոդելը դադարում է լինել ավտոմատացումների մեծ մասի bottleneck-ը — հերթի աճի հետ ավելի կարևոր է դառնում զուգահեռության վարքը։
Ինչ սա ՉԻ ասում
- Grammar-սահմանափակված դեկոդավորում չի օգտագործվել։ Սրանք prompt-մակարդակի արդյունքներ են; llama.cpp-ի grammar-հարկադրանքը կարող է մեխանիկորեն ապահովել պարսվելիությունը, թեև ոչ ամեն բանալու ճշտությունը, և միտումնավոր անջատված էր — չափել ենք մոդելները, ոչ թե զսպաշապիկը։
- Փակ պիտակների բազմություններ, կարճ խնդիրներ։ Երկար ազատ JSON փաստաթղթերը՝ ներդրված կառուցվածքով, ավելի բարդ խնդիր են, որն այս workload-ը չի զոնդում։
- Երկու մոդելային ընտանիք, մեկ տուփ։ Այն գտածոն, որ շարժվող մասը մոդելն է, հենց այն պատճառն է, որ մենք այն չենք էքստրապոլացնում մեր չգործարկած մոդելների վրա։
Վերևի ամեն թիվ ունի մշտական էջ՝ շրջանակով, սահմանափակումներով և հում գործարկումներով. claim-երի ռեեստրը։