உங்க AI Agent Cloud Bill எகிற காரணம் என்ன? Cache Engineering தரும் புது தீர்வு!

Cache Engineering அப்படின்னா என்ன?#

நீங்க இப்போ ஒரு AI Agent-ஐ உருவாக்குறீங்கன்னு வைப்போம். அந்த ஏஜென்ட் ஒரு வெப்சைட்டை ஸ்கிராப் பண்ணி, API வழியா தகவலை எடுத்து, டேபிளை ஒப்பிட்டு பார்த்து ஒரு ரிப்போர்ட் தரணும். முதல் இரண்டு ஸ்டெப் மின்னல் வேகத்துல முடியும். ஆனா பத்தாவது அல்லது இருபதாவது ஸ்டெப் போகும்போது, சிஸ்டம் பயங்கரமா ஸ்லோ ஆகும். மாசக் கடைசியில கிளவுட் சர்வர் பில் பார்த்தா தலை சுற்றும்.

இந்த பிரச்னைக்கு முக்கிய காரணம் Key-Value Cache, அதாவது சுருக்கமா KV Cache. ஒரு Large Language Model அடுத்த வார்த்தையை யோசிக்கும் போது, ஏற்கனவே படிச்ச வார்த்தைகளோட கணித மதிப்புகளை (Mathematical states) மெமரில பத்திரப்படுத்தி வைக்கும். சாதாரண சேட்பாட் அரட்டைகளுக்கு இது பெரிய பாரமா தெரியாது. ஆனா ஒரு AI Agent தொடர்ந்து ஃபைல்களை வாசிக்கும் போது, JSON டேட்டாவை எடுக்கும் போது இந்த மெமரி எக்கச்சக்கமா பெருசாகுது.

இந்த கேஷ் எக்கச்சக்கமா வளர்றதை தடுக்க, மாடலின் அதிகபட்ச Context Length அளவை தாண்டாமல் பார்த்துக்க புது வழி தேவைப்படுது. முன்னாடி வரைக்கும் Context Engineering வழியா பழைய மெசேஜ்களை கட் பண்ணி எடுத்தாங்க. இப்போ Tsinghua-NICS-EFC குழுவினர் கொண்டு வந்திருக்கிற 'Cache Engineering' கான்செப்ட் என்னன்னா, பிராம்ப்ட்டை மாத்தாமலேயே மாடலின் உள்ளே இருக்கும் KV Cache-ஐ நேரடியாகவே கட் பண்ணி சரிசெய்யும் ஒரு புது டெக்னிக்.

இந்த டெக்னாலஜி GPU-ல எப்படி வேலை செய்யுது?#

இதை எளிமையா ஒரு ஆபீஸ் உதாரணம் மூலமா புரிஞ்சிக்கலாம். ஒரு டேபிள்ல ஒரு கிளார்க் உட்கார்ந்து பைல்களை அடுக்கி வேலை பார்க்கிறார். மேஜை முழுக்க பேப்பர் நிரம்பிடுச்சு. மேனேஜர் வந்து, 'பழைய அஞ்சு பேப்பரை தூக்கிட்டு ஒரு சின்ன நோட்ல சுருக்கமா எழுதி வை'ன்னு சொல்றாரு. இப்போ அந்த கிளார்க் என்ன பண்ணுவார்? பழைய பேப்பரை தூக்கிப் போட்டுட்டு, புது சுருக்கத்தை வச்சிட்டு, அதுக்கு அப்புறம் இருக்கிற எல்லா பேப்பரையும் திரும்ப முதல் பக்கத்துல இருந்து வரிசையா படிச்சு புரிஞ்சிக்கிட்டா தான் வேலையை தொடர முடியும். இதுக்கு பேர் தான் Re-prefilling. இதுல நேரம், பேட்டரி, GPU உழைப்பு எல்லாமே வீணாகுது.

இதற்கு தீர்வாக தான் ஆராய்ச்சியாளர்கள் Cache Engineering முறையை முன்வைக்கிறாங்க. இதுல ஏஜென்ட் தன்னோட கேஷை தானே கையாளுது. இதற்காக இரண்டு முக்கிய ஆபரேஷன்கள் பயன்படுது: ஒன்று drop, இன்னொன்று repos. தேவையில்லாத பழைய டூல் ரெஸ்பான்ஸ்களை drop பண்ணி அடுத்த அட்டென்ஷன் கால்குலேஷன்ல இருந்து தூக்கிடலாம். அதேநேரம் மிச்சமிருக்கும் தகவல்களுக்கு ஏற்ப பொசிஷன் என்கோடிங் மதிப்புகளை repos மூலம் அட்ஜஸ்ட் பண்ணிக்கலாம்.

அதாவது, மேஜையில் இருக்கும் தேவையில்லாத ஒரு பேப்பரை மட்டும் யாருக்கும் தெரியாம உருவி எடுத்துட்டு, மத்த பேப்பர்களை கொஞ்சம் நகர்த்தி வச்சிக்கிற மாதிரி. இதனால மாடல் திரும்பவும் ஆரம்பத்துல இருந்து எல்லா டோக்கனையும் Re-prefill பண்ண வேண்டிய அவசியமே வராது.

நம்ம Developers எந்த தப்பு பண்ணி அதிக பில் கட்டுறாங்க?#

நம்ம ஊர் ஸ்டார்ட்-அப்கள் மற்றும் டெவலப்பர்கள் பலரும் ஏஜென்ட் லூப் பெருசாகும் போது ஒரே ஒரு வழியை மட்டும் தான் நம்பியிருக்காங்க. அது பழைய ஹிஸ்டரியை ட்ரிம் பண்றது (Context Trimming) அல்லது சுருக்கி அனுப்புறது (Summarization). இதுக்கு பேரு தான் Context Engineering. மேலோட்டமா பார்த்தா இது டோக்கன் எண்ணிக்கையை குறைப்பது போல தோன்றும்.

ஆனா உள்ளுக்குள்ள என்ன நடக்குதுன்னா, டிரஜெக்டரி பிரீஃபிக்ஸை (Trajectory prefix) நீங்க தொட்ட அடுத்த விநாடியே, அதுக்கு அப்புறம் மாடல் சேர்த்து வச்ச அத்தனை கேஷ் தகவல்களும் செல்லாததாகிடும். GPU திரும்பவும் முதல் வரியில இருந்து எல்லா வார்த்தைகளையும் படித்து பிரீ-ஃபில் பண்ணும். இதனால டோக்கன் பில் வேணா பேப்பர்ல குறையலாம், ஆனா கிளவுட் GPU சர்வர் ரன் ஆகுற நேரம் அதிகமாயி பில் கிடுகிடுன்னு உயரும்.

இன்னொரு பெரிய சிக்கல் என்னன்னா, ரீ-பிரீஃபில் செலவுக்கு பயந்துகிட்டு ஹிஸ்டரியை ரொம்ப கம்மியா சுருக்கிடுவாங்க. இதனால முந்தைய ஸ்டெப்ல ஏஜென்ட் என்ன பண்ணுச்சுன்னே மறந்து போய் தப்பான அவுட்புட் தர ஆரம்பிச்சிடும். டாஸ்க் அக்யூரசி (Task accuracy) படுமோசமா அடிவாங்கும்.

AKV சர்விங் என்ஜின் ஏன் ரொம்ப முக்கியம்?#

இந்த கேஷ் எஞ்சினியரிங் முறையில ஒரு பெரிய சவால் இருக்கு. அதுக்கு பேரு 'History Dependence'. ஒரே மாதிரியான டோக்கன் வரிசை இருந்தாலும், நீங்க எந்தெந்த கேஷை எப்போ டிராப் பண்ணீங்கன்ற வரலாறை பொறுத்து உள்ளே இருக்கும் கேஷ் நிலைகள் மாறும். வழக்கமான சர்வர்களில் உள்ள Prefix Matching முறை இதுக்கு செட் ஆகாது.

இந்த சவாலை சமாளிக்க தான் ஆராய்ச்சியாளர்கள் AKV என்ற சர்விங் என்ஜினை இணைத்து உருவாக்கியிருக்காங்க. வெளி உலகத்துக்கு இது ஒரு சாதாரண ஸ்டேட்லெஸ் (Stateless) API போல இயங்கும். நாம இப்போ வழக்கமா பயன்படுத்துற சர்விங் API-களோடு அப்படியே பொருந்தும். ஆனா உள்ளுக்குள்ள அதுவே புத்திசாலித்தனமா கேஷ் ரீயூஸ், எவிக்ஷன் (Eviction), மற்றும் ரீஸ்டோரேஷன் வேலைகளை கவனிச்சுக்கும். அவங்களுடைய சோதனையில், டூல்-ரெஸ்பான்ஸ் ரோலிங்-டிராப் (Tool-response rolling-drop) பாலிசியை பயன்படுத்திய போது நல்ல முன்னேற்றம் தெரிஞ்சதா சொல்றாங்க.

நீங்க இப்போ உங்க AI Project-ல என்ன பண்ணணும்?#

சரி, இதையெல்லாம் படிச்சிட்டு உடனே இன்னைக்கே உங்க ஆபீஸ் புரொடக்ஷன் கோட்ல இத மாத்த முடியுமான்னு கேட்டா, அவசரப்படாதீங்க. இது இப்போதைக்கு ஒரு ஆரம்பகட்ட ஆராய்ச்சி மட்டுமே. இந்த ஆய்வுக் கட்டுரையை Tsinghua-NICS-EFC குழுவினர் வெளியிட்டுருக்காங்க. இதுபற்றிய முழு விவரங்களை அதிகாரப்பூர்வ பேப்பர் பக்கமான https://huggingface.co/papers/2610.28577 தளத்தில் பார்க்கலாம்.

அவங்களோட கோட் GitHub-ல (thu-nics/AKV) கிடைக்குது. நீங்க சொந்தமா vLLM, SGLang போன்ற சர்விங் என்ஜின்களை கஸ்டமைஸ் பண்ணி இயக்கும் அனுபவம் உள்ள சீனியர் டெவலப்பரா இருந்தா, இந்த ரெப்போவை எடுத்து டெஸ்ட் பண்ணி பார்க்கலாம். ஆனால் AWS, Azure அல்லது வழக்கமான கிளவுட் API வழியா ஏஜென்ட் ஓட்டும் சாதாரண டெவலப்பர்கள் இந்த டெக்னாலஜி மெயின்ஸ்ட்ரீம் டூல்களில் எப்போது சேருதுன்னு உன்னிப்பா கவனிக்கலாம்.

எதிர்காலத்துல ஏஜென்ட்களுக்கான காஸ்ட் ஆப்டிமைசேஷன் என்பது வெறும் பிராம்ப்ட் சுருக்குவதோடு நிக்காது; கேஷை எப்படி துல்லியமா மேனேஜ் பண்றோம் என்பதிலும் அடங்கியிருக்கு என்பதை இந்த ஆராய்ச்சி தெளிவா காட்டுது.

நம்ம ஊர் Startup-களுக்கு இதனால என்ன நிஜமான லாபம்?#

உதாரணமா, நம்ம ஊர்ல ஒரு ஈ-காமர்ஸ் சப்போர்ட் ஏஜென்ட் அல்லது லோக்கல் டிராவல் புக்கிங் பாட் ஒன்னை நீங்க உருவாக்குறீங்கன்னு வச்சுப்போம். கஸ்டமர் வந்து 'நேத்து போட்ட ஆர்டர் எங்க இருக்கு?'ன்னு கேட்கிறார். ஏஜென்ட் உடனே டேட்டாபேஸ் API-ஐ கூப்பிடுது, கஸ்டமரோட அட்ரஸ் வாங்குது, பேமெண்ட் ஸ்டேட்டஸை செக் பண்ணுது, கூரியர் பார்ட்னர் API-க்கு போய் பார்சல் லொகேஷனை தேடுது. இப்படி ஒவ்வொரு முறை புது டூல் கால் பண்ணும் போதும், பெருசான ஒரு JSON ரெஸ்பான்ஸ் மெமரிக்குள்ள வந்து விழும். இந்த மாதிரி பத்து கஸ்டமர்கள் தொடர்ந்து பேசினாலே கிளவுட் சர்வரோட KV Cache தாங்க முடியாம தத்தளிக்கும்.

இப்போ இருக்கிற முறையில, பில் எகிறாம இருக்க டெவலப்பர்கள் என்ன பண்ணுவாங்கன்னா, பழைய டூல் அவுட்புட் மொத்தத்தையும் ட்ரிம் பண்ணிடுவாங்க. ஆனா அடுத்த நிமிஷமே அந்த கஸ்டமர் 'அப்போ கூரியர் எந்த ஊர்ல இருக்குன்னு சொன்னீங்க?'ன்னு திரும்ப கேட்டா, மாடலுக்கு ஒண்ணுமே புரியாது. ஏன்னா அது பழைய கேஷை இழந்துட்டு, மொத்த பிராம்ப்ட்டையும் முதல்ல இருந்து Re-prefill பண்ண முற்படும் போது சிஸ்டம் லேட்டன்சி அதிகமாகி கஸ்டமர் கடுப்பாகிடுவார். அதேநேரம் Cache Engineering முறையை பயன்படுத்தினா, அந்த குறிப்பிட்ட டூல் டேட்டாவை மட்டும் தேவைக்கு ஏற்ப drop மற்றும் repos பண்ணிக்க முடியும் என்பதால் சர்வர் மெமரியும் மிச்சமாகும், ரெஸ்பான்ஸ் வேகமும் குறையாது.

அடுத்ததா AI கத்துக்கிற மாணவர்கள் என்ன கவனிக்கணும்?#

பொதுவா காலேஜ் படிக்கிற பசங்களும், இப்பதான் AI துறைக்குள்ள நுழையுற ஜூனியர் இன்ஜினியர்களும் வெறும் பிராம்ப்ட் எழுத கத்துக்கிட்டா மட்டும் போதும்னு நினைக்கிறாங்க. ஒரு சிம்பிள் சிஸ்டம் பிராம்ப்ட் மாத்தி மாத்தி எழுதுறதோட நம்ம வேலை முடிஞ்சு போயிடுதுன்னு தப்பு கணக்கு போடுறாங்க. ஆனா நிஜமான இண்டஸ்ட்ரி உலகம் இப்போ மெமரி மற்றும் GPU இன்ஃப்ராஸ்ட்ரக்சர் மேனேஜ்மென்ட் பக்கம்தான் வேகமாக நகருது. இன்டர்வியூக்கள்ல கூட வெறும் 'LangChain எப்படி யூஸ் பண்ணுவீங்க?'ன்னு கேட்காம, 'லார்ஜ் கான்டெக்ஸ்ட் ஏஜென்ட் ரன் பண்ணும் போது KV Cache சைஸை எப்படி கண்ட்ரோல் பண்ணுவீங்க?'ன்னு ஆழமான கேள்விகள் கேட்க ஆரம்பிச்சிட்டாங்க.

அதனால AI ஃபீல்டுல லாங்-டெர்ம் கேரியர் தேடுறவங்க, வெறும் API கால் பண்ற வேலையை மட்டும் பார்க்காம, இந்த மாதிரி vLLM, SGLang, மற்றும் இந்த ஆராய்ச்சியில் வந்திருக்கும் AKV போன்ற சர்விங் என்ஜின்கள் பேக்-எண்ட்ல எப்படி இயங்குதுன்னு கத்துக்க ஆரம்பிக்கணும். டிரான்ஸ்பார்மர் மாடல்களில் KV Cache I/O மற்றும் அட்டென்ஷன் மேட்ரிக்ஸ் கணக்கீடுகள் எப்படி நடக்குதுன்னு புரிஞ்சிக்கிட்டா தான், நாள பின்ன ஒரு பெரிய ஸ்டார்ட்-அப்ல கிளவுட் காஸ்ட்டை குறைக்கிற ரியல்-வேர்ல்ட் இன்ஜினியரா உங்களால ஜெயிக்க முடியும். இந்த திசையில வர்ற புது ஓபன் சோர்ஸ் முயற்சிகளை தொடர்ந்து கவனிச்சிட்டு வாங்க.