XLA:GPU AOT সামঞ্জস্য নির্দেশিকা

এই নির্দেশিকাটি একটি সিরিয়ালাইজড এক্সিকিউটেবল তৈরি করে এমন XLA:GPU কম্পাইলার এবং সেটিকে লোড করে এমন রানটাইমের মধ্যেকার সামঞ্জস্য চুক্তিটি সংজ্ঞায়িত করে এবং সেই চুক্তি ভঙ্গ না করে কীভাবে কোনো পরিবর্তন প্রয়োগ করতে হয় তা বলে দেয়। AOT কম্পাইলেশন কী এবং একটি আর্টিফ্যাক্ট কীভাবে গঠিত ও লোড করা হয়, তা জানতে XLA:GPU ahead-of-time compilation দেখুন।

এই চুক্তিটি শুধুমাত্র XLA:GPU ব্যাকএন্ড ( GpuExecutableProto )-এর ক্ষেত্রে প্রযোজ্য। CPU এবং TPU AOT এক্সিকিউটেবলগুলো ভিন্ন সিরিয়ালাইজেশন পদ্ধতি ব্যবহার করে এবং এগুলো এর আওতার বাইরে।

সামঞ্জস্যতা উইন্ডোজ {#compatibility}

XLA:GPU দুটি সামঞ্জস্য উইন্ডো প্রদান করে:

• পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্যতা (৬ মাস): আপনার পরিবর্তন ধারণকারী একটি রানটাইমকে অবশ্যই বিগত ৬ মাসে কম্পাইলার দ্বারা উৎপাদিত প্রতিটি আর্টিফ্যাক্ট অভিন্ন অর্থসহ লোড ও এক্সিকিউট করতে হবে। এর ফলে কিছু সময় আগে কম্পাইল করা মডেলগুলো একটি আপডেট করা রানটাইমে লোড করা যায়।
• ফরোয়ার্ড কম্প্যাটিবিলিটি (২ সপ্তাহ): আপনার পরিবর্তন সম্বলিত একটি কম্পাইলার এমন কোনো সিরিয়ালাইজেশন কনস্ট্রাক্ট তৈরি করবে না, যা ২ সপ্তাহ পর্যন্ত পুরোনো কোনো রানটাইম ডিসিরিয়ালাইজ করতে পারে না বা ভুলভাবে ব্যাখ্যা করে। এটি রোলিং ডেপ্লয়মেন্টের সময় পুরোনো, দীর্ঘ সময় ধরে চলমান ইনফারেন্স সার্ভারগুলিতে সর্বশেষ কম্পাইলার দিয়ে কম্পাইল করা মডেল লোড করার সুযোগ দেয়।

GpuExecutableProto থেকে পরোক্ষভাবে পৌঁছানো যায় এমন প্রতিটি প্রোটো বার্তা এবং ফিল্ড এই চুক্তির অংশ।

পরিবর্তন বাছাই: আমার পরিবর্তনটি কি নিরাপদ? {#change_triage}

আপনার পরিবর্তনটি পর্যায়ক্রমিক বাস্তবায়নের প্রয়োজন আছে কিনা তা নির্ধারণ করতে এই সিদ্ধান্ত অনুক্রমটি অনুসরণ করুন:

1. আপনার পরিবর্তনটি কি নিম্নলিখিত বিষয়গুলোর কোনোটিকে প্রভাবিত করে?

   • GpuExecutableProto থেকে পৌঁছানো যায় এমন একটি প্রোটো
   • ToProto / FromProto
   • HLO অপকোড বা HLO প্রোটো যা একটি GPU এক্সিকিউটেবলে অন্তর্ভুক্ত হতে পারে।
   • নিবন্ধিত কার্নেল প্রতীক, কাস্টম কল, বা FFI হ্যান্ডলারের নাম বা অর্থ
   • লোড-টাইম থাঙ্ক রানটাইম রিডগুলোকে পাস বা ফ্ল্যাগ করে।
   • বিদ্যমান থাঙ্কগুলির এক্সিকিউশন সেম্যান্টিকস

   না: পরিবর্তনটি কম্পাইলার-অভ্যন্তরীণ (যেমন অপ্টিমাইজেশন, ফিউশন লজিক, কোডজেন রিরাইট) অথবা এটি একটি সম্পূর্ণ অভ্যন্তরীণ রানটাইম রিফ্যাক্টর, যেখানে বিদ্যমান থাঙ্কগুলোর আচরণ অপরিবর্তিত থাকবে। এটি সরাসরি ল্যান্ড করা নিরাপদ।

   হ্যাঁ: ধাপ ২-এ যান।

2. এই পরিবর্তনটি কি রানটাইম কর্তৃক বিদ্যমান আর্টিফ্যাক্টগুলোর ব্যাখ্যার পদ্ধতিতে কোনো পরিবর্তন আনে (যেমন—বিদ্যমান থাঙ্কগুলোর এক্সিকিউশন, লোড-টাইম পাস, রানটাইম-রিড ফ্ল্যাগের ডিফল্ট মান)?

   হ্যাঁ: শুধুমাত্র তখনই অনুমোদিত হবে যদি গত ৬ মাসে নির্গত প্রতিটি আর্টিফ্যাক্টের জন্য তা সঠিক হয়; যদি শব্দার্থগত অর্থ পরিবর্তিত হয়, তাহলে তার পরিবর্তে একটি নতুন ফিল্ড বা ফ্ল্যাগ চালু করুন।

   না: ধাপ ৩-এ যান।

3. এই পরিবর্তনটি কি বিদ্যমান কোনো থাঙ্ক কাইন্ড, প্রোটো ফিল্ড, বা ডিসিরিয়ালাইজেশন ফলব্যাক ব্রাঞ্চ মুছে ফেলে?

   হ্যাঁ: এটি ব্যাকওয়ার্ড কম্প্যাটিবিলিটি লঙ্ঘন করে, যদি না কম্পাইলার এমিশন কমপক্ষে ৬ মাস আগে বন্ধ হয়ে গিয়ে থাকে। ৬-মাসের সময়সীমা শেষ না হওয়া পর্যন্ত ডিসিরিয়ালাইজেশন ফলব্যাকটি চালু রাখুন, এবং মুছে ফেলা প্রোটো ট্যাগ ও নামগুলোকে reserved হিসেবে চিহ্নিত করুন।

   না: ধাপ ৪-এ যান।

4. এই পরিবর্তনটি কি সিরিয়ালাইজড আর্টিফ্যাক্টে একটি নতুন থাঙ্ক কাইন্ড, সঠিকতার জন্য প্রয়োজনীয় নতুন প্রোটো ফিল্ড, বা নতুন HLO অপকোড অন্তর্ভুক্ত করে?

   হ্যাঁ: অবিলম্বে প্রকাশ করা হলে এটি ফরোয়ার্ড কম্প্যাটিবিলিটি লঙ্ঘন করবে। পর্যায়ক্রমিক রোলআউট অনুসরণ করুন।

   না: ধাপ ৫-এ যান।

5. এই পরিবর্তনটি কি কোনো নিবন্ধিত কার্নেল সিম্বল, কাস্টম কল, বা FFI হ্যান্ডলারের নাম পরিবর্তন বা মুছে ফেলে?

   হ্যাঁ: এটি ব্যাকওয়ার্ড কম্প্যাটিবিলিটি লঙ্ঘন করে। ব্যাকওয়ার্ড-কম্প্যাটিবল রেজিস্ট্রেশনগুলো লিগ্যাসি নামে কমপক্ষে ৬ মাসের জন্য বজায় রাখুন।

   না: ধাপ ৬-এ যান।

6. এই পরিবর্তনটি কি এমন একটি ঐচ্ছিক প্রোটো ফিল্ড যোগ করে, যা পুরোনো রানটাইমগুলো সঠিকতার অবনতি ছাড়াই নিরাপদে উপেক্ষা করতে পারে?

   হ্যাঁ: অবতরণ করা নিরাপদ, যদি অনির্ধারিত প্রোটো ফিল্ডগুলো পূর্ববর্তী রানটাইম অর্থ অক্ষুণ্ণ রাখে।

   না: পশ্চাৎ ও ভবিষ্যৎ সামঞ্জস্যতা বজায় রেখে পরিবর্তনটি পুনরায় ডিজাইন করুন।

নিরাপদ বনাম বিঘ্নকারী পরিবর্তন

বড় ধরনের পরিবর্তনের জন্য পর্যায়ক্রমিক রোলআউট {#staged_rollout}

নতুন কোনো সিরিয়ালাইজেশন কনস্ট্রাক্ট চালু করার সময়, এটিকে তিনটি ধাপে বাস্তবায়ন করুন, যাতে উভয় কম্প্যাটিবিলিটি উইন্ডোই সন্তুষ্ট হয়:

1. রানটাইম সাপোর্ট। রানটাইমে ডিসিরিয়ালাইজেশন এবং এক্সিকিউশন লজিক যোগ করুন। যদি একই পিআর-এ কম্পাইলার এমিশন অন্তর্ভুক্ত থাকে, তবে একটি এক্সপেরিমেন্টাল ফ্ল্যাগের আড়ালে ডিফল্টরূপে এমিশন নিষ্ক্রিয় রাখুন। এরপর এই পরিবর্তনটি মার্জ হওয়ার পর অন্তত ২ সপ্তাহ অপেক্ষা করুন, যাতে আপডেট করা রানটাইমটি বিভিন্ন ডেপ্লয়মেন্ট এনভায়রনমেন্টে ছড়িয়ে পড়ে।
2. কম্পাইলার এমিশন। ডিফল্টরূপে কম্পাইলার এমিশন সক্রিয় করুন (অথবা ফিচার ফ্ল্যাগের ডিফল্ট মান পরিবর্তন করুন)। তারপর, রানটাইমে লিগ্যাসি ডিসিরিয়ালাইজেশন ফলব্যাকটি কমপক্ষে ৬ মাসের জন্য রাখুন, যা এই ফেজ থেকে গণনা করা হবে (যখন কম্পাইলার লিগ্যাসি ফর্মটি এমিট করা বন্ধ করে দেয়), ফেজ ১ থেকে নয়।
3. পরিষ্করণ। পুরোনো ডিসিরিয়ালাইজেশন পাথটি মুছে ফেলুন এবং অপ্রচলিত প্রোটো ট্যাগ নম্বর ও ফিল্ডের নামগুলোকে reserved হিসেবে চিহ্নিত করুন।

ফেজ ১ এবং ২ দুটি পুল রিকোয়েস্ট হতে পারে (প্রথমটি ২ সপ্তাহ পুরোনো হলে দ্বিতীয়টি পাঠানো হবে) অথবা একটিমাত্র পিআর হতে পারে, যেখানে একটি ফ্ল্যাগের আড়ালে এমিশন ডিফল্টরূপে নিষ্ক্রিয় থাকে এবং পরবর্তী কোনো রিকোয়েস্টে তা সক্রিয় করা হয়।

অপসারণ মন্তব্য এবং উদাহরণ

রানটাইমের প্রতিটি কম্প্যাটিবিলিটি ফলব্যাকের মেয়াদ শেষ হওয়ার তারিখ নথিভুক্ত করা উচিত:

// Backward-compatibility fallback for legacy AOT-compiled kernels without
// an explicit CollectiveKernelSpec.
// Can be removed in <month year> (6 months backward compatibility window).

পাবলিক ওপেনএক্সএলএ রোলআউটের উদাহরণ:

• PR #49046 : প্রথমে রানটাইমে ডেডিকেটেড স্ট্রিম অ্যাসাইনমেন্ট চালু করা হয়েছে, এবং রোলআউট উইন্ডো চলাকালীন এমিশন ডিফল্টরূপে নিষ্ক্রিয় রাখা হয়েছে।
• PR #46865 : CollectiveReduce জন্য রানটাইম থাঙ্ক সাপোর্ট যোগ করা হয়েছে, যেখানে কম্পাইলার এমিশন একটি পরীক্ষামূলক ফ্ল্যাগের মাধ্যমে সুরক্ষিত রাখা হয়েছে।

ডিসিরিয়ালাইজড এক্সিকিউটেবলের জন্য রানটাইম কোড রচনা করা

রানটাইম থাঙ্কস এবং ডিসিরিয়ালাইজেশন রুটিন বাস্তবায়ন করার সময়:

• কম্পাইলার-ভিত্তিক টাইপ ব্যবহার করা যাবে না: রানটাইম থাঙ্ক অবশ্যই HloInstruction* বা BufferAssignment মতো কম্পাইলার ডেটা স্ট্রাকচারের উপর নির্ভরশীল হবে না।
• ডিসিরিয়ালাইজড বাউন্ড যাচাই করুন: ইনডেক্সিং করার আগে সর্বদা বাফার অ্যালোকেশন ইনডেক্স, স্লাইস অফসেট এবং স্ট্রিম আইডি-কে অ্যালোকেশন বাউন্ডের সাথে মিলিয়ে যাচাই করুন।
• পেলোড ডুপ্লিকেট করবেন না: একই বড় পেলোড (যেমন ধ্রুবক) আর্টিফ্যাক্টে একাধিকবার সংরক্ষণ করবেন না; এটি লোড-টাইম মেমরি বহুগুণ বাড়িয়ে দেয়।
• ইনিশিয়ালাইজেশন অ্যালোকেশন সুরক্ষিত রাখুন: সার্ভিং রানটাইমগুলো কঠোর মেমরি সীমাবদ্ধতার অধীনে কাজ করে। FromProto বা থাঙ্ক ইনিশিয়ালাইজেশনের সময় শর্তহীন হিপ অ্যালোকেশন এড়িয়ে চলুন।

পরীক্ষা

সমস্ত সিরিয়ালাইজেশন পরিবর্তন অবশ্যই স্বয়ংক্রিয় পরীক্ষার আওতায় থাকতে হবে:

• রাউন্ড-ট্রিপ ইউনিট টেস্ট: ToProto এবং FromProto টেস্টের মাধ্যমে সিরিয়ালাইজেশন ও ডিসিরিয়ালাইজেশনের নির্ভুলতা যাচাই করুন ( ThunkProtoDeserializationTest দেখুন)।
• গোল্ডেন AOT টেস্ট: এন্ড-টু-এন্ড কম্প্যাটিবিলিটি টেস্টগুলো xla/tests/aot_compatibility/gpu অধীনে থাকে (যেমন collective_ops_aot_test.cc ), executables/<target>/v<N>/ এ থাকা সিরিয়ালাইজড গোল্ডেন এক্সিকিউটেবলগুলোর ওপর চালানো হয়।
• সমস্ত ঐতিহাসিক সংস্করণ পরীক্ষা করা: ডিফল্টরূপে, গোল্ডেন টেস্টগুলি বাউন্ডারি সংস্করণগুলির (সবচেয়ে পুরানো এবং দ্বিতীয়-নতুন) সাথে যাচাই করা হয়। সমস্ত ঐতিহাসিক গোল্ডেন সংস্করণের সাথে পরীক্ষা চালানোর জন্য আপনার টেস্ট এনভায়রনমেন্টে XLA_AOT_TEST_ALL_VERSIONS=1 সেট করুন।