পাঠ ৫৩ · ৫৭-এর মধ্যে · মডিউল ১২
Home / Courses / Microprocessors, Embedded Systems & IoT / এজ কম্পিউটিং

এজ কম্পিউটিং ও এজ AI

Edge computing and edge AI
৯ মিনিট পড়া মধ্যম · Intermediate Python সিমুলেশনসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • এজ কম্পিউটিং কী, এবং কেন এটি সব র‌ও ডেটা ক্লাউডে পাঠানোর বিকল্প
  • এজ প্রসেসিং-এর সুবিধা (লেটেন্সি, অফলাইন সক্ষমতা, ব্যান্ডউইথ সাশ্রয়) ও সীমাবদ্ধতা (কম্পিউট/মেমরি, কোয়ান্টাইজেশন)
  • এজ AI/TinyML-এর honest-scope ধারণা — কী সম্ভব আর কী নয়
  • একটি বাস্তব সেন্সর ডেটা-রেট দৃশ্যকল্পে র‌ও ডেটা বনাম প্রসেসড রেজাল্ট পাঠানোর ব্যান্ডউইথ পার্থক্য জেনুইনভাবে গণনা

১ · কেন সব ডেটা ক্লাউডে পাঠানো সবসময় ভালো সমাধান নয়

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

  • লেটেন্সি। ডেটা ডিভাইস থেকে নেটওয়ার্ক হয়ে ক্লাউডে পৌঁছানো, প্রসেস হওয়া, এবং ফলাফল ফিরে আসা — এই পুরো রাউন্ড-ট্রিপে সময় লাগে। একটি নিরাপত্তা ক্যামেরার মোশন-ডিটেকশন বা একটি শিল্প যন্ত্রের ইমার্জেন্সি-স্টপ সিদ্ধান্তে এই বিলম্ব গ্রহণযোগ্য নাও হতে পারে।
  • অফলাইন সক্ষমতা। ইন্টারনেট/নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হলে ক্লাউড-নির্ভর ডিভাইস কাজ করা বন্ধ করে দেয়। ডিভাইসেই সিদ্ধান্ত নেওয়ার সক্ষমতা থাকলে নেটওয়ার্ক না থাকলেও মৌলিক কাজ চালু থাকে।
  • ব্যান্ডউইথ। প্রতিটি র‌ও রিডিং (বিশেষ করে উচ্চ-স্যাম্পলিং-রেট সেন্সর, যেমন ভাইব্রেশন বা অডিও) ক্রমাগত পাঠানো ব্যান্ডউইথ ও ডেটা খরচ দুটোই বাড়ায় — বিশেষত LoRaWAN/সেলুলার IoT-এর মতো সীমিত-ব্যান্ডউইথ সংযোগে (M10) এটি বড় সমস্যা।
ডিভাইস (সেন্সর) (শুধু রিডিং নেয়) র‌ও ডেটা -- প্রতি সেকেন্ডে বহু বাইট ক্লাউড (সব প্রসেসিং এখানে) ডিভাইস + এজ (স্থানীয়ভাবে প্রসেস করে) শুধু ফিচার -- প্রতি সেকেন্ডে কয়েক বাইট ক্লাউড (সংক্ষিপ্ত রেজাল্ট গ্রহণ)
উপরের পথে সব র‌ও ডেটা ক্লাউডে যায়; নিচের পথে এজেই প্রসেস করে শুধু একটি সংক্ষিপ্ত ফলাফল পাঠানো হয় — নিচের কোড সেলে এই ব্যান্ডউইথ পার্থক্য জেনুইনভাবে গণনা করা হয়েছে।

এজ কম্পিউটিংEdge Computingর‌ও ডেটা ক্লাউডে পাঠানোর বদলে ডেটা তৈরি হওয়ার জায়গার কাছাকাছি (ডিভাইসেই বা একটি লোকাল গেটওয়েতে) প্রসেসিং করা। হলো এই সমস্যাগুলোর সমাধান — ডেটা যেখানে তৈরি হচ্ছে তার কাছাকাছি (ডিভাইসেই, বা একটি লোকাল গেটওয়ে/ফগ নোডে) প্রসেসিং করে ফেলা, এবং শুধু প্রয়োজনীয়, প্রসেসড রেজাল্ট (পুরো র‌ও ডেটা নয়) ক্লাউডে পাঠানো।

২ · এজ AI — সুযোগ ও সীমাবদ্ধতা

যখন এজে চলা প্রসেসিংটি একটি মেশিন-লার্নিং মডেলের ইনফারেন্স হয় (যেমন একটি অডিও ক্লিপে "wake word" শনাক্ত করা, বা একটি ছবিতে গতি/বস্তু শনাক্ত করা), তখন একে এজ AI বা TinyML বলা হয়। এটি honest-scope-এ বোঝা জরুরি — এটি ক্লাউডের বড় মডেলের প্রতিস্থাপন নয়, বরং একটি ভিন্ন, সীমাবদ্ধ ট্রেডঅফ:

  • সীমিত কম্পিউট। একটি মাইক্রোকন্ট্রোলারের CPU একটি ক্লাউড GPU সার্ভারের তুলনায় বহু গুণ কম শক্তিশালী — বড়, জটিল নিউরাল নেটওয়ার্ক রিয়েল-টাইমে চালানো সম্ভব নয়।
  • সীমিত মেমরি। একটি সাধারণ মাইক্রোকন্ট্রোলারের SRAM/Flash কিলোবাইট থেকে কয়েক মেগাবাইটের মধ্যে (L06-এ আলোচিত মেমরি ম্যাপ অনুযায়ী) — একটি সাধারণ ক্লাউড-স্কেল মডেলের ওজন এতে ধরেই না।
  • কোয়ান্টাইজেশন। এই সীমাবদ্ধতা মোকাবিলার একটি সাধারণ, ভালোভাবে ডকুমেন্টেড কৌশল হলো মডেলের ওয়েট/অ্যাক্টিভেশনকে 32-বিট float-এর বদলে 8-বিট integer-এর মতো কম-প্রিসিশন ফরম্যাটে রূপান্তর করা — এতে মডেলের সাইজ ও কম্পিউট খরচ উল্লেখযোগ্যভাবে কমে, সামান্য নির্ভুলতা কমার বিনিময়ে।

এই কারণেই এজ AI মডেল সাধারণত অনেক ছোট ও নির্দিষ্ট একটি কাজে কেন্দ্রীভূত (যেমন শুধু "কম্পন স্বাভাবিক নাকি অস্বাভাবিক" শনাক্ত করা) — একটি সাধারণ-উদ্দেশ্যের বড় মডেল নয়।

৩ · একটি সত্যিকারের গণনা — র‌ও ডেটা বনাম এজ-প্রসেসড ফলাফল পাঠানো

L41-এর মতো একই ধরনের গণনা এখানে আরেকটু বাস্তব দৃশ্যকল্পে প্রয়োগ করা হচ্ছে। ধরা যাক একটি শিল্প যন্ত্রের ভাইব্রেশন সেন্সর ৩-অক্ষে (X/Y/Z), প্রতি অক্ষে ১৬-বিট রেজোলিউশনে, ১০০০ Hz-এ স্যাম্পল করছে। নিচের কোড সেলে এই সেন্সরের র‌ও ডেটা রেট বনাম এজে প্রসেস করে শুধু একটি সংক্ষিপ্ত ফিচার পাঠানোর ডেটা রেট জেনুইনভাবে গণনা ও তুলনা করা হয়েছে।

Python
# --- র‌ও ডেটা বনাম এজ-প্রসেসড ফলাফল পাঠানোর ব্যান্ডউইথ তুলনা ---

sample_rate_hz = 1000       # ভাইব্রেশন সেন্সরের স্যাম্পলিং রেট
axes = 3                    # X, Y, Z তিন অক্ষ
bytes_per_sample = 2        # প্রতি অক্ষে ১৬-বিট (২ বাইট) ADC রিডিং

# --- বিকল্প ১: প্রতিটি র‌ও স্যাম্পল সরাসরি ক্লাউডে পাঠানো ---
raw_bytes_per_sec = sample_rate_hz * axes * bytes_per_sample
raw_bytes_per_day = raw_bytes_per_sec * 86400

# --- বিকল্প ২: এজে প্রসেস করে প্রতি সেকেন্ডে শুধু একটি RMS ভাইব্রেশন-ম্যাগনিচিউড ফিচার (৪-বাইট float)
#     ও একটি anomaly ফ্ল্যাগ (১ বাইট) পাঠানো ---
edge_feature_bytes = 4      # RMS ম্যাগনিচিউড, float হিসেবে
edge_flag_bytes = 1         # anomaly flag (0/1)
edge_bytes_per_sec = edge_feature_bytes + edge_flag_bytes
edge_bytes_per_day = edge_bytes_per_sec * 86400

reduction_ratio = raw_bytes_per_sec / edge_bytes_per_sec
savings_pct = 100 * (1 - edge_bytes_per_sec / raw_bytes_per_sec)

print(f"সেন্সর: {axes}-অক্ষ ভাইব্রেশন, {sample_rate_hz} Hz স্যাম্পলিং, {bytes_per_sample*8}-বিট রেজোলিউশন\n")

print("বিকল্প ১ -- র‌ও ডেটা সরাসরি ক্লাউডে:")
print(f"  {raw_bytes_per_sec:,} বাইট/সেকেন্ড")
print(f"  {raw_bytes_per_day/1e6:.2f} MB/দিন\n")

print("বিকল্প ২ -- এজে প্রসেস করে শুধু ফিচার পাঠানো:")
print(f"  {edge_bytes_per_sec} বাইট/সেকেন্ড")
print(f"  {edge_bytes_per_day/1e3:.2f} KB/দিন\n")

print(f"ব্যান্ডউইথ কমেছে: {reduction_ratio:,.0f}x  ({savings_pct:.3f}% সাশ্রয়)")

    
লক্ষ্য করুন — পার্থক্যটি শুধু কিছুটা কম নয়, বরং কোড সেলের আউটপুট অনুযায়ী প্রায় ১,২০০ গুণ (৯৯.৯% এর বেশি সাশ্রয়)। এটাই কারণ কেন LoRaWAN-এর মতো লো-ব্যান্ডউইথ, লো-পাওয়ার সংযোগে (M10/L43) এজ প্রসেসিং প্রায়োগিকভাবে অপরিহার্য — একটি উচ্চ-স্যাম্পলিং-রেট সেন্সরের র‌ও ডেটা LoRaWAN-এর মতো সংযোগে পাঠানোর মতো ব্যান্ডউইথই থাকে না। তবে খেয়াল রাখুন — এজ প্রসেসিং একটি ট্রেডঅফ: ক্লাউডে আর পুরো র‌ও ওয়েভফর্ম সংরক্ষিত থাকে না, শুধু সংক্ষিপ্ত ফিচার — যদি পরে বিস্তারিত ফরেনসিক বিশ্লেষণ দরকার হয়, সেই তথ্য হারিয়ে যায়।
মূল কথা · Key takeaway

এজ কম্পিউটিং মানে ক্লাউড বাদ দেওয়া নয় — বরং কোন প্রসেসিং কোথায় হবে তা বুদ্ধিমানের সাথে ভাগ করা। লেটেন্সি, অফলাইন সক্ষমতা ও ব্যান্ডউইথ সাশ্রয়ের বিনিময়ে সীমিত কম্পিউট/মেমরির মধ্যে ছোট, প্রায়ই কোয়ান্টাইজড মডেল বা সাধারণ ফিচার-এক্সট্রাকশন লজিক দিয়ে কাজ চালাতে হয়। L54-এর ইন্ডাস্ট্রিয়াল IoT কেস স্টাডিতে এই ধরনের এজ প্রসেসিং একটি বাস্তব উদাহরণে দেখা যাবে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ইমার্জেন্সি-স্টপ সিদ্ধান্তের জন্য এজ প্রসেসিং কেন ক্লাউড-নির্ভর প্রসেসিং-এর চেয়ে ভালো পছন্দ?

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

প্র ০২ কোয়ান্টাইজেশন (32-বিট float থেকে 8-বিট integer-এ রূপান্তর) মডেলের নির্ভুলতার উপর কী প্রভাব ফেলতে পারে, এবং কেন এমবেডেড ডিভাইসে এই ট্রেডঅফ প্রায়ই গ্রহণযোগ্য?

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

প্র ০৩ উপরের কোড সেলে sample_rate_hz যদি ১০ গুণ বাড়িয়ে ১০,০০০ Hz করা হয়, তাহলে reduction_ratio-এর উপর কী প্রভাব পড়বে?

raw_bytes_per_sec সরাসরি sample_rate_hz-এর সমানুপাতিক, তাই এটিও ১০ গুণ বাড়বে। কিন্তু edge_bytes_per_sec স্যাম্পলিং রেটের উপর নির্ভর করে না (এজে প্রসেস করার পর প্রতি সেকেন্ডে একটি ফিচারই পাঠানো হয়) — তাই reduction_ratioও প্রায় ১০ গুণ বেড়ে যাবে। এটি দেখায় — স্যাম্পলিং রেট যত বেশি, এজ প্রসেসিং-এর ব্যান্ডউইথ সাশ্রয় তত বেশি গুরুত্বপূর্ণ হয়ে ওঠে।

অনুশীলন

  1. চিন্তা করুন: যদি এজ ফিচার পেলোড শুধু একটি ১-বাইট anomaly flag হতো (RMS ম্যাগনিচিউড বাদ দিয়ে), তাহলে edge_bytes_per_sec ও reduction_ratio কীভাবে বদলাতো?

    edge_bytes_per_sec ৫ থেকে কমে ১ হতো, ফলে reduction_ratio ($6000 / 1 = 6000$) আগের ($6000 / 5 = 1200$) চেয়ে ৫ গুণ বেড়ে যেত — অর্থাৎ আরও কম তথ্য পাঠানো হলে ব্যান্ডউইথ সাশ্রয় আরও বেশি হয়, তবে এর বিনিময়ে ক্লাউডে RMS মানটি আর পাওয়া যেত না।

  2. পরীক্ষা করুন: উপরের কোড সেলে axes = 3-কে axes = 1 করে (শুধু একটি অক্ষের সেন্সর ধরে নিয়ে) Run চেপে দেখুন raw_bytes_per_day ও reduction_ratio কীভাবে বদলায়।

    raw_bytes_per_sec ৩ গুণ কমে যাবে ($1000 \times 1 \times 2 = 2000$ বাইট/সেকেন্ড, আগে ছিল $6000$), ফলে raw_bytes_per_dayও প্রায় ৩ গুণ কমবে। যেহেতু edge_bytes_per_sec (৫ বাইট/সেকেন্ড) অপরিবর্তিত থাকে, reduction_ratioও প্রায় ৩ গুণ কমে যাবে — $6000/5=1200$x থেকে $2000/5=400$x-এ — কারণ এখন র‌ও ডেটাই তুলনামূলক কম।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার, এমবেডেড C, GPIO, টাইমার/PWM/ADC, সিরিয়াল প্রোটোকল, RTOS, সেন্সর/অ্যাকচুয়েটর, IoT আর্কিটেকচার, ওয়্যারলেস প্রোটোকল, MQTT/CoAP ও IoT সিকিউরিটি — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
  • Cloud Computing & DevOps কোর্স সহোদর কোর্স ক্লাউড-সাইড ইনফ্রাস্ট্রাকচার ও ডেভঅপস প্র্যাকটিসের ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই কোর্স ডিভাইস/এজ-সাইড প্রসেসিং-এ ফোকাস করে।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Design and Analysis of Algorithms ও আরও অনেক কোর্স — সব এক জায়গায়।
আগের পাঠ
এমবেডেড ডিভাইস সিকিউর করা — সিকিউর বুট ও এনক্রিপশন