মেগাস্কেলএক্সএলএ (MXLA) ডেটা সেন্টার নেটওয়ার্ক (DCN)-এর মাধ্যমে টিপিইউ স্লাইসগুলোর মধ্যে যোগাযোগ সমন্বয় করে। এই নির্দেশিকাটি মাল্টি-স্লাইস টিপিইউ ওয়ার্কলোড পরিচালনাকারী ব্যবহারকারীদের জন্য মেগাস্কেলএক্সএলএ ফ্ল্যাগ কনফিগার এবং টিউন করার নির্দেশিকা ও সর্বোত্তম অনুশীলন প্রদান করে। বেশিরভাগ ক্ষেত্রে যুক্তিসঙ্গত ডিফল্ট মান নির্ধারণ করার চেষ্টা করা হয়েছে।
সম্মিলিত বাফার আকার
ছোট সমষ্টির ক্ষেত্রে, ল্যাটেন্সি ওভারহেড কমাতে ছোট TPU প্রেরণ/গ্রহণ এবং নেটওয়ার্ক প্রেরণ/গ্রহণগুলোকে বড় আকারে একত্রিত করা সাধারণত বেশি কার্যকর। বড় সমষ্টির ক্ষেত্রে, অধিক সংখ্যক ছোট মধ্যবর্তী বাফার ব্যবহার করা সুবিধাজনক হতে পারে। এমন বেশ কিছু টুল রয়েছে যা এই আচরণ পরিবর্তন করার সুযোগ দেয়। কিছু সমষ্টির জন্য, TPU DMA রিডগুলোকে একত্রিত বা বিভক্ত করা যেতে পারে।
--megascale_target_dma_size=<value>
যা টার্গেট সাইজের যতটা সম্ভব কাছাকাছি ডিএমএ রিড শিডিউল করার চেষ্টা করবে। ডিফল্টরূপে, ৮ এমবি ব্যবহার করা হয়। শুধুমাত্র তখনই এই মানটি সামঞ্জস্য করার পরামর্শ দেওয়া হয়, যখন কোনো প্রোফাইলিং ট্রেসে দেখা যায় যে একটি ডিএমএ শুরু হওয়ার সময় এবং কোনো নির্দিষ্ট কালেক্টিভের জন্য প্রথম নেটওয়ার্ক ট্রান্সফার শুরু হওয়ার সময়ের মধ্যে উল্লেখযোগ্য বিলম্ব হচ্ছে।
ছোট সমষ্টির ক্ষেত্রে, হ্রাসকরণ কার্যক্রম সম্পাদনের জন্য সমষ্টির উপলব্ধ অংশগ্রহণকারীদের একটি উপসেট ব্যবহার করা প্রায়শই সুবিধাজনক হয়। এটি 'স্পার্স রিডাকশন' নামে পরিচিত। যে বাফার সাইজ থ্রেশহোল্ডের জন্য স্পার্স রিডাকশন সক্রিয় থাকে, তা ফ্ল্যাগ দ্বারা নিয়ন্ত্রিত হয়।
--megascale_sparse_reduction_threshold=<value>
ডিফল্টরূপে, এই মানটি হলো ২৫৬ কিলোবাইট। যদি কোনো প্রোফাইলার একটি রিডাকশন অপারেশনের জন্য উল্লেখযোগ্য ল্যাটেন্সি ওভারহেড দেখায়, তবে এই মানটি বাড়িয়ে দেওয়া সুবিধাজনক হতে পারে, যাতে কম সংখ্যক রিডিউসার ব্যবহৃত হয় এবং ফলস্বরূপ কম সংখ্যক বড় নেটওয়ার্ক ট্রান্সফার সম্পন্ন হয়।
কিছু পরিস্থিতিতে বড় নেটওয়ার্ক ট্রান্সফার এড়িয়ে চলার এবং তার পরিবর্তে অধিক সংখ্যক ছোট ট্রান্সফার ব্যবহার করার প্রয়োজন হতে পারে। এই ফ্ল্যাগটির মাধ্যমে এটি সমন্বয় করা যায়:
--megascale_max_reduction_shard_size=<value>
যা বাফারটিকে সমষ্টির প্রয়োজনের চেয়ে বেশি সংখ্যক ছোট ছোট শার্ডে বিভক্ত করবে। ডিফল্টরূপে, এই মানটি হলো ৮ মেগাবাইট। megascale_max_reduction_shard_size >> megascale_sparse_reduction_threshold হওয়া উচিত, কারণ এদের প্রভাব বিপরীতধর্মী।
এক-থেকে-এক স্থানান্তরের (যেমন collective-permute ) ক্ষেত্রে, একটি হোস্টে স্থানান্তরগুলিকে নিম্নলিখিত উপায়ে খণ্ডে বিভক্ত করা যেতে পারে:
--megascale_chunk_size=<value>
শূন্য না হলে, এটি একটি হোস্টে প্রতিটি ওয়ান-টু-ওয়ান ট্রান্সফারকে megascale_chunk_size বাইটের (ডিফল্ট: ৮ এমবি) একাধিক খণ্ডে বিভক্ত করে ডিএমএ এবং নেটওয়ার্ক ট্রান্সফারকে পাইপলাইন করে। অন্যান্য সমস্ত কালেক্টিভ শার্ডিং এবং চাংকিং নিয়ন্ত্রণ করতে megascale_target_dma_size , megascale_sparse_reduction_threshold , এবং megascale_max_reduction_shard_size ব্যবহার করে।
Memory Management & Zero-Copy Transfers
মেগাস্কেল নেটওয়ার্ক ট্রান্সফারগুলো জিরো-কপি হিসেবে ডিজাইন করা হয়েছে: হোস্ট মেমরি অঞ্চলগুলোকে টিপিইউ-এর সাথে ডিএমএ-এর জন্য পিন এবং প্রি-ম্যাপ করা থাকে। রানটাইমে যদি প্রি-ম্যাপ করা মেমরি শেষ হয়ে যায়, তবে সিস্টেম অন-ডিমান্ড ম্যাপিং বা ডায়নামিক মেমরি কপিতে ফিরে যায়, যা থ্রুপুটকে মারাত্মকভাবে প্রভাবিত করে।
Pre-Mapped Memory Region
--megascale_grpc_premap_memory_bytes=17179869184 # Default: 16 GB (16LL << 30)
ডিএমএ ট্রান্সফারের জন্য প্রারম্ভিক পর্যায়ে বরাদ্দকৃত হোস্ট পিনড-মেমরি অঞ্চলের আকার নিয়ন্ত্রণ করে।
রোগ নির্ণয়ের লক্ষণ
-
MapDmaBufferস্থিতিশীল অবস্থায় : XProf Trace Viewer-এMapDmaBufferঅনুসন্ধান করুন। এই কলগুলো শুধুমাত্র স্টার্টআপের সময় হওয়া উচিত। যদি এগুলো ট্রেনিং ইটারেশনের সময়ও চলতে থাকে, তাহলে ডাইনামিক রিম্যাপিং হচ্ছে। -
Megascale: Memory Copyট্রেস : যদি XProf-এর কমিউনিকেশন ট্রান্সপোর্ট ট্র্যাকেMegascale: Memory Copyইভেন্ট প্রদর্শিত হয়, তাহলে মেমরি বাফারগুলো জিরো-কপি ডিএমএ-এর মাধ্যমে স্থানান্তরের পরিবর্তে কপি করা হচ্ছে।
সমাধান
--megascale_grpc_premap_memory_bytes মান বাড়ান (যেমন, আপনার TPU VM ইনস্ট্যান্সে উপলব্ধ হোস্ট মেমরির ওপর নির্ভর করে ২৪ জিবি বা ৩২ জিবি পর্যন্ত) এবং জবটি পুনরায় চালু করুন।