জটিল চিপ সরবরাহ বণ্টন উন্নত করতে AI ব্যবহার করছে NVIDIA

NVIDIA তাদের উৎপাদন নেটওয়ার্কজুড়ে দুষ্প্রাপ্য উপাদান বণ্টনে সহায়তার জন্য Palantir Foundry, GPU-ত্বরিত অপ্টিমাইজেশন এবং একটি open-weight ভাষা মডেল ব্যবহার করছে। NVIDIA Technical Blog-এ developer.nvidia.com-এ প্রকাশিত একটি পোস্ট অনুযায়ী, এই উদ্যোগের লক্ষ্য হলো সম্পূর্ণ সিলিকনকে কার্যকর ডেটা-সেন্টার অবকাঠামোতে রূপান্তর করতে যে সময় লাগে, তা কমানো।

NVIDIA এই ব্যবধানকে দুটি ধাপে পরিমাপ করে। প্রথমটি হলো time-to-rack—একটি চিপ ফ্যাব্রিকেশন প্ল্যান্ট থেকে বের হওয়া থেকে শুরু করে একটি সম্পূর্ণ সিস্টেম ডেটা-সেন্টারের ফ্লোরে পৌঁছানো পর্যন্ত সময়। দ্বিতীয়টি হলো time-to-token—হার্ডওয়্যার পৌঁছানোর পর শুরু হয় এবং সেটি কার্যকর কাজ করতে পারার আগে প্রয়োজনীয় বিদ্যুৎ, কুলিং, নেটওয়ার্কিং ও সফটওয়্যার প্রস্তুত করার সময়ও এর অন্তর্ভুক্ত। পোস্টে বর্ণিত প্রকল্পটি মূলত time-to-rack কমানোর ওপর কেন্দ্রীভূত।

পরিবর্তনশীল প্রতিবন্ধকতায় ভরা সরবরাহ শৃঙ্খল

চ্যালেঞ্জটির ব্যাপ্তি যথেষ্ট বড়। NVIDIA বলছে, তাদের Grace Blackwell NVL72 প্ল্যাটফর্মের জন্য বিশ্বজুড়ে লাখ লাখ উপাদান এবং হাজার হাজার সরবরাহকারীর ওপর নির্ভর করতে হয়। চূড়ান্ত সিস্টেম সংযোজনে কয়েক ডজন original equipment manufacturer এবং original design manufacturer অংশ নেয়।

এমনকি একটি মাত্র compute tray-ও অত্যন্ত জটিল। প্রতিটি র্যাকে থাকে 18টি tray, আর একটি tray-তে থাকে দুটি Grace CPU, চারটি Blackwell GPU এবং 32টি HBM3e memory stack। NVIDIA বলছে, Vera Rubin-এর জন্য তৈরি করা সরবরাহ শৃঙ্খলটি Grace Blackwell নেটওয়ার্কের দ্বিগুণ আকারের।

উপাদানের প্রাপ্যতা স্থির থাকে না। CPU, GPU এবং মেমরি—প্রতিটি আলাদা সময়ে সীমাবদ্ধতা সৃষ্টিকারী উপাদান হয়ে উঠতে পারে; যে অংশটি এক সপ্তাহ উৎপাদন বিলম্বিত করছে, পরের সপ্তাহে সেটিই সহজে পাওয়া যেতে পারে। প্রতিটি গুরুত্বপূর্ণ উপাদানের নিজস্ব bill of materials, সরবরাহকারী এবং সরবরাহের সময়সূচিও থাকে। প্রয়োজনীয় সব উপকরণ না আসা পর্যন্ত কোনো উৎপাদন সাইট সংযোজন শুরু করতে পারে না—সেগুলো সরাসরি NVIDIA থেকে, NVIDIA-র হাতে থাকা consignment stock থেকে, অথবা বাইরের সরবরাহকারীদের কাছ থেকে আসুক না কেন। ফলে কোনো একটি উপাদান অনুপস্থিত থাকলে, আগে এসে পৌঁছানো উপকরণগুলোও অব্যবহৃত অবস্থায় পড়ে থাকতে পারে এবং পুরো নির্মাণপ্রক্রিয়া আটকে যেতে পারে।

কোনো উৎপাদন স্থানে উপকরণ পৌঁছানোর পর থেকে সেগুলো sub-assembly বা সম্পূর্ণ পণ্যের অংশ হিসেবে সাইটটি ছেড়ে যাওয়া পর্যন্ত NVIDIA উপকরণগুলো কত সময় তাদের নিয়ন্ত্রণে থাকে, তা হিসাব করে। কোম্পানিটি এই পরিমাপকে Time of Ownership বা TOO বলে।

উপকরণ বণ্টন সাপ্তাহিকভাবে পর্যালোচনা করা হয় এবং এর পরিধি চলতি ত্রৈমাসিকের বাকি সময় পেরিয়ে পরবর্তী ত্রৈমাসিক পর্যন্ত বিস্তৃত। নিকট-মেয়াদের সিদ্ধান্তগুলো সাধারণত আগেই চূড়ান্ত হয়ে যায়, অর্থাৎ নতুন তথ্যের প্রভাব পরবর্তী সপ্তাহগুলোতেই সবচেয়ে বেশি পড়ে। প্রতিটি সাইটের সক্ষমতা ও capacity বিবেচনায় নিয়ে সীমিত উপকরণ কোন কোন উৎপাদন সাইট পাবে এবং কী পরিমাণে পাবে—তা নির্ধারণ করাই এই কাজের উদ্দেশ্য।

কার্যক্রমসংক্রান্ত তথ্যকে সিদ্ধান্তে রূপ দেওয়া

NVIDIA-র supply-chain operations team Palantir-এর সঙ্গে কাজ করে ওই সিদ্ধান্তগুলোর পেছনে থাকা তথ্যের একটি যৌথ চিত্র তৈরি করেছে। কোম্পানিটি ফলাফলটিকে Digital Supply Chain Intelligence command centre বলে অভিহিত করে। এটি সতর্কবার্তা, উৎপাদন-সংক্রান্ত বাধা এবং অন্যান্য সংকেত একত্র করে, যেগুলো আগে হয়তো আলাদা আলাদা সিস্টেমে ছড়িয়ে থাকত।

Palantir Foundry অন্তর্নিহিত operating environment সরবরাহ করে। এর Ontology উপকরণ, সাইট, সরবরাহকারীদের প্রতিশ্রুতি, উৎপাদন সক্ষমতা, বণ্টন এবং output-কে সংযুক্ত করে। এটি গুণগত তথ্যও গ্রহণ করতে পারে, ফলে সরবরাহ শৃঙ্খলের সম্পর্কগুলোকে বিচ্ছিন্ন table entry হিসেবে না দেখে সেগুলোর একটি নিয়ন্ত্রিত উপস্থাপনা তৈরি করা যায়।

এই কাঠামো পরিকল্পনাকারীদের বিকল্প ভবিষ্যৎ পরীক্ষা করার সুযোগ দেয়। তারা কম মেমরি পাওয়ার পরিণতি বিশ্লেষণ করতে পারেন, অথবা আরেকটি উৎপাদন সাইট উপলভ্য হলে নেটওয়ার্ক কীভাবে বদলাতে পারে তা মূল্যায়ন করতে পারেন। লক্ষ্য হলো শুধু একটি হিসাব করা উত্তর পাওয়ার বাইরে গিয়ে, সেই উত্তরের সঙ্গে জড়িত সমঝোতাগুলো বোঝা।

NVIDIA cuOpt—পোস্টে যাকে GPU-ত্বরিত decision optimization-এর জন্য একটি open-source library হিসেবে বর্ণনা করা হয়েছে—বণ্টনের হিসাব করে। এটি Ontology থেকে তথ্য নিয়ে একটি allocation recommendation ফেরত দেয়। সমস্যাটিকে একটি mixed-integer linear program হিসেবে প্রকাশ করা হয়, যার উদ্দেশ্য TOO কমানো।

সফটওয়্যারটি ফলাফল সীমিত করে এমন প্রতিবন্ধকতাগুলোও শনাক্ত করে। এর মাধ্যমে পরিকল্পনাকারীরা বুঝতে পারেন, কোনো সিদ্ধান্ত কি নির্দিষ্ট কোনো আঞ্চলিক উৎপাদন capacity, মেমরির প্রাপ্যতা বা অন্য কোনো কারণে আটকে আছে। হিসাব দ্রুত হওয়ায় ব্যবহারকারীরা বারবার অনুমান পরিবর্তন করে সম্ভাব্য পরিবর্তনের প্রভাব খতিয়ে দেখতে পারেন।

বিশেষজ্ঞদের জ্ঞান ধারণ করা

ঐতিহাসিক পরীক্ষায় দেখা যায়, শুধু সংখ্যাভিত্তিক অপ্টিমাইজেশন মানুষের সিদ্ধান্তের সম্পূর্ণ ভিত্তি পুনরুৎপাদন করতে পারে না। পরিকল্পনাকারীরা অংশীদারদের সঙ্গে যোগাযোগ, আবহাওয়াজনিত ঝুঁকি, ভূরাজনৈতিক পরিস্থিতির পরিবর্তন, সরবরাহকারীদের সঙ্গে কলের transcript এবং বছরের পর বছর সঞ্চিত অভিজ্ঞতাও বিবেচনা করছিলেন। এসব বিবরণ সাইটটি কতটা উপকরণ পাবে, তা প্রভাবিত করতে পারত—যদিও solver-এর কাঠামোবদ্ধ input-এ সেগুলোর প্রতিনিধিত্ব না-ও থাকত।

তাই NVIDIA ও Palantir এমন একটি workflow তৈরি করেছে, যা শুধু একটি allocation নয়, এর পেছনের যুক্তি, প্রত্যাশিত ফলাফল এবং শেষ পর্যন্ত কী ঘটেছে—সেগুলোও রেকর্ড করে। কোম্পানিটির বক্তব্য, এর ফলে আগে অনানুষ্ঠানিক থাকা দক্ষতা এমন তথ্যে পরিণত হয়, যা পর্যালোচনা করা এবং একটি model প্রশিক্ষণে ব্যবহার করা যায়।

Open Nemotron model-গুলো মূল্যায়নের পর দলগুলো সিস্টেমের execution অংশের জন্য Nemotron 3.5 Lightning বেছে নেয়। মডেলটি mixture-of-experts নকশা ব্যবহার করে, এতে 30 billion parameter রয়েছে এবং প্রতিটি forward pass-এর সময় প্রায় 3 billion parameter সক্রিয় হয়। NVIDIA এই তুলনামূলক কমপ্যাক্ট footprint-কে এমন একটি focused model-এর জন্য উপযোগী বলে তুলে ধরে, যা বৃহত্তর general-purpose system-এর চেয়ে কম computing capacity দিয়ে প্রশিক্ষণ ও স্থাপন করা যায়।

মডেলটির উদ্দেশ্য হলো উৎপাদন-ঝুঁকি অনুমান করা, একটি allocation range প্রস্তাব করা, সুপারিশের পেছনের প্রমাণ শনাক্ত করা এবং supply-chain staff-কে ফলাফল ব্যাখ্যা করা। Nemotron open হওয়ায় NVIDIA বলছে, প্রতিষ্ঠানগুলো নিজেদের computing environment-এ অভ্যন্তরীণ কার্যক্রমসংক্রান্ত তথ্য ব্যবহার করে এটিকে post-train করতে পারে।

অতীতের সিদ্ধান্তগুলোও একটি evaluation method সরবরাহ করে। সিস্টেমটি কোনো ঐতিহাসিক সিদ্ধান্তকে সেই সময়ে উপলভ্য তথ্য ব্যবহার করে পুনরায় চালাতে পারে, পরবর্তী ফলাফল গোপন রাখতে পারে এবং model-এর recommendation-এর সঙ্গে planner-এর সিদ্ধান্ত ও প্রকৃত ফলাফলের তুলনা করতে পারে। Palantir Autopilot সংশ্লিষ্ট workflow পরিচালনা করে; এর মধ্যে রয়েছে Ontology data থেকে চালু করা job, customized model-এর monitoring এবং source data-কে model version ও ফলাফলের সঙ্গে যুক্ত করা lineage।