CUDA Graphs, Reasoning Models மற்றும் Disaggregated Serving - நவீன AI Infrastructure-இன் எல்லைகள்

நவீன AI உள்கட்டமைப்பு (infrastructure), CPU மேல்சுமையை நீக்கல் (CPU-overhead elimination), inference-நேர reasoning சுழற்சிகள் (inference-time reasoning loops), மற்றும் கட்டம் சார்ந்த GPU cluster திசைவியாக்கம் (phase-specialized cluster routing) ஆகிய மூன்றின் வழியே சிலிக்கானினதும் cluster-களினதும் இயற்கை எல்லைகள் வரை செயல்திறனைத் தள்ளுகிறது. இம்மூன்று நுட்பங்களே இன்றைய மிக வேகமான, மிகப் புத்திசாலி உற்பத்தி (production) AI அமைப்புகளை இயக்குகின்றன.

1. CUDA Graphs மற்றும் Kernel Fusion: CPU & Memory மேல்சுமையை நீக்கல்

H100, B200 போன்ற நவீன GPU-கள் பன்மடங்கு வேகமாக வளர்ந்திருப்பதால், ஒரு இலகுரக GPU kernel-ஐ இயக்க வெறும் 2 முதல் 5 microsecond-களே ஆகும். ஆனால் அந்த kernel-ஐ PCIe driver வழியே தயார்படுத்தி, சரிபார்த்து, தொடங்குவதற்கே (launch) CPU பெரும்பாலும் 10 முதல் 20 microsecond-கள் எடுக்கும் — இதனால் பல மில்லியன் டாலர் பெறுமதியான GPU, CPU அறிவுறுத்தல்களுக்காகக் காத்திருந்து முற்றிலும் செயலற்ற நிலையில் கிடக்கும்.

• Kernel Fusion (நினைவகத்தையும் Launch-களையும் சேமிக்கச் செயல்பாடுகளை இணைத்தல்).

• Fusion இல்லாத நெருக்கடி (Bottleneck). ஒரு சாதாரண Transformer layer டஜன் கணக்கான சிறிய செயல்பாடுகளை ஒன்றன் பின் ஒன்றாக இயக்குகிறது (எ.கா., LayerNorm → Linear → Add Residual → GeLU). Fusion இல்லாவிட்டால், GPU ஒவ்வொரு படிக்கும் தனித்தனி kernel-களை launch செய்கிறது; இடைநிலை tensor-களை மெதுவான HBM (VRAM)-இல் எழுதி, அடுத்த படிக்காக அவற்றை உடனே மீண்டும் உள்வாங்குகிறது.
• இணைக்கப்பட்ட இயக்கம் (Fused Execution). torch.compile (TorchInductor), TensorRT-LLM போன்ற compiler-கள் பல element-wise மற்றும் reduction செயல்பாடுகளை ஒரே தனிப்பயன் CUDA/Triton kernel-ஆக இணைக்கின்றன. பெறுமானங்கள் HBM-இலிருந்து ஒரே ஒரு முறை ஏற்றப்பட்டு, அதிவேக on-chip register/SRAM-க்குள் உருமாற்றம் செய்யப்பட்டு, மிக இறுதியில் மட்டுமே HBM-இல் மீளெழுதப்படுகின்றன — இது memory bandwidth போக்குவரத்தையும் kernel launch எண்ணிக்கையையும் கணிசமாகக் குறைக்கிறது.

• CUDA Graphs (முழு Execution Pipeline-ஐயும் ஒரே முறையில் மீளிசைத்தல்).

• பதிவு செய்து மீளிசைத்தல் (Record and Replay). Kernel fusion-க்குப் பின்னரும், உருவாக்கப்படும் ஒவ்வொரு token-க்கும் ஒரு LLM forward pass நூற்றுக்கணக்கான kernel launch-களைத் தேவைப்படுத்துகிறது. CUDA Graphs இதைத் தீர்க்கின்றன: warmup இயக்கத்தின் போது GPU செயல்பாடுகளின் முழுத் தொடரையும் — kernel-கள், memory நகல்கள் (copies), சார்புகள் (dependencies) — பதிவு செய்து (capture), அவற்றை GPU நினைவகத்திலேயே சேமிக்கப்படும் ஒரு நிலையான execution graph-ஆகத் தொகுக்கின்றன.
• CPU தலையீடு பூச்சியம் (Zero CPU Intervention). நேரடி inference-இன் போது, CPU 300 தனித்தனி kernel-களை ஒவ்வொன்றாக launch செய்வதற்குப் பதிலாக, ஒரே ஒரு API அழைப்பை (cudaGraphLaunch) மட்டுமே வெளியிடுகிறது; அது GPU-இல் முழு forward pass-ஐயும் தன்னிச்சையாகத் தொடங்கிவிடுகிறது.
• மாறும் வடிவங்களைக் கையாளுதல் (Handling Dynamic Shapes). CUDA Graphs நிலையான memory முகவரிகளையும் tensor வடிவங்களையும் (shapes) தேவைப்படுத்துவதால், inference engine-கள் வரும் batch-களை நிலையான bucket அளவுகளுக்கு (எ.கா., batch sizes 1, 2, 4, 8, 16) நிரப்பி (pad), முன்பதிவு செய்யப்பட்ட graph-ஐ மீளிசைக்கும் முன் input pointer-களை அதே இடத்தில் புதுப்பிக்கின்றன.

2. Test-Time Compute & Reasoning Models (o1/o3 & DeepSeek-R1)

வரலாற்றில், AI ஆய்வகங்கள் புத்திசாலித்தனத்தை அதிகரிக்க pre-training-இல் (அதிக இணைய உரையில் பயிற்சி பெற்ற பெரிய model-கள்) மேலும் மேலும் அதிக compute-ஐ மட்டுமே பயன்படுத்தின. OpenAI-இன் o1/o3, DeepSeek-R1 போன்ற reasoning model-கள் இரண்டாவது scaling அச்சை திறந்துவிட்டன: Test-Time Compute (Inference-Time Scaling) — பதில் சொல்வதற்கு முன் model-கள் நீண்ட நேரம் "சிந்திக்க" இது வழிவகுக்கிறது.

• Chain-of-Thought (CoT)-க்கான Reinforcement Learning.

• படிப்படியான reasoning-இன் மனிதர் எழுதிய எடுத்துக்காட்டுகளை மட்டும் நம்பியிராமல், இம்மாதிரிகள் கணிதம், coding, முறையியல் தர்க்கம் (formal logic) போன்ற சரிபார்க்கக்கூடிய துறைகளில் பெருந்தொகை Reinforcement Learning (RL) மூலம் (DeepSeek-R1-இல் GRPO – Group Relative Policy Optimization போன்றவை) பயிற்சி பெறுகின்றன.
• Model பல சாத்தியமான reasoning பாதைகளை உருவாக்கி, அதன் இறுதிப் பதில் unit test-கள் அல்லது கணிதச் சரிபார்ப்பில் தேர்ச்சி பெறும்போது மட்டுமே புறநிலை வெகுமதிகளைப் (objective rewards) பெறுகிறது; மேலும் தானாகவே தோன்றும் அறிவாற்றல் நடத்தைகளை — தன்னைத்தானே சரிபார்த்தல் (self-verification), முடிவில்லாத பாதையை அடையும்போது பின்வாங்குதல் (backtracking), சிக்கலான பிரச்சினைகளைத் துணை இலக்குகளாகப் (sub-goals) பிரித்தல் ஆகியவற்றை — தன்னிச்சையாகக் கண்டறிந்து கொள்கிறது.

• Inference Compute எவ்வாறு அளவிடப்படுகிறது (Scales).

• கடினமான prompt கொடுக்கப்படும்போது, model இறுதிப் பதிலை வெளியிடுவதற்கு முன் மறைந்திருக்கும் scratchpad-இல் ஆயிரக்கணக்கான உள் "thinking token"-களை உருவாக்குகிறது. Model கருதுகோள்களை (hypotheses) ஆராய அதிக inference token-களைச் செலவிடச் செலவிட, துல்லியம் logarithmic விகிதத்தில் மேம்படுகிறது.
• Compute சமரச மாற்றம் (Compute Trade-Off Shift). பாரம்பரிய LLM-களில் inference மலிவானதும் வேகமானதும் (~50 output token-கள் உருவாக்கம்). Reasoning model-களில் ஒரே ஒரு query 10,000 முதல் 50,000 thinking token-களை உருவாக்கலாம்; இது inference-ஐ KV-cache வளர்ச்சியும் நீண்ட-context attention திறனும் ஆதிக்கம் செலுத்தும் ஒரு பாரிய, தொடர்ச்சியான batch-generation பணிச்சுமையாக மாற்றிவிடுகிறது.

3. பிரிக்கப்பட்ட Prefill மற்றும் Decode (Disaggregated Prefill and Decode)

ஒரு LLM-ஐ வழங்குதல் (serving) அடிப்படையில் எதிரெதிரான இரண்டு கணினியியல் கட்டங்களைக் (phases) கொண்டது. இரு கட்டங்களையும் ஒரே GPU-இல் இயக்கினால் கடுமையான scheduling முரண்பாடுகளும் hardware குறைபயன்பாடும் ஏற்படுகின்றன.

• ஒரே இடத்தில் அமைத்தலால் ஏற்படும் குறுக்கீட்டுப் பிரச்சினை (Co-Location Interference Problem).

• பாரம்பரிய ஒருங்கிணைந்த serving-இல், 50 பயனாளர்கள் Decode token-களை stream செய்துகொண்டிருக்கும்போது மற்றொரு பயனாளர் 32,000-token பாரிய ஆவணத்தை Prefill-க்கு சமர்ப்பித்தால், அந்தப் பாரிய prefill matrix கணிதம் GPU-இன் Tensor Core-களை முழுவதுமாகப் பிடித்துவிடும் — stream செய்யும் 50 பயனாளர்களுக்கும் தெரியத்தக்க உறைதல்களும் (freezes) latency உச்சங்களும் ("stuttering") ஏற்படும்.
• மேலும், Prefill-க்கு அதிக compute FLOPs தேவை; அதேசமயம் Decode-க்கு பாரிய batch KV cache-களைத் தாங்க பெருத்த HBM memory bandwidth-ம் கொள்ளளவும் தேவை.

• Cluster-ஐப் பிரித்தல் (Disaggregated Architecture).

• நவீன hyperscale inference அமைப்புகள் (Mooncake, DistServe, NVIDIA Dynamo போன்றவை) GPU cluster-ஐ இரண்டு அர்ப்பணிக்கப்பட்ட pool-களாகப் பிரிக்கின்றன:
• 1. Prefill Pool: நீண்ட prompt-களை வேகமாகச் செயாக்கி தீவிர Time-To-First-Token (TTFT) இலக்குகளை அடைய, தூய compute throughput-க்கு மேம்படுத்தப்பட்டது (உயர் Tensor Core பயன்பாடு, குறைந்த tensor parallelism).
• 2. Decode Pool: உச்ச tokens-per-second-இல் token-களை சீராக stream செய்ய, உயர் memory bandwidth-க்கும் பாரிய KV-cache கொள்ளளவுக்கும் மேம்படுத்தப்பட்டது (அகலமான tensor/expert parallelism, பெரிய batch அளவுகள்).
• அதிவேக KV Cache இடமாற்றம். ஒரு Prefill GPU prompt செயாக்கத்தை முடித்து ஆரம்ப KV Cache-ஐ உருவாக்கியதும், அந்த KV Cache-ஐ அதிவேக NVLink அல்லது InfiniBand RDMA interconnect-கள் வழியே நேரடியாக ஒரு Decode GPU-இன் VRAM-க்குள் stream செய்கிறது; அந்த Decode GPU எந்தக் குறுக்கீடுமின்றி உடனே token உருவாக்கத்தை ஏற்றுக்கொள்கிறது.