PIVOT, જે sparse-attention મોડલ્સ માટે એક નવી inference-time ટ્રિક છે, તે મોડલના weights માં કોઈ ફેરફાર કર્યા વિના indexer ખર્ચને ચાર ગણો ઘટાડે છે અને એકંદર latency ને અંદાજે 1.6× ઘટાડે છે. તે queries ને ગ્રુપિંગ કરીને અને એક સિંગલ “proxy” query ને મુખ્ય કામ સોંપીને કામ કરે છે.
શા માટે sparse attention 100 K tokens પર અટકી જાય છે
Sparse attentionનો હેતુ compute ને પરવડે તે રીતે transformers ને ખૂબ લાંબા sequences—જેમ કે 100 K tokens અથવા તેથી વધુ—જોઈ શકવા દેવાનો હતો. વ્યવહારમાં, એકવાર sequence થોડા દસ હજાર tokens થી વધી જાય પછી વચન આપેલ speed-up નાશ પામે છે. આનું કારણ indexer છે, જે કયા tokens sparse pattern માં હોવા જોઈએ તે નક્કી કરવા માટે દરેક query સામે દરેક token ને score કરે છે. તેનું કામ O(L²) (L = sequence length) મુજબ વધે છે, તેથી 100 K tokens પર માત્ર indexer જ runtime પર હાવી થઈ જાય છે અને sparsity થી મળતા કોઈપણ ફાયદાને ઘટાડી દે છે.
PIVOT પાછળના બે અવલોકનો
સંશોધકોએ જોયું કે નજીકની queries લગભગ હંમેશા સમાન top-k tokens પસંદ કરે છે—આશરે 90% overlap. તેનો અર્થ એ છે કે એક સિંગલ representative query આખા neighbours ના batch નું સ્થાન લઈ શકે છે અને તેમ છતાં ઉપયોગી candidate set મેળવી શકે છે. PIVOT આનો લાભ નીચે મુજબ લે છે:
- Grouping નિશ્ચિત સંખ્યામાં ક્રમિક queries (size g).
- Averaging ગ્રુપનું proxy query બનાવવા માટે.
- દરેક મૂળ query માટે એકવાર કરવાને બદલે proxy પર એક જ વાર indexer ચલાવવો.
- ગ્રુપના દરેક સભ્ય માટે proxy ની candidate list ને Refining કરવું.
ગણિત O(L²) થી ઘટીને O(L² / g) થઈ જાય છે. આઠના ગ્રુપ સાઈઝ સાથે, indexer આઠ ગણી ઓછી વખત full scans ચલાવે છે.
બે operating modes
- PIVOT-Refine indexer stage પર લગભગ ત્રણ ગણો speed boost આપતી વખતે dense indexer ની accuracy જાળવી રાખે છે.
- PIVOT-Reuse વધુ ઝડપ આપે છે, જે મહત્તમ throughput લાભ માટે થોડી ચોકસાઈ (accuracy) નો ત્યાગ કરે છે.
DeepSeek-V3.2 અને GLM-5.1 મોડલ્સ પરના benchmarks દર્શાવે છે કે જ્યારે inference દરમિયાન PIVOT લાગુ કરવામાં આવે છે, ત્યારે indexer ની ઝડપ સતત ચાર ગણી વધે છે અને end-to-end latency માં 1.6× ઘટાડો થાય છે.
Plug-and-play implementation
આ ટેકનિક એક reference implementation તરીકે આવે છે જેને કોઈપણ હાલના Dynamic Sparse Attention (DSA) pipeline માં ઉમેરી શકાય છે. તેમાં weights માં કોઈ ફેરફારની જરૂર નથી, તેથી standard sparse-attention recipes સાથે તાલીમ પામેલા મોડલ્સ કોઈપણ ફેરફાર વગર કામ કરે છે. એકમાત્ર મર્યાદા એ છે કે reference code generic GPU kernels પર ચાલે છે; સંપૂર્ણ ઝડપ મેળવવા માટે production deployments માં hand-tuned Triton અથવા CUDA kernels ની જરૂર પડશે.
Trade-offs કેવા દેખાય છે
PIVOT-Reuse નો ઝડપનો ફાયદો attention quality માં થોડા ઘટાડા સાથે આવે છે, જે ચોક્કસ token selection માટે અત્યંત સંવેદનશીલ કાર્યો માટે મહત્વનું હોઈ શકે છે. ટીમોએ તે નુકસાનને તેમના latency budget સામે તોલવું જોઈએ. આ ઉપરાંત, custom kernels ની જરૂરિયાત GPU-kernel નિષ્ણાત વગરની સંસ્થાઓ માટે engineering overhead વધારે છે.
આગળ શું જોવું
PIVOT દર્શાવે છે કે કામનું ચતુર રીતે પુનઃ વ્યવસ્થાપન—queries નું ગ્રુપિંગ કરવું અને proxy scan શેર કરવું—ખરેખર લાંબા contexts માટે sparse attention ના વચનને ફરી જીવંત કરી શકે છે, જે retraining ના ખર્ચ વગર નોંધપાત્ર ઝડપ આપે છે.
