ত্রুটি কোড: E1000

বিভাগ: কম্পাইল সময়: HBM OOM

এই ত্রুটিটি নির্দেশ করে যে প্রোগ্রামটির জন্য টিপিইউ ডিভাইসে শারীরিকভাবে উপলব্ধ পরিমাণের চেয়ে বেশি হাই ব্যান্ডউইথ মেমোরি (এইচবিএম) প্রয়োজন।

নমুনা ত্রুটি বার্তা:

RESOURCE_EXHAUSTED: TPU TensorCore Hbm usage: 34.82G, SparseCore Hbm usage 174.10G, exceeding available bytes: 95.74G

RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space hbm. Used 49.34G of 32.00G hbm. Exceeded hbm capacity by 17.34G.

XLA ব্যাকএন্ড: TPU

সংক্ষিপ্ত বিবরণ

সমস্ত প্রয়োজনীয় স্ট্যাটিক অ্যালোকেশনের মোট আকার ডিভাইসটির HBM-এর মধ্যে আঁটে কিনা, তা নিশ্চিত করার জন্য XLA যাচাই করে।

কম্পাইলার বিভিন্ন ধরণের অ্যালোকেশনের জন্য টিপিইউ-এর নির্দিষ্ট এইচবিএম ধারণক্ষমতা পরিচালনা করে:

• প্রোগ্রামের ইনপুট এবং আউটপুট: ট্রেনিং ব্যাচ, অপটিমাইজারের অবস্থা ইত্যাদি।
• টিপিইউ টেম্পোরারি: অন্তর্বর্তীকালীন গণনার জন্য প্রয়োজনীয় ডাইনামিক মেমরি (যেমন অ্যাক্টিভেশন, গ্রেডিয়েন্ট ইত্যাদি)।
• কম্পাইল করা বাইনারি: TensorCore (TC) এবং SparseCore (SC) উভয়ের মেশিন কোড।
• সিস্টেম ওভারহেড: XLA রানটাইমের জন্য সংরক্ষিত স্থান (যেমন পুরোনো প্রজন্মের TPU-গুলিতে ইনফিড বাফার)।
• ধ্রুবকসমূহ: HLO IR-এ অন্তর্ভুক্ত ধ্রুবক মানগুলো HBM-এ বরাদ্দ করা হয়।
• কম্পাইলারের অভ্যন্তরীণ বিষয়াবলী: প্রোগ্রাম স্তর এবং প্রতি-HLO বরাদ্দ (যেমন মেশের নোডগুলির জন্য রাউটিং তথ্য)।

এই ত্রুটিটি ঘটে যখন XLA কম্পাইলার উপরের সমস্ত অ্যালোকেশন ডিভাইস HBM-এ স্থান দিতে পারে না।

ডিবাগিং

আপনার ত্রুটিটি নিচের কোন শ্রেণীর HBM OOM-এর সাথে সবচেয়ে ভালোভাবে মেলে, তা নির্ধারণ করতে ত্রুটির বার্তা এবং লগগুলি মনোযোগ সহকারে বিশ্লেষণ করুন:

• "TC HBM ব্যবহার: X, SC HBM ব্যবহার Y": যদি ত্রুটিটি স্পষ্টভাবে HBM ব্যবহারের বিবরণ দেয়, তাহলে TensorCore (TC) + SparseCore (SC)-এর মোট ব্যবহার HBM সীমা অতিক্রম করেছে। → সিনারিও ১-এ যান। TC এবং SC HBM ব্যবহারের মধ্যে ভারসাম্য আনুন ।
• "HBM মেমরি স্পেসে মেমরি শেষ হয়ে গেছে" : HBM-এ হওয়া বৃহত্তম অ্যালোকেশনগুলোর তালিকা দেখতে লগগুলো পরীক্ষা করুন।
  • যদি এক বা একাধিক অপ্রত্যাশিতভাবে বড় টেনসর (যেমন HBM সীমার ৫০%-এর বেশি) উপস্থিত থাকে → সিনারিও ২-এ যান। অপ্রত্যাশিতভাবে বড় অ্যালোকেশনের কারণে মেমোরি শেষ হয়ে গেছে ।
  • যদি লগগুলিতে অপ্রত্যাশিতভাবে বড় কোনো টেনসর না থাকে → সরাসরি সিনারিও ৩-এ যান। অ্যাগ্রিগেট অ্যালোকেশনের কারণে মেমোরি শেষ হয়ে গেছে ।

দৃশ্যকল্প ১. টিসি এবং এসসি এইচবিএম ব্যবহারের ভারসাম্য

যদি ত্রুটি বার্তায় ব্যবহারের বিবরণ স্পষ্টভাবে দেওয়া থাকে, যেমন, "TC Hbm usage: X, SC Hbm usage Y" , এর মানে হলো TensorCore (TC) এবং SparseCore (SC)-এর মোট ব্যবহার HBM সীমা অতিক্রম করেছে। বাধা সৃষ্টিকারী কারণটি শনাক্ত করতে এই দুটি মান তুলনা করুন:

• উচ্চ স্পার্সকোর ব্যবহার
  • HBM স্ট্যাকের ব্যবহার অপ্টিমাইজ করুন: HBM স্ট্যাকের মেমরি খরচ feature_width , max_unique_nz_per_row এবং logical_replica_count এর সাথে আনুপাতিকভাবে বাড়ে। আপনি --xla_sc_num_serialized_tables_to_optimize_hbm ফ্ল্যাগটি টিউন করে স্ট্যাকের সর্বোচ্চ ব্যবহার কমাতে পারেন, যা টেবিলের প্রসেসিংকে সিরিয়ালাইজ করে। এর ফলে প্যারালালিজম কমে যায়।
  • প্যাডিং ওভারহেড পরীক্ষা করুন: স্পার্সকোর এমবেডিং টেবিলগুলিকে ৩২ বাইট (৮টি ফ্লোট) আকারে অ্যালাইন করে। কম ফিচার প্রস্থের (যেমন, < ৮টি ফ্লোট) টেবিলগুলিতে উল্লেখযোগ্য প্যাডিং ওভারহেড তৈরি হয়, যা HBM অপচয় করে।
  • হিপ ব্যবহার হ্রাস করুন: maximum_parallel_iterations এর উচ্চ মান HBM হিপে প্রিফেচ করা ইনপুট ডেটার পরিমাণ বাড়িয়ে দেয়। এই মান কমালে উল্লেখযোগ্য পরিমাণ মেমরি খালি করা সম্ভব।
  • শার্ডিং যাচাই করুন: নিশ্চিত করুন যে এমবেডিং টেবিলগুলো সমস্ত চিপ জুড়ে সঠিকভাবে মড-শার্ড করা হয়েছে। লিমিটগুলো কীভাবে টেবিলে রূপান্তরিত হয় তা দেখুন।
  • আরও ধারণার জন্য SC: Performance and memory bottlenecks দেখুন।
• উচ্চ টেনসরকোর ব্যবহার
  • সিনারিও ২- এ অগ্রসর হোন।
• ভারসাম্যপূর্ণ
  • যদি কোনোটিই আলাদাভাবে অতিরিক্ত না হয় কিন্তু উভয়ের যোগফল খুব বেশি হয়ে যায়, তাহলে আপনি চিপটির ধারণক্ষমতার শেষ সীমায় পৌঁছে গেছেন। আপনাকে অবশ্যই উভয় উপাদানের ব্যবহার কমানোর চেষ্টা করতে হবে। তিনটি বিভাগের সুপারিশগুলোই অনুসরণ করুন।

দৃশ্যকল্প ২. অপ্রত্যাশিতভাবে বেশি মেমরি বরাদ্দের কারণে মেমরি শেষ হয়ে যাওয়া

যদি আপনি "Ran out of memory in memory space HBM" এই এরর মেসেজটি দেখতে পান এবং লগগুলিতে এক বা একাধিক অপ্রত্যাশিতভাবে বড় অ্যালোকেশন (> HBM লিমিটের ৫০%) উপস্থিত থাকে, তবে এটি প্রায় কখনোই হার্ডওয়্যারের ধারণক্ষমতা সংক্রান্ত সমস্যা নয়। এটি সাধারণত একটি কনফিগারেশন এরর। বড় অ্যালোকেশনগুলির JAX সোর্স কোড সম্পর্কে সূত্র পেতে সেগুলির XLA লেবেল (যদি থাকে) পরীক্ষা করুন।

• ডিবাগিং আর্টিফ্যাক্টগুলি সরান
  • বড় আকারের রানে jax.debug.print() ব্যবহার করলে তা কম্পাইলারকে সিপিইউ-তে স্থানান্তরের জন্য HBM-এ সম্পূর্ণ টেনসরটি ম্যাটেরিয়ালাইজ করতে বাধ্য করতে পারে, যা ফিউশন ভেঙে দেয় এবং সর্বোচ্চ মেমরি ব্যবহার বাড়িয়ে দেয়। অবশিষ্ট যেকোনো jax.debug.print() মুছে ফেলুন।
• অদক্ষ মেশ আকার বা শার্ডিং ঠিক করুন
  • ভুল মেশ শেপ বা অনুপস্থিত শার্ডিং অ্যানোটেশনের কারণে কম্পাইলার ডিফল্টভাবে রেপ্লিকেশন পদ্ধতিতে চলে যেতে পারে—যার ফলে কম্পাইলার একটিমাত্র চিপে অত্যন্ত বড় টেনসরগুলোকে আঁটানোর চেষ্টা করতে বাধ্য হয়।
  • বৃহৎ অ্যালোকেশনগুলোর গঠন পরীক্ষা করুন এবং যাচাই করুন যে শার্ডিং সঠিকভাবে নির্দিষ্ট করা হয়েছে এবং XLA দ্বারা তা প্রচারিত হচ্ছে।

দৃশ্যকল্প ৩. সমষ্টিগত বরাদ্দের কারণে মেমোরি শেষ হয়ে যাওয়া

যদি আপনি "Ran out of memory in memory space HBM" এই এরর মেসেজটি দেখতে পান এবং লগগুলিতে অপ্রত্যাশিতভাবে বড় কোনো টেনসর উপস্থিত না থাকে, তাহলে বুঝতে হবে যে অ্যালোকেশনের মোট পরিমাণ HBM সীমা অতিক্রম করার কারণে প্রোগ্রামটির ধারণক্ষমতা শেষ হয়ে গেছে। এই ক্ষেত্রে, সর্বোচ্চ ব্যবহারের জন্য দায়ী নির্দিষ্ট বাফারগুলি শনাক্ত করতে মেমরি প্রোফাইল ভিজ্যুয়ালাইজ করা প্রায়শই সহায়ক হয়। সর্বোচ্চ মেমরি ব্যবহারের জন্য দায়ী বাফারগুলি শনাক্ত করার ধাপে ধাপে নির্দেশিকার জন্য "Debug OOM errors with XProf" দেখুন।

একবার আপনি শীর্ষ অবদানকারীদের চিহ্নিত করে ফেললে, মেমরি ফুটপ্রিন্ট অপ্টিমাইজ করতে নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করুন।

দৃশ্যকল্প ৩.ক কনফিগারেশন সমন্বয় করুন

এই কনফিগারেশন সমন্বয়গুলির মাধ্যমে আপনি প্রায়শই OOM সমস্যার সমাধান করতে পারেন:

• ব্যাচ সাইজ কমান: মধ্যবর্তী অ্যাক্টিভেশন এবং গ্রেডিয়েন্টের জন্য প্রয়োজনীয় মেমরি ব্যাচ সাইজের সাথে সরাসরি সমানুপাতিক। ব্যাচ সাইজ কমালে প্রায়শই মেমরির ব্যবহার কমাতে সাহায্য হতে পারে, যদিও মডেলের স্থিতিশীলতা বজায় রাখার জন্য আপনাকে আপনার লার্নিং রেট, মোমেন্টাম বা অপটিমাইজার হাইপারপ্যারামিটারগুলো পুনরায় টিউন করতে হতে পারে।
• ইনপুট বাফার দান করুন: JAX যখন কোনো গণনা সম্পাদন করে, তখন এটি সমস্ত ইনপুট এবং আউটপুটের জন্য ডিভাইসের বাফার ব্যবহার করে। যদি আপনি জানেন যে গণনার পরে ইনপুটগুলির মধ্যে একটির আর প্রয়োজন নেই, এবং যদি এটি আউটপুটগুলির মধ্যে একটির আকার এবং উপাদানের ধরনের সাথে মিলে যায়, তবে আপনি নির্দিষ্ট করতে পারেন যে আপনি সংশ্লিষ্ট ইনপুট বাফারটিকে একটি আউটপুট ধারণ করার জন্য দান করতে চান। এটি দান করা বাফারের আকারের সমান পরিমাণ এক্সিকিউশনের জন্য প্রয়োজনীয় মেমরি কমিয়ে দেবে। jax.jit ব্যবহার করার সময় আর্গুমেন্ট হিসেবে donate_argnums প্যারামিটারটি নির্দিষ্ট করে আপনি এটি করতে পারেন।
• মিশ্র নির্ভুলতা (bfloat16) সক্রিয় করুন: যদি মডেলের গঠন এবং গুণমানের প্রয়োজনীয়তা অনুমতি দেয়, তবে প্রোগ্রামের বৃহত্তম টেনসরগুলির জন্য bfloat16 বা কোয়ান্টাইজেশন (int8 ইত্যাদি) ব্যবহার করুন। মনে রাখবেন যে এই পরিবর্তনটি মডেলের আচরণকে প্রভাবিত করতে পারে এবং এটি সাবধানে বিবেচনা করা উচিত।

মাইক্রো-ব্যাচিং (ঐচ্ছিক)

যদি গ্লোবাল ব্যাচ সাইজ কমানো বা চিপের সংখ্যা বাড়ানো সম্ভব না হয়, এবং প্রতি চিপের ব্যাচ সাইজ আগে থেকেই সর্বনিম্ন করা না থাকে, তাহলে আপনি একটি মাইক্রো-ব্যাচিং কৌশল চেষ্টা করতে পারেন:

• প্রতিটি ব্যাচকে n সংখ্যক ক্ষুদ্র ব্যাচে ভাগ করুন;
• প্রতিটি মাইক্রো-ব্যাচের জন্য, ফরোয়ার্ড এবং ব্যাকওয়ার্ড পাস প্রক্রিয়া করুন;
• এটি সম্পন্ন হয়ে গেলে, গ্রেডিয়েন্টগুলো একত্রিত করুন এবং সামগ্রিকভাবে ওয়েট আপডেট করুন।

এই প্রক্রিয়ায় অ্যাক্টিভেশন মেমরি কমে যায়, কারণ আমরা প্রতিটি ব্যাচকে n সংখ্যক মাইক্রো-ব্যাচে ভাগ করেছি, ফলে যদি মূল ব্যাচের আকার M হয়, তবে অ্যাক্টিভেশন মেমরির আকার M/n হয়ে যায়।

সম্ভাব্য সমস্যা: - এই প্রক্রিয়ায় একাধিকবার সামনে ও পেছনে যাওয়ার কারণে স্টেপ টাইম বেড়ে যায়। - যদি মডেল এবং মাইক্রো-ব্যাচের আকারের মধ্যে খুব বেশি পার্থক্য থাকে, তাহলে আপনার মডেলে কনভারজেন্স সংক্রান্ত সমস্যা দেখা দিতে পারে।

দৃশ্যকল্প ৩.বি: আর্কিটেকচার এবং শার্ডিং অপ্টিমাইজ করুন

কনফিগারেশন পরিবর্তন অপর্যাপ্ত হলে, মডেল টপোলজিটি বর্তমান হার্ডওয়্যার সেটআপের জন্য খুব বড় হয়ে যেতে পারে।

• নতুন প্রজন্মের টিপিইউ ব্যবহার করুন: নতুন টিপিইউগুলোতে সাধারণত প্রতি চিপে বেশি এইচবিএম থাকে; সম্ভব হলে নতুন প্রজন্মের টিপিইউ ব্যবহার করুন।
• বৃহত্তর চিপ টপোলজিতে চালান: যদি মডেলের ওয়েটগুলো বিদ্যমান টপোলজির জন্য খুব বড় হয়ে যায়, তাহলে আপনি সেগুলোকে আরও চিপে শার্ডিং করার চেষ্টা করতে পারেন।

• উন্নত শার্ডিং কৌশল প্রয়োগ করুন:

  • আরও উন্নত ডেটা, টেনসর বা পাইপলাইন প্যারালালিজম পদ্ধতিগুলো অন্বেষণ করুন।
  • অন্তর্বর্তী মান এবং আউটপুটগুলির জন্য শার্ডিং ইঙ্গিত নির্দিষ্ট করুন।

  উল্লেখ্য যে, একাধিক চিপের মধ্যে টেনসর বিভক্ত করার কারণে এটি নেটওয়ার্ক যোগাযোগের ওভারহেড বাড়িয়ে দিতে পারে।

• JAX হোস্ট অফলোডিং ব্যবহার করুন: হোস্ট অফলোডিং কৌশলগুলি ব্যবহারকারীকে বড় টেনসরগুলিকে হোস্ট সিপিইউ মেমরিতে অফলোড করার সুযোগ দেয় (যেমন অ্যাক্টিভেশন অফলোডিং এবং অপটিমাইজার স্টেট অফলোডিং )। মনে রাখবেন যে হোস্ট অফলোডিং কৌশলগুলি পারফরম্যান্সের উপর মারাত্মক প্রভাব ফেলতে পারে, কারণ এই অপারেশনগুলি সিস্টেমকে TPU HBM এবং CPU RAM-এর মধ্যে ক্রমাগত বড় টেনসরগুলিকে আনা-নেওয়া করতে বাধ্য করে।

দৃশ্যকল্প ৩.সি টেনসরের প্যাডিং এবং অ্যালাইনমেন্ট পরীক্ষা করুন

অদক্ষ টেনসর আকার হলো টিপিইউ-তে OOM (আউট অফ মেমরি) এর একটি সাধারণ ও নীরব কারণ। টিপিইউ-তে সর্বোচ্চ পারফরম্যান্স পেতে, XLA টেনসরের ডাইমেনশনগুলোতে প্যাডিং যোগ করে—সাধারণত ক্ষুদ্রতম ডাইমেনশনের জন্য ১২৮-এর গুণিতক এবং দ্বিতীয় ক্ষুদ্রতম ডাইমেনশনের জন্য ৮-এর গুণিতক ব্যবহার করে। এই প্যাডিং ইনপুট অ্যারে এবং মধ্যবর্তী টেনসর (HLO টেম্পোরারি) উভয়কেই প্রভাবিত করে, যা মেমরি ব্যবহারকে উল্লেখযোগ্যভাবে বাড়িয়ে তুলতে পারে, বিশেষ করে ছোট ডাইমেনশন আকারের ক্ষেত্রে। অ্যারে লেআউটস দেখুন।

• বৃহৎ বাফারের আকার নিরীক্ষা করুন: (ডিফল্ট লেআউট সহ TPU v5-এ)
  • Xprof মেমরি ভিউয়ারে কোনো বাফারের উপর মাউস রাখলে বাফার ডিটেইলস কার্ডটি প্রদর্শিত হয়, যেটিতে প্যাডিং তথ্যসহ বাফারের বিস্তারিত বিবরণ থাকে।
  • উদাহরণ : (129, 1024) আকারের একটি আকৃতিকে প্যাড করে (256, 1024) করা হতে পারে, যার ফলে প্রায় 50% মেমরি অপচয় হয়।
  • সংশোধন: (128, 1024) আকারের জন্য কোনো প্যাডিংয়ের প্রয়োজন হয় না এবং এতে ০% মেমরি অপচয় হয়।
• ডাইমেনশন সমন্বয় করুন: নিশ্চিত করুন যে টেনসরের সমস্ত বড় ডাইমেনশন (ব্যাচ সাইজ, এমবেডিং ডাইমেনশন, হিডেন সাইজ) ১২৮-এর গুণিতক। মনে রাখবেন, এই পরিবর্তনটি মডেলের আচরণকে প্রভাবিত করতে পারে এবং এটি সতর্কতার সাথে বিবেচনা করা উচিত।

সিনারিও ৩.ডি: XLA ফ্ল্যাগগুলিকে প্রভাবিত করে এমন কী মেমরি টিউন করুন

কম মেমরি ব্যবহারের জন্য পারফরম্যান্সের সাথে আপোস করতে গুরুত্বপূর্ণ মেমরি ফ্ল্যাগগুলো টিউন করা যেতে পারে। তবে, এই কৌশলটি শেষ উপায় হিসেবে ব্যবহার করা উচিত, কারণ এটি পারফরম্যান্সের উপর বিরূপ প্রভাব ফেলতে পারে।

সিনারিও ৩.ই টিউন এক্সএলএ রিম্যাটেরিয়ালাইজেশন পাস/ম্যানুয়াল চেকপয়েন্টিং

যদি মডেলটি মেমোরিতে প্রায় এঁটে যায়, তাহলে আপনি jax.grad সাথে jax.checkpoint ডেকোরেটর ব্যবহার করে ম্যানুয়ালি নিয়ন্ত্রণ করতে পারেন যে ফরওয়ার্ড পাসে কোন ইন্টারমিডিয়েটগুলো সেভ করা হবে এবং ব্যাকওয়ার্ড পাসে কোনগুলো পুনরায় গণনা করা হবে। মনে রাখবেন যে এই অপারেশনটি পারফরম্যান্সে প্রভাব ফেলতে পারে, কারণ আপনি স্পষ্টভাবে HBM-এর জন্য কম্পিউট সাইকেল বিনিময় করছেন। আরও তথ্যের জন্য JAX ডকুমেন্টেশন দেখুন: - jax.checkpoint ( jax.remat ) দিয়ে গ্রেডিয়েন্ট চেকপয়েন্টিং - jax.checkpoint (ওরফে jax.remat ) দিয়ে অটোডিফের সেভ করা মান নিয়ন্ত্রণ - JAX মেমোরি এবং হোস্ট অফলোডিং

বিকল্পভাবে, আপনি মেমরি সাশ্রয়কে অগ্রাধিকার দিতে XLA::Rematerialization পাসটিকে বাধ্য করতে পারেন, যার ফলে কম্পাইলেশন ধীরগতির হতে পারে:

মনে রাখবেন যে, XLA ফ্ল্যাগ পরিবর্তন করাকে একেবারে শেষ উপায় হিসেবে ব্যবহার করা উচিত, কারণ এটি পারফরম্যান্সের ওপর নেতিবাচক প্রভাব ফেলতে পারে।

দৃশ্যকল্প ৩.এফ উন্নত প্রোফাইলিং টুল ব্যবহার করুন

XProf-এর সাহায্যে OOM ত্রুটি ডিবাগ করুন (Debug OOM errors with XProf) শীর্ষক এই টিউটোরিয়ালটিতে, HBM ব্যবহারের বিষয়ে কম্পাইলারের দৃষ্টিভঙ্গি দেখার জন্য XProf মেমরি ভিউয়ার কীভাবে ব্যবহার করতে হয়, তা আলোচনা করা হয়েছে।

এই টুলটি আপনাকে সর্বোচ্চ মেমরি অ্যালোকেশন এবং বাফার লাইফটাইম দেখতে দেয়, যা সর্বোচ্চ ব্যবহারের মুহূর্তে ঠিক কী কারণে HBM ব্যবহৃত হচ্ছে তা বোঝার জন্য অত্যন্ত গুরুত্বপূর্ণ। সাধারণ প্রোফাইলিং সেটআপের জন্য, “Xprof এবং TensorBoard Profiling দিয়ে শুরু করা” দেখুন।

সারসংক্ষেপ সারণী

নিম্নলিখিত সারণিতে OOM ত্রুটি সমাধানের সম্ভাব্য উপায়গুলোর একটি সারসংক্ষেপ এবং কী করতে হবে সে বিষয়ে সিদ্ধান্ত নিতে সহায়ক তথ্য রয়েছে।