The Two Week Deluge That Changed the Game

விளையாட்டின் போக்கையே மாற்றியமைத்த அந்த இரண்டு வார வெள்ளம்

ஜூலை 1 மற்றும் ஜூலை 16, 2026 ஆகிய காலப்பகுதியில், AI சூழல் மாறியது. அது படிப்படியாக அல்ல, ஒரே அடியாக நிகழ்ந்தது.

Anthropic நிறுவனம் Claude Fable 5-ஐ உலகளாவிய சந்தைக்குக் கொண்டு வந்தது. SpaceXAI நிறுவனம் Grok 4.5-ஐ வெளியிட்டது. OpenAI நிறுவனம் GPT-5.6 குடும்பத்தைச் சேர்ந்த Sol, Terra மற்றும் Luna ஆகியவற்றை அறிமுகப்படுத்தி, உருவாக்குநர்களுக்கு ஒரே குடையின் கீழ் மூன்று புதிய விருப்பங்களை வழங்கியது. Meta நிறுவனம் தனது வணிக ரீதியான API மூலம் Muse Spark 1.1-ஐத் திறந்தது. மேலும் Moonshot AI நிறுவனம் Kimi K3-ஐ வெளியிட்டது.

ஐந்து முன்னணி மாதிரிகள் (frontier models). பதினாறு நாட்கள். இது ஒரு தயாரிப்பு சுழற்சி (product cycle) அல்ல. இது ஒரு வெள்ளம் போன்ற தொடர்ச்சி.

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

மாடல் போர்களிலிருந்து பிளாட்ஃபார்ம் போர்களுக்கு

நாம் தனி ஆதிக்கம் செலுத்தும் யுகத்தைக் கடந்துவிட்டோம். பல ஆண்டுகளாக, ஒரு முறை ஒரு ஆய்வகம் ஒரு புரட்சிகரமான கண்டுபிடிப்பை வெளியிட்டால், மற்றவை அதனுடன் போட்டியிடப் போராடும், அந்தத் தலைவன் பல மாதங்கள் சந்தையைத் தன் வசம் வைத்திருப்பார். ஆனால் அந்த மாதங்கள் இப்போது நாட்களாகச் சுருங்கிவிட்டன.

ஒரே பதினைந்து நாட்களில் ஐந்து உண்மையான திறன் கொண்ட மாதிரிகள் சந்தைக்கு வரும்போது, முதல் மற்றும் ஐந்தாவது இடத்திற்கு இடையிலான இடைவெளி மிகச் சிறியதாகிவிடுகிறது. திறன் (Capability) என்பது இனி ஒரு வேறுபடுத்திக் காட்டும் காரணியாக இருக்காது. போர்க்களம் இப்போது தொழில்நுட்ப அடுக்குகளுக்கு (stack) மாறியுள்ளது. நாம் 'மாடல் போர்களிலிருந்து' (Model Wars) 'பிளாட்ஃபார்ம் போர்களுக்கு' (Platform Wars) மாறுவதை நேரில் காண்கிறோம்.

இது நடைமுறையில் என்ன சொல்கிறது என்று யோசித்துப் பாருங்கள். உங்கள் பெஞ்ச்மார்க்கில் GPT-5.6 Terra மற்றும் Grok 4.5 ஆகிய இரண்டும் மிக நெருக்கமான மதிப்பெண்களைப் பெற்றால், வெற்றியாளரைத் தீர்மானிப்பது அதன் நுண்ணறிவு அல்ல. Terra-வின் லேட்டன்சி (latency) உங்கள் நிகழ்நேர சாட் பட்ஜெட்டிற்குப் பொருந்துகிறதா அல்லது Grok-ன் Cursor ஒருங்கிணைப்பு உங்கள் குழுவின் அடிப்படை வேலைகளை (plumbing work) ஒவ்வொரு ஸ்பிரிண்டிலும் மூன்று மணிநேரம் மிச்சப்படுத்துகிறதா என்பதே தீர்மானிக்கும். ஆய்வகத்தில் உள்ள புத்திசாலித்தனமான மாடல், பெரும்பாலும் தயாரிப்பில் (production) தவறான மாடலாக இருக்கலாம்.

இப்போது உண்மையில் முக்கியமானது என்ன

செயல்திறன் சமமாகும்போது, மற்ற காரணிகள் முன்னிலை பெறுகின்றன. உங்கள் மதிப்பீட்டு அளவுகோல்கள் ஒரு ஆராய்ச்சித் தாளைப் போல இல்லாமல், ஒரு கொள்முதல் பட்டியலைப் (procurement sheet) போல இருக்க வேண்டும்.

முதலில் டோக்கன் ஒருim விலையைக் (cost per token) கவனியுங்கள். ஒரு மாடல் தர்க்கரீதியாக (reasoning) 10% சிறப்பாக இருந்து, ஆனால் பெரிய அளவில் பயன்படுத்தும்போது 3 மடங்கு அதிக செலவு ஏற்பட்டால், அது உங்கள் தயாரிப்பை மேம்படுத்துவதற்கு முன்பே உங்கள் லாபத்தை அழித்துவிடும்.

லேட்டன்சி மற்றும் வேகத்தைக் கவனியுங்கள். நீங்கள் ஒரு நேரடி கோடிங் அசிஸ்டண்ட் அல்லது நிகழ்நேர மொழிபெயர்ப்பு கருவியைப் பயன்படுத்துகிறீர்கள் என்றால், 500ms தாமதம் என்பது அந்தத் தயாரிப்பையே அழித்துவிடும். 50ms-இல் பதிலளிக்கும் சற்று குறைவான திறன் கொண்ட மாடல் பயனர்களைத் தக்கவைத்துக் கொள்ளும்.

நம்பகத்தன்மையைக் கவனியுங்கள். இயங்கும் நேரம் (Uptime guarantees), விகித வரம்புகள் (rate limits) மற்றும் நிலையான வெளியீட்டு அமைப்பு (consistent output structure) ஆகியவை கோட்பாட்டுத் திறனை விட முக்கியமானவை. ஒரு மாடல் 2% குறைவாகத் தவறான தகவல்களைத் (hallucinate) தந்தாலும், ஒவ்வொரு செவ்வாய்க்கிழமையும் செயலிழந்தால், அது உங்கள் நம்பிக்கையை இழந்துவிடும்.

கான்டெக்ஸ்ட் நீளத்தைக் (context length) கவனியுங்கள். அது உங்கள் முழுமையான கோட்பாட்டை (codebase) அல்லது உங்கள் சட்ட ஒப்பந்தத்தை அல்லது பல ஆண்டுகால நோயாளித் தரவுகளைத் தாங்கிக் கொள்ள முடியுமா? பதில் 'இல்லை' என்றால், மற்ற எதுவும் முக்கியமல்ல.

பணிப்பாய்வு ஒருங்கிணைப்பைக் (workflow integration) கவனியுங்கள். அது உங்கள் கண்காணிப்பு அமைப்பில் (observability stack) இணைகிறதா? உங்கள் தற்போதைய பிராம்ப்ட் மேலாண்மை அமைப்போடு வேலை செய்கிறதா? சிறந்த மாடல் என்பது உங்கள் பொறியாளர்கள் உண்மையில் பயன்பாட்டிற்கு கொண்டு வரும் மாடலே ஆகும்.

நுண்ணறிவு உள்கட்டமைப்பாக மாறிவருகிறது

OpenAI நிறுவனம் GPT-5.6 குடும்பத்திற்கான அடுக்கு விலை நிர்ணயம் (tiered pricing) மூலம் தயாரிப்புத் தயார்நிலையை (production readiness) நோக்கி நகர்கிறது. Meta நிறுவனம் இனி ஆராய்ச்சித் தரவிறக்கங்களுக்காக மாடல்களை இலவசமாகத் தருவதில்லை; அது வணிக ரீதியான API மூலம் உண்மையான டெவலப்பர்களின் செலவினங்களைக் குறிவைக்கிறது. SpaceXAI நிறுவனம், டெவலப்பர்கள் ஏற்கனவே பயன்படுத்தும் Cursor போன்ற கருவிகளில் Grok-ஐ இணைப்பதன் மூலம், விநியோகம் (distribution) என்பது வெறும் சிறப்பம்சங்களை விட மேலானது என்று பந்தயம் கட்டுகிறது. Moonshot AI நிறுவனம், Kimi K3 போன்ற ஓபன்-வெயிட் (open-weight) வெளியீடுகள், ஒரு பில்லியன் டாலர் மதிப்புள்ள மூடிய API இல்லாமல் கூட முன்னணிப் பட்டியலில் இருக்க முடியும் என்பதை நிரூபித்து வருகிறது.

இது உங்களுக்குப் பரிச்சயமானதாகத் தெரியலாம். கிளவுட் கம்ப்யூட்டிங்கில் (cloud compute) நாம் ஏற்கனவே இதைப் பார்த்திருக்கிறோம். AWS, Azure மற்றும் GCP ஆகிய நிறுவனங்கள் யார் வேகமான CPU வைத்திருப்பார்கள் என்பதில் வெற்றி பெறுவதில்லை. அவை கட்டணக் கணிப்புத்தன்மை (billing predictability), பிராந்தியக் கிடைப்புத்தன்மை (regional availability) மற்றும் IAM ஒருங்கிணைப்பு ஆகியவற்றின் மூலம் வெற்றி பெறுகின்றன. நுண்ணறிவும் அதே பாதையைப் பின்பற்றுகிறது. அது ஒரு பொதுவான பயன்பாட்டுப் பொருளாக (commodity utility) மாறிவருகிறது. அதன் தனித்துவமான பாதுகாப்பு அரண் (moat) மறைந்துவிட்டது.

மாற்றத்தின் மறைமுக வரி

வெளியீட்டு குறிப்புகள் (release notes) உங்களுக்குச் சொல்லாத விஷயம் இதுதான். ஒவ்வொரு மாடல் இடமாற்றமும் ஒரு மறைமுக வரியைக் (hidden tax) கொண்டுள்ளது.

நீங்கள் பிராம்ப்ட்களை (prompts) மீண்டும் எழுத வேண்டியிருக்கும். பயிற்சித் தரவு அல்லது டோக்கனைசர் நடத்தையில் ஏற்படும் சிறிய மாற்றங்கள் கூட, ஒரு பயன்பாட்டிற்குத் தயாராக இருந்த பிராம்ப்ட்டை ஒரு குழப்பமான நீளமான உரையாக மாற்றிவிடும். நீங்கள் பணிப்பாய்வுகளை மீண்டும் சோதனை செய்ய வேண்டியிருக்கும். நீங்கள் நம்பியிருந்த அந்த JSON வெளியீடு? புதிய மாடல் அதை பாதி நேரங்களில் மார்க்க்டவுனாக (markdown) மாற்றிவிடும். நீங்கள் ஒருங்கிணைப்புகளைப் புதுப்பிக்க வேண்டியிருக்கும். SDK-கள் மாறும். பிழை கையாளுதல் (Error handling) மாறும். ஆவணங்கள் (Documentation) ஒரு வாரம் தாமதமாக வரும்.

இதன் கணக்கீடு மிகக் கடுமையானது. இன்ஃபரன்ஸ் செலவுகளை (inference costs) 15% சேமிப்பதற்காக, ஐந்து பொறியாளர்கள் கொண்ட ஒரு குழு இரண்டு வாரங்கள் மாடலை இடமாற்றம் செய்ய செலவழித்தால், அவர்கள் டோக்கன்களில் ஈட்டும் லாபத்தை விட சம்பளமாகவே அதிகம் இழக்கக்கூடும். அதைவிட மோசமான விஷயம் என்னவென்றால், அந்த இரண்டு வாரங்கள் பயனர்கள் கேட்ட புதிய அம்சங்களை உருவாக்குவதற்குப் பயன்படுத்தப்படுவதில்லை. வாய்ப்புச் செலவு (Opportunity cost) பெஞ்ச்மார்க் மதிப்பெண்களை விட வேகமாகப் பெருகுகிறது.

இது அலட்சியமாக இருக்க வேண்டும் என்பதற்கான வாதம் அல்ல. இது துல்லியமான மேம்படுத்தல்களுக்கான வாதம்.

எப்போது மாற வேண்டும்: ஒரு நடைமுறை வடிகட்டி

அடுத்த முறை ஒரு அதிநவீன மாதிரி (frontier model) வெளியாகும் போது—இந்த வேகத்தில் பார்த்தால், அது அடுத்த செவ்வாய்க்கிழமையே நடக்கலாம்—உங்கள் குறியீட்டுத் தொகுப்பை (codebase) மாற்றும் முன், நான்கு கேள்விகளைக் கேட்டுப் பாருங்கள்.

முதலாவதாக, உங்கள் தற்போதைய மாதிரி உண்மையிலேயே தீர்க்க முடியாத ஒரு சிக்கலை இது தீர்க்கிறதா? இது ஒரு தத்துவார்த்தமான சிக்கலாக இருக்கக்கூடாது. பயனர்கள் எதிர்கொள்ளும் ஒரு உண்மையான தடையாக இருக்க வேண்டும். உங்கள் வாடிக்கையாளர்கள் தர்க்கரீதியான ஆழத்தைப் (reasoning depth) பற்றிப் புகார் இல்லை என்றால், தர்க்கரீதியான மேம்படுத்தல் என்பது வெறும் காட்சிப்படைப்பு மட்டுமே.

இரண்டாவதாக, இது செலவை கணிசமாகக் குறைக்கிறதா அல்லது செயல்திறனை அதிகரிக்கிறதா? "கணிசமாக" என்பது, ஒரு காலாண்டிற்குள்ளேயே அந்த மாற்றத்திற்கான செலவை ஈடுகட்ட வேண்டும் என்பதாகும். அதற்கு மேல் எடுக்கும் காலம், பதினாறு நாட்களில் மீண்டும் மாறக்கூடிய ஒரு சந்தையின் மீதான வெறும் ஊகம் மட்டுமே.

மூன்றாவதாக, இது உங்கள் தற்போதைய பணிப்பாய்விற்கு (workflow) பொருந்துகிறதா? இதற்கு ஒரு புதிய இன்ஃபரன்ஸ் வழங்குநர் (inference provider), ஒரு தனிப்பயனாக்கப்பட்ட ப்ராக்ஸி (custom proxy) மற்றும் உங்கள் மதிப்பீட்டு வழிமுறையை (evaluation pipeline) மீண்டும் எழுத வேண்டியிருந்தால், அந்த மாதிரி ஒரு எளிதான மேம்படுத்தல் அல்ல. அது ஒரு பக்கத் திட்டம் (side project) மட்டுமே.

நான்காவதாக, மற்றும் மிக முக்கியமானது: இந்த மாற்றத்திற்கான செலவு, அதிலிருந்து கிடைக்கும் லாபத்தை விடக் குறைவாக இருக்குமா? பொறியியல் நேரத்தைப் (engineering hours) பொறுத்தவரை நேர்மையாக இருங்கள். சோதனை (testing), கண்காணிப்பு (monitoring) மற்றும் தவிர்க்க முடியாத பழைய நிலைக்குத் திரும்பும் திட்டம் (rollback plan) ஆகியவற்றையும் கணக்கில் கொள்ளுங்கள். கணக்கு நஷ்டத்தைக் காட்டினால், அப்படியே இருங்கள்.

இவற்றில் எதற்காவது பதில் 'இல்லை' என்றால், அந்த அதீத எதிர்பார்ப்புகளைப் புறக்கணித்துவிடுங்கள். உங்கள் தற்போதைய தொழில்நுட்ப அடுக்கு (stack) போதுமானது.

வெளியிடுங்கள், அளவீடுகளை மட்டும் செய்யாதீர்கள்

மதிப்பீடுகளை (evaluations) நடத்துவதில் ஒருவித நிம்மதி இருக்கிறது. அது முன்னேற்றம் போலத் தோன்றும். ஆனால் அது முன்னேற்றம் அல்ல.

அளவீடுகள் (Benchmarks) என்பது ஒரு குறிப்பிட்ட நேரத்தின் நிலை மட்டுமே. உங்கள் தயாரிப்பு என்பது மாறிக்கொண்டே இருக்கும் ஒரு இலக்கு. ஜூலை மாதத்தை ஐந்து மாதிரிகளுக்கு இடையிலான நேரடி ஒப்பீடுகளைச் செய்வதிலேயே செலவிடும் குழு, ஆகஸ்ட் மாதத்தில் எதையும் வெளியிட முடியாது. அதே நேரத்தில், ஜூன் மாதத்தில் ஒரு மாதிரியைத் தேர்ந்தெடுத்து, ஜூலை மாதத்தை அதை பயனர்களிடம் கொண்டு சேர்ப்பதில் செலவிட்ட குழுவிடம், நீங்கள் அளவீடுகள் மூலம் பெற முடியாத கருத்துக்கள் (feedback) இருக்கும்.

செயல்பாட்டின் மூலம் பலன் பெருகும் (Execution compounds). ஒரு தேர்ந்தெடுக்கப்பட்ட மாதிரியை ஒருங்கிணைப்பதற்கும் (integrating), கண்காணிப்பதற்கும் (monitoring) மற்றும் மீண்டும் மீண்டும் மேம்படுத்துவதற்கும் (iterating) செலவிடப்படும் ஒவ்வொரு மணிநேரமும், எந்த ஒரு லீடர்போர்டாலும் (leaderboard) பிடிக்க முடியாத செயல்பாட்டு அறிவை (operational knowledge) உங்களுக்கு வழங்கும். உங்கள் ப்ராம்ப்ட்கள் (prompts) எங்கே தோல்வியடைகின்றன என்பதை நீங்கள் கற்றுக்கொள்வீர்கள். உங்கள் பயனர்களுக்கு உண்மையில் எங்கே உதவி தேவைப்படுகிறது என்பதை நீங்கள் கற்றுக்கொள்வீர்கள். நீங்கள் அமைப்புகளை (systems) உருவாக்குகிறீர்கள், அறிவியல் சோதனைகளை அல்ல.

இந்தத் தகவல் поток குறையப்போவதில்லை. பதினாறு நாட்களில் ஐந்து மாதிரிகள் என்பது ஒரு சிறிய மாற்றம் அல்ல. அதுவே புதிய இயல்பு நிலை. இதில் பிழைக்கப் போகும் உருவாக்குநர்கள் (builders), சிறந்த அளவீட்டுத் தாளை (benchmark spreadsheet) வைத்திருப்பவர்கள் அல்ல. மாறாக, தங்கள் தொழில்நுட்ப அடுக்குக்கு (stack) எவ்வளவு செலவாகிறது, அது எங்கே முறிந்து போகிறது மற்றும் ஒரு புதிய கருவி எப்போது மாற்றத்திற்குத் தகுதியானது என்பதைத் துல்லியமாகத் தெரிந்திருப்பவர்களே வெற்றியாளர்களாக இருப்பார்கள்.

வெளியீட்டுத் தகவல்களைத் (release feed) தொடர்ந்து பார்ப்பதை நிறுத்துங்கள். தயாரிப்புகளை வெளியிடுவதைத் தொடங்குங்கள்.