সংক্ষিপ্ত বিবরণ
এই প্রকল্পটি দুটি NVIDIA GB10 DGX Spark সিস্টেমে স্থানীয়ভাবে DeepSeek V4.1 Flash পরিবেশন করে। এতে 2.9 bits-per-weight EXL3 চেকপয়েন্ট, উভয় নোডে টেনসর প্যারালেলিজম, নেটিভ sm_121a কার্নেল এবং 8888 পোর্টে OpenAI-সামঞ্জস্যপূর্ণ vLLM API ব্যবহৃত হয়েছে।
পরিবেশিত মডেল শনাক্তকারী হলো DeepSeek-v4.1-Flash-EXL3। ডিপ্লয়মেন্টটি কেবল টেক্সট-ভিত্তিক এবং CX7-এর মাধ্যমে সংযুক্ত দুই-নোডের GB10 কিটের জন্য বিশেষভাবে তৈরি।
কনটেইনারটি vllm/vllm-openai:deepseekv41-flash-0909-এর ওপর EXL3 সমর্থন যুক্ত করে। এটি একটি ARM64 vLLM ইমেজ, যাতে প্রয়োজনীয় DeepseekV41 আর্কিটেকচার রয়েছে।
প্রকল্পটি যা সরবরাহ করে
- স্থানীয় OpenAI-সামঞ্জস্যপূর্ণ পরিবেশন: অ্যাপ্লিকেশনগুলো стандарт
/v1/chat/completionsএন্ডপয়েন্টে কল করতে পারে। - দুই-নোড টেনসর প্যারালেলিজম: CX7 সংযোগের ওপর টেনসর-প্যারালেল সাইজ 2 ব্যবহার করে মডেলটি চলে।
- EXL3 কোয়ান্টাইজেশন: চেকপয়েন্টটির গড় 2.9 bpw এবং প্রতি-টেনসর কোয়ান্টাইজেশন সেটিংসহ
mul1কোডবুক ব্যবহৃত হয়েছে। - নেটিভ DSpark স্পেকুলেশন: ড্রাফট এক্সপার্টগুলো ইতিমধ্যে চেকপয়েন্টে
mtp.*-এর অধীনে সংরক্ষিত, তাই আলাদা ড্রাফট মডেল প্রয়োজন নেই। - দীর্ঘ-কনটেক্সট সমর্থন: সরবরাহকৃত কনফিগারেশনে
MAX_MODEL_LEN=600000সেট করা আছে এবং 2.5 GiB KV ক্যাশ পুল ব্যবহার করা হয়। - ফাইল-সমর্থিত Engram টেবিল: আনকোয়ান্টাইজড Engram ডেটা হোস্ট মেমরিতে পিন না করে মূল মডেলের 47 ও 48 নম্বর শার্ড থেকে পড়া হয়।
- স্বয়ংক্রিয় স্টার্টআপ:
start.shওজন ডাউনলোড করে, ইমেজ সংগ্রহ বা বিল্ড করে, ওয়ার্কারের সঙ্গে ফাইল শেয়ার করে, GPU পরীক্ষা চালায় এবং API চালু করে। - রানটাইম সুরক্ষা: লঞ্চার বুট-মার্জিন পরীক্ষা চালায়, প্রিফিল ধাপগুলোর মধ্যে অ্যালোকেটর ছেড়ে দেয়, লোডিংয়ের পর পেজ ক্যাশ সরিয়ে ফেলে এবং কনটেইনারগুলোর OOM স্কোর সমন্বয় করে।
হার্ডওয়্যার ও স্টোরেজের প্রয়োজনীয়তা
এই রিপোজিটরিটি ঠিক দুটি NVIDIA GB10 DGX Spark নোডের জন্য তৈরি। ডিফল্ট হেড নোডের ঠিকানা 10.0.0.1, এবং নোডগুলো CX7-এর মাধ্যমে যোগাযোগ করে। README-তে পরীক্ষিত ইন্টারফেস হিসেবে প্রথম নোডে enp1s0f1np1/rocep1s0f1 এবং দ্বিতীয় নোডে enp1s0f0np0/rocep1s0f0 উল্লেখ করা হয়েছে।
প্রায় 387 GiB মডেল ডেটার জন্য পরিকল্পনা করুন:
- Mia-AiLab/DeepSeek-V4.1-Flash-EXL3-2.9bpw থেকে 39টি EXL3 শার্ডের জন্য প্রায় 197 GiB।
- মূল DeepSeek-এর 47 ও 48 নম্বর শার্ড এবং ইনডেক্সের জন্য প্রায় 190 GiB। এগুলোতে নেটিভ Engram টেবিল রয়েছে।
- মিল থাকা ইমেজ বিল্ড না করে সংগ্রহ করা গেলে প্রকাশিত কনটেইনার ইমেজের জন্য প্রায় 9 GiB।
আপনার কাছে সম্পূর্ণ DeepSeek-V4.1-Flash ডিরেক্টরি থাকলে Engram-এর উৎস আবার ডাউনলোড এড়াতে ENGRAM_DIR-এ সেটির পথ দিন। এই উদ্দেশ্যে কেবল 47 ও 48 নম্বর শার্ড এবং ইনডেক্স পড়া হয়।
DGX Spark-এ হোস্ট RAM-ও GPU মেমরি হিসেবে ব্যবহৃত হয়। প্রতিটি CUDA অ্যালোকেশন সঙ্গে সঙ্গে শেয়ার্ড মেমরি ব্যবহার করে, তাই স্টোরেজ ও মেমরি সেটিং আলাদাভাবে পরিবর্তন করে দীর্ঘ প্রম্পট দিয়ে পরীক্ষা করা উচিত।
হেড নোড প্রস্তুত করুন
1. রিপোজিটরি ক্লোন করে এনভায়রনমেন্ট ফাইল তৈরি করুন
হেড Spark-এর রিপোজিটরি ডিরেক্টরি থেকে ডিপ্লয়মেন্ট চালান:
cp .env.example .env
প্রথমবার চালানোর সময় .env না থাকলে লঞ্চার নিজেও এটি তৈরি করে। ফাইলটি পর্যালোচনা করুন এবং আপনার সিস্টেম অনুযায়ী প্রয়োজন হলে WORKER_USER ও GID-এর মতো মান হালনাগাদ করুন।
.env-এ স্পষ্টভাবে উল্লেখ করা মানগুলো কমান্ড-লাইনের এনভায়রনমেন্ট প্রিফিক্সের ওপর অগ্রাধিকার পায়, কারণ start.sh উত্তরাধিকারসূত্রে পাওয়া এনভায়রনমেন্টের ওপর ফাইলটি সোর্স করে। উদাহরণস্বরূপ, WEIGHT_SYNC=zfs ./start.sh চালানোর পরিবর্তে .env-এর ভেতরে WEIGHT_SYNC পরিবর্তন করুন।
2. Hugging Face ডাউনলোড টুল ইনস্টল করুন
স্বয়ংক্রিয় মডেল ডাউনলোডের জন্য ট্রান্সফার সমর্থনসহ Hugging Face CLI প্রয়োজন:
pip install -U 'huggingface_hub[hf_transfer]'
ডাউনলোড পুনরায় চালিয়ে যাওয়া যায়। কোনো বাধাপ্রাপ্ত রান মডেল অসম্পূর্ণ রেখে গেলে লঞ্চার বা ডাউনলোডার আবার চালান।
3. সার্ভার চালু না করে ঐচ্ছিকভাবে ডাউনলোড করুন
vLLM চালুর আগে EXL3 ও Engram ফাইল প্রস্তুত করতে চালান:
./download.sh
ডিফল্টভাবে স্বয়ংক্রিয় ডাউনলোড সক্রিয় থাকে। ফাইলগুলো নিজে পরিচালনা করতে চাইলে কনফিগারেশনে AUTO_DOWNLOAD=0 সেট করুন।
সার্ভার চালু করুন
হেড নোডের রিপোজিটরি থেকে চালান:
./start.sh
প্রথমবার চালানোর সময় লঞ্চারটি উচ্চ-স্তরের নিম্নলিখিত কাজগুলো করে:
- উপলব্ধ মেমরি মার্জিন ও নোড কনফিগারেশন পরীক্ষা করে।
- অনুপস্থিত EXL3 ও Engram ফাইল ডাউনলোড করে।
- পাবলিক ইমেজ
ghcr.io/miaai-lab/deepseek-v4.1-flash-exl3-2x-dgx-sparks:2.9bpwসংগ্রহ করে। - রেসিপি স্ট্যাম্প পরিবর্তিত হলে বা রেজিস্ট্রি অনুপলব্ধ থাকলে কেবল স্থানীয়ভাবে বিল্ড করে।
- ওয়ার্কারের জন্য ওজনগুলো উপলব্ধ করে।
- EXL3 GEMM ও Engram ডিকোয়ান্টাইজেশন GPU পরীক্ষা চালায়।
- দুইটি টেনসর-প্যারালেল র্যাঙ্ক চালু করে এবং
8888পোর্টে API প্রকাশ করে।
পরিষ্কার চেকআউটের রেসিপি স্ট্যাম্প প্রকাশিত ইমেজের সঙ্গে মিলে যাওয়ার কথা, তাই সাধারণত কম্পাইলের প্রয়োজন হয় না।
ইমেজ বিল্ডিং ও ট্রান্সফার নিয়ন্ত্রণ করুন
BUILD=1 ./start.shসবসময় ইমেজটি স্থানীয়ভাবে বিল্ড করে।SKIP_BUILD=1 ./start.shরেসিপির স্ট্যাম্প ভিন্ন হলেও পুল করা ইমেজটি রেখে দেয়।SKIP_PULL=1 ./start.shকনটেইনার রেজিস্ট্রির সঙ্গে যোগাযোগ করা এড়িয়ে যায়।PULL=1 ./start.shস্থানীয় স্ট্যাম্প মিলে গেলেও ইমেজটি আবার পুল করে।SKIP_SHIP=1 ./start.shহেডকে ইমেজটি ওয়ার্কারে কপি করা থেকে বিরত রাখে।
ডিফল্টভাবে, ইমেজ পাঠানোর জন্য পুনরারম্ভযোগ্য rsync-এর মাধ্যমে স্থানান্তরিত একটি স্টেজ করা tar ফাইল ব্যবহার করা হয়। IMAGE_SHIP=stream সেট করলে docker save-এর আউটপুট ওয়ার্কারের docker load-এ পাইপ করা হয়। স্ট্রিমিংয়ে কোনো অস্থায়ী জায়গা লাগে না, তবে স্থানান্তর বাধাগ্রস্ত হলে শুরু থেকে আবার চালু হয়। auto মোড পুনরারম্ভযোগ্য স্থানান্তরকে অগ্রাধিকার দেয় এবং ওয়ার্কারের ডিস্কে জায়গা সীমিত হলে স্ট্রিমিংয়ে ফিরে যায়।
ডিপ্লয়মেন্ট পরীক্ষা ও পরিচালনা করুন
দুটি কনটেইনার আলাদাভাবে পরিচালনা না করে লঞ্চারের ব্যবস্থাপনা কমান্ড ব্যবহার করুন:
./start.sh status
./start.sh logs
./start.sh logs worker
./start.sh stop
./start.sh restart
ওয়ার্কারে যদি ইতিমধ্যে সিঙ্ক্রোনাইজ করা ওজন থাকে, সিঙ্ক্রোনাইজেশন ধাপটি পুনরাবৃত্তি না করে রিস্টার্ট করুন:
SKIP_SYNC=1 ./start.sh restart
স্টার্টআপের সময় 420-সেকেন্ডের লগ-নীরবতা শনাক্তকারী উভয় র্যাঙ্ক থেকে Python স্ট্যাক ট্রেস সংগ্রহ করে। ডায়াগনস্টিক ফাইল logs/-এর অধীনে লেখা হয়।
আপনার প্রথম API অনুরোধ পাঠান
সার্ভার সুস্থভাবে চালু হলে হেড নোডে একটি chat completion অনুরোধ পাঠান। এই smoke অনুরোধে thinking নিষ্ক্রিয় করা হয়েছে, যাতে সরাসরি উত্তরটি সহজে পরীক্ষা করা যায়:
curl -s http://127.0.0.1:8888/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"DeepSeek-v4.1-Flash-EXL3","messages":[{"role":"user","content":"What is 17*19? Reply with the integer only."}],"max_tokens":32,"temperature":0,"chat_template_kwargs":{"enable_thinking":false}}'
প্রত্যাশিত উত্তর হলো 323। যেকোনো OpenAI-সামঞ্জস্যপূর্ণ ক্লায়েন্ট একই base URL এবং model identifier ব্যবহার করতে পারে।
প্রস্তাবিত sampling সেটিংস ব্যবহার করুন
সাধারণ মডেল ব্যবহারের জন্য অফিসিয়াল sampling সেটিংস হলো:
temperature=1.0top_p=0.95- Thinking সক্রিয়
চ্যাট টেমপ্লেটে ডিফল্টভাবে উচ্চ reasoning effort সেট করা থাকে, যা 75 দিয়ে প্রকাশ করা হয়। এটি 50-এর জন্য low, 100-এর জন্য max, অথবা 1 থেকে 100 পর্যন্ত একটি পূর্ণসংখ্যাও গ্রহণ করে।
প্রস্তাবিত sampling কনফিগারেশন ব্যবহার করা একটি অনুরোধ এমন হতে পারে:
curl -s http://127.0.0.1:8888/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"DeepSeek-v4.1-Flash-EXL3","messages":[{"role":"user","content":"Explain how tensor parallel inference works."}],"max_tokens":512,"temperature":1.0,"top_p":0.95,"reasoning_effort":"high"}'
DSpark Speculative Decoding বুঝুন
এই ডিপ্লয়মেন্টে checkpoint-এর মধ্যে সংযুক্ত draft experts-সহ DSpark speculative decoding ব্যবহার করা হয়। আলাদাভাবে কোনো drafter ডাউনলোড, লোড বা সার্ভ করার প্রয়োজন নেই।
অন্তর্নিহিত vLLM কনফিগারেশনটি এর সমতুল্য:
--speculative-config '{"method":"dspark","num_speculative_tokens":3}'
Checkpoint-এ draft block-size-এর সর্বোচ্চ সীমা পাঁচ, তবে shipped সেটিংসে তিনটি speculative token ব্যবহার করা হয়, কারণ prose-এর ক্ষেত্রে এটি দ্রুততর পরিমাপ করা হয়েছে। Capture size-এর মধ্যে 1 2 3 4 6 8 12 18 24 রয়েছে; এর মধ্যে size ছয়ও আছে, যেখানে দুটি sequence প্রতিটি তিনটি speculative token তৈরি করে।
প্রতিবেদিত পরিমাপে DSpark single-stream decoding উন্নত করে। বড় batch-এর ক্ষেত্রে SPEC_METHOD=none দিয়ে এটি নিষ্ক্রিয় করুন। এতে আনুমানিক 3.5 GiB মেমরি মুক্ত হয়। README অনুযায়ী, একটি speculative stream-এ প্রতি সেকেন্ডে প্রায় 31.6 token পাওয়া যায়, আর চারটি stream-এ speculation বন্ধ রেখে পরিবেশন করলে সামগ্রিক throughput বেশি হয়।
নিরাপদে মেমরি পরিচালনা করুন
প্রতি নোডে আনুমানিক allocation-এর মধ্যে প্রতিটি rank-এর জন্য 99.5 GiB EXL3 weights, একটি 2.5 GiB KV pool, context, NCCL, workspace এবং CUDA graph-এর জন্য প্রায় 5 থেকে 7 GiB, এবং vLLM process, Docker, অপারেটিং সিস্টেম ও desktop-এর জন্য আনুমানিক 9 GiB অন্তর্ভুক্ত।
Shipped সীমাগুলো হলো:
MAX_MODEL_LEN=600000MAX_NUM_SEQS=2MAX_NUM_BATCHED_TOKENS=1024- একটি 2.5 GiB KV cache pool
KV layout স্বয়ংক্রিয়ভাবে DeepSeek-এর fp8_ds_mla হিসেবে নির্বাচিত হয়। --kv-cache-dtype পাস করবেন না। পরিমাপ করা pool-এ 614,400-এর context limit-এ 774,400 token রাখা হয়েছিল, যেখানে প্রতি token-এর খরচ আনুমানিক 3.4 KiB।
2.9-কে পূর্ণসংখ্যা 2-এ রূপান্তর করে এই checkpoint-এর quantization অনুমান করবেন না। এর quantization parameter প্রতি tensor অনুযায়ী নির্বাচিত হয়, এবং বিভিন্ন routed expert, shared expert, attention matrix, Engram tensor, MTP tensor ও language-model head ভিন্ন ভিন্ন মান ব্যবহার করে।
Warm-up-এর পর, প্রতিবেদিত পরীক্ষায় হেডে আনুমানিক 4.07 থেকে 4.21 GiB ব্যবহারযোগ্য মেমরি অবশিষ্ট ছিল। 601,000-token prefill-এর ফলে এই ব্যবধান প্রায় 2.1 GiB-এ নেমে আসে। তাই স্টার্টআপের ঠিক পরেই নয়, দীর্ঘ prefill-এর পর পরিবর্তন যাচাই করুন।
একবারে কেবল একটি memory-related সেটিং বাড়ান। README সতর্ক করে যে KV pool-এ 0.5 GiB যোগ করলে prefill margin প্রায় 1 GiB কমে যেতে পারে। 3 GiB pool একটি সংক্ষিপ্ত smoke test পাস করেছিল, কিন্তু 600,000-token prompt-এ প্রায় 470,000 token-এ ব্যর্থ হয়।
ঐচ্ছিক memory guard সতর্কতার সঙ্গে ব্যবহার করুন
scripts/memguard.sh প্রতি সেকেন্ডে একবার /proc/meminfo পরীক্ষা করে এবং DSV41_MEM_GUARD_GIB-এর নিচে পরপর দুটি sample পাওয়া গেলে স্থানীয় serving container বন্ধ করে দেয়। এর ডিফল্ট threshold হলো 1.5 GiB।
গার্ডটি ডিফল্টভাবে নিষ্ক্রিয় থাকে, কারণ কোন প্রক্রিয়া মেমোরি ব্যবহার করেছে তা এটি নির্ধারণ করতে পারে না। চাপের কারণ কোনো সম্পর্কহীন হোস্ট ওয়ার্কলোড হলেও এটি সবসময় নিজের vLLM কনটেইনার বন্ধ করে দেয়। এটি স্পষ্টভাবে সক্রিয় করতে সেট করুন:
DSV41_MEM_GUARD=1
ভারী হোস্ট-সাইড কাজের ক্ষেত্রে README-তে এর পরিবর্তে সমস্যাসৃষ্টিকারী কাজটির সীমা নির্ধারণের পরামর্শ দেওয়া হয়েছে:
systemd-run --scope -p MemoryMax=2G <job>
ডিপ্লয়মেন্টে এখনও উভয় কনটেইনারের জন্য --oom-score-adj 1000 ব্যবহার করা হয়, পাশাপাশি থাকে বুট-মার্জিন প্রিফ্লাইট, প্রতিটি প্রিফিলের পর অ্যালোকেটর রিলিজ এবং লোড-পরবর্তী পেজ-ক্যাশ ড্রপ।
ওজন সিঙ্ক্রোনাইজেশনের কৌশল বেছে নিন
NFS: ডিফল্ট
পরীক্ষিত কিটের জন্য NFS-ই উপযুক্ত কনফিগারেশন। এটি vllm-fn-nfs এক্সপোর্টার পুনর্ব্যবহার করে, EXL3 ও slim Engram ডিরেক্টরিগুলো উন্মুক্ত করে এবং worker কনটেইনারে সেগুলো যথাক্রমে /model ও /engram-src হিসেবে মাউন্ট করে।
./start.sh share
./start.sh
start.sh স্বয়ংক্রিয়ভাবে শেয়ারিং ধাপ সম্পন্ন করে, তাই এক্সপোর্ট প্রস্তুত বা সমস্যা নির্ণয়ের সময় স্পষ্টভাবে share কমান্ড চালানোই মূলত উপযোগী।
ZFS: নোড-স্থানীয় প্রতিলিপি
প্রতিটি নোডে একটি স্থানীয় ডেটাসেট বজায় রাখতে .env-এ WEIGHT_SYNC=zfs সেট করুন। ZFS স্থিতিস্থাপকতা বাড়াতে পারে এবং প্রাথমিক প্রতিলিপির পর শুধু পরিবর্তিত ব্লক পাঠায়। এটি স্ন্যাপশট-ভিত্তিক রোলব্যাকের সুবিধাও দেয়।
এর খরচ উল্লেখযোগ্য: প্রতিটি নোডে আনুমানিক 385 GiB খালি পুল স্পেস প্রয়োজন। README-তে উল্লেখ করা হয়েছে, পরীক্ষিত দ্বিতীয় Spark-এ মাত্র প্রায় 41 GiB খালি ছিল, তাই সেখানে ZFS ব্যবহার করা যায়নি।
প্রতিটি নোডে একটি প্রতিনিধিত্বমূলক সেটআপ হলো:
sudo apt-get install -y zfsutils-linux
sudo zpool create -f models <vdev>
sudo zfs create -o recordsize=1M -o atime=off -o compression=lz4 \
-o mountpoint=/path/to/model models/dsv41-exl3
sudo zfs create -o recordsize=1M -o atime=off -o compression=lz4 \
-o mountpoint=/path/to/engram models/dsv41-engram
sudo zfs allow -u "$WORKER_USER" create,destroy,mount,receive,snapshot,rollback models
শুধু 47 ও 48 নম্বর shard এবং index দিয়ে Engram ডেটাসেট পূরণ করুন। সম্পূর্ণ 476 GiB native model tree কপি করবেন না। পুল বা worker-এর zfs recv অনুপলব্ধ হলে launcher streaming-এ ফিরে যায়।
Rsync: আরও সহজ স্থানীয় কপি
WEIGHT_SYNC=rsync ব্যবহার করলে ZFS পুলের প্রয়োজন ছাড়াই প্রচলিত নোড-স্থানীয় কপি তৈরি হয়। এটি ZFS-এর ব্লক-স্তরের incremental update সুবিধা দেয় না।
দ্রুততর প্রিফিলের জন্য Engram ডেটা প্যাক করুন
Engram টেবিল native FP8 ফরম্যাটে থাকে এবং quantized EXL3 tree-এর অংশ নয়। ডিফল্টভাবে, file-backed embedding implementation মেমোরিতে প্রতি layer-এ আনুমানিক 47 GiB পিন না করেই row পুনরুদ্ধার করে।
প্রতিটি নোডের স্থানীয় NVMe-তে rank-specific Engram row file সরাতে চালান:
./start.sh pack
tensor parallel size দুই হলে প্যাকিং প্রতি নোডে আনুমানিক 94 GiB লেখে। এটি ঐচ্ছিক এবং বুটের জন্য প্রয়োজনীয় নয়। প্রতিবেদিত পরীক্ষায়, স্থানীয়ভাবে প্যাক করা Engram file প্রিফিল কর্মক্ষমতা আনুমানিক 25 থেকে 50 শতাংশ বাড়িয়েছে, কারণ row miss-এ NFS-এর পরিবর্তে স্থানীয় direct I/O ব্যবহৃত হয়েছে।
dequantization kernel-এ পাঠানোর সময় Engram row-কে অবশ্যই fp8_e4m3fn হিসেবে typed রাখতে হবে। এগুলোকে uint8 হিসেবে বিবেচনা করলে আপাতদৃষ্টিতে বিশ্বাসযোগ্য কিন্তু ভুল output তৈরি হতে পারে।
ভ্যালিডেশন পরীক্ষা চালান
রিপোজিটরিতে এমন source-level check রয়েছে, যেগুলোর জন্য PyTorch বা vLLM প্রয়োজন হয় না:
python3 tests/test_numeric_config.py
python3 tests/test_engram_src.py
python3 tests/test_engram_secondary.py
python3 tests/test_k_map.py
python3 tests/test_memory_log.py
python3 tests/test_exl3_lm_head.py
python3 tests/test_sm120_block64.py
python3 tests/test_h2d_stage.py
python3 scripts/weight_budget.py --tp 2
chat-template parity test-এর জন্য transformers এবং মূল model-এর encoding/encoding.py প্রয়োজন:
python3 tests/test_chat_template.py --src /path/to/DeepSeek-V4.1-Flash
API চালু হওয়ার পর end-to-end smoke test চালান:
bash tests/test_smoke.sh
smoke test-এ model-কে 17*19 হিসাব করতে বলা হয় এবং 323 প্রত্যাশা করা হয়। সার্ভিস চালু করার আগে start.sh একটি অস্থায়ী কনটেইনারে GPU parity ও Engram dequantization check-ও চালায়। ফলাফল logs/overlay-verify.log-এ লেখা হয়।
উন্নত অপারেশনাল পরামর্শ
- এক বা দুটি স্ট্রিমের জন্য DSpark বেছে নিন: প্রতিবেদনে একক-স্ট্রিম ডিকোড হার ছিল প্রতি সেকেন্ডে 31.6 টোকেন, আর দুটি স্ট্রিমে মোট হার ছিল প্রতি সেকেন্ডে 42.5 টোকেন।
- বড় ব্যাচের জন্য স্পেকুলেশন নিষ্ক্রিয় করুন:
SPEC_METHOD=noneব্যবহার করলে একক-স্ট্রিম থ্রুপুট কমে যায়, তবে প্রতিবেদিত পরীক্ষায় চারটি স্ট্রিমে মোট থ্রুপুট প্রতি সেকেন্ডে 53.7 টোকেনে পৌঁছায়। - পুনরাবৃত্ত দীর্ঘ প্রম্পটের জন্য Engram প্যাক করুন: স্থানীয় NVMe রো ফাইল হেড নোডের NFS এক্সপোর্টের ওপর নির্ভরতা কমায় এবং প্রিফিলের গতি উল্লেখযোগ্যভাবে বাড়াতে পারে।
- ডিপ্লয়মেন্টে শুধু টেক্সট রাখুন: SM120 কার্নেল এনভেলপ মডেলের ভিশন-টোকেন প্রস্থের জন্য প্রয়োজনীয় sparse-MLA কার্নেল সরবরাহ করে না।
- ভেবেচিন্তাহীনভাবে EXL3 সহায়ক স্ট্রিম পুনরায় চালু করবেন না: ডিপ্লয়মেন্ট EXL3 স্ট্রিমগুলোকে সিরিয়াল করে, কারণ ভিন্ন CUDA স্ট্রিমের দুটি কার্নেল প্রতি ডিভাইসে রানটাইমের একক লক বাফারের সঙ্গে ডেডলক করতে পারে।
- সঠিক নেটওয়ার্ক ইন্টারফেস পর্যবেক্ষণ করুন: NCCL
10.0.0.xলুপব্যাক অ্যালিয়াস ব্যবহার করতে পারে না। প্রতি-NIC GID-এর ভুল নির্বাচন প্রায় এক মিনিট পরibv_modify_qperrno 61 দিয়ে ব্যর্থ হতে পারে। - দীর্ঘ প্রিফিলের মেমরি পরীক্ষা করুন: বুট সফল হওয়া এবং সংক্ষিপ্ত স্মোক টেস্ট বড় KV পুল বা কনটেক্সট সেটিং নিরাপদ, এমন প্রমাণ দেয় না।
- রিপোজিটরির লঞ্চার ব্যবহার করুন: এটি NFS বা স্থানীয় সিঙ্ক্রোনাইজেশন, প্রিফ্লাইট পরীক্ষা, ইমেজ যাচাই, দুই-র্যাঙ্ক স্টার্টআপ এবং ডায়াগনস্টিক সমন্বয় করে।
প্রত্যাশিত কর্মদক্ষতা
প্রকাশিত পরিমাপ অনুযায়ী, একটি ডিকোড স্ট্রিমে প্রতি সেকেন্ডে 31.6 টোকেন এবং দুটি স্ট্রিমে মোট প্রতি সেকেন্ডে 42.5 টোকেন পাওয়া যায়। প্যাক করা Engram ডেটা ও গ্রুপ করা এক্সপার্ট কার্নেল ব্যবহার করলে সংক্ষিপ্ত-প্রম্পট প্রিফিলের গতি ছিল প্রায় প্রতি সেকেন্ডে 965 থেকে 1,041 টোকেন।
দীর্ঘ-প্রম্পট প্রিফিল স্বাভাবিকভাবেই ধীর হয়। প্রতিবেদিত উদাহরণগুলোর মধ্যে রয়েছে 100,000-টোকেন প্রম্পটে প্রায় প্রতি সেকেন্ডে 979 টোকেন, 455,000 টোকেনে 802 টোকেন এবং 601,000 টোকেনে 810 টোকেন। প্রকৃত ফলাফল প্রম্পটের গঠন, স্টোরেজ কনফিগারেশন, স্পেকুলেশন, ব্যাচের প্রস্থ এবং নির্ধারিত প্রিফিল খণ্ডের আকারের ওপর নির্ভর করে।
উপসংহার
এই প্রকল্পে দুইটি GB10 DGX Spark-এ DeepSeek V4.1 Flash পরিবেশনের জন্য প্রয়োজনীয় বিশেষায়িত কার্নেল, EXL3 লোডার, ফাইল-সমর্থিত Engram বাস্তবায়ন, নেটওয়ার্কিং কনফিগারেশন, মেমরি নিয়ন্ত্রণ এবং লঞ্চার একত্র করা হয়েছে। সরবরাহকৃত ডিফল্ট দিয়ে শুরু করুন, স্মোক টেস্ট ব্যবহার করে API যাচাই করুন, তারপর একবারে একটি সেটিং সমন্বয় করুন। সবচেয়ে নিরাপদ পরিচালনার জন্য বাস্তবসম্মত দীর্ঘ-প্রিফিল ওয়ার্কলোডে থ্রুপুট এবং উপলভ্য মেমরি দুটিই মূল্যায়ন করুন।
