অ্যাটম পডকাস্টে উল্লেখ করেন যে OpenAI কেন Codex-এর প্রতি সংস্থান প্রাধান্য দিচ্ছে Sora-এর বদলে। Sora-এর ভিডিও জেনারেশনের জন্য বিপুল পরিমাণ নিরবচ্ছিন্ন কম্পিউটিং পাওয়ার প্রয়োজন, যা একটি টাস্কের জন্য GPU সময়কে পুনরায় ব্যবহারযোগ্য করে তোলে না; অন্যদিকে, Codex KV cache, continuous batching, এবং টুল কল মেকানিজমের মাধ্যমে কম্পিউটিং পাওয়ারকে বিভিন্ন ক্রস-অপারেটিং পর্যায়ে বিভক্ত করে, যার ফলে একই GPU-এ একাধিক সমান্তরাল ওয়ার্কফ্লোকে সমর্থন করা যায়। GPU সময়ের পুনরায় ব্যবহারের ক্ষমতা এখন AI পণ্যের বিস্তারের গতি নির্ধারণ করছে।

লেখক এবং উৎস: লেইফেঙ্গোয়েন

সোরা কেন কোডেক্সকে হারাল?

অগাস্ট ২৩-এ, অটিমান ওপেনএআই-এর ভিতরের সম্পদের প্রাধান্য নিয়ে ডেভিড সেন্রার পডকাস্টে সোরা উল্লেখ করেন।

তিনি সরাসরি বলেছেন: Sora একটি ভালো পণ্য, এটি চালিয়ে যাওয়া একটি ভালো ব্যবসা হতে পারে, কিন্তু এটি খুব বেশি compute খায়, একই সময়ে, Codex-এর অগ্রাধিকার বেশি, তাই compute এবং টিমের সম্পদ Codex-এর দিকে ঝুঁকে পড়তে শুরু করে।

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

একটি একক ভিডিও জেনারেশনে কম্পিউটেশনাল পাওয়ার কেন্দ্রীভূত করে, অন্যটি একটি এজেন্ট ওয়ার্কফ্লোতে কম্পিউটেশনাল পাওয়ার বিস্তার করে যা কয়েক দশক পর্যন্ত বা তারও বেশি সময় ধরে চলতে পারে। তাই, Sora এবং Codex-এর প্রকৃত পার্থক্য শুরু হচ্ছে ডেটা সেন্টারের ভিতরে।

একই ধরনের GPU এর জন্য, ভিডিও জেনারেশনের কম্পিউট কেন বেশি কঠিনভাবে বণ্টন করা যায়, যখন কোডিং এজেন্ট KV ক্যাশ, কন্টিনিউয়াস ব্যাচিং, প্রিফিল / ডিকোড স্কিডিউলিং এবং টুল ওয়েটিংয়ের মাধ্যমে ক্যালকুলেশনকে আরও বেশি সমান্তরাল টাস্কে ফিরিয়ে আনতে পারে?

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

এই লাইনের নিচে দেখা যায় যে, সোরা যে সম্পদ হারায়, তার পিছনে হয়তো GPU সময় কিভাবে ব্যবহার করা উচিত তার একটি বাছাইয়ের বিষয় রয়েছে।

সোরার খরচ সম্ভবত ভিডিওটি মডেলে প্রবেশ করার সময় থেকেই বৃদ্ধি পায়। এটি প্রাথমিক ভিডিওটিকে latent space-এ কম্প্রেস করে, তারপর spacetime patches-এ ভাগ করে, যাতে Transformer এই patches-এর উপর গণনা করতে পারে।

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

প্রায় দেখে, ভিজুয়াল টোকেন সংখ্যাকে বুঝা যায় N_video ≈ T × H × W। এখানে T、H এবং W কম্প্রেস এবং প্যাচ করা হয়েছে, কিন্তু ত্রিমাত্রিক গুণনের সম্পর্ক বজায় থাকে।

ভিডিওর সময়কে বাড়ানো সময় দিকে patch বাড়ায়, আর ছবির আকার বাড়ানো স্থানীয় patch বাড়ায়। অর্থাৎ, ভিডিওর দৈর্ঘ্য এবং স্থানীয় আকার পরস্পর স্বাধীনভাবে খরচ বাড়ায় না, তারা একসাথে latent গ্রিডকে প্রসারিত করে।

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

একটি ভিডিওর গণনা পরিমাণ প্রায় হিসাব করা যায় C_video ≈ D × C_transformer(N_video), যেখানে D হল নমুনা পুনরাবৃত্তির সংখ্যা। ভিডিও লেটেন্ট যত বড়, প্রতিটি পুনরাবৃত্তি তত ভারী; নমুনা পুনরাবৃত্তি বাড়লে, একই ভিডিওর জন্য নেটওয়ার্ক আরও কয়েকবার চালানো লাগবে।

এখানে ভিডিও ডিফিউশন এবং এলএলএম-এর মূল পার্থক্য দেখা যায়। ভাষা মডেল পরবর্তী টোকেন জেনারেট করার সময়, পূর্ববর্তী Key এবং Value কে KV cache-এ সংরক্ষণ করা যায়, যাতে মডেলটিকে প্রতিটি ধাপে সম্পূর্ণ ইতিহাসের অবস্থা পুনর্গঠন করার দরকার না হয়।

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

সুতরাং সোরার খরচকে “ঐতিহাসিক পুনর্ব্যবহার” দ্বারা ব্যাপকভাবে কমানো কঠিন। এটি একটি ভিজুয়াল ইফেক্ট শটের মতো, যা একাধিক প্রক্রিয়াকরণ পারে, প্রতিটি প্রক্রিয়ায় একটি পুরোপুরি পরিবর্তিত ছবি প্রক্রিয়া করতে হয়। ভিডিওটি যত দীর্ঘ, উচ্চ রেজোলিউশনের হবে, এবং যত বেশি নমুনা নেওয়া হবে, জেনারেশন পথটি তত বেশি ভারী হবে।

একটি একক টাস্ক যথেষ্ট ভারী হওয়ায়, Sora-এর GPU ব্যবহারের হার বেশ ভালো দেখাতে পারে। বড় আকারের ম্যাট্রিক্স গণনা টেনসর কোরকে দীর্ঘক্ষণ ব্যস্ত রাখে, যার ফলে মনিটরিং গ্রাফে GPU প্রায় কখনও বিশ্রাম নেয় না।

উচ্চ ব্যবহারযোগ্যতা শুধু এটিকে বোঝায় যে চিপটি সর্বদা কাজ করছে, এটি একক সময়ে অনেকগুলি কাজ প্রদান করেছে তা বোঝায় না। যদি একটি ভিডিও একটি GPU গ্রুপকে দীর্ঘক্ষণ ধরে দখল করে রাখে, তবে utilization যতই সুন্দর হোক না কেন, প্রতিটি অনুরোধের জন্য GPU-seconds খরচ এখনও খুব বেশি থাকবে।

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

সুতরাং, সোরার বেশিরভাগ ক্যালকুলেশন খরচ একটি ভিডিওর নিজস্ব জেনারেশন পথে বন্ধ হয়ে গেছে। স্যাম্পলিং রাউন্ড কমানো যায়, ল্যাটেন্ট আরও কম্প্রেস করা যায়, মডেল ডিসিল করা যায়, কার্নেলও আরও অপ্টিমাইজ করা যায়, কিন্তু স্কিডিউলার মূলত “এই ভারী টাস্কগুলোকে কীভাবে সাজানো যায়” এটাই পরিবর্তন করতে পারে, “একটি ভিডিওর জন্যই অসংখ্য ক্রমিক ক্যালকুলেশনের প্রয়োজন” এই তথ্যটি পরিবর্তন করা খুবই কঠিন।

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

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

সুতরাং একটি Codex টাস্ক অনেক রাউন্ডের সমষ্টির মতো। Prefill + Decode + Tool কী গুরুত্বপূর্ণ, প্রতিটি টুল কল সম্পন্নের পরে, পরবর্তী রাউন্ডে মডেল যে কনটেক্সট দেখে তা পূর্ববর্তী রাউন্ডের চেয়ে প্রায়শই বেশি ঘন।

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

ব্যবহারকারী শেষ পর্যন্ত যা দেখতে পাবেন, তা হতে পারে কয়েকশো শব্দের সম্পূর্ণ বর্ণনা, কিন্তু GPU-এর মধ্যে প্রক্রিয়াকরণকৃত কনটেন্টটি ইতিমধ্যেই খুব বড় হয়ে গেছে। Agent token consumption-এর চাপটি এই অবিরাম বৃদ্ধি পাচ্ছে কাজের ট্রেকের মধ্যে লুকিয়ে আছে।

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

ধরুন একটি এজেন্টের ইতিমধ্যে 100K টোকেনের কনটেক্সট রয়েছে, এবং টুল বাস্তবায়নের পর শুধুমাত্র 3K টোকেনের লগ যোগ হয়; যদি পূর্ববর্তী স্থির prefix ক্যাশে মিলে যায়, তবে এই রাউন্ডের নতুন কম্পিউটেশন মূলত পিছনের অংশে কেন্দ্রীভূত হয়; যদি prompt-এর শুরুতে পরিবর্তনের কারণে cache miss হয়, তবে সিস্টেমটি হয়তো আবার একটি ভারী prefill-এর সম্মুখীন হবে।

এখানে একটি গুরুত্বপূর্ণ পরিবর্তন দেখা যাচ্ছে: লজিক্যাল টোকেন সংখ্যা এখন সরাসরি বাস্তব GPU খরচকে প্রতিনিধিত্ব করতে পারে না। দুটি অনুরোধেই 100K ইনপুট টোকেন দেখানো হয়েছে, যার একটিতে বেশিরভাগ কনটেন্ট ইতিমধ্যে ক্যাশে করা হয়েছে, আর অন্যটিতে পুনরায় গণনা করা প্রয়োজন, এবং তাদের GPU-এর উপর চাপ সম্পূর্ণভাবে ভিন্ন। এজেন্টের লোড তাই কনটেক্সটের বৃদ্ধির গতি, cache hit, এবং একটি টাস্ক মডেলে কতবার পুনরায় প্রবেশ করে তার উপর নির্ভর করে।

একবারের ইনফারেন্সে প্রবেশ করার পর, প্রিফিল এবং ডিকোডের জন্য ভিন্ন হার্ডওয়্যার প্রয়োজনীয়তা থাকে। প্রিফিল একসাথে অনেক ইনপুট টোকেন প্রক্রিয়া করে, যার ম্যাট্রিক্স আকার বড়, এবং এটি সহজেই কম্পিউট-ভারী ওয়ার্কলোড তৈরি করে; ডিকোড প্রতিটি সিকোয়েন্সের প্রতিটি ধাপে শুধুমাত্র কয়েকটি টোকেন তৈরি করে, কিন্তু মডেল ওয়েটস এবং KV ক্যাশেকে বারবার অ্যাক্সেস করে, তাই এটি HBM ব্যান্ডউইথ এবং সমান্তরালতার উপর বেশি নির্ভরশীল।

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

এবং ব্যাচ আরও বাড়ানো যাবে কিনা, তা KV ক্যাশের সীমাবদ্ধতার কারণে নির্ভর করে। প্রতিটি সিকোয়েন্সের কনটেক্সট যত বেশি হবে, এটি HBM-এ তত বেশি জায়গা দখল করবে। এজেন্টের সংখ্যা বাড়ানোর পরেও GPU-এ গাণিতিক ক্ষমতা থাকতে পারে, কিন্তু VRAM-এ আর বেশি একটিভ স্টেট রাখা সম্ভব নয়।

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

টুল কল আবার কোডেকের লোডকে আরও বিভক্ত করে। এজেন্ট টেস্ট চালায়, কোড কম্পাইল করে বা I/O এর জন্য অপেক্ষা করে এমন সময়, GPU-কে এটির জন্য কাজ করতে থাকতে হয় না, CPU, কন্টেইনার এবং ফাইল সিস্টেম এটি নিয়ে নেয়। ফলাফল ফিরে আসার পর, এই এজেন্টটি পরবর্তী ইনফারেন্স রাউন্ডে প্রবেশ করে।

একটি 60 মিনিট চলমান এজেন্টের অর্থ এই নয় যে এটি 60 মিনিট ধরে নিরবচ্ছিন্নভাবে GPU ব্যবহার করে। এর কাজের সময়কে মডেল গণনা এবং বাহ্যিক কার্যক্রম হিসাবে দুটি অংশে ভাগ করা হয়েছে, যার ফলে scheduler-এর একটি সুযোগ তৈরি হয়েছে যা Sora-এর মতো কোনো জিনিসই প্রদান করতে পারে না: যখন কোনো এজেন্ট টুল চালায়, GPU-টি তাৎক্ষণিকভাবে অন্য কোনো sequence-এর জন্য সেবা প্রদান করতে পারে।

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

এখানে, Codex এবং Sora-এর পার্থক্য এখন “কে বেশি গুরুত্বপূর্ণ” নয়, বরং খরচ কি বিভক্ত হয়েছে কিনা। Sora-এর ক্যালকুলেশন একটি ধারাবাহিক জেনারেশন পথে কেন্দ্রীভূত, যেখানে Codex-এর ক্যালকুলেশন বিভিন্ন পর্যায়ে বিস্তৃত। এটি বিভক্ত হওয়ার কারণেই Codex পরবর্তী স্তরের অপ্টিমাইজেশনে প্রবেশ করতে পারে: scheduler-কে এই পর্যায়গুলির মধ্যে একই GPU ব্যবহারের ব্যবস্থা করতে দেওয়া।

বড় মডেলগুলি অনলাইনে চলাকালীন, ওয়েট সাধারণত দীর্ঘস্থায়ীভাবে GPU-এ থাকে এবং টেনসর প্যারালাল, নোড কমিউনিকেশন এবং ক্যাশ স্টেট বজায় রাখতে হয়। তাই Sora এবং Codex-এর মধ্যে সম্পদের জন্য প্রতিযোগিতা বেশিরভাগই fleet level-এ ঘটে: একটি অংশ GPU দীর্ঘস্থায়ীভাবে ভিডিও সার্ভিং পুলে প্রবেশ করে, অন্যটি দীর্ঘস্থায়ীভাবে LLM পুলে প্রবেশ করে, এবং উপরের ক্ষমতা সিস্টেমটি কোনটির জন্য স্কেল-আপ বা স্কেল-ডাউন করতে হবে তা নির্ধারণ করে।

বাস্তবিক জটিলতা কোডেক পুলের ভিতরে ঘটে। ধরুন, সিস্টেমে একসাথে ২০০টি এজেন্ট সিকোয়েন্স রয়েছে, যার কিছু decode করছে, কিছু টুলের জন্য অপেক্ষা করছে, আর কয়েকটি সাম্প্রতিক টুল পরিবেশ থেকে ফিরে এসেছে এবং নতুন দীর্ঘ কনটেক্সট প্রসেস করার প্রয়োজনীয়তা রাখছে। স্কিডিউলারের সামনে FLOPs-এর পাশাপাশি HBM ক্ষমতা, মেমোরি ব্যান্ডউইথ, KV ক্যাশে বাসস্থান এবং ল্যাটেন্সি বাজেটও সীমাবদ্ধতা হিসেবে রয়েছে।

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

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

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

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

চাঙ্কড প্রিফিল দীর্ঘ ইনপুটকে কয়েকটি ছোট ব্লকে ভাগ করে প্রিফিল এবং ডিকোডকে একসাথে ক্রমাগত প্রক্রিয়া করে; আরও উন্নত পদ্ধতি হলো প্রিফিল এবং ডিকোডকে ভিন্ন জিপিইউ পুলে বিভক্ত করা।

কারণ হলো, দুটি পর্যায় নিজ নিজ হার্ডওয়্যার বাধা এর প্রতি ভিন্নভাবে ঝুঁকে পড়ে: prefill বেশি কম্পিউটেশনাল থ্রুপুটের প্রতি ঝুঁকে পড়ে, আর decode বেশি HBM ব্যান্ডউইথ, KV cache এবং স্থিতিশীল টোকেন-ভিত্তিক ল্যাটেন্সির প্রতি নির্ভরশীল। এগুলোকে আলাদা করে ফেললে, প্রতিটির জন্য তাদের নিজস্ব প্রয়োজনীয়তা অনুযায়ী সম্পদ কনফিগার করা যায়।

এটি বোঝায় যে Agent সার্ভিং-এর কেন্দ্রীয় বিষয়টি শুধু “মডেল কার্নেলকে আরও দ্রুত লেখা” এর বাইরে চলে গেছে। অনেক ক্ষমতা বৃদ্ধি পায় কাজগুলির সময় পুনরায় সাজানো, কোথায় চালানো, কোন অবস্থা গ্রাফিক্স মেমরিতে রাখা উচিত, এবং বর্তমান ব্যাচে কাকে পূরণ করা উচিত—এইসবের মাধ্যমে।

অতএব, GPU ব্যবহার এখানেই যথেষ্ট নয়। ক্ষমতা দলকে একসাথে GPU-seconds per task, TTFT (প্রথম শব্দের লেটেন্সি, যা ব্যবহারকারীর অনুভূতি নির্ধারণ করে), TPOT (প্রতিটি শব্দ তৈরির সময়, যা মডেলের “কথা বলার” গতি নির্ধারণ করে), queueing latency, prefix cache hit, KV cache occupancy এবং SLO goodput (প্রাসঙ্গিক থ্রুপুট, যা প্রকৃতপক্ষে আয় করার যোগ্য ক্ষমতা নির্দেশ করে) দেখতে হবে।

এই মাপকাঠিগুলি একটি প্রশ্নের উত্তর দেয়: ব্যবহারকারীর গ্রহণযোগ্য দেরির মধ্যে, এক ঘন্টায় একটি GPU কতগুলি কার্যকরী কাজ বজায় রাখতে পারে।

কোডেক্সের স্কেডিউলেবিলিটি এখানে প্রকাশ পায়। স্টেবল প্রিফিক্স পুনরাবৃত্তি প্রিফিল কমায়, ডিকোড কনটিনিউয়াস ব্যাচ করতে পারে, KV ক্যাশে পেজিং এবং ড্রাইভ করতে পারে, এবং এজেন্ট টুল অপেক্ষা করার সময় GPU ছেড়ে দিতে পারে। এর ওয়ার্কলোড খুব ছোট ছোট টুকরোতে বিভক্ত, কিন্তু এই টুকরোগুলোকে স্কেডিউলার পুনরায় সাজাতে পারে।

এটি প্রশ্নটিকে স্বাভাবিকভাবেই সংস্থান স্তরে নিয়ে যায়: যদি একই সেট জিপিইউ একাধিক দীর্ঘমেয়াদী এজেন্টকে একসাথে সার্ভ করতে পারে, তাহলে এক ঘন্টার জিপিইউ আসলে এক ঘন্টার বেশি কাজের সমর্থন করতে পারে।

ধরুন একটি Codex Agent একটি টাস্ক শুরু করে শেষ করতে 60 মিনিট সময় নেয়, যার মধ্যে শুধুমাত্র কিছু সময় মডেলের prefill এবং decode-এর জন্য ব্যয় হয়, বাকি সময় কম্পাইল, টেস্ট, ফাইল পড়া-লেখা বা টুলসের জন্য অপেক্ষা করার জন্য ব্যয় হয়। এই অনুপাতটি টাস্কের উপর নির্ভর করে পরিবর্তিত হবে, কিন্তু কাঠামোটি গুরুত্বপূর্ণ: Agent-এর wall-clock time এবং GPU compute time এক-একটি অনুপাতে নয়।

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

এই সম্পর্কটিকে প্রায় এভাবে বুঝা যায়: Agent-hours নির্ভর করে GPU-hours, মডেল ইনফারেন্স ডিউটি সাইকেল এবং স্কিডিউলিং দক্ষতার উপর। যত বেশি টুল এক্সিকিউশন সময়, তত বেশি batch মোটা, এবং ক্যাশ হিট রেট যত বেশি, এক ঘন্টার GPU তত বেশি Agent wall-clock কাজ সম্পাদনের সুযোগ পায়।

এটি নতুন GPU যোগ করার অর্থকে সরাসরি পরিবর্তন করবে। Codex-এ একটি গ্রুপ GPU যোগ করলে শুধুমাত্র একটি টাস্ক দ্রুততর হয় না, বরং সিস্টেমটি একসাথে আরও বেশি Agent রাখতে পারে। একজন ইঞ্জিনিয়ার একাধিক টাস্ক সমান্তরালে শুরু করতে পারেন—একটি ব্যাকএন্ড পরিবর্তন, একটি টেস্ট পূরণ, এবং আরেকটি রিপোজিটরি প্রক্রিয়াকরণ—যদি এই টাস্কগুলির মধ্যে শক্তিশালী নির্ভরশীলতা না থাকে, তবে মেশিনের কাজের সময় সমান্তরালভাবে বৃদ্ধি পাবে।

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

কোডেক্সের একটি সফটওয়্যার টাস্ক GPU, CPU, কন্টেইনার, ফাইল সিস্টেম এবং টুল এনভায়রনমেন্টের মধ্যে চলাচল করে। GPU মডেল ইনফারেন্সের জন্য দায়ী, অন্যান্য সিস্টেমগুলি কার্যক্রম পরিচালনা করে, এবং একাধিক Agent সিস্টেমের মাধ্যমে scheduler-এর দ্বারা inference capacity-এর সাথে বিকল্পভাবে শেয়ার করে। ফলে GPU কেবলমাত্র জেনারেটিভ ডিভাইস থেকে Agent সিস্টেমের মধ্যে একটি সীমিত “চিন্তার সম্পদ”-এ পরিণত হয়।

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

যখন একটি গ্রুপ GPU বেশি দীর্ঘমেয়াদী এজেন্টকে সমর্থন করতে পারে, এবং এই এজেন্টগুলি নতুন সফটওয়্যার টাস্ক প্রাপ্তি চালিয়ে যায়, তখন সম্পদ সহজেই এই দিকে প্রবাহিত হয়।

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

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

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

সুতরাং ভবিষ্যতে কিছু অত্যন্ত মৌলিক সমস্যা পণ্য সমস্যার দিকে আরও বেশি কাছাকাছি যাবে। KV cache কোথায় রাখবেন, prefill কীভাবে কাটবেন, decode batch কতটা ঘন করে রাখা যায়, প্রতীক্ষারত টুলের Agent-এর ক্যাশ বাতিল করা উচিত কি না—এই সিদ্ধান্তগুলি চূড়ান্তভাবে একটি GPU-এর সমান্তরালে কতগুলি টাস্ক বজায় রাখতে পারবে তা নির্ধারণ করবে।

সোরা এবং কোডেক্সের পার্থক্য শুধু ভিডিও এবং কোডের পার্থক্য নয়।

তারা একই ঘন্টার GPU নিয়ে প্রতিদ্বন্দ্বিতা করছে, যা কতটা কাজ সম্ভব করতে পারে।