Google’s Gemma-4 31B மாடலை AWS Inferentia2 inf2.24xlarge-க்கு மாற்றியபோது, CPU reference உடன் ஒவ்வொரு டோக்கனும் (token) சரியாகப் பொருந்தியது—இருப்பினும் உருவாக்கப்பட்ட ஒவ்வொரு வாக்கியமும் அர்த்தமற்றதாக (gibberish) இருந்தது. "பொருந்துதல்" (matching) மற்றும் "செயல்படுதல்" (working) ஆகியவற்றிற்கு இடையிலான இந்த இடைவெளி, அமேசானின் பிரத்யேக inference சிப்களில் (custom inference chips) பிரம்மாண்டமான LLM-களைப் பயன்படுத்த முயற்சிப்பவர்களுக்கு ஒரு எச்சரிக்கையாக அமைகிறது.

டோக்கன் வாரியாகப் பொருந்துவது மட்டும் ஏன் போதுமானதல்ல

டெவலப்பர், Inferentia சாதனத்திலிருந்து பெறப்பட்ட ஒவ்வொரு அவுட்புட் டோக்கனையும், மாடலின் CPU ரன்னால் உருவாக்கப்பட்ட டோக்கனுடன் ஒப்பிட்டார். அந்தத் தரவுத் தொடர்கள் (streams) ஒரே மாதிரியாக இருந்ததால், வன்பொருள் (hardware) அந்த reference implementation-ஐ அப்படியே பிரதிபலிப்பதாகத் தோன்றியது. ஆனால் உண்மையில், இரண்டு தொடர்களும் மாடலுக்குத் தவறான முறையில் வடிவமைக்கப்பட்ட (malformed) ப்ராம்ப்ட்டை வழங்கின; மேலும் மாடலின் chat template நீக்கப்பட்டு, தவறான turn markers வழங்கப்பட்டிருந்தன. அந்த template இல்லாததால், மாடல் ஒரு முடிவில்லாத சுழற்சிக்குள் (infinite loop) சிக்கி, அர்த்தமற்றத் தகவல்களைத் தள்ளியது. வன்பொருள் தனது வேலையைச் சரியாகச் செய்தது—reference code-இல் இருந்த ஒரு பிழையை (bug) அது அப்படியே பிரதிபலித்தது.

பாடம் எளிமையானது: SEQ_MATCH (வரிசைமுறை டோக்கன் சமநிலை) என்பது சரியானத் தன்மையைக் (correctness) குறிக்காது. ஒருவேளை reference implementation தவறாக இருந்தால், வன்பொருளின் துல்லியமான நகலும் அதே தோல்வியையே பெறும். சரிபார்ப்பு (Validation) என்பது டோக்கன் அளவிலான ஒற்றுமையைத் தாண்டி, சரியாக வடிவமைக்கப்பட்ட இன்புட்களுடன் கூடிய end-to-end செயல்பாட்டுச் சோதனைகளை (functional checks) மேற்கொள்ள வேண்டும்.

பாராமீட்டர்களாகத் தோற்றமளிக்கும் பஃபர்கள் (Buffers)

லோட் செய்யும் போது (load phase), மாடல் லோடர் layer_scalar எனப்படும் ஒரு கூறுகளைத் தவிர்த்தது. PyTorch மாடல் வரையறையில் (definition), இந்த ஆப்ஜெக்ட் ஒரு parameter-ஆகக் கருதப்படாமல் ஒரு buffer-ஆகப் பதிவு செய்யப்பட்டிருந்தது. பஃபர்கள் என்பவை நிலையான டென்சர்கள் (static tensors), பயிற்சியின் போது (training) இவை மாற்றப்படுவதில்லை; எனவே பல லோடர்கள் இவற்றை Neuron-க்கு ஏற்ற வடிவங்களாக மாற்றும்போது புறக்கணித்துவிடுகின்றன. இதைத் தவிர்த்ததால், பல அடுக்குகளுக்கான (layers) ஸ்கேலிங் காரணிகள் (scaling factors) அவற்றின் இயல்பு நிலைகளிலேயே (defaults) இருந்தன, இது முழு நெட்வொர்க்கிலும் கணிதத் தவறுகளை ஏற்படுத்தியது. எந்தத் தவறுச் செய்தியும் (error) காட்டப்படவில்லை; மாடல் கம்பைல் (compile) ஆனது, inference pipeline-உம் இயங்கியது, ஆனால் அதன் எண்முறை முடிவுகள் (numerical results) தவறாக இருந்தன.

Inferentia-விற்குப் பெரிய மாடல்களை மாற்றும் எவரும், பாராமீட்டர் அல்லாத ஒவ்வொரு டென்சரையும் (non-parameter tensor) ஆய்வு செய்ய வேண்டும். ஒரு டென்சர் கற்றலுக்காக (learning) வடிவமைக்கப்படவில்லை என்றாலும், அது சரியான forward-pass கணக்கீட்டிற்கு அவசியமானதாக இருக்கலாம். பஃபர்கள் சேர்க்கப்பட்டுள்ளதா என்பதைத் தனிப்பட்ட முறையில் சரிபார்ப்பது, கண்டறிவதற்கு கடினமான அமைதியான அளவீட்டுப் பிழைகளைத் (silent scale errors) தவிர்க்க உதவும்.

ஸ்பாட்-இன்ஸ்டன்ஸ் ஏற்ற இறக்கங்களும் 39 நிமிட கம்பைல் நேரமும்

ஒரு ஸ்பாட் இன்ஸ்டன்ஸில் (spot instance) 31-பில்லியன் பாராமீட்டர் கொண்ட மாடலை இயக்குவது மலிவாகத் தோன்றலாம், ஆனால் அந்தச் சேமிப்பு கணிக்க முடியாத ரீகிளைம் நிகழ்வுகளுடன் (reclaim events) வருகிறது. மாடலை Neuron-க்கு ஏற்ற குறியீடாக மாற்ற எடுத்துக்கொண்ட டெவலப்பரின் 39 நிமிட கம்பைல் நேரம், AWS அந்த இன்ஸ்டன்ஸை திரும்பப் பெற்றபோது (reclaimed) வீணானது. இடையூறுகளைத் தாங்குவதற்கு அவர் மூன்று அடுக்கு பாதுகாப்பு வலையமைப்பை உருவாக்கினார்:

  • ModelBuilder மெமரி பயன்பாட்டை 384 GB ஹோஸ்ட் வரம்பிற்குள் வைத்திருந்தது, இது ரீஸ்டார்ட் செய்ய வேண்டிய கட்டாயத்தை ஏற்படுத்தும் கிராஷ்களைத் (crashes) தவிர்த்தது.
  • மூல வெயிட் கோப்புகள் (raw weight files) மற்றும் கம்பைல் செய்யப்பட்ட “neffs” (Neuron executable files) ஆகிய இரண்டையும் உடனடியாக S3-இல் பிரதிபலிப்பதன் (mirroring) மூலம், ஒரு புதிய இன்ஸ்டன்ஸ் முந்தைய இன்ஸ்டன்ஸ் விட்ட இடத்திலிருந்தே தொடர முடிந்தது.
  • ஒரு multi-region poller, கிடைக்கும் ஸ்பாட் கொள்ளளவிற்காக AWS ரீஜன்களை ஸ்கேன் செய்து, ஒரு இன்ஸ்டன்ஸ் கிடைத்தவுடன் புதிய ஒன்றை இயக்கியது.

இந்த நடவடிக்கைகள், ஒரு நிலையற்ற, ஒற்றைப் புள்ளியில் தங்கியிருக்கும் கம்பைல் முறையை, ஸ்பாட் சந்தையின் மாற்றங்களைத் தாங்கி நிற்கும் ஒரு நெகிழ்வான (resilient) குழாயாக (pipeline) மாற்றின.

கலப்பு அட்டென்ஷன் லேஅவுட்களுடன் கூடிய ஷார்டிங் சிக்கல்கள்

Gemma-4 31B இரண்டு அட்டென்ஷன் கட்டமைப்புகளைப் (attention configurations) பயன்படுத்துகிறது. சில அடுக்குகளில் நான்கு key-value (KV) ஹெட்கள் (heads) உள்ளன, மற்றவற்றில் வேறு எண்ணிக்கையில் உள்ளன. ஒரு அடுக்கின் KV ஹெட் எண்ணிக்கை சரியாகப் பிரிக்க முடியாதபோது, மாடலை எட்டு இணையான ரேங்க்குகளாக (parallel ranks) சமமாகப் பிரிப்பது தோல்வியடையும். 4-ஹெட் கொண்ட ஒரு அடுக்கை எட்டு ரேங்க்குகளாகப் பிரிக்க முயலும்போது, ஒவ்வொரு ரேங்க்கும் ஒரு ஹெட்டின் பாதியை கையாள வேண்டியிருக்கும்—இது ஒரு கணித ரீதியான சாத்தியமற்ற செயல், இது shape mismatches மற்றும் runtime errors-களைத் தூண்டும்.

இதற்கான தீர்வு, உலகளாவிய ரீதியில் ஷார்ட் செய்யப்பட்ட அடுக்குகளை (globally-sharded layers - அதாவது பொருந்தக்கூடிய ஹெட் எண்ணிக்கையைக் கொண்டவை) அனைத்து ரேங்க்குகளிலும் நகலெடுத்து (replicate), ஹெட் எண்ணிக்கையைச் சரியாகப் பிரிக்கக்கூடிய “sliding” அடுக்குகளை மட்டும் ஷார்ட் செய்வதுதான். இந்த ஹைப்ரிட் உத்தி (hybrid strategy), KV ஹெட்களின் சட்டவிரோதப் பிரிவைத் தவிர்த்து, டென்சர்-பேரலல் செயல்திறனை (tensor-parallel efficiency) தக்கவைத்ததுடன், முந்தைய முயற்சிகளில் சிக்கலை ஏற்படுத்திய டென்சர்-பேரலலைசேஷன் பிழைகளையும் நீக்கியது.

முடிவுரை

ஒரு பிரம்மாண்டமான LLM-ஐ Inferentia-விற்கு மாற்றுவது என்பது வெறும் கம்பைல் செய்து இயக்குவது மட்டுமல்ல. இது டோக்கன் சமநிலையைத் தாண்டி கடுமையான செயல்பாட்டுச் சோதனைகளையும் (functional testing), ஒவ்வொரு டென்சரும்—பாராமீட்டர் அல்லது பஃபர்—சரியாகக் கையாளப்படுகிறதா என்ற நுணுக்கமான சரிபார்ப்பையும், ஸ்பாட்-இன்ஸ்டன்ஸ் ரீகிளைம் நிகழ்வுகளைக் கணக்கில் கொண்ட ஒரு வரிசைப்படுத்தல் உத்தியையும் (deployment strategy) கோருகிறது. இறுதியாக, ஷார்டிங் (sharding) மாடலின் உள் அட்டென்ஷன் வடிவியலை (attention geometry) மதிக்க வேண்டும்; இல்லையெனில், வேகத்தை உறுதி செய்யும் பேரலலிசம் (parallelism), அமைதியான தோல்வியின் ஆதாரமாக மாறிவிடும்.