5 ақпанда DFlash туралы мақала жарық көрді — бұл кез келген тілдік модельдің генерациясын модельдің өзіне тимей жылдамдату тәсілі, — ал соңынан NVIDIA бенчмарктарын жариялады, тақырыбында «өткізу қабілеті 15× дейін жоғары» деп тұрды. Мұндай сан үшін бәрін тоқтатып тексеруге тұрарлық. Біз Gemma 4 26B-ге арналған DFlash драфтерін алдық — ол модельдің өзі жүктелетін репозиторийде жатыр, — оны өз стендімізде сынап, 2,31× алдық — бірақ картада бір ғана сұраныс тұрғанда. Төрт қатарлас сұраныстан кейін DFlash жалпы өткізу қабілеті бойынша кәдімгі модельден ұтыла бастайды, сегізінде — бір жарым есе ұтылады.
Төменде: бұл қалай жұмыс істейді, 15× қайдан шығады және неге біздің график вендордікінен ажырайды — оның үстіне ешкім өтірік айтпаған.
DFlash генерацияны қалай жылдамдатады
Кәдімгі модель авторегрессивті декодтайды: барлық салмақ арқылы бір өту — бір токен. Бір сұраныстан тұратын батчта бұл өте тиімсіз. Жалғыз токенді есептеу үшін GPU модельдің бүкіл салмағын жадтан айдап өтуге мәжбүр, әрі ол есептеуге емес, жадтың өткізу қабілетіне тіреледі. Арифметикалық блоктар бұл кезде дерлік бос тұрады.
Спекулятивті декодтау осы бос тұруды сатады. Кішкентай «жоба» моделі бірден бірнеше келесі токенді ұсынады, ал үлкен модель бүкіл блокты бір өтуде тексереді — сол өтуді ол бір токен үшін бәрібір жасамақ еді. Сәйкес келген префикс толығымен қабылданады, алғашқы алшақтық қалғанын кесіп тастайды. Схема математикалық тұрғыдан адал: шығыс үлестірімі өзгермейді, сондықтан жылдамдық сапа есебінен келмейді.
Бұл жердегі тар жер — жобаның өзі. EAGLE-3 сияқты классикалық әдістер оны да авторегрессивті, яғни бірінен соң бірі жасайды: бес жоба токені — бес кішкене өту. DFlash идеясы жоба моделін блоктық диффузиялық модельге ауыстыруда: ол бүкіл блокты бір өтуде, қатарлас түрде береді, токенді бір-бірлеп емес. Оған қоса оны үлкен модельдің ішкі белгілерімен қоректендіреді, сонда жоба контекстке дәлірек түседі. Авторлар сапаны жоғалтпай алты еселік жылдамдықты және EAGLE-3-тен 2,5× дейін артықшылықты мәлімдейді.
Біздің жағдайда жоба — бұл 26B параметрлі (4B белсенді) MoE модельге тағылған 451 МБ бөлек диффузиялық модуль. Бізде ол жалғасты шамамен төрттен бір жағдайда дәл тапты, ал қабылданған блоктың орташа ұзындығы 2,06 токен болды: үлкен модельдің бір өтуінде біреудің орнына орта есеппен екі токен шығады.
15× қайдан шықты
Сан шынайы, бірақ оны шарттарымен бірге оқу керек. NVIDIA 15×-ті gpt-oss-120b, сегіз DGX B300 және TensorRT-LLM жиынтығында алды, әрі «жалпы» емес, Парето қисығының нақты бір нүктесінде — әр пайдаланушыға секундына 500–600 токен келетін жерде. Бұл — шекті жауап беру режимі, онда кәдімгі авторегрессивті декодтау әрең өміршең: бір пайдаланушыға сонша токен беру үшін батчты дерлік бос ұстап, картаны бекерге жағу керек. DFlash бұл нүктеде базалық сызықты шынымен де быт-шыт қылады, өйткені оны әдейі тиімсіз жұмыс режимімен салыстырады.
Қалыпты режимге жылжысаң — көбейткіш отырады. Сол мақалада NVIDIA салыстырмалы қатарластық кезіндегі кестені келтіреді: gpt-oss-120b үшін орта есеппен 2,3×, Llama 3.1 8B үшін 2,8×. Бір сұраныс пен бір картада — Gemma-4 31B үшін Math500-де 5,8×, MBPP-де 4,4× — біз алған модельдің отбасылық көршісі. Яғни вендордың өз деректері қай жерде өлшеуге байланысты 1,8×-тен 15×-ке дейін шашырау береді, ал 15× — ең шеті.
Бізде не шықты
Біз өз стендіміздегі жалпы генерация жылдамдығын өлшедік, қатарлас сұраныстар санын арттыра отырып. Базалық сызық — спекуляциясыз Gemma 4 26B, екінші баған — сол модель DFlash-пен.
Стенд: бір NVIDIA RTX 6000 PRO, драйвер 610.57.04, CUDA UMD 13.3, инференс Docker 29.7.2 ішінде — llama.cpp server-cuda, 10711 құрастырмасы. Модель gemma-4-26B-A4B-it-Q4_0, KV-кэш q4_0, сұранысына 512 токен, жоба ұзындығы --spec-draft-n-max 4.
| Қатарлас сұраныстар | База, токен/с | DFlash, токен/с | Қатынасы |
|---|---|---|---|
| 1 | 180,8 | 418,0 | 2,31× |
| 2 | 325,8 | 519,3 | 1,59× |
| 3 | 440,8 | 480,3 | 1,09× |
| 4 | 517,3 | 522,3 | 1,01× |
| 6 | 674,7 | 581,5 | 0,86× |
| 8 | 779,4 | 538,2 | 0,69× |
Бұл графикті қатынас бойынша емес, екі қисықтың пішіні бойынша оқу қызықтырақ. База дерлік сызықты өседі: 181 → 326 → 441 → 517 — карта біртіндеп жүктеледі, қосылған әр сұраныс бірінші сұраныспен шамалас токен әкеледі. DFlash бірінші сұраныстан кейін бірден жазыққа шығады және әрі қарай қатарластықты қайда жылжытсақ та 480–580 дәлізінде қалады. Бетбұрыс — шамамен 4,1 сұраныс. Оның үстіне біздің графиктің сол шеті де сол отбасының көрші моделіндегі вендорлық 5,8×-тен екі еседен астам төмен: NVIDIA өз стендінде Math500-ді өлшеген, ал бізде — бір картадағы аралас жүктеме.
Маңызды бір егжей-тегжей: мұнда жеке пайдаланушы емес, сервер тұтас ұтылады. DFlash-тағы бір ағынның жылдамдығы дамудың бірде-бір нүктесінде базалық сызықтан төмен түскен жоқ — сегіз қатарлас сұраныста тепе-теңдік шықты, ағынына 97,5-ке қарсы 98,8 токен/с. Отыратыны — дәл жалпы өткізу қабілеті: карта тактілерін сол сәтте лақтырылатын жобаларға жұмсайды.
Неге қатарластық жылдамдықты жеп қояды
Екі әдіс те бір ресурспен — GPU-дың бос тұрған арифметикалық блоктарымен — өмір сүреді, сондықтан олар қосылмайды, бәсекелеседі.
Спекуляция бұл бос тұруды жоба токендеріне жұмсайды, олардың бір бөлігі алдын ала қоқысқа кетеді: блок соңғы позициясында кесілмейді дерлік, ал кесіндіден кейінгінің бәрі бекерге есептелген. Бір сұраныс кезінде бұл ештеңе тұрмайды — арифметикалық блоктар бәрібір бос тұрған, лақтырылған есептеулер тегін.
Батчинг сол бос тұруды бөгденің шынайы токендеріне жұмсайды. Сегіз қатарлас сұраныс салмақтарды жад арқылы бәріне бір рет айдап, өтуіне сегіз пайдалы токен есептейді — бірде-біреуі лақтырылмайды. Батч картаны толтырған бойда тар жер жадтан есептеуге көшеді, дәл сонда лақтырылған жоба токендері тегін болуын қояды: олар нақты жұмыстан такт жеп кетеді. Біздің графиктегі жазық та, базалық сызықтан төмен түсу де осыдан.
Бұл DFlash-тың ақауы емес, оның қолданылу шекарасы — әрі индустрия бұл туралы біледі. Өндірістік стектер қатарластық өскенде спекуляцияны өздері өшіре алады; шекті жиі 32 қатарлас тізбек шамасында қояды.
Адал ескерту: біздің бетбұрыс индустрияға тән отыз шақты сұраныстан әлдеқайда ерте келеді. Бұл вендор сандарын жоққа шығару емес, сол қисықтағы басқа нүкте: басқа жабдық — сегіз B300 (Blackwell Ultra) емес, бір ғана карта, әрі басқа стек — TensorRT-LLM емес, llama.cpp. Сегіз B300-де TensorRT-LLM-мен жазық едәуір оңға жылжиды. Өлшеудің мәні NVIDIA асыра сілтеді дегенде емес, көбейткішті вендор стендінен өз кластеріңе көшіруге болмайды дегенде.
Неге өсім тек математика мен кодта бар
Өлшеулерден көрінетін екінші нәрсе: жылдамдық не сұрағаныңа қатты байланысты. Айқын өсімді біз математикалық есептерде және код генерациясында алдық. Еркін мәтінде ол жай ғана жоғалып қоймайды, минусқа кетеді.
Міне, сол стендтегі бөлек прогонның тапсырма түрлері бойынша бөлінісі: картада бір сұраныс, 1024 токен, жоба ұзындығы 15 токенге дейін — жоғарыдағы кестедегіден әлдеқайда ашкөз. Үшінші жол — mtp режимі, қосымша сынаған екінші спекуляция тәсілі.
| Режим | Математика | Код | Проза | Орташа | Базаға |
|---|---|---|---|---|---|
| База | 188,0 | 189,6 | 189,4 | 189,0 | — |
| DFlash | 303,9 | 254,5 | 179,1 | 245,8 | 1,30× |
| MTP | 211,7 | 175,0 | 143,7 | 176,8 | 0,94× |
Математика — 1,62×, код — 1,34×, проза — 0,95×: еркін мәтінде DFlash көмектесуін қойып, кедергі келтіре бастайды, ал орташа 1,30× тек алғашқы екі бағанның есебінен тұр. mtp-де математика небәрі 1,13× берді, ал код пен проза минусқа кетті — орта есеппен ол базалық сызықтан ұтылады, сондықтан оны әрі қарай қарамадық.
Бұл кесте мұндағы 1,30× пен жоғарыдағы дамудағы 2,31× неге бөлек екенін де түсіндіреді: мәселе жобаның ұзындығында. Он бес токенді біз құжаттамадағы мысалдардан алдық, ал ол тексерілгендердің ішіндегі ең нашары болып шықты: сол 1024 токен n-max=4-те n-max=15-тегі 245,8-ге қарсы 330,6 токен/с береді. Жоба неғұрлым ұзын болса, бас тартқанда соғұрлым көп есептеу күйіп кетеді, сондықтан мәлімделген блок өлшемі — ұсыныс емес, жоғарғы шек.
Механикасы сол — қабылданған жобалардың үлесі. Жоба моделі жалғасында энтропия неғұрлым аз болса, соғұрлым жақсы болжайды. Есептеуде немесе кодта келесі токендер синтаксис пен үлгімен қатаң белгіленген: жабылатын жақша, айнымалының аты, теңдік белгісі, функцияның стандартты тақырыбы. Тірі прозада әр қадамда ықтималдығы шамалас ондаған жалғас бар, жоба екінші-үшінші позицияда жаңылады, блок кесіледі — және біз бір-екі қабылданған токен үшін бүкіл есептелген блокқа төлейміз. Морфологиясы бай тілдер мұны одан әрі ушықтырады: сол сөзге көбірек токен кетеді, демек блок ішінде жаңылу мүмкіндігі де көбірек.
Вендорлық жиынтықтарда дәл осы көрінеді: DFlash Math500, GSM8K, HumanEval және MBPP-де сыналады — бұл бар мәтіннің ішіндегі ең болжамдысы. NVIDIA-ның өзінде «жазушылық» тапсырмаларда көбейткіш кодтағы 2,6×-ке қарсы 1,8×-ке дейін түседі. Ішкі шектеу де бар: жоба дәлдігі блок соңына қарай төмендейді — әдістің екінші нұсқасының авторлары бойынша, бірінші позициядағы 99,5%-дан жетіншідегі 87,8%-ға дейін.
Қосымша олжа: кванттталған KV-кэш жылдамдықтың 39%-ын жейді
Баптауларды таңдап жүріп, DFlash-қа қатысы жоқ, бірақ түзетуге әлдеқайда арзан нәрсеге тап болдық. Біз ұзын контекст үшін KV-кэшті кванттталған күйде (--cache-type-k/v q4_0) ұстап келдік. Оны f16-ға ауыстыру базалық сызықты 189,0-ден 263,1 токен/с-қа көтерді — ешқандай спекуляциясыз 39%; сегіз қатарлас сұраныста — 784-ке қарсы 917.
Бұл ұтыс тегін емес: f16-кэш шамамен төрт есе көп жад алады, ал кішірек картада ол модель мен ұзын контекстпен бірге сыймайды — контекст пен жылдамдықтың арасынан таңдауға тура келеді. Бірақ шаманың реті көрнекі: спекуляцияны тағар алдында, сол 39%-ды кэшті кванттауға беріп қойған жоқпысың — соны тексерген жөн.
Әрі бұл — мақаланың негізгі тезисінің көрнекі мысалы. q4_0-кэште DFlash-тың ең жақсы нұсқасы базаға 1,75× берді, ал f16-да — небәрі 1,35×. Базалық инференс неғұрлым мұқият сығылған болса, спекуляцияға сығатыны соғұрлым аз қалады.
Бұл нені өзгертеді
DFlash — қолданылу аясы тар жақсы инженерия, бәріне арналған тегін жылдамдық емес. Ол жабдықтың жалпы өткізу қабілеті емес, бір пайдаланушының жылдамдығы маңызды жерде өтеледі: бір картадағы жергілікті іске қосу, IDE ішіндегі көмекші, кодты автотолықтыру, агенттің құралдарды шақыруы. Осының бәрінде карта шынымен де толық жүктелмеген, ал спекуляция әйтпесе бекерге кететін бос тұруды өзіне алады. Оның үстіне карта неғұрлым баяу болса, спекуляция соғұрлым тиімді: мақсатты модельдің қадамы қымбатқа түскен сайын, жоба өзін көбірек ақтайды.
Картада пайдаланушылар кезегі тұрған жерде — яғни кез келген жария сервисте — кәдімгі батчинг тиімдірек, ал қосулы спекуляция кедергі келтіре бастайды. Біз үшін тұжырым практикалық әрі көңілсіз: өз конфигурацияңды өзің өлшеу керек, өз тапсырмаларыңда, өз тілдеріңде және өзіңнің нақты қатарластығыңда. Баспасөз релизіндегі бір көбейткіш ешқайда көшпейді.
Жылдамдықты бізде қайдан көруге болады
Біз бұл тұжырымды өзімізге қолдандық. GPTunneL-де Grom 1.5 бар — өз жабдығымыздағы өз моделіміз, әрі біз онда пайдаланушы сезінетін нәрсенің дәл өзін қудық: алғашқы токен шамамен 500 мс-та және ағында секундына 120 токенге дейін. Бұған спекуляциямен емес, бүкіл стекті бақылайтынымызбен қол жеткіздік: балансировщик сұраныстарды тапсырма салмағына қарай пулдарға таратады, диалог префиксі GPU жадында жатады, ал модельдің өлшемі ол шынымен жұмыс істейтін жабдыққа қарай таңдалған.