alex.dev@portfolio:~$ article

Ray Cluster, কেন?

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

Published in Category:

MLOps

MLOps

AI Engineering

AI Engineering

AI Systems

AI Systems

Infrastructure

Infrastructure

Published on:

Read time:

পরিধির ইন্টার্নাল কিছু PoC'র জন্য আমরা Ray ক্লাস্টার ডেপ্লয় করে কাজ করেছি। সামনে আমরা এন্ড ইউজারদের জন্য Spark Cluster এর মতোই Ray Cluster প্রভাইড করবো। কিছুটা সময় হয়তো লাগবে।


কিন্ত, প্রশ্ন হচ্ছে Ray ক্লাস্টার নিয়ে দৌড়ঝাপ কেন?


একটা লার্জ স্কেলের মেশিন লার্নিং ওয়ার্কলোড, ধরা যাক আমাদের ডেটাসেটের সাইজ আমরা যে লোকাল মেশিনে প্রসেস করার চেষ্টা করছি তার RAM-এর ৩-৪ গুন। এই অবস্থায় স্বাভাবিক ভাবেই ওয়ার্কফ্লো কন্টিনিউ করা যাবে না। এমন সিনারিওতে কি করা যেতে পারে? একটা সমাধান হতে পারে লোকাল হার্ডওয়্যার কনফিগারেশন বাড়িয়ে ফেলা, আরো সিপিইউ, RAM, স্টোরেজ মেশিনটাতে যুক্ত করা (ভার্টিক্যাল স্কেলিং, সিস্টেম ডিজাইনের বেসিক কনসেপ্ট যদি নিয়ে আসি এখানে)।


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


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

কিন্তু তখন অনেকগুলো চ্যালেঞ্জিং টাস্ক সামনে চলে আসে, যেমন সার্ভারগুলোর নেটওয়ার্কিং কেমন হবে, ডেটাসেট কিভাবে ডিস্ট্রিবিউট হবে, ট্রেনিং ওয়ার্কলোডটাও কিভাবে সার্ভার টু সার্ভার ডিস্ট্রিবিউট হবে বা মডেল প্রডাকশনে ডেপ্লয় করার সময়ে রিসোর্স অ্যালোকেশন কেমন হবে। মানে আসলে "ডিস্ট্রিবিউটেড কম্পিউটিং" এর দরকার পড়ে যাচ্ছে।

এই সব কিছু আসলে একজন মেশিন লার্নিং ইঞ্জিনিয়ারের সমাধান করার কথা না, কিন্তু তারপরও তাকে নিজেই করতে হয় নতুবা প্ল্যাটফর্ম ইঞ্জিনিয়ারদের সাহায্য নিতে হয়। মজার ব্যাপার হচ্ছে, এভাবেই আমরা যাকে "মেশিন লার্নিং ইঞ্জিনিয়ারিং" বলছি, সেটা কিন্তু ধীরে ধীরে আল্টিমেটলি "সফটওয়্যার ইঞ্জিনিয়ারিং"-ই হয়ে যাচ্ছে।


তো এই সিনারিওটা আমরা মেশিন লার্নিং ইঞ্জিনিয়ার হিসেবে কীভাবে সমাধান করতে পারি ? আমরা তা করতে পারি Ray ক্লাস্টার বিল্ড করার মাধ্যমে। Ray মূলত একটা ডিস্ট্রিবিউটেড কম্পিউটিং ফ্রেমওয়ার্ক, যেটা এই মেশিন লার্নিং ওয়ার্কলোড কে ক্লাস্টারে থাকা নোডগুলোর মধ্যে খুব ইফেশিয়েন্টলি ডিস্ট্রিবিউট করে দেয়।

যেমন, মেশিন লার্নিং ওয়ার্কফ্লোতে থাকা ডেটাসেটগুলোর প্রসেসিং বা ট্রান্সফর্মেশন জবগুলো সবগুলো রে ক্লাস্টারে থাকা নোডগুলোতে ডিস্ট্রিবিউট হয়ে যাবে (কিছুটা Spark এর মতোই, কিন্তু Ray আর Spark এর ইন্টেগ্রেশনটা আরো বেশি চমৎকার!)


Ray যেটা করে, মেশিন লার্নিং ওয়ার্কলোডগুলোকে সব নোডে ডিস্ট্রিবিউট করে দেয়, এর পর যদি অটোস্কেলার কনফিগারেশন ঠিকঠাক থাকে তাহলে প্রয়োজন পড়লে নোড আরো বাড়িয়ে দেয় বা দরকার না পড়লে স্কেল ডাউন করে ফেলে।

অনেকভাবে, অনেক সিস্টেমে Ray ক্লাস্টার ডেপ্লয় করা যায়, সেটা ক্লাউড হোক, বেয়ার মেটাল সার্ভার হোক বা কয়েকটা পড়ে থাকা লোকাল মেশিন হোক।

কন্টেইনার, কুবারনেটিস বা ক্লাউড ভিএম, যেকোনো জায়গাতে খুব সহজেই Ray ক্লাস্টার ডেপ্লয় করে ফেলা যায়। আর ডেপ্লয়মেন্টের পর ক্লাস্টার ম্যানেজ করা আরো সহজ।

কিন্তু, ফান্ডামেন্টাল কিছু চ্যালেঞ্জ থেকেই যায়। যেমন, যে kubernetes ক্লাস্টার বা ক্লাউড ভিএমগুলোতে ক্লাস্টার ডেপ্লয় করা হবে, সেগুলোর সিকিউরিটি, সাসটেইনেবিলিটি বা অ্যাভেইলেভেলিটি কিভাবে নিশ্চিত করা যাবে? বা, এত বড় স্কেলের কম্পিউট, স্টোরেজ ইনফ্রা ডেপ্লয় করে তারপর তাতে Ray ক্লাস্টার বিল্ড করার যে লম্বা টাইম কনজিউমিং প্রসেস সেটা পুরো মেশিন লার্নিং ওয়ার্কফ্লোতে কীভাবে প্রভাব ফেলবে?


আমার কাছে ব্যক্তিগতভাবে মনে হয়, এই ইনফ্রাস্ট্রাকচার না থাকা বা ইনফ্রাস্ট্রাকচার সেটআপের বটলনেক থাকার কারণেই অনেক ভালো ভালো মেশিন লার্নিং প্রজেক্টের ইনিশিয়েশন হচ্ছে না, বা মেশিন লার্নিং ইঞ্জিনিয়াররা তাদের ফুল যে পোটেনশিয়াল সেটা আনলক করতে পারছেন না।


ইনফ্রা সেট আপ যদি অটোমেট করে ফেলা যায়, আর তাতে Ray ক্লাস্টার ডেপ্লয়মেন্টও অটোমেট করে ফেলা যায়, তাহলে মেশিন লার্নিং ওয়ার্কফ্লোর সবথেকে গুরুত্বপূর্ণ কমপোনেন্টগুলোতে ফোকাস করা একদমই সহজ হয়ে যায়। মেশিন লার্নিং রিসার্চার, বা ইঞ্জিনিয়ার বা একজন ভ্যানিলা সফটওয়্যার ইঞ্জিনিয়ার, তখন খুব সহজেই মডেল ট্রেনিং/রিট্রেনিং, ডেপ্লয়মেন্ট, ডেপ্লয়মেন্ট মনিটরিং-ম্যানেজমেন্টের কাজগুলো করে ফেলতে পারবেন (যদিও, সবসময়েই প্রজেক্টের 'কনটেক্সট' ম্যাটার করে, আমরা এটাকে কোনোভাবেই ইগনোর করে যেতে পারি না)।

এই ইনফ্রা ডেপ্লয়মেন্টের কাজটাই আমরা এখানে Pulumi দিয়ে অটোমেট করেছি। একদম এই কন্টেক্সটে দরকারী নেটওয়ার্কিং, স্টোরেজ, কম্পিউট কমপোনেন্টগুলো ডেপ্লয় করা, এমনকী কম্পিউট নোডগুলোতে রিকোয়ারমেন্টস ইন্সটলেশন্স থেকে শুরু করে Ray ক্লাস্টার বিল্ড করা, পুরো প্রসেসটুকু Pulumi দিয়েই অটোমেট করা হয়েছে। এরপর, বাকি থাকে শুধু মেশিন লার্নিং এর কোর ওয়ার্কফ্লোগুলোই।

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

সফটওয়্যার ইঞ্জিনিয়ারিং (বা এই কন্টেক্সটে MLOps Engineering) আসলে মূলত, "Abstraction upon abstraction," এখানকার আর্কিটেকচারটা দেখে হয়তো তা-ই মনে হতে পারে। কিন্তু, Ray ক্লাস্টারের অ্যাক্সেস পাওয়ার পর, সেটা হয়তো আর মনে হবে না। এই আশা-ই করছি।

MLOps

Infrastructure

15 Minute Read

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗮𝗻𝗱 𝗖𝗼𝘀𝘁 𝗘𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝗗𝗮𝘁𝗮 𝗪𝗮𝗿𝗲𝗵𝗼𝘂𝘀𝗲𝘀 𝗳𝗼𝗿 𝗦𝗠𝗕𝘀?

Modernizing data warehouses with a hybrid Azure approach enables centralized storage, real‑time analytics, and secure integration across tools like Synapse, Data Lake, Stream Analytics, and Power BI to deliver scalable insights and compliance‑ready infrastructure.

MLOps

Infrastructure

15 Minute Read

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗮𝗻𝗱 𝗖𝗼𝘀𝘁 𝗘𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝗗𝗮𝘁𝗮 𝗪𝗮𝗿𝗲𝗵𝗼𝘂𝘀𝗲𝘀 𝗳𝗼𝗿 𝗦𝗠𝗕𝘀?

Modernizing data warehouses with a hybrid Azure approach enables centralized storage, real‑time analytics, and secure integration across tools like Synapse, Data Lake, Stream Analytics, and Power BI to deliver scalable insights and compliance‑ready infrastructure.

MLOps

Infrastructure

15 Minute Read

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗮𝗻𝗱 𝗖𝗼𝘀𝘁 𝗘𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲 𝗗𝗮𝘁𝗮 𝗪𝗮𝗿𝗲𝗵𝗼𝘂𝘀𝗲𝘀 𝗳𝗼𝗿 𝗦𝗠𝗕𝘀?

Modernizing data warehouses with a hybrid Azure approach enables centralized storage, real‑time analytics, and secure integration across tools like Synapse, Data Lake, Stream Analytics, and Power BI to deliver scalable insights and compliance‑ready infrastructure.

MLOps

Infrastructure

12 Minute Read

Building Production ML Pipelines with Kubernetes

A deep dive into designing fault-tolerant, scalable ML training and serving pipelines on K8s — from resource scheduling to model versioning.

MLOps

Infrastructure

12 Minute Read

Building Production ML Pipelines with Kubernetes

A deep dive into designing fault-tolerant, scalable ML training and serving pipelines on K8s — from resource scheduling to model versioning.

MLOps

Infrastructure

12 Minute Read

Building Production ML Pipelines with Kubernetes

A deep dive into designing fault-tolerant, scalable ML training and serving pipelines on K8s — from resource scheduling to model versioning.

AI Systems

15 Minute Read

CUDA Kernel Optimization for Transformer Inference

Exploring kernel fusion, memory coalescing, and custom CUDA kernels to achieve 3x speedup in transformer model inference on consumer GPUs.

AI Systems

15 Minute Read

CUDA Kernel Optimization for Transformer Inference

Exploring kernel fusion, memory coalescing, and custom CUDA kernels to achieve 3x speedup in transformer model inference on consumer GPUs.

AI Systems

15 Minute Read

CUDA Kernel Optimization for Transformer Inference

Exploring kernel fusion, memory coalescing, and custom CUDA kernels to achieve 3x speedup in transformer model inference on consumer GPUs.

© Tahnik Ahmed | 2026