বড় এম্বেডিং মডেলের (LEM) জন্য SparseCore-এ একটি গভীর ডুব

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

1. SparseCore এর ভূমিকা

মূল স্থাপত্য বৈশিষ্ট্য:

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

এক নজরে স্পেসিফিকেশন:

2. SparseCore হোস্ট প্রিপ্রসেসিং

SparseCore পারফরম্যান্সের জন্য কার্যকর ডেটা প্রস্তুতি সর্বাগ্রে, এবং এখানেই হোস্ট প্রিপ্রসেসিং একটি গুরুত্বপূর্ণ ভূমিকা পালন করে। এটি বেশ কয়েকটি মূল কার্যকারিতা অন্তর্ভুক্ত করে:

• ডেটা রূপান্তর :
  • কাঁচা ইনপুট ডেটাতে প্রয়োজনীয় রূপান্তর প্রয়োগ করুন।
  • আইডি রূপান্তরগুলি পরিচালনা করুন, যা বৈশিষ্ট্য বা টেবিল স্ট্যাকিং নিয়ে কাজ করার সময় বিশেষভাবে গুরুত্বপূর্ণ।
  • ইনপুট ডেটাকে কোঅর্ডিনেট (COO) স্পার্স ফরম্যাটে রূপান্তর করুন, নিম্নলিখিত বিভাগে বিস্তারিত।
  • চিপে উপলব্ধ বিভিন্ন SparseCores জুড়ে দক্ষ বিতরণের জন্য ডেটা বিভাজন করুন।
• সীমা বৈধতা :
  • নিশ্চিত করুন যে ইনপুট ডেটার বৈশিষ্ট্যগুলি (উদাহরণস্বরূপ, আইডিগুলির সংখ্যা) স্পারসকোরের পূর্বনির্ধারিত অপারেশনাল সীমার সাথে সামঞ্জস্যপূর্ণ, যেমন max_ids_per_partition এবং max_unique_ids_per_partition ।
  • যদি ইনপুট ডেটা এই সীমা অতিক্রম করে, আপনার হোস্ট প্রিপ্রসেসিং স্তর ডেটাকে ছোট ছোট মিনি-ব্যাচগুলিতে ভাগ করার চেষ্টা করতে পারে যা সীমাবদ্ধতার মধ্যে ফিট করে।
• ডেটা স্থানান্তর :
  • TPU এর হাই ব্যান্ডউইথ মেমরি (HBM) এ প্রক্রিয়াকৃত এবং যাচাইকৃত ডেটা দক্ষতার সাথে অনুলিপি করুন, এটিকে SparseCore সম্পাদনের জন্য প্রস্তুত করে।

টেবিল স্ট্যাকিং বোঝা:

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

• বৈশিষ্ট্য স্ট্যাকিং : এটি ঘটে যখন একাধিক স্বতন্ত্র বৈশিষ্ট্য একই অন্তর্নিহিত এম্বেডিং টেবিল ভাগ করে। একটি সাধারণ উদাহরণ হল বিভিন্ন প্রেক্ষাপট থেকে জিপ কোডের মতো বিভিন্ন শ্রেণিবদ্ধ বৈশিষ্ট্যের জন্য একটি একক এম্বেডিং অভিধান ব্যবহার করা।
• টেবিল স্ট্যাকিং : এই পরিস্থিতিতে, একাধিক স্বতন্ত্র এমবেডিং টেবিল একসাথে স্ট্যাক করা হয়। যে টেবিলগুলি একই এম্বেডিং মাত্রা এবং অপ্টিমাইজার কনফিগারেশন ভাগ করে সেগুলি প্রায়শই গোষ্ঠীবদ্ধ হয়৷

টেবিল স্ট্যাকিংয়ের প্রাথমিক সুবিধা হল এই স্ট্যাক করা টেবিলগুলিতে অপারেশনের জন্য একটি বড় কার্যকর ব্যাচ আকার তৈরি করা। এটি কম্পিউটেশনাল ওভারহেড হ্রাস করে এবং ইন্টার-চিপ কমিউনিকেশন (ICI) দেরি লুকিয়ে রাখতে কার্যকর হতে পারে। সর্বোত্তম কর্মক্ষমতার জন্য, একটি মাঝারি সংখ্যক স্ট্যাক করা টেবিল (সাধারণত 5 থেকে 100 এর মধ্যে) সুপারিশ করা হয়।

3. COO টেনসরে রূপান্তর

SparseCore দ্বারা ডেটা প্রক্রিয়া করার আগে, এটি সাধারণত একটি স্থানাঙ্ক (COO) স্পার্স টেনসর ফর্ম্যাটে রূপান্তরিত হয়। COO বিন্যাসটি সাধারণত তিনটি অ্যারে ব্যবহার করে দক্ষতার সাথে স্পার্স ম্যাট্রিক্স উপস্থাপন করার একটি উপায়:

• row_ids : প্রতিটি অ-শূন্য উপাদানের জন্য সারি সূচক ধারণকারী একটি অ্যারে। ব্যাচ প্রক্রিয়াকরণের প্রসঙ্গে, এটি প্রায়শই ব্যাচের মাত্রার সাথে মিলে যায়।
• col_ids : প্রতিটি অ-শূন্য উপাদানের জন্য কলাম সূচক ধারণকারী একটি অ্যারে। এমবেডিংয়ের জন্য, এগুলি প্রায়শই বৈশিষ্ট্য বা আইডি মান।
• values (ঐচ্ছিক): সংশ্লিষ্ট ( row , col ) স্থানাঙ্কে অ-শূন্য উপাদানগুলির প্রকৃত মান ধারণ করে একটি অ্যারে৷ আইডি গণনার সাথে সম্পর্কিত সীমা গণনার জন্য (পরে আলোচনা করা হয়েছে), এই মানগুলি (লাভ) প্রায়ই বিবেচনা করা হয় না।

দৃষ্টান্তমূলক উদাহরণ:

আইডিগুলির ব্যাচগুলিকে উপস্থাপন করে একটি ইনপুট স্পার্স ম্যাট্রিক্স বিবেচনা করুন:

[
    [id_A],                 // Sample 0
    [id_A, id_B, id_C],     // Sample 1
    [id_B, id_B, id_D],     // Sample 2 (note duplicate id_B)
]

COO ফর্ম্যাটে রূপান্তর করার পরে (এবং সম্ভাব্যভাবে একই নমুনার মধ্যে আইডিগুলি কেটে নেওয়ার পরে):

row_ids = [0, 1, 1, 1, 2, 2]
col_ids = [id_A, id_A, id_B, id_C, id_B, id_D]

SparseCore কীভাবে কাজ করে এবং বিতরণ করে তার জন্য এই রূপান্তরটি মৌলিক। বিশেষ করে col_ids , একটি আইডি কোন নির্দিষ্ট SparseCore পার্টিশনের অন্তর্গত তা নির্ণয় করার জন্য অত্যন্ত গুরুত্বপূর্ণ, দক্ষ শার্ডিং এবং লুকআপ সক্ষম করে।

4. SparsecoreConfig: উচ্চ-স্তরের API

ফ্রেমওয়ার্ক নির্দিষ্ট এম্বেডিং API:

• JAX : https://github.com/jax-ml/jax-tpu-embedding
• টেনসরফ্লো : https://www.tensorflow.org/recommenders/api_docs/python/tfrs/layers/embedding/TPUEmbedding
• কেরাস : https://keras.io/keras_rs/api/embedding_layers/distributed_embedding

SparsecoreConfig , বা সমতুল্য প্রক্রিয়া যেমন XLA পতাকা, SparseCore আচরণের বিস্তৃত অ্যারে নিয়ন্ত্রণ করার জন্য একটি উচ্চ-স্তরের ইন্টারফেস হিসাবে কাজ করে। কার্যকর পারফরম্যান্স টিউনিং এবং আপনার মডেলগুলির সঠিক অপারেশন নিশ্চিত করার জন্য এই পরামিতিগুলির একটি পুঙ্খানুপুঙ্খ বোধগম্যতা গুরুত্বপূর্ণ৷

• disable_table_stacking: bool = False
  • ব্যাখ্যা : এই পতাকা নিয়ন্ত্রণ করে যে স্বয়ংক্রিয় টেবিল স্ট্যাকিং ফ্রেমওয়ার্ককে টেবিলের স্ট্যাকিং থেকে বাধা দিচ্ছে, সম্ভাব্যভাবে বর্ধিত ওভারহেড এবং ইন্টার-চিপ ইন্টারকানেক্ট (ICI) লেটেন্সি লুকানোর ক্ষমতা হ্রাসের কারণে কর্মক্ষমতা হ্রাস করতে পারে।
  • ডিফল্ট : False (সূচনা সারণী স্ট্যাকিং সাধারণত ডিফল্টরূপে সক্রিয় করা হয় যেখানে ফ্রেমওয়ার্ক এটিকে সমর্থন করে)।
• max_ids_per_chip_per_sample: int = 64
  • ব্যাখ্যা : এই প্যারামিটারটি এমবেডিং আইডিগুলির মোট সংখ্যার উপর একটি বিশ্বব্যাপী উচ্চ সীমা স্থাপন করে যা একটি একক চিপ ইনপুট ব্যাচের একটি নমুনা থেকে সমস্ত টেবিল জুড়ে একত্রিত করে প্রক্রিয়া করতে পারে। এটি চিপ স্তরে সংস্থানগুলি পরিচালনা করার জন্য একটি প্রক্রিয়া, আগে আরও দানাদার প্রতি-টেবিল বা প্রতি-পার্টিশন সীমাগুলি বিবেচনায় নেওয়া হয়। এই মানটিকে ফাইন-টিউনিং সাধারণত নির্দিষ্ট মডেলের বৈশিষ্ট্য এবং সামগ্রিক সিস্টেমের ক্ষমতার উপর নির্ভর করে।
  • ডিফল্ট : 64 ।
• max_ids_per_table: Optional[Dict[str, int]] = None
  • ব্যাখ্যা : এই পরামিতিটি সমস্ত স্পারসকোর জুড়ে এর সমস্ত পার্টিশন বিবেচনা করে প্রতিটি লজিক্যাল টেবিলের জন্য প্রসেস করা যেতে পারে এমন সর্বাধিক সংখ্যক এমবেডিং আইডি (যাতে ডুপ্লিকেট থাকতে পারে) নির্দিষ্ট করে। এটি max_ids_per_partition থেকে একটি বিস্তৃত সীমা। যদি একটি টেবিল T P পার্টিশনে বিভক্ত করা হয়, তাহলে এই সীমাটি সমস্ত P পার্টিশনে নির্দেশিত ID-এর যোগফলের জন্য প্রযোজ্য। এটি প্রায়ই max_ids_per_partition_per_sample এবং সামগ্রিক ব্যাচের আকারের সাথে সম্পর্কিত।
  • সেটিং : সাধারণত একটি সীমা ফাইল ব্যবহার করে কনফিগার করা হয় (উদাহরণস্বরূপ, xla_sparse_core_max_ids_file পতাকা ব্যবহার করে), যেখানে max_ids_per_partition সংজ্ঞায়িত করা হয়। এই টেবিল-স্তরের ধারণাটি সেই পার্টিশন-স্তরের সীমা নির্ধারণ করার একটি পদ্ধতি ( max_ids এবং max_uniques )।
  • ডিফল্ট : None (মানটি প্রতি-পার্টিশন সীমা বা অন্যান্য কনফিগারেশন থেকে অনুমান করা যেতে পারে যদি স্পষ্টভাবে প্রদান করা না হয়)।
• max_unique_ids_per_table: Optional[Dict[str, int]] = None
  • ব্যাখ্যা : max_ids_per_table এর সাথে সাদৃশ্যপূর্ণ, কিন্তু এই প্যারামিটারটি প্রতিটি লজিক্যাল টেবিলের জন্য সর্বোচ্চ সংখ্যক অনন্য আইডি নির্দিষ্ট করে। অনন্য আইডি প্রসেসিং এবং পরবর্তী ভেক্টর অপারেশনগুলিতে ব্যবহৃত অন-ডিভাইস বাফারগুলিকে যথাযথভাবে আকার দেওয়ার জন্য এটি একটি গুরুত্বপূর্ণ সেটিং।
  • সেটিং : এছাড়াও সাধারণত একটি সীমা ফাইলে সংজ্ঞায়িত বা max_unique_ids_per_partition_per_sample থেকে প্রাপ্ত।
  • ডিফল্ট : None ।
• allow_id_dropping: bool = False
  • ব্যাখ্যা : এই বুলিয়ান ফ্ল্যাগ আইডি ড্রপিং নিয়ন্ত্রণ করে যখন ইনপুট ডেটাতে (পরিক্ষিত সীমা) আইডির সংখ্যা সংকলনের সময় সেট করা সীমা অতিক্রম করে (উদাহরণস্বরূপ, max_ids_per_partition )।
    • যদি True : সীমা অতিক্রম করতে পারে এমন আইডিগুলি নিঃশব্দে বাদ দেওয়া হয়৷ সাধারণত, একটি পার্টিশনের মধ্যে আইডিগুলি একটি সাজানো ক্রমে প্রক্রিয়া করা হয়, এবং যে কোনও আইডি যা তার নির্ধারিত মিনি-ব্যাচের জন্য চলমান সংখ্যাকে সীমা ছাড়িয়ে যায় তা বাতিল করা হয়। এটি প্রোগ্রামটিকে এক্সিকিউশন চালিয়ে যেতে দেয় তবে মডেলের নির্ভুলতার উপর বিরূপ প্রভাব ফেলতে পারে।
    • যদি False : একটি ত্রুটি ট্রিগার হয়, এবং যদি পর্যবেক্ষণ করা সীমা সংকলিত সীমা অতিক্রম করে তবে প্রক্রিয়াটি সম্ভবত বন্ধ হয়ে যাবে। এই পদ্ধতিটি নিশ্চিত করে যে সমস্ত ডেটা প্রক্রিয়া করা হয়েছে তবে সীমা আরও রক্ষণশীলভাবে কনফিগার করা প্রয়োজন।
  • ডিফল্ট : False (নিঃশব্দ ডেটা ড্রপিংয়ের পরিবর্তে ওভারফ্লোতে একটি ত্রুটি ঘটায়)।

• initialize_tables_on_host: bool = True

  • ব্যাখ্যা : এই পতাকা নির্ধারণ করে যে এম্বেডিং টেবিলগুলি পরবর্তীতে TPU-এর উচ্চ ব্যান্ডউইথ মেমরিতে (HBM) স্থানান্তরিত হওয়ার আগে হোস্ট CPU-তে আরম্ভ করা হয়েছে কিনা। স্ট্যান্ডার্ড অনুশীলন হল হোস্টে টেবিলগুলি শুরু করার জন্য। এটিকে True সেট করা এই নিয়ম অনুসরণ করে। যদি এটি False এ সেট করা হয়, তাহলে এটি একটি অন-ডিভাইস ইনিশিয়ালাইজেশন মেকানিজমকে বোঝাবে, যার বিভিন্ন কর্মক্ষমতা প্রভাব বা নির্দিষ্ট প্রারম্ভিক পূর্বশর্ত থাকতে পারে।

• enable_fast_table_initialization: bool = False

  • ব্যাখ্যা : সরাসরি TPU-তে টেবিল শুরু করে। এটি মডেল স্টার্টআপ সময় কমাতে সাহায্য করতে পারে।

5. কর্মক্ষমতা জন্য পাইপলাইন

পাইপলাইনিং হল একটি পারফরম্যান্স অপ্টিমাইজেশন কৌশল যা টেনসরকোর (টিসি) এবং স্পারসকোর (এসসি) তে একযোগে ক্রিয়াকলাপ সম্পাদন করতে সক্ষম করে। এই গণনাগুলিকে ওভারল্যাপ করে, সামগ্রিক থ্রুপুট উল্লেখযোগ্যভাবে উন্নত করা যেতে পারে।

• মেকানিজম : একটি প্রমিত প্রশিক্ষণের ধাপে যেখানে স্পার্স এম্বেডিং লুকআপ (SC দ্বারা পরিচালিত) এবং ঘন স্তর গণনা (TC দ্বারা পরিচালিত) জড়িত থাকে, পাইপলাইনিং SC-কে তার ধাপ i এর অংশে কাজ করতে দেয় (উদাহরণস্বরূপ, ফরোয়ার্ড বা পিছন দিকে পাস) যখন TC একই ধাপ i এর একটি ভিন্ন অংশ বা এমনকি i-1 এর মতো i+1 অংশ প্রক্রিয়াকরণ করে।
• গ্রেডিয়েন্টের উপর প্রভাব : SparseCore "বাসি" গ্রেডিয়েন্টে কাজ করতে পারে। উদাহরণ স্বরূপ, ধাপ i এর ব্যাকপ্রপাগেশন পর্বের সময় গণনা করা গ্রেডিয়েন্ট সম্পূর্ণরূপে আপডেট নাও হতে পারে এবং ধাপ i+2 পর্যন্ত SC এর কাছে দৃশ্যমান নাও হতে পারে।
• পারফরম্যান্স বনাম সংখ্যাবিজ্ঞান ট্রেড-অফ : এই ওভারল্যাপিং এক্সিকিউশনটি যথেষ্ট গতির দিকে নিয়ে যেতে পারে, সম্ভাব্যভাবে ডিভাইসের ধাপে 2x উন্নতি পর্যন্ত। যাইহোক, বাসি গ্রেডিয়েন্ট ব্যবহারের ফলে সংখ্যায় সূক্ষ্ম পরিবর্তনগুলি (এম্বেডিং_ওয়েট) মডেল অভিসারী আচরণ বা চূড়ান্ত অর্জিত নির্ভুলতাকে প্রভাবিত করতে পারে। এই ট্রেড-অফের গ্রহণযোগ্যতা অত্যন্ত মডেল-নির্ভর এবং প্রায়ই অভিজ্ঞতামূলক বৈধতা প্রয়োজন।
• নিয়ন্ত্রণ পতাকা : পাইপলাইনিং tf_xla_disable_full_embedding_pipelining দ্বারা নিয়ন্ত্রণ করা যেতে পারে। এই পতাকাটিকে true সেট করা সম্পূর্ণ পাইপলাইনিংকে নিষ্ক্রিয় করে (টেনসরকোর এবং স্পার্সকোর গণনাকে ওভারল্যাপ করে), যেখানে এটিকে false সেট করা (অথবা যদি পতাকার শব্দার্থগুলি মিথ্যা হলে সক্রিয় করে) এটি সক্রিয় করে।

ধারণাগত পাইপলাইন প্রবাহ:

• পাইপলাইন ছাড়া (সরলীকৃত অনুক্রমিক প্রবাহ) :

  Loop: SC/F_i -> TC/F_i -> TC/B_i -> SC/B_i

• পাইপলাইনিংয়ের সাথে (সরলীকৃত ওভারল্যাপড প্রবাহ) :

  Time ->
  Step i:   SC/F_i | TC/F_i | TC/B_i | SC/B_i
  Step i+1:          SC/F_i+1| TC/F_i+1| TC/B_i+1| SC/B_i+1
  

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

6. XLA এর ভূমিকা

XLA (অ্যাক্সিলারেটেড লিনিয়ার অ্যালজেব্রা) হল ডোমেন-নির্দিষ্ট কম্পাইলার যা উচ্চ-স্তরের কম্পিউটেশনাল গ্রাফগুলিকে অনুবাদ করে, সাধারণত টেনসরফ্লো-এর মতো ফ্রেমওয়ার্কগুলি থেকে, TPU-গুলির জন্য তৈরি করা অত্যন্ত অপ্টিমাইজ করা মেশিন কোডে। এর মধ্যে SparseCore-এর জন্য নির্ধারিত ক্রিয়াকলাপগুলির জন্য নির্দেশাবলী তৈরি করা অন্তর্ভুক্ত।

SparseCore প্রসঙ্গে মূল ফাংশন:

• স্পার্স অপারেশনের সংকলন : XLA এম্বেডিং লুকআপ অপারেশন (যেমন SparseDenseMatmulOp ) এবং নিম্ন-স্তরের, এক্সিকিউটেবল স্পারসকোর প্রোগ্রামে অন্যান্য স্পার্স কম্পিউটেশন কম্পাইল করার জন্য দায়ী।
• সীমার একীকরণ : এটি কনফিগার করা অপারেশনাল সীমাগুলি ব্যবহার করে (উদাহরণস্বরূপ, max_ids_per_partition , max_unique_ids_per_partition , প্রায়শই xla_sparse_core_max_ids_file এর মতো ফ্ল্যাগ দ্বারা নির্দিষ্ট একটি সীমা ফাইলের মাধ্যমে সরবরাহ করা হয়) মেমরি এবং বিশেষ ডিভাইসের সমস্ত আকারের মধ্যে স্ট্যাটিকভাবে নির্ধারণ করতে। এসপিএমইএম।
• টার্গেটেড অপ্টিমাইজেশান : XLA বিশেষভাবে SparseCore আর্কিটেকচারের জন্য ডিজাইন করা অপ্টিমাইজেশনের একটি স্যুট সম্পাদন করে। এর মধ্যে নির্দেশের সময়সূচী, মেমরি লেআউট রূপান্তর এবং কার্যকারিতা সর্বাধিক করার জন্য ফিউশন অন্তর্ভুক্ত থাকতে পারে।
• পতাকা ব্যবহার করে নিয়ন্ত্রণ : SparseCore আচরণ, টিউনিং পরামিতি এবং অপ্টিমাইজেশন কৌশলগুলির অনেক দিক এক্সএলএ পতাকাগুলির মাধ্যমে উন্মুক্ত এবং নিয়ন্ত্রিত হয় (উদাহরণস্বরূপ, সীমা অনুমানের জন্য xla_sparse_core_estimate_max_ids , বা ডিবাগিংয়ের জন্য xla_sc_detect_nan )।

ওপেন সোর্স স্ট্যাটাস:

বর্তমানে স্পার্সকোর বাস্তবায়ন অভ্যন্তরীণ এবং libtpu.so ব্যবহার করে পরিবেশন করা হয়।

ত্রুটি রিপোর্টিং এবং ডায়াগনস্টিকস:

SparseCore কনফিগারেশন বা সংস্থান সীমাবদ্ধতার সাথে সম্পর্কিত সংকলন ব্যর্থতাগুলি প্রায়শই XLA:TPU কম্পাইল-টাইম ত্রুটি হিসাবে প্রকাশ করে। এই ত্রুটির বার্তাগুলি উপলব্ধ এসপিএমইএম-এর জন্য সীমা খুব বেশি সেট করা বা অসমর্থিত কনফিগারেশনের ব্যবহারের মতো সমস্যাগুলির মূল্যবান অন্তর্দৃষ্টি প্রদান করতে পারে।

7. কিভাবে সীমা SparseCore টেবিলে অনুবাদ করে

SparseCore-এ, "সীমা" হল মৌলিক কনফিগারেশন পরামিতি যা প্রাথমিকভাবে প্রতিটি টেবিলের জন্য দুটি প্রতি-পার্টিশন সেটিংসকে নির্দেশ করে যা উপলব্ধ SparseCores জুড়ে শার্ডেড (বন্টন করা) হয়:

• max_ids_per_partition : এটি একটি একক গণনামূলক ধাপের মধ্যে প্রদত্ত টেবিলের একটি নির্দিষ্ট পার্টিশনে যে কোনো একক SparseCore পাঠাতে বা প্রক্রিয়া করার জন্য প্রত্যাশিত মোট আইডির (ডুপ্লিকেট সহ) সর্বাধিক সংখ্যা নির্ধারণ করে।
• max_unique_ids_per_partition : এটি সর্বোচ্চ সংখ্যক অনন্য আইডি সংজ্ঞায়িত করে যা কোনো একক SparseCore-এ পাঠানো বা প্রক্রিয়া করার জন্য প্রত্যাশিত।

ফিজিক্যাল টেবিল লেআউট এবং প্রক্রিয়াকরণে অনুবাদ:

• টেবিল শার্ডিং কৌশল : এম্বেডিং টেবিলগুলি সাধারণত সিস্টেমের সমস্ত স্পারসকোর জুড়ে "মড-শার্ডেড" হয়। এর মানে প্রতিটি স্পার্সকোর প্রতিটি টেবিলের শব্দভান্ডারের (সারি) একটি স্বতন্ত্র উপসেটের জন্য দায়ী। একটি আইডি j সাধারণত k = j % num_total_sparse_cores মত একটি সূত্রের উপর ভিত্তি করে SparseCore_k কে বরাদ্দ করা হবে।
• একটি "পার্টিশন" এর সংজ্ঞা : এই প্রসঙ্গে, একটি "পার্টিশন" একটি এমবেডিং টেবিলের নির্দিষ্ট সেগমেন্টকে বোঝায় যার জন্য একটি একক SparseCore লুকআপ পরিচালনা করে।
• SPMEM বাফার বরাদ্দ : এই সীমাগুলি XLA কম্পাইলার দ্বারা স্ট্যাটিক আকারে ব্যবহার করা হয় এবং অন-ডিভাইস স্ক্র্যাচপ্যাড মেমরি (SPMEM) এর মধ্যে বাফার বরাদ্দ করা হয়। বাফারগুলি এমনভাবে পরিমাপ করা হয় যে প্রদত্ত পার্টিশনের জন্য আইডি সম্পর্কিত সমস্ত প্রয়োজনীয় ডেটা (নির্দিষ্ট max_ids এবং max_unique_ids সীমা পর্যন্ত) প্রক্রিয়াকরণের জন্য SPMEM-এ লোড করা যেতে পারে। এটি বিশেষত উপাদান-ভিত্তিক গণনার জন্য গুরুত্বপূর্ণ, যেমন একটি পার্টিশনের মধ্যে ডুপ্লিকেট আইডিগুলি হ্রাস করা (উদাহরণস্বরূপ, একটি কম্প্রেসড স্পার্স রো (CSR) উপস্থাপনা তৈরি করার সময়), যেখানে সেই পার্টিশনের আইডিগুলির জন্য সম্পূর্ণ প্রাসঙ্গিক ডেটাসেট দ্রুত মেমরিতে সহজেই উপলব্ধ হওয়া প্রয়োজন।

• সংকলিত সীমা বনাম পর্যবেক্ষণ সীমা :

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

• সীমা গণনা করা : উপযুক্ত সীমা নির্ধারণের প্রক্রিয়ার মধ্যে ইনপুট ডেটা বিতরণের একটি যত্নশীল বিশ্লেষণ জড়িত। যেকোনো প্রদত্ত টেবিলের জন্য (আসুন এটিকে T1 বলি, যা নিজেই একটি বড় স্ট্যাক করা টেবিলের অংশ হতে পারে T ):

  1. ইনপুট ব্যাচ (উদাহরণস্বরূপ, আকৃতির একটি 2D SparseTensor [BatchSize, MaxSequenceLength] ) প্রাথমিকভাবে উপলব্ধ SparseCores জুড়ে বিভক্ত হয়। উদাহরণস্বরূপ, যদি একটি TensorCore 2টি SparseCores-এর সাথে যুক্ত করা হয়, প্রতিটি SparseCore আকৃতির একটি সাব-ব্যাচ পেতে পারে [BatchSize/2, MaxSequenceLength] ।
  2. এই সাব-ব্যাচটি তারপর COO ফর্ম্যাটে রূপান্তরিত হয়, row_ids এবং col_ids দেয়।
  3. একই নমুনার মধ্যে ডুপ্লিকেট আইডি (অর্থাৎ, একই row_id এবং col_id সহ এন্ট্রি) সরানো হয়।
  4. প্রতিটি অবশিষ্ট অনন্য col_id জন্য (একটি নমুনার মধ্যে), এই ID-এর জন্য দায়ী লক্ষ্য SparseCore mod-sharding নিয়ম ব্যবহার করে নির্ধারিত হয়: target_sc_id = col_id % num_total_sparse_cores ।
  5. প্রতিটি target_sc_id জন্য নির্দিষ্ট target_sc_id স্বতন্ত্রতা নিশ্চিত করার পর মোট আইডি ( ids_per_sparse_core[target_sc_id]++ ) এবং অনন্য আইডির সংখ্যা ( unique_ids_per_sparse_core[target_sc_id]++ ) একটি গণনা বজায় রাখা হয়।
  6. টেবিল T1 জন্য max_ids_per_partition তারপর max(ids_per_sparse_core_array) এ সেট করা হয়েছে।
  7. একইভাবে, টেবিল T1 জন্য max_unique_ids_per_partition max(unique_ids_per_sparse_core_array) এ সেট করা হয়েছে।
  8. যদি টেবিল T1 একটি স্ট্যাক করা টেবিলের একটি উপাদান হয়, তবে সমস্ত উপাদান টেবিল থেকে পরিসংখ্যান যোগ করার আগে আইডি বিতরণে ঘূর্ণন বা শিফটের মতো অতিরিক্ত রূপান্তর প্রয়োগ করা যেতে পারে। এটি চিপস জুড়ে ভার ভারসাম্য বজায় রাখতে সহায়তা করে।

এই সীমাগুলি সঠিকভাবে সেট করা একটি ভারসাম্যমূলক কাজ: নিম্ন সীমাগুলি সম্ভাব্যভাবে উচ্চ কার্যক্ষমতার দিকে নিয়ে যেতে পারে (যেহেতু প্রতি ধাপে কম ডেটা প্রক্রিয়া করা প্রয়োজন এবং SPMEM চাপ হ্রাস করা হয়), কিন্তু যদি খুব কম সেট করা হয়, তাহলে এর ফলে অত্যধিক মিনি-ব্যাচিং বা অবাঞ্ছিত আইডি ড্রপ হতে পারে।

8. প্রতিটি SparseCore কিভাবে যোগাযোগ করে

SparseCore যোগাযোগ, বিশেষ করে এম্বেডিং লুকআপের জন্য আইডিগুলির একটি তালিকা প্রক্রিয়াকরণের প্রসঙ্গে, বিভিন্ন সমন্বিত প্রক্রিয়ার উপর নির্ভর করে:

• মোড শার্ডিং এবং অন্তর্নিহিত রাউটিং :
  • এম্বেডিং টেবিলগুলি সিস্টেমের সমস্ত SparseCores জুড়ে মোড-শার্ড করা হয়।
  • যখন হোস্ট ইনপুট ডেটার একটি ব্যাচ প্রদান করে (যা পরবর্তীতে col_ids সহ COO ফর্ম্যাটে প্রি-প্রসেস করা হয়), সেই নির্দিষ্ট ID-এর জন্য কোন SparseCore দায়ী তা নির্ধারণ করতে col_id মান ব্যবহার করা হয়: target_sc_id = col_id % num_total_sparse_cores ।
  • প্রতিটি SparseCore কার্যকরভাবে শুধুমাত্র আইডিগুলির উপসেটগুলি গ্রহণ করে এবং প্রক্রিয়া করে যা তার নির্ধারিত শব্দভাণ্ডার পার্টিশনে ম্যাপ করে। হোস্ট প্রিপ্রসেসিং পর্যায়টি এমনভাবে ডেটা প্রস্তুত করার জন্য অত্যন্ত গুরুত্বপূর্ণ যাতে প্রতিটি স্পারসকোর তার প্রাসঙ্গিক আইডিগুলিকে সহজেই সনাক্ত করতে এবং পরিচালনা করতে পারে।
• হোস্ট দ্বারা ডেটা বিতরণ :
  • হোস্ট প্রিপ্রসেসিং লজিক সামগ্রিক ইনপুট ব্যাচকে বিভাজন করে এবং row_ids এবং col_ids এর প্রাসঙ্গিক অংশগুলি (প্রযোজ্য যেকোন সম্পর্কিত বৈশিষ্ট্য বা ওজন সহ) হয় মেমরিতে (HBM) প্রতিটি SparseCore দ্বারা সরাসরি অ্যাক্সেসযোগ্য বা একটি ভাগ করা HBM-এ বিতরণ করে যেখান থেকে SparseCores তাদের প্রয়োজনীয় ডেটা আনবে।
• ইন্ট্রা-স্পার্সকোর প্রক্রিয়াকরণ :
  • একবার একটি SparseCore একটি প্রদত্ত টেবিল পার্টিশনের জন্য আইডিগুলির নির্ধারিত সেট পেয়ে গেলে, এটি এই আইডিগুলির অনুলিপিকরণ এবং সংশ্লিষ্ট এমবেডিং ভেক্টরগুলি সংগ্রহ করার মতো ক্রিয়াকলাপগুলি সম্পাদন করে। এগুলি মূলত স্থানীয় গণনা যা SparseCore এর নিজস্ব টাইলসের মধ্যে সম্পাদিত হয় এবং এর স্থানীয় SPMEM ব্যবহার করে।
• ইন্টার-স্পার্সকোর কমিউনিকেশন (অল-টু-অল) :
  • প্রাথমিক প্রক্রিয়াকরণ পর্যায়ের পরে (যেমন এম্বেডিং লুকআপ), একটি "অল-টু-অল" যোগাযোগ প্যাটার্ন ব্যবহার করা যেতে পারে SparseCores জুড়ে ফলাফল একত্রিত বা পুনরায় বিতরণ করতে (উদাহরণস্বরূপ, একটি TensorCore স্তরে সক্রিয়করণগুলি খাওয়ানোর আগে যা সমস্ত মূল নমুনা অবস্থানের সাথে সম্পর্কিত ইনপুট আশা করে)। মূল ইনপুট ব্যাচ সমান্তরাল প্রক্রিয়াকরণের জন্য বিতরণ করা হলে সক্রিয়করণের সম্পূর্ণ সেট পুনর্গঠনের জন্য এটি গুরুত্বপূর্ণ।
• TensorCores এর সাথে যোগাযোগ :
  • SparseCores এম্বেডিং অ্যাক্টিভেশন পাঠাতে (ফরওয়ার্ড পাসের সময়) এবং গ্রেডিয়েন্ট গ্রহণ করতে (পশ্চাদগামী পাসের সময়) টেনসরকোরসের সাথে যোগাযোগ করে। এই মিথস্ক্রিয়াটি XLA-সংকলিত প্রোগ্রাম দ্বারা সংগঠিত হয় এবং প্রায়শই একটি মধ্যস্থতাকারী বাফার হিসাবে এইচবিএমকে জড়িত করে। পাইপলাইনিং কৌশল (আগে আলোচনা করা হয়েছে) এই SC-TC যোগাযোগের সময় এবং সিঙ্ক্রোনাইজেশনকে ব্যাপকভাবে প্রভাবিত করে।

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

9. SparseCore মেমরি ব্যবস্থাপনা

প্রতিটি SparseCore দক্ষতার সাথে তার গণনা সম্পাদন করতে বিভিন্ন ধরণের মেমরি পরিচালনা করে:

• স্ক্র্যাচপ্যাড মেমরি (SPMEM) :
  • প্রকৃতি : একটি অপেক্ষাকৃত ছোট, কিন্তু খুব দ্রুত, স্থানীয় SRAM যা প্রতিটি SparseCore-এর জন্য একচেটিয়াভাবে উপলব্ধ। এটা মনে রাখা গুরুত্বপূর্ণ যে SPMEM একটি ক্যাশে নয়; এর ব্যবহার XLA কম্পাইলার দ্বারা সুস্পষ্টভাবে পরিচালিত এবং অর্কেস্ট্রেট করা হয়।
  • উদ্দেশ্য : SPMEM "সুবিধাবাদীভাবে ডেটা স্টেজ" করতে ব্যবহৃত হয়। এর মধ্যে ইনপুট, আউটপুট এবং মধ্যবর্তী ফলাফল রয়েছে যা চলমান SC গণনার জন্য প্রয়োজনীয়। SPMEM-এ ডেটা স্টেজিং উল্লেখযোগ্যভাবে HBM অ্যাক্সেস করার সাথে যুক্ত উচ্চ লেটেন্সি হ্রাস করে।
  • সাইজিং : "সীমা" বিভাগে যেমন আলোচনা করা হয়েছে, কম্পাইলের সময় SPMEM বাফারগুলি স্ট্যাটিকভাবে আকার দেওয়া হয়। এই সাইজিং max_ids_per_partition এবং max_unique_ids_per_partition এর মত প্যারামিটারের উপর ভিত্তি করে করা হয়। এই স্ট্যাটিক অ্যালোকেশন নিশ্চিত করে যে একটি টেবিল পার্টিশনে যে কোনো প্রদত্ত অপারেশনের জন্য (যেমন CSR হ্রাস), সেই পার্টিশনের আইডিগুলির জন্য সমস্ত প্রয়োজনীয় ডেটা (সংজ্ঞায়িত সীমা পর্যন্ত) SPMEM-এ ফিট হতে পারে।
  • কম্পাইলার অপ্টিমাইজেশান : XLA কম্পাইলার অত্যাধুনিক অপ্টিমাইজেশানগুলিকে অন্তর্ভুক্ত করে সঠিকভাবে নির্ধারণ করতে কতটা ডেটা এবং কোন নির্দিষ্ট ডেটা উপাদানগুলিকে কার্যকরভাবে HBM লেটেন্সি লুকিয়ে রাখতে এবং পারফরম্যান্সকে সর্বোচ্চ করতে SPMEM-এ মঞ্চস্থ করতে হবে৷
  • গতিশীল বরাদ্দের সীমাবদ্ধতা : SparseCore কম্পাইলার বর্তমানে গতিশীল স্ক্র্যাচপ্যাড বরাদ্দ সমর্থন করে না। এটি সীমার সতর্ক কনফিগারেশনের মাধ্যমে স্ট্যাটিক সাইজিংয়ের গুরুত্বপূর্ণ গুরুত্ব তুলে ধরে।
• উচ্চ ব্যান্ডউইথ মেমরি (HBM) :
  • প্রকৃতি : একটি বৃহৎ, শেয়ার করা মেমরি রিসোর্স যা সকল SparseCores, TensorCores, এবং হোস্ট সিস্টেম দ্বারা অ্যাক্সেসযোগ্য। প্রাথমিক এম্বেডিং টেবিলগুলি HBM এ সংরক্ষণ করা হয়।
  • স্ট্যাক ব্যবহার : SparseCore অপারেশনগুলির জন্য প্রায়ই মধ্যবর্তী ফলাফলের জন্য HBM-এ অস্থায়ী সঞ্চয়স্থানের প্রয়োজন হয় যা হয় সীমিত SPMEM-এর সাথে খাপ খায় না বা প্রক্রিয়াকরণ পাইপলাইনের বৃহত্তর পর্যায়গুলির মধ্যে পাস করতে হয়। ফরোয়ার্ড এবং ব্যাকওয়ার্ড উভয় পাসের সময় HBM স্ট্যাকের ব্যবহার নিম্নরূপ অনুমান করা যেতে পারে -
    • ফরোয়ার্ড পাস HBM স্ট্যাক (একক টেবিল) ≈ (2 * feature_width + 1) * max_unique_nz_per_row * logical_replica_count * 4 বাইট
    • ব্যাকওয়ার্ড পাস এইচবিএম স্ট্যাক (একক টেবিল) ≈ 3 * feature_width * max_unique_nz_per_row * logical_replica_count * 4 বাইট
  • হিপ ব্যবহার : HBM হিপকেও মিটমাট করে, যা হোস্ট দ্বারা পরিচালিত হয়। হিপ ডেটা সঞ্চয় করে যেমন ঘন স্তরের ওজন, মডেল দ্বারা ব্যবহৃত ধ্রুবক এবং প্রিফেচ করা ইনপুট ডেটা। হোস্ট ডেটা প্রিফেট করে ( maximum_parallel_iterations পতাকা দ্বারা নিয়ন্ত্রিত) ধাপের সংখ্যার সাথে হিপ ব্যবহার বৃদ্ধি পায়। যদিও আরও প্রিফেচিং ডিভাইস গণনার সাথে হোস্ট-টু-ডিভাইস স্থানান্তরকে ওভারল্যাপ করে কার্যক্ষমতা উন্নত করতে পারে, এটি আরও HBM খরচ করে।
  • এইচবিএম অপ্টিমাইজেশানের জন্য সিরিয়ালাইজেশন : ফ্ল্যাগ xla_sc_num_serialized_tables_to_optimize_hbm কোন নির্দিষ্ট সময়ে HBM স্ট্যাক মেমরিতে কতগুলি টেবিলের ডেটা "লাইভ" রাখা হবে তা নিয়ন্ত্রণ করার একটি ব্যবস্থা প্রদান করে। এই সংখ্যা বাড়ানো কার্যকরীভাবে আরও টেবিলের জন্য প্রক্রিয়াকরণকে সিরিয়ালাইজ করে, যা সর্বোচ্চ HBM স্ট্যাকের ব্যবহার কমাতে পারে কিন্তু সমান্তরালতা হ্রাসের কারণে কার্যক্ষমতার খরচ হতে পারে।
• ভেক্টর মেমরি (VMEM) :
  • VMEM হল একটি স্থানীয় স্ক্র্যাচপ্যাড মেমরি যা একচেটিয়াভাবে TC (TensorCore) দ্বারা ব্যবহৃত হয়। যদিও VMEM সরাসরি SparseCore দ্বারা পরিচালিত হয় না, এটি মেমরি ইকোসিস্টেমের একটি অবিচ্ছেদ্য অংশ যার সাথে SC যোগাযোগ করে, প্রাথমিকভাবে TensorCore এর মাধ্যমে।

সামগ্রিক মেমরি ব্যবস্থাপনা কৌশল:

SparseCore-এর মূল মেমরি ম্যানেজমেন্ট কৌশলটি "হট" ডেটার জন্য ছোট, দ্রুত SPMEM ব্যবহার করে ঘোরে যা একটি SparseCore টাইল দ্বারা সক্রিয়ভাবে প্রক্রিয়া করা হচ্ছে, যার ফলে ধীরগতির HBM-এ অ্যাক্সেস কমিয়ে দেওয়া হয়। কনফিগার করা সীমা হল SPMEM যাতে ওভারফ্লো না হয় তা নিশ্চিত করার প্রাথমিক প্রক্রিয়া। HBM বড় এম্বেডিং টেবিল এবং অস্থায়ী ডেটা সঞ্চয় করার জন্য ব্যবহার করা হয় যা হয় SPMEM ধারণক্ষমতা অতিক্রম করে বা বিভিন্ন প্রক্রিয়াকরণ ইউনিট বা পাইপলাইন পর্যায়ে ভাগ করা প্রয়োজন। XLA কম্পাইলার এই স্থাপত্য নীতি এবং ব্যবহারকারী-কনফিগার করা সীমার উপর ভিত্তি করে সমস্ত ডেটা চলাচল এবং বাফার বরাদ্দের জন্য দায়ী।

10. কর্মক্ষমতা এবং মেমরি বাধা

SparseCore-এর সাথে সর্বোত্তম পারফরম্যান্স অর্জনের জন্য সম্ভাব্য প্রতিবন্ধকতাগুলি এবং কীভাবে সেগুলি মোকাবেলা করা যায় সে সম্পর্কে একটি পরিষ্কার বোঝার প্রয়োজন। এগুলি হোস্টে, স্পারসকোরের মধ্যেই বা টেনসরকোরের সাথে এর মিথস্ক্রিয়ায় দেখা দিতে পারে।

সাধারণ কর্মক্ষমতা বাধা:

• হোস্ট বাধা :
  • সমস্যা : হোস্ট সিপিইউ ডেটা প্রিপ্রসেস করতে ব্যর্থ হতে পারে এবং এটি টিপিইউতে দ্রুত যথেষ্ট পরিমাণে ফিড করতে পারে, যার ফলে স্পারসকোরস এবং টেনসরকোরস-এর ব্যবহার কম হয়। এটি একটি ঘন ঘন কর্মক্ষমতা সীমাবদ্ধ.
  • প্রশমন : হোস্ট সিপিইউ ব্যবহার এবং ইনপুট পাইপলাইন মেট্রিক্স মনিটর করুন। হোস্ট-সাইড ডেটা লোডিং এবং প্রিপ্রসেসিং রুটিনগুলি অপ্টিমাইজ করুন (সিওও রূপান্তর টিপস পড়ুন)। সূক্ষ্ম-টিউন ডেটা প্রিফেচিং-এ maximum_parallel_iterations পতাকা সামঞ্জস্য করুন।
• সাবঅপ্টিমাল TC/SC সিঙ্ক্রোনাইজেশন (পাইপলাইনিংয়ের অভাব) :
  • ইস্যু : যদি TensorCore এবং SparseCore-এর মধ্যে পাইপলাইন নিষ্ক্রিয় করা হয় বা দক্ষতার সাথে কাজ না করে, তাহলে একটি ইউনিট অন্যটির জন্য অপেক্ষা করার জন্য উল্লেখযোগ্য সময় ব্যয় করতে পারে, যার ফলে সামগ্রিক সিস্টেম থ্রুপুট হ্রাস পায়।
  • প্রশমনঃ নিশ্চিত করুন যে পাইপলাইনিং সক্রিয় আছে (উদাহরণস্বরূপ, tf_xla_disable_full_embedding_pipelining = false বা এর সমতুল্য)।
• সীমা-প্ররোচিত বাধা :
  • সমস্যা :
    • সীমা খুব কম : অতিরিক্ত মিনি-ব্যাচিং ট্রিগার করতে পারে (আঁটসাঁট সীমা পূরণের জন্য ইনপুট ব্যাচগুলিকে অসংখ্য ছোট সাব-ব্যাচে বিভক্ত করা)। যদিও এটি সঠিকতা বজায় রাখে, প্রতিটি মিনি-ব্যাচ কিছু প্রসেসিং ওভারহেড প্রবর্তন করে, সম্ভাব্যভাবে সামগ্রিক নির্বাহকে ধীর করে দেয়। allow_id_dropping সত্য হলে, অত্যধিক কম সীমাও আইডি ড্রপিং হতে পারে, যা মডেলের সঠিকতাকে প্রভাবিত করে।
    • সীমাগুলি খুব বেশি (কিন্তু এখনও উপযুক্ত) : যদিও খুব উচ্চ সীমাগুলি মিনি-ব্যাচিং প্রতিরোধ করতে পারে, তবে প্রকৃত ডেটা বৈশিষ্ট্যগুলি খুব কমই এই সর্বোচ্চ মানগুলির কাছে গেলে তারা অপ্রয়োজনীয়ভাবে SPMEM চাপ বাড়াতে পারে। এগুলি কঠোরভাবে প্রয়োজনের চেয়ে বড় HBM স্ট্যাক ব্যবহারের দিকে নিয়ে যেতে পারে।
    • কম্পাইলেশন ব্যর্থতা : কনফিগার করা সীমার জন্য উপলব্ধ শারীরিক মেমরির চেয়ে বেশি SPMEM বা HBM স্ট্যাকের প্রয়োজন হলে, সংকলন ব্যর্থ হবে।
  • প্রশমন : সীমা সঠিকভাবে সেট করা হয়েছে তা নিশ্চিত করুন।
• ডেটা বিতরণ তির্যক :
  • ইস্যু : যদি নির্দিষ্ট স্পারসকোর পার্টিশনগুলি ধারাবাহিকভাবে অন্যদের তুলনায় অসম পরিমাণে বেশি সংখ্যক আইডি পায় (একটি দুর্বল আইডি বিতরণ নির্দেশ করে), সেগুলি ওভারলোড করা স্পারসকোরগুলি কার্যক্ষমতার বাধা হয়ে দাঁড়াবে৷
  • প্রশমন : মিনি-ব্যাচিং প্রক্রিয়া চলাকালীন আইডি শাফলিং স্ট্যাক করা টেবিলের জন্য এটি উপশম করতে সাহায্য করতে পারে, বিশেষ করে যাদের "হট" ব্যবহারকারী টেবিল রয়েছে। উপযুক্ত এবং ভারসাম্যপূর্ণ প্রতি-টেবিল সীমা সেট করতে আইডি বিতরণগুলি সাবধানে বিশ্লেষণ করুন।
• টেবিল স্ট্যাকিং সমস্যা :
  • সমস্যা :
    • খুব কম টেবিল স্তুপীকৃত : কার্যকরভাবে ICI লেটেন্সি লুকাতে বা প্রক্রিয়াকরণ ওভারহেডগুলি পর্যাপ্তভাবে কমাতে যথেষ্ট নাও হতে পারে৷
    • অনেকগুলি টেবিল স্তুপীকৃত : খুব বড় লজিক্যাল টেবিল তৈরি হতে পারে যা পরিচালনা করতে অদম্য হয়ে ওঠে বা উপলব্ধ সংস্থান সীমা অতিক্রম করতে পারে।
  • প্রশমন :
    • স্ট্যাকিংয়ের জন্য সর্বোত্তম সংখ্যক টেবিল নিশ্চিত করুন। একটি সাধারণ নির্দেশিকা স্ট্যাকিংয়ের জন্য 5-100 টেবিলের একটি "মিষ্টি স্থান" প্রস্তাব করে।
• অদক্ষ সংখ্যা/পরিমাণকরণ :
  • ইস্যু : সম্পূর্ণ FP32 নির্ভুলতা ব্যবহার করা যখন BF16 বা কোয়ান্টাইজড পূর্ণসংখ্যার মতো নিম্ন নির্ভুলতা বিন্যাস যথেষ্ট হবে (এবং দ্রুত গণনা অফার করে) একটি কর্মক্ষমতা বাধা হতে পারে।
  • প্রশমন : নিম্ন নির্ভুলতার বিকল্পগুলি অন্বেষণ করুন। যাইহোক, সচেতন থাকুন যে কোয়ান্টাইজেশনের নিজেই কিছু ওভারহেড আছে এবং মডেলের নির্ভুলতা বজায় রাখার জন্য কোয়ান্টাইজেশন প্যারামিটারগুলির যত্নশীল টিউনিংয়ের প্রয়োজন হতে পারে।
• HBM ব্যান্ডউইথ স্যাচুরেশন :
  • সমস্যা : HBM-এ এবং থেকে অত্যধিক ডেটা চলাচল, সম্ভাব্যভাবে খুব ছোট বৈশিষ্ট্যের প্রস্থ (উচ্চ প্যাডিং ওভারহেডের দিকে পরিচালিত করে), অদক্ষ মেমরি অ্যাক্সেস প্যাটার্ন, বা অত্যন্ত সংখ্যক লুকআপ, উপলব্ধ HBM ব্যান্ডউইথকে পরিপূর্ণ করতে পারে।
  • প্রশমন : TPU-র সংখ্যা স্কেল করা HBM ব্যান্ডউইথ স্যাচুরেশনে সাহায্য করতে পারে।

সাধারণ স্মৃতির বাধা:

• SPMEM ওভারফ্লো (সংকলন ব্যর্থতা) :
  • সমস্যা : যদি max_ids_per_partition এবং max_unique_ids_per_partition খুব বেশি সেট করা হয়, XLA কম্পাইলার পর্যাপ্ত SPMEM বরাদ্দ করতে অক্ষম হতে পারে, যার ফলে কম্পাইলেশন ত্রুটিগুলি দেখা দেয় যেমন: "Fixed size allocations (...) do not fit in TileSpmem (...)" । অতিরিক্তভাবে, যদি শব্দটি (sample_count * feature_width) / kNumTiles (যেখানে kNumTiles হল প্রতি SC প্রতি টাইলের সংখ্যা) টাইল SPMEM-এর মধ্যে গ্যাদার অপারেন্ড স্টেজ করার জন্য খুব বড় হয়, "Gather operand too large..." এর মতো ত্রুটি ঘটতে পারে।
  • প্রশমন : ব্যাচের আকার হ্রাস করুন বা প্রক্রিয়াকরণের জন্য ব্যবহৃত চিপের সংখ্যা বাড়ান।
• HBM স্ট্যাক ওভারফ্লো (রানটাইম বা সংকলন) :
  • সমস্যা : যদি feature_width , max_unique_nz_per_row , এবং logical_replica_count এর সংমিশ্রণ HBM স্ট্যাক মেমরির প্রয়োজনীয়তার দিকে নিয়ে যায় যা উপলব্ধ HBM ছাড়িয়ে যায়, এটি রানটাইমে বা সংকলনের সময় আউট-অফ-মেমরি (OOM) ত্রুটির কারণ হতে পারে।
  • প্রশমন : টেবিলের প্রক্রিয়াকরণের মাধ্যমে এইচবিএম স্ট্যাকের ব্যবহার কমাতে xla_sc_num_serialized_tables_to_optimize_hbm ফ্ল্যাগ টিউন করুন (এটি সাধারণত পারফরম্যান্স খরচে আসে)।
• HBM গাদা ক্লান্তি :
  • সমস্যা : প্রাথমিকভাবে খুব বড় ঘন স্তরের ওজন, মেমরিতে সংরক্ষিত অসংখ্য ধ্রুবক, বা অত্যধিক আক্রমণাত্মক ইনপুট প্রিফেচিং (উচ্চ maximum_parallel_iterations ) দ্বারা সৃষ্ট।
  • প্রশমন : XProf মেমরি ভিউয়ারের মতো টুল ব্যবহার করে হিপ ব্যবহার নিরীক্ষণ করুন।
• ওভারহেড প্যাডিং :
  • ইস্যু : বৈশিষ্ট্যের মাত্রায় এম্বেডিং টেবিলগুলি 32B-সারিবদ্ধ (8 ফ্লোটের সমতুল্য) প্যাড করা হয়েছে৷ ফলস্বরূপ, ছোট বৈশিষ্ট্যের প্রস্থ (উদাহরণস্বরূপ, 1 ফ্লোট) উল্লেখযোগ্য প্যাডিং ওভারহেড বহন করে (উদাহরণস্বরূপ, বরাদ্দকৃত বাফার স্থানের 7/8 প্যাডিং), যার ফলে এইচবিএম নষ্ট হয়। টেবিলের শব্দভান্ডারের মাত্রাও প্যাড করা হয় যাতে সিস্টেমে স্পারসকোরের সংখ্যার একাধিক হয়; যাইহোক, এই প্রভাব সাধারণত যথেষ্ট উচ্চ শব্দভান্ডারের আকারের টেবিলের জন্য নগণ্য।

কর্মক্ষমতা এবং স্মৃতিকে প্রভাবিত করে এমন সাধারণ কারণগুলি:

• টপোলজি : উপলব্ধ চিপ সংখ্যা এবং তাদের আন্তঃসংযোগ আর্কিটেকচার.
• ব্যাচের আকার : স্পারসকোর প্রতি sample_count সরাসরি প্রভাবিত করে, যা ফলস্বরূপ মেমরি খরচ এবং গণনা লোডকে প্রভাবিত করে।
• ডেটা ফরম্যাটিং : একটি দক্ষ অন-ডিভাইস ডেটা লেআউট নিশ্চিত করা সর্বোত্তম কর্মক্ষমতার জন্য অত্যন্ত গুরুত্বপূর্ণ।

11. একটি SparseCore প্রোফাইল বিশ্লেষণ করা

একটি পারফরম্যান্স প্রোফাইল বিশ্লেষণ করা হল বাধা শনাক্ত করার এবং আপনার SparseCore কাজের চাপের মধ্যে অপ্টিমাইজেশনের সুযোগ উন্মোচনের একটি মূল পদক্ষেপ।

1. একটি ট্রেস পান :
   • আপনার মডেল প্রশিক্ষণ বা অনুমান চালানোর সময় একটি বিস্তারিত এক্সিকিউশন ট্রেস ক্যাপচার করতে প্রোফাইলিং টুলস, যেমন XProf ব্যবহার করুন। এই ট্রেস হোস্ট, TensorCores এবং SparseCores-এ ঘটছে অপারেশনের একটি সময়রেখা প্রদান করবে।
2. ট্রেস ভিউয়ার পরীক্ষা করুন (উদাহরণস্বরূপ, XProf বা TensorBoard এ) :
   • হোস্ট কার্যকলাপ : হোস্ট এর কার্যকলাপ যাচাই. TPU কার্যকলাপে উল্লেখযোগ্য ফাঁক আছে? এই ধরনের ফাঁকগুলি ইঙ্গিত দিতে পারে যে হোস্ট একটি বাধা, যথেষ্ট দ্রুত ডেটা ফিড করতে ব্যর্থ। আপনার ইনপুট পাইপলাইনের কর্মক্ষমতা বিশ্লেষণ করুন।
   • TensorCore (TC) এবং SparseCore (SC) কার্যকলাপ :
     • TC এবং SC উভয়ের জন্যই সম্পাদনের সময়সীমা দেখুন। তারা কি সমান্তরালভাবে কাজ করছে, কার্যকর পাইপলাইনিং নির্দেশ করে? অথবা সেখানে বর্ধিত সময়সীমা আছে যেখানে একটি ইউনিট অলস, অন্যটির জন্য অপেক্ষা করছে?
     • SC এবং TC উভয় ক্ষেত্রেই যে অপারেশনগুলি সবচেয়ে বেশি সময় ব্যয় করে (সবচেয়ে বেশি সময় ধরে চলা অপারেশন) সনাক্ত করুন৷
     • ভিজ্যুয়াল ট্রেস আউটপুট (প্রায়শই রঙিন ব্লক দেখানো হয় যা সময়ের সাথে বিভিন্ন ক্রিয়াকলাপের প্রতিনিধিত্ব করে, যেমন TPU:0 SparseCore 1 (pid 1005) ) প্রভাবশালী ক্রিয়াকলাপ এবং নিষ্ক্রিয় সময়গুলিকে দৃশ্যমানভাবে সনাক্ত করার জন্য অমূল্য।
   • ধাপের সময় বিশ্লেষণ : সামগ্রিক ধাপ সময় পর্যবেক্ষণ করুন এবং হোস্ট প্রসেসিং, এসসি গণনা এবং টিসি গণনার মধ্যে কীভাবে এটি বিতরণ বা ভাঙা হয় তা বুঝুন।
3. মেমরি বিশ্লেষণ (XProf মেমরি ভিউয়ার) :
   • হিপ ব্যবহার : HBM হিপ ব্যবহার পরিদর্শন করতে XProf-এর "মেমরি ভিউয়ার" ট্যাবের মতো টুল ব্যবহার করুন। এটি নির্ধারণ করতে সাহায্য করতে পারে যে বড় মডেলের ওজন, ধ্রুবক, বা অত্যধিক আক্রমণাত্মক ইনপুট প্রিফেচিং অত্যধিক পরিমাণে HBM গ্রহণ করছে কিনা। --vmodule=best_fit_allocator=1 মতো পতাকা সক্ষম করা পিক হিপ ব্যবহারের লগ সরবরাহ করতে পারে।
   • স্ট্যাক ব্যবহার (পরোক্ষ) : যখন সরাসরি এইচবিএম স্ট্যাক প্রোফাইলিং জটিল হতে পারে, যদি আপনি মেমরির বাইরে ত্রুটিগুলি এবং স্তূপের ব্যবহার যুক্তিসঙ্গত বলে মনে করেন তবে এইচবিএম স্ট্যাক ক্লান্তি (প্রায়শই অত্যধিক বড় সীমা বা বৈশিষ্ট্য প্রস্থের কারণে) একটি শক্তিশালী সন্দেহভাজন। এইচবিএম স্ট্যাক ব্যবহারের জন্য প্রদত্ত সূত্রগুলি এটি অনুমান করতে সহায়তা করতে পারে।
4. নির্দিষ্ট নিদর্শনগুলির সন্ধান করুন :
   • মিনি-ব্যাচিং : যদি সীমাবদ্ধতা প্রায়শই অতিক্রম করা হয় তবে আপনি ট্রেসে মিনি-ব্যাচিংয়ের প্রমাণগুলি পর্যবেক্ষণ করতে পারেন (উদাহরণস্বরূপ, বিশ্ব ব্যাচের আকারের জন্য প্রত্যাশার চেয়ে বেশি সংখ্যক এসসি অপারেশন)। এটি প্রায়শই লগগুলি থেকে বা নির্দিষ্ট ক্রিয়াকলাপগুলির অনুরোধ গণনাগুলি পর্যবেক্ষণ করে অনুমান করা যায়।
   • আইডি ড্রপিং : যদি আইডি ড্রপিং সক্ষম হয় এবং ঘটে থাকে তবে সিস্টেম লগগুলি এর ইঙ্গিতগুলি সরবরাহ করতে পারে। এটি একটি স্পষ্ট লক্ষণও হবে যে কনফিগার করা সীমাটি ইনপুট ডেটার জন্য খুব সীমাবদ্ধ।
   • সংকলনের সময় : বর্ধিত পুনঃসংযোগের সময়গুলি, বিশেষত যদি প্রতিক্রিয়া নির্দেশিত অপ্টিমাইজেশন (এফডিও) সক্ষম হয় এবং প্রায়শই সীমাবদ্ধতা সামঞ্জস্য করে, সামগ্রিক প্রশিক্ষণের সময়টিতে উল্লেখযোগ্য ওভারহেড যুক্ত করতে পারে।
5. পতাকা এবং কনফিগারেশনের সাথে সম্পর্কিত :
   • আপনার স্পারস্কোর কনফিগারেশনগুলিতে ফিরে প্রোফাইলে পর্যবেক্ষণ করা আচরণটি সম্পর্কিত (সীমাবদ্ধ ফাইলগুলিতে সেটিংস, এক্সএলএ পতাকা)। উদাহরণস্বরূপ, যদি xla_sc_num_serialized_tables_to_optimize_hbm একটি উচ্চ মানের সেট করা থাকে তবে আপনি ধীর এসসি পারফরম্যান্স আশা করতে পারেন তবে এইচবিএম স্ট্যাকের ব্যবহার কম।
6. পুনরাবৃত্ত প্রক্রিয়া :
   • প্রোফাইলিং প্রায়শই একটি পুনরাবৃত্তি পরিশোধন প্রক্রিয়া। একটি নির্দিষ্ট পরিবর্তন করুন (একটি সীমা সামঞ্জস্য করুন, কোনও বৈশিষ্ট্য সক্ষম বা অক্ষম করুন), একটি নতুন প্রোফাইল ক্যাপচার করুন এবং তারপরে আপনার পরিবর্তনের প্রভাব দেখতে পূর্ববর্তী প্রোফাইলের সাথে এটি তুলনা করুন।

12। সাধারণ ডিবাগিং পতাকা

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

• আইডি চেকস (পরিসীমা-বহির্ভূত) :
  • পতাকা : xla_sparse_core_enable_id_bound_check = true
  • উদ্দেশ্য : ইনপুট ডেটাতে কোনও এম্বেডিং আইডিগুলি প্রদত্ত এম্বেডিং টেবিলের জন্য সংজ্ঞায়িত বৈধ শব্দভাণ্ডার পরিসরের বাইরে পড়ে কিনা তা সনাক্ত করতে হোস্ট সিস্টেমে চেকগুলি সক্ষম করে। এটি ভুল বা দূষিত ইনপুট ডেটা সম্পর্কিত সমস্যাগুলি ধরতে সহায়তা করে।
• নান চেকার :
  • পতাকা : xla_sc_detect_nan = true
  • উদ্দেশ্য : স্পারস্কোরে প্রক্রিয়াজাত ভাসমান-পয়েন্ট ডেটার মধ্যে ন্যান (একটি সংখ্যা নয়) মান সনাক্তকরণ সক্ষম করে। যদি বিভিন্ন সংকলক পাসগুলির ইনপুট বা আউটপুটগুলিতে কোনও ন্যান সনাক্ত করা হয় তবে এই পতাকাটি একটি ত্রুটি উত্থাপনের কারণ হতে পারে। এই জাতীয় ত্রুটিগুলি সাধারণত ন্যানের মুখোমুখি হয়েছিল সে সম্পর্কে তথ্য সরবরাহ করে।
• বাউন্ডস চেকার (মেমরি অ্যাক্সেস) :
  • পতাকা : xla_sc_assert_level=bounds
  • উদ্দেশ্য : এই পতাকাটি গতিশীল চেকগুলি অন্তর্ভুক্ত করার জন্য একটি আসান (অ্যাড্রেসসানিটাইজার)-স্টাইল সরঞ্জাম সক্ষম করে যা মেমরি-অ্যাক্সেসের নির্দেশাবলী (যেমন ভিএমইএম লোড/স্টোর এবং ডিএমএ অপারেশন) পুনর্লিখন করে। এই চেকগুলি যাচাই করে যা মেমরি অ্যাক্সেস লক্ষ্য মেমরি অঞ্চলের বরাদ্দ সীমানার মধ্যে রয়েছে কিনা।
  • আচরণ : যদি কোনও আউট-অফ-বাউন্ডের মেমরি অ্যাক্সেস সনাক্ত করা হয় তবে কার্যকর করা ব্যর্থ হবে।
  • সতর্কতা : এই চেকারের পক্ষে মিথ্যা ধনাত্মক উত্পাদন করা সম্ভব, উদাহরণস্বরূপ, জটিল স্ট্রাইড অ্যাক্সেস নিদর্শনগুলির কারণে যা চেকার দ্বারা পুরোপুরি উপলব্ধি করা হয় না। এই রূপান্তরটি ব্যাকএন্ড সংকলন প্রক্রিয়াতে দেরী পর্যায়ে প্রয়োগ করা হয়।
• বাফার চেকার (স্মৃতি দুর্নীতি) :
  • পতাকা :
    • xla_tpu_buffer_contents_sanitizer_config='cores_to_sanitize: [TC, SC_SCS, SC_TILE], sanitizer_mode: LOCAL_ONLY'
    • xla_tpu_verify_launch_id_across_cores=true
  • উদ্দেশ্য : এই পতাকাগুলি নিশ্চিত করতে সহায়তা করে যে মেমরি বাফারগুলি অজান্তেই দুর্নীতিগ্রস্থ বা সম্পর্কযুক্ত ক্রিয়াকলাপ দ্বারা ওভাররাইট করা হচ্ছে না। বাফার স্যানিটাইজার বাফারগুলির বিষয়বস্তু যাচাই করে তা যাচাই করে যে তারা অপ্রত্যাশিতভাবে পরিবর্তন হচ্ছে না তা যাচাই করে।

13। কোয়ান্টাইজেশন সমর্থন

স্পারসোরের SparseDenseMatmulOp 32-বিট ফ্লোটিং-পয়েন্ট (এফপি 32) এবং পূর্ণসংখ্যার ডেটা প্রকার উভয়ই ব্যবহার করে এম্বেডিং টেবিলগুলিতে অপারেশনগুলিকে সমর্থন করার জন্য ডিজাইন করা হয়েছে। মডেল প্রশিক্ষণ সাধারণত এম্বেডিং টেবিলগুলির জন্য FP32 নির্ভুলতা ব্যবহার করে সঞ্চালিত হয়, প্রশিক্ষণ পরবর্তী কোয়ান্টাইজেশন (পিটিকিউ) প্রয়োগ করা যেতে পারে। পিটিকিউ অনুমানের জন্য নিম্ন-নির্ভুলতা ডেটাটাইপগুলি (8-বিট পূর্ণসংখ্যার মতো) ব্যবহারের অনুমতি দেয়, যা সম্ভাব্যভাবে উন্নত কর্মক্ষমতা এবং একটি হ্রাস মেমরির পদচিহ্নের দিকে পরিচালিত করতে পারে।

সিমুলেটেড কোয়ান্টাইজেশন:

"সিমুলেটেড কোয়ান্টাইজেশন" সম্পাদন করতে SparseDenseMatmulOp কনফিগার করা যেতে পারে। এই অপারেশনাল মোডে, এম্বেডিং ভেক্টরগুলি প্রথমে একটি নিম্ন নির্ভুলতায় পরিমাণযুক্ত হয় এবং তারপরে পরবর্তী গণনাগুলিতে ব্যবহারের আগে উচ্চতর নির্ভুলতায় ফিরে আসে (উদাহরণস্বরূপ, এফপি 32)। এই কৌশলটি কোয়ান্টাইজেশন শব্দের প্রভাবগুলির জন্য অ্যাকাউন্টিং করার সময় মডেলগুলিকে প্রশিক্ষণ দেওয়ার অনুমতি দেয়। সিমুলেটেড কোয়ান্টাইজেশন সহ প্রশিক্ষণ চূড়ান্ত মডেলের যথার্থতা উন্নত করতে পারে যখন এটি অনুমানের জন্য সম্পূর্ণরূপে পরিমাণযুক্ত হয়।

SparseDenseMatmulOp (কোয়ান্টাইজেশনের জন্য) এর জন্য কনফিগারেশন বৈশিষ্ট্য:

• quantization_config_num_buckets = 256
  • এই বৈশিষ্ট্যটি পৃথক বালতি বা স্তরগুলির সংখ্যা নির্দিষ্ট করে যেখানে 32-বিট ভাসমান-পয়েন্ট নম্বরটি কোয়ান্টাইজ করা হবে। উদাহরণস্বরূপ, 8-বিট পূর্ণসংখ্যার পরিমাণ নির্ধারণ করার সময়, একটি সাধারণত 2^8 = 256 বালতি নির্দিষ্ট করে।
• quantization_config_low = -XX
  • এই বৈশিষ্ট্যটি কোয়ান্টাইজেশন রেঞ্জের সর্বনিম্ন ভাসমান-পয়েন্ট মানকে সংজ্ঞায়িত করে। এই নির্দিষ্ট ন্যূনতম নীচে যে কোনও ইনপুট মানগুলি কোয়ান্টাইজেশনের সময় এই ন্যূনতম মানটিতে ক্লিপ করা হবে।
• quantization_config_high = YY
  • এই বৈশিষ্ট্যটি কোয়ান্টাইজেশন রেঞ্জের সর্বাধিক ভাসমান-পয়েন্ট মানকে সংজ্ঞায়িত করে। এই নির্দিষ্ট সর্বাধিক উপরে যে কোনও ইনপুট মানগুলি কোয়ান্টাইজেশনের সময় এই সর্বোচ্চ মানটিতে ক্লিপ করা হবে।

সংখ্যা এবং পাইপলাইনিং ইন্টারঅ্যাকশন:

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

14। আসন্ন বৈশিষ্ট্য এবং সাম্প্রতিক উন্নতি

স্পারসোর ইকোসিস্টেম অবিচ্ছিন্ন বিকাশ এবং বর্ধনের সাপেক্ষে।

রোডম্যাপ:

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

সাম্প্রতিক উন্নতি:

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

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