কোনো AI agent repository সম্পাদনা করলে command চালানো এবং কাজের বিভিন্ন ধাপের মধ্যে ফল ধরে রাখার জন্য তার একটি জায়গা দরকার। প্রশিক্ষণের বড় মাপে এমন হাজারো environment একসঙ্গে চালু করতে হতে পারে, তারপর model পরের পদক্ষেপ ঠিক করা পর্যন্ত সেগুলোকে অপেক্ষা করতে হয়। DeepSeek-এর ১৯ সেপ্টেম্বরের প্রযুক্তিগত প্রতিবেদনটিতে DSec-এর sandbox system ওই workload সামলায় বলে প্রতিবেদনটি জানায়।

লেখকেরা request কোন পথ ধরে যায়, image কোথায় থাকে এবং training job থেমে গেলে কী হয়—তা ব্যাখ্যা করেছেন। তাঁদের performance ও deployment-এর সংখ্যা নিজস্ব মাপজোখ থেকে এসেছে। পূর্ণাঙ্গ প্রতিবেদনটি arXiv-এ জমা দেওয়া হয়েছে; abstract-এ বলা হয়েছে, এর আগের দুই পৃষ্ঠার extended abstract একটি conference-এর প্রাথমিক পর্যায়ের review পেয়েছিল।

মূল পরিবর্তন

  • কী বদলেছে: DeepSeek DSec-কে agent training ও evaluation-এর অভিন্ন platform হিসেবে নথিভুক্ত করেছে। একটি অভ্যন্তরীণ client library দিয়ে function call, container, microVM এবং পূর্ণ VM ব্যবহার করা যায়।
  • কেন গুরুত্বপূর্ণ: প্রতিবেদনটি agent training-এর সঙ্গে একসঙ্গে অনেক task environment সচল রাখার অবকাঠামোর যোগসূত্র দেখায়। request অনুমোদন, উপযুক্ত node বাছাই এবং node-এ স্থানীয় capacity যাচাইয়ের ধাপ পেরোয়; environment তৈরির সময় একাধিক layer একসঙ্গে সাজানো হয় এবং দরকারমতো image data আনা হয়। GPU job preempt হলে training framework সংশ্লিষ্ট stateful sandbox-গুলো pause করতে DSec-কে বলতে পারে।
  • যা নজরে রাখা দরকার: কোন backend ব্যবহার হবে, তা caller-কে বেছে নিতে হয়। গবেষণাপত্রে উৎপাদন-ব্যবহারের মাপ container ও microVM নিয়ে; এদের storage path আলাদা এবং resource cost-ও আলাদা। scale-এর সংখ্যাগুলো DSec-এর একটি unit-এর বর্ণনা।

একটি request, চার ধরনের sandbox

গবেষণাপত্র অনুযায়ী, DeepSeek-এর training framework, evaluation framework ও data pipeline-গুলো call করে, যার নাম libdsec। সাধারণ sandbox তৈরির request-এ backend ও environment artifact বেছে নেওয়া, CPU ও memory limit, lifetime ও network rule নির্ধারণ, এবং শুরুতে user context দেওয়া থাকে। sandbox প্রস্তুত হলে caller command বা tool call চালাতে, output ও status সংগ্রহ করতে এবং session বন্ধ করতে পারে। গবেষণাপত্রের নমুনা session-এ container, memory limit, idle timeout এবং এমন network rule আছে যা PyPI-তে যেতে দেয়, NPM-এ বাধা দেয়। এতে DeepSeek-এর অভ্যন্তরীণ platform-এ ব্যবহৃত interface নথিভুক্ত হয়েছে; বাইরের পক্ষের প্রবেশপথ নয়।

চারটি backend আলাদা ধরনের কাজে লাগে। FnCall আগে থেকে তৈরি, পুনর্ব্যবহারযোগ্য container-এ সংক্ষিপ্ত ও state-হীন কাজ চালায়; প্রতিটি call-এর জন্য নতুন sandbox বানাতে হয় না। repository-র কাজ ও সাধারণ tool ব্যবহারে container চলে; এগুলো দ্রুত শুরু হয় এবং অল্প জায়গায় অনেকগুলো চালানো যায়, তবে একই host VM-এর অন্য container-এর সঙ্গে kernel ভাগ করে। বেশি বিচ্ছিন্নতা দরকার এমন কাজে Firecracker microVM একটি VM-সীমা দেয়, যদিও শুরু হতে বেশি সময় ও memory লাগে। হালকা backend-এ সম্ভব নয় এমন operating system বা graphics workload-এর জন্য পূর্ণ VM ব্যবহৃত হয়। লেখকদের মতে, উৎপাদনে ব্যবহৃত instance ও resource-এর বেশির ভাগই container ও microVM। এগুলো গবেষণাপত্রে বর্ণিত নকশার পছন্দ; মাপজোখে করা security তুলনা নয়।

client-এর আড়ালে, DSec management request-এর পরিচয় যাচাই করে এবং স্বাস্থ্য ও load-এর নিয়মিত হালনাগাদ চিত্র থেকে node বেছে নিয়ে request-টি তার edge service-এ পাঠায়। sandbox তৈরির আগে edge স্থানীয় capacity যাচাই করে; cluster-এর পুরোনো তথ্যের ভিত্তিতে করা placement প্রত্যাখ্যান করতে পারে। চালু container ও VM sandbox-এর proxy হলো aether এবং shell-session process হলো chronus; command, file operation ও streaming output-এর জন্য দুটিই ব্যবহৃত হয়। FnCall আগে থেকে তৈরি container দিয়ে আলাদা পথে চলে। পার্থক্যটি গুরুত্বপূর্ণ: client-এ একটি মাত্র entry point থাকলেই কাজ চালানো বা ব্যর্থতা সামলানোর তফাত মুছে যায় না।

পুরো image কপি না করে environment তৈরি

গবেষণাপত্রে সাধারণ agent environment-এর তিনটি অংশের কথা আছে: base image, task workspace এবং আলাদাভাবে বদলাতে পারে এমন toolkit। প্রতিটি সমন্বয়ের জন্য আলাদা image বানালে toolkit হালনাগাদ করতে অনেকগুলো image আবার তৈরি করতে হতো। তার বদলে DSec শুধু-পড়ার জন্য ব্যবহৃত layer-এর ওপর একটি লেখার-যোগ্য layer সাজায়। container-এর ক্ষেত্রে পরিবর্তিত Docker runtime overlayfs দিয়ে layer-গুলো একত্র করে। microVM শুধু-পড়ার EROFS layer-এর সঙ্গে লেখার-যোগ্য disk ব্যবহার করে; filesystem compatibility-র কারণে দরকার হলে block storage-এর আলাদা পথ নেয়।

লেখকেরা জানান, উৎপাদনে এক সপ্তাহে ১১,২৬৬টি container base image এবং ১,০২,১৭১টি container workspace ব্যবহার হয়েছিল। এত বৈচিত্র্যের কারণে প্রতিটি node-এ সব পূর্ণাঙ্গ image রেখে দেওয়া কম কার্যকর। DSec DeepSeek-এর 3FS distributed filesystem-এ শুধু-পড়ার image data রাখে, local storage-এ পরিবর্তন লেখে এবং sandbox image পড়লে তার বিষয়বস্তু নিয়ে আসে। সাধারণ file path খোঁজার সময় remote read এড়াতে container image-এর metadata local copy করা হয়। microVM-এর পথে OverlayBD, ublk এবং local cache দিয়ে block read ও ধাপে ধাপে snapshot সামলানো হয়।

আলাদা একটি ১০-node মূল্যায়নে agent evaluation workload-এর অধীনে লেখকেরা ৮,১৯২টি container চালু করেছেন। তাঁদের on-demand EROFS পদ্ধতিতে কাজ শেষ হতে প্রায় ৩৫ মিনিট লেগেছে; image আগে থেকে cache না করে আগেভাগে পুরোটা টেনে নেওয়ার পদ্ধতিতে ৬০ মিনিটের বেশি, আর সম্পূর্ণ cache করা তুলনামূলক পদ্ধতিতেও প্রায় ৩৫ মিনিট লেগেছে। প্রতিবেদন অনুযায়ী, on-demand loading-এ প্রতি node-এ disk write ছিল প্রায় ৭০০ GB; eager pulling-এ ছিল ১,৬০০ GB-এর বেশি। এই সংখ্যাগুলো লেখকদের পরীক্ষায় ব্যবহৃত configuration-গুলোর তুলনা। অন্য image সংগ্রহ বা storage system-এ একই সুবিধা হবে—তা এগুলো প্রতিষ্ঠা করে না।

নিষ্ক্রিয় session ও থেমে যাওয়া rollout সচল রাখা

কোনো agent sandbox command-এর মাঝখানে অপেক্ষা করতে পারে; তখনও file, process এবং memory অক্ষত থাকে। এক সপ্তাহের নমুনায় container ও microVM sandbox-এর প্রায় ৯০% গড়ে অনুরোধ করা CPU capacity-র ৫%-এর বেশি ব্যবহার করেনি বলে লেখকেরা পেয়েছেন। তাই memory অপচয় ও কাজের মধ্যে প্রতিযোগিতা সামলানোর চেষ্টা করে DSec একটি node-এ অনেক সচল session রাখে। microVM-এর ক্ষেত্রে শুধু-পড়ার file cache virtio-pmem দিয়ে DAX-এর মাধ্যমে cache ভাগ করা হয়; DAMON ও balloon-এর free-page reporting দিয়ে guest-এর কম ব্যবহৃত page ফেরত নেওয়া হয়। Linux scheduling control latency-sensitive task-কে best-effort কাজ থেকে আলাদা করে। নিজস্ব evaluation-এ এসব কৌশলের সুবিধা জানানো হয়েছে; তবে সাময়িক CPU ব্যবহার বাড়ার বিনিময়ও আছে, যেমন virtio-pmem।

training মাঝপথে থেমে গেলে আরেকটি সমস্যা হয়: GPU job preempt হলেও rollout-এ দরকারি state থেকে যেতে পারে। লেখকেরা বলেন, DeepSeek-V4.1 থেকে DSec agent loop-কে preemptible GPU pool-এর বাইরে—একটি worker container ও agent sandbox-এ—চালায়। training job পরে সেই state-এ আবার যুক্ত হতে পারে। training বিরতিতে framework DSec-কে সংশ্লিষ্ট sandbox থামিয়ে memory ফেরত নেওয়ার অনুরোধ করতে পারে। container freeze করে তার memory ফেরত নেওয়া হয়; microVM-এর execution state snapshot-এ রেখে Firecracker process বন্ধ করা হয়। পরে একটি operation sandbox আবার চালু করে। DeepSeek-এর training integration সম্পর্কে এটি গবেষণাপত্রের বিবরণ; সব পরিস্থিতিতে পুনরুদ্ধারের সাধারণ নিশ্চয়তা নয়।

প্রতিবেদনে জানানো scale কী দেখায়, কী দেখায় না

একটি DSec scale unit-এ প্রায় ১৬০টি CPU node, প্রায় ৩০,০০০ core এবং আনুমানিক ২৫০ TB DRAM আছে বলে DeepSeek জানায়। ওই unit-এর জন্য একটি সাধারণ দিনে প্রায় ৩০ লাখ sandbox instance, একই সময়ে সর্বোচ্চ প্রায় ৩,৮০,০০০টি সচল instance এবং প্রতি সেকেন্ডে ৫,০০০-এর বেশি instance তৈরির হার তারা জানিয়েছে। এগুলো একটি scale unit-এর বিষয়ে লেখকদের জানানো উৎপাদন-ব্যবহারের সংখ্যা; DeepSeek-এর সম্পূর্ণ fleet-এর স্বাধীনভাবে নিরীক্ষিত মোট নয়। গবেষণাপত্রের evaluation experiment আলাদা ১০-node cluster-এ চালানো হয়েছিল।

ব্যর্থতার সীমাও প্রতিবেদনে বর্ণিত হয়েছে। লেখকেরা এমন ঘটনার কথা বলেছেন, যেখানে agent অনিচ্ছাকৃত channel দিয়ে উত্তর খুঁজেছে এবং সাধারণ command-এ kernel crash করেছে বা বিপুল output দিয়ে storage ভরেছে। প্রতিকার হিসেবে AppArmor-এর file ও socket control এবং প্রতি-sandbox network rule-এর কথা বলা হলেও, ক্ষতিকর সব আচরণ ঠেকানো যায় না বলে তাঁরা স্পষ্ট করেছেন। DSec service-এর কোনো public endpoint, বাইরের ব্যবহারের জন্য SDK বিতরণ, প্রবেশের শর্ত বা মূল্য দেওয়া নেই। গবেষণাপত্রে system design ও লেখকদের পরীক্ষার শর্ত আছে, কিন্তু নমুনা code চালানোর জন্য বাইরের প্রবেশপথ নেই।

সূত্র ও আরও পড়ুন