VPS-এ Ollama দিয়ে GLM 5.2 চালানো যাবে কি?

VPS-এ GLM 5.2 চালানো যাবে কি?

না। কোনো কিছু ভাড়া নেওয়ার আগে এর কারণ জানা দরকার। 18 August 2026 পর্যন্ত Ollama-এর library-তে GLM 5.2-এর ঠিক একটি tag আছে: glm-5.2:cloud। :cloud tag Ollama-এর server-এ চলে। আপনার server prompt পাঠায় এবং token গ্রহণ করে। তাই model-এর weight আপনার disk-এ কখনো আসে না। Model-টিতে 756 billion parameter আছে। প্রতি parameter-এ 4 bit ধরলে 756 billion parameter-এর weight-এর জন্য প্রায় 378 GB লাগে। Context, activation বা operating system-এর হিসাব ধরার আগেই এই পরিমাণ memory প্রয়োজন। কোনো সাধারণ VPS plan-এ এত memory থাকে না।

আপনার ভাড়া করা server-এ যে GLM model চলতে পারে, সেটি হলো glm-4.7-flash। Downloadযোগ্য weight-সহ এটি 4টি tag-এ প্রকাশিত হয়েছে। এটি একটি mixture-of-experts model। অর্থাৎ প্রতিটি token-এর জন্য network-এর কেবল একটি ছোট অংশ চলে। Z.ai এটিকে 30B-A3B হিসেবে বর্ণনা করে: মোট 30 billion parameter, যার মধ্যে প্রতি token-এ প্রায় 3 billion সক্রিয় থাকে। তাই এই guide-এ এমন প্রশ্নের উত্তর দেওয়া হয়েছে, যার ভিত্তিতে আপনি কাজ করতে পারবেন। একটি tag নির্দিষ্ট করুন, server-এর আকার নির্ধারণ করুন, নিজের গতি মাপুন এবং endpoint private রাখুন।

কোনো command copy করার আগে tag যাচাই করুন, এখানকার command-গুলোও এর অন্তর্ভুক্ত। Ollama-এর library পূর্বঘোষণা ছাড়াই পরিবর্তিত হতে পারে। glm-4.7-flash tag list খুলে tag-টি এখনো আছে কি না নিশ্চিত করুন। নতুন কোনো GLM release-এ local weight পাওয়া গেলে সেটি অগ্রাধিকার দিন এবং বাস্তবে কোন tag পরীক্ষা করেছেন তা লিখে রাখুন।

তারপরও যদি GLM 5.2 নিজেই ব্যবহার করতে চান, ollama run glm-5.2:cloud কাজ করবে ollama signin-এর পরে। Client-এর দিক থেকে এটি অন্য যেকোনো Ollama model-এর মতোই আচরণ করে। আপনি কীতে সম্মত হচ্ছেন তা বুঝে নিন: prompt আপনার server ছেড়ে বাইরে যায়। Self-hosting করার কারণ যদি হয় যে data আপনার machine-এই থাকতে হবে, তাহলে :cloud tag সেই শর্ত পূরণ করে না।

কোন GLM tag আছে এবং কোনটি pin করবেন

এখানে তিনটি official GLM entry গুরুত্বপূর্ণ। glm-5.2 এবং glm-5.1 শুধু cloud-এ ব্যবহার করা যায়। glm-4.7-flash হলো local entry। নিচে এর published tag এবং প্রতিটির জন্য Ollama তালিকাভুক্ত download size দেওয়া হলো।

[
  {
    "label": "q4_K_M",
    "download_gb": 19
  },
  {
    "label": "latest",
    "download_gb": 19
  },
  {
    "label": "q8_0",
    "download_gb": 32
  },
  {
    "label": "bf16",
    "download_gb": 60
  }
]

এগুলো library page-এ প্রকাশিত সংখ্যা, সরাসরি মাপা নয়। latest এবং q4_K_M উভয়ের size 19 GB হিসেবে তালিকাভুক্ত। তাই latest বর্তমানে Q4 build-এ resolve হয়। যেকোনো republish-এর সময় এটি বদলে যেতে পারে। এই কারণে script বা Dockerfile-এ কখনো bare ollama pull glm-4.7-flash লিখবেন না। Quantisation-এর নাম উল্লেখ করুন। সবচেয়ে বড় tag, bf16, হলো 60 GB download, যাতে unquantised bfloat16 weight রয়েছে।

Library-তে search করলে নামের মধ্যে slash থাকা namespaced upload-ও দেখা যায়, যেমন someuser/glm-5.2। Slash থাকার অর্থ এটি কোনো user account থেকে published হয়েছে। তাই এটি official entry নয়, community re-upload। এর মধ্যে কোন weight রয়েছে, তার কোনো নিশ্চয়তা নেই। অনলাইনে পাওয়া কোনো unsigned binary যেভাবে যাচাই না করে ব্যবহার করবেন না, এটিকেও সেভাবেই বিবেচনা করুন।

Ollama ইনস্টল করুন এবং নির্দিষ্ট tag pull করুন

Ollama-এর Linux installer একটি command।

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Installer একটি systemd service তৈরি করে, যা ollama user হিসেবে চলে। কোনো কিছু pull করার আগে service-টি চালু হয়েছে কি না নিশ্চিত করুন।

systemctl status ollama --no-pager

Active: active (running)-এর অর্থ হলো API port 11434-এ listening করছে। Unit না থাকলে installer সাধারণ binary install-এ ফিরে গেছে। এ ক্ষেত্রে Ollama Linux documentation-এ হাতে service file তৈরি করার নির্দেশনা রয়েছে।

glm-4.7-flash page-এ Ollama-এর minimum version উল্লেখ আছে। পুরোনো binary model-টি ধীরে চালায় না; এটি model প্রত্যাখ্যান করে। Pull ব্যর্থ হয়ে এমন message দেখায় যে model-টির জন্য আরও নতুন Ollama version প্রয়োজন। Upgrade করতে install script আবার চালান। 18 August 2026 অনুযায়ী current release হলো 0.32.14, যা ওই minimum version-এর চেয়ে যথেষ্ট নতুন।

এখন নাম ব্যবহার করে একটি tag pull করুন।

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls-এ glm-4.7-flash:q4_K_M এবং published 19 GB-এর কাছাকাছি size দেখা উচিত। Pull মাঝপথে ব্যর্থ হলে চালানোর উপযোগী কিছু অবশিষ্ট থাকে না, তাই একই command আবার চালান। ছোট plan-এ pull ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ network problem নয়, full disk। কারণ model-টি root filesystem-এর /usr/share/ollama/.ollama/models-এ লেখা হয়। শুরু করার আগে df -h /usr/share/ollama দিয়ে পরীক্ষা করুন।

প্রতিটি quantisation-এর কত RAM প্রয়োজন?

প্রথমে download size-কে ন্যূনতম সীমা ধরে হিসাব শুরু করুন। এরপর অতিরিক্ত প্রয়োজন যোগ করুন। weights-গুলোকে memory-তে resident থাকতে হয়। এর ওপর থাকে KV cache (key/value cache), যা runtime কথোপকথনে ইতিমধ্যে ব্যবহৃত token মনে রাখতে ব্যবহার করে। এর সঙ্গে compute buffers এবং operating system-এর ব্যবহার করা memory-ও যোগ হয়। ঠিক 19 GB RAM থাকা কোনো machine 19 GB tag চালাতে পারবে না।

সবার জন্য কার্যকর এমন কোনো একক multiplier নেই। কারণ আপনি যত context length অনুমতি দেন, KV cache তত বাড়ে। এ ছাড়া runtime version পরিবর্তনের সঙ্গে বাকি memory ব্যবহারের পরিমাণও বদলে যায়। তাই অনুমান না করে পরিমাপ করুন। একটি সাধারণ prompt দিয়ে model load করুন। এরপর server কত memory reserve করেছে, তা দেখুন।

ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama ps

ollama ps একটি loaded model দেখায়। এতে SIZE column এবং PROCESSOR column থাকে। SIZE হলো runtime বাস্তবে যত memory reserve করেছে। আপনার পরিকল্পনার সঙ্গে তুলনা করার জন্য এই সংখ্যাটিই ব্যবহার করুন। PROCESSOR দেখায় কাজটি কোথায় হচ্ছে। তাই 100% CPU মানে GPU একেবারেই ব্যবহৃত হয়নি।

Model fit না করলে ব্যর্থতা নীরবে ঘটে এবং দুটি রূপ নেয়। swap enabled থাকলে load সফল হয়েছে বলে মনে হয়। এরপর generation অত্যন্ত ধীর হয়ে যায়, কারণ প্রতিটি token-এর সময় disk ও RAM-এর মধ্যে pages সরানো হয়। swap না থাকলে process সরাসরি killed হয়। তখন journalctl -k | grep -i "out of memory" kernel-এর Out of memory: Killed process line দেখায়, যেখানে ollama-এর নাম থাকে। দুটিই পরীক্ষা করুন। কারণ আপনি যে terminal-এ command লিখছিলেন, সেখানে কোনোটিই সহায়ক message দেখায় না।

19 GB Q4 tag থেকে 32 GB Q8 tag-এ যাওয়াই এই সংখ্যার ওপর আপনার প্রধান নিয়ন্ত্রণ। Q4 ব্যবহার করলে কিছু output quality কমে। কতটা কমবে, তা task-এর ওপর নির্ভর করে। Structured output এবং দীর্ঘ reasoning chain সাধারণ casual chat-এর তুলনায় বেশি ক্ষতিগ্রস্ত হয়। Model ব্যবহারের সিদ্ধান্ত নেওয়ার আগে Q4, Q8 এবং FP16 বাস্তবে কীভাবে আলাদা পড়ে নেওয়া উপযোগী। কারণ শুধু CPU-নির্ভর VPS-এ quantisation choice সাধারণত ঠিক করে model আদৌ চলবে কি না।

CPU-only VPS-এ কী ঘটে

বেশিরভাগ VPS plan-এ GPU থাকে না, তাই Ollama কোনো সতর্কতা না দিয়েই CPU-তে model চালাবে। ফল ব্যবহারযোগ্য হবে কি না, তা workload এবং আপনার অপেক্ষা করার সামর্থ্যের ওপর নির্ভর করে।

Mixture-of-experts design গতি বাড়াতে সাহায্য করে। প্রতিটি token-এর জন্য 30 billion parameter-এর মধ্যে প্রায় 3 billion ব্যবহার করা হয়। তাই প্রতিটি token-এর জন্য প্রয়োজনীয় arithmetic একটি dense 30B model-এর তুলনায় অনেক কম। কিন্তু memory-এর প্রয়োজন কমে না। প্রতিটি expert memory-তে resident থাকতে হয়, কারণ পরবর্তী token-এর জন্য router যেকোনো expert বেছে নিতে পারে। তাই CPU-only box-এর জন্যও Q4 tag-এর সম্পূর্ণ 19 GB বা তার বেশি storage প্রয়োজন। Throughput মূলত clock speed নয়, memory bandwidth দ্বারা নির্ধারিত হয়।

এর একটি ব্যবহারিক ফল আছে। একই core count এবং একই RAM থাকা দুটি plan-এও generation speed লক্ষণীয়ভাবে ভিন্ন হতে পারে, কারণ তাদের memory subsystem আলাদা। Shared plan-এ দ্বিতীয় একটি পরিবর্তনশীল যুক্ত হয়। noisy neighbour-এর CPU steal time tokens-per-second মানে প্রকাশ পায়, যা ঘণ্টায় ঘণ্টায় পরিবর্তিত হতে পারে। এ কারণেই অন্য কারও প্রকাশিত সংখ্যা আপনার ফলাফল পূর্বানুমান করতে পারে না। একই কারণে পরের section-এ ফলাফলের table নয়, measurement recipe দেওয়া হয়েছে।

নিজের tokens per second পরিমাপ করুন

Ollama-এর generate endpoint তার চূড়ান্ত JSON object-এ timing field ফেরত দেয়। generated token-এর সংখ্যা generation duration দিয়ে ভাগ করলে আপনার plan ও prompt অনুযায়ী প্রকৃত মান পাবেন।

sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash:q4_K_M",
  "prompt": "Write a 200 word explanation of how TCP congestion control works.",
  "stream": false,
  "options": {"num_ctx": 8192}
}' | jq '{
  tokens: .eval_count,
  tokens_per_second: (.eval_count / .eval_duration * 1e9),
  prompt_seconds: (.prompt_eval_duration / 1e9),
  load_seconds: (.load_duration / 1e9)
}'

eval_count কতগুলো token generated হয়েছে এবং eval_duration সেগুলো generate করতে কত nanosecond লেগেছে তা নির্দেশ করে। তাই eval_count / eval_duration * 1e9 হলো tokens per second। prompt_eval_duration আপনার prompt পড়তে ব্যয় হওয়া সময় নির্দেশ করে। প্রথম token দেখা দেওয়ার আগের অপেক্ষা হিসেবে ব্যবহারকারী এই সময়টিই অনুভব করেন। load_duration disk থেকে model load করতে ব্যয় হওয়া সময়। তাই restart-এর পর প্রথম call-এ এটি বড় হয় এবং পরের call-এ প্রায় শূন্য থাকে।

এটি তিনবার চালান এবং দ্বিতীয় ও তৃতীয় ফলাফল রাখুন, কারণ প্রথম ফলাফলে model load করার সময় অন্তর্ভুক্ত থাকে। এরপর অনেক দীর্ঘ prompt দিয়ে আবার চালান, কারণ prompt processing input length অনুযায়ী বাড়ে, কিন্তু generation speed বাড়ে না। আপনার plan name এবং quantisation-এর পাশে সংখ্যাগুলো লিখে রাখুন। এই record আপনার পড়া যেকোনো benchmark-এর চেয়ে বেশি কার্যকর, কারণ আপনি যে hardware-এর জন্য অর্থ দিচ্ছেন, এই পরিমাপ সেটিতেই করা হয়েছে।

কনটেক্সটের দৈর্ঘ্য কীভাবে মেমরি খরচ বহুগুণ বাড়ায়

Ollama-তে ডিফল্ট কনটেক্সট 4096 টোকেন। মডেলটি এর চেয়ে অনেক বেশি, অর্থাৎ glm-4.7-flash-এর জন্য 198K টোকেন সমর্থন করে। তবে এটি ডিফল্টভাবে সক্রিয় থাকে না, এবং সক্রিয় করলে অতিরিক্ত মেমরি প্রয়োজন হয়।

KV cache-এ প্রতিটি টোকেনের জন্য প্রতিটি layer-এ একটি key vector এবং একটি value vector সংরক্ষিত থাকে। আপনি যত টোকেন অনুমতি দেবেন, এর আকার তত সরলরৈখিকভাবে বাড়বে। 4096 থেকে 32768 টোকেনে গেলে কনটেক্সট 8 গুণ হয়, তাই KV cache-ও প্রায় 8 গুণ হয়। যে সিস্টেমে শুধু model weights রাখার মতো মেমরি আছে, সেখানে এই অতিরিক্ত allocation-ই swap ব্যবহার শুরু করায়। এ কারণেই ছোট prompt-এর উত্তর ঠিকভাবে দেওয়া একটি মেশিনে কেউ দীর্ঘ document paste করলে হঠাৎ কাজের গতি খুব কমে যায়।

উপরের curl command-এর মতো options object-এ num_ctx ব্যবহার করে প্রতিটি request-এর জন্য এটি নির্ধারণ করুন, অথবা server-এর default পরিবর্তন করুন।

sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

শেষ command-টি আপনার OLLAMA_CONTEXT_LENGTH value প্রদর্শন করবে। এটি যদি খালি Environment= প্রদর্শন করে, তাহলে override file ভুল directory-তে আছে অথবা reload করা হয়নি। পরবর্তী model load-এর পরে ollama ps-তে 4096-এর সময়ের তুলনায় দৃশ্যত বড় SIZE দেখা উচিত। ধাপে ধাপে value বাড়ান এবং প্রতিবার ওই সংখ্যা পর্যবেক্ষণ করুন। num_ctx দিয়ে Ollama-এর context length নির্ধারণ-এ keep-alive এবং parallel request-এর সঙ্গে এর সম্পর্ক ব্যাখ্যা করা হয়েছে; উভয় ক্ষেত্রেই একই খরচ বহুগুণ হয়। একাধিক client server ব্যবহার করলে context নির্ধারণের সময়ই concurrency limit ঠিক করুন, কারণ প্রতিটি parallel slot নিজের KV cache বহন করে এবং queue setting নির্ধারণ করে দ্বিতীয় request অপেক্ষা করবে, নাকি সরাসরি প্রত্যাখ্যাত হবে।

API যখন সার্ভারের চেয়ে সস্তা

Self-hosting স্বয়ংক্রিয়ভাবে সস্তা নয়। এই model family-এর ক্ষেত্রে প্রকাশিত list price বিষয়টি অস্বাভাবিকভাবে স্পষ্ট করে।

[
  {
    "label": "GLM-5.2 input",
    "usd_per_million_tokens": 1.4
  },
  {
    "label": "GLM-5.2 output",
    "usd_per_million_tokens": 4.4
  },
  {
    "label": "GLM-4.7-Flash input",
    "usd_per_million_tokens": 0
  },
  {
    "label": "GLM-4.7-Flash output",
    "usd_per_million_tokens": 0
  }
]

18 August 2026 অনুযায়ী, Z.ai প্রতি million input token-এর জন্য GLM-5.2-এর দাম $1.4 এবং প্রতি million output token-এর জন্য $4.4 নির্ধারণ করেছে। এই guide-এ locally চালানো model GLM-4.7-Flash-এর জন্য input ও output—উভয় দিকেই দাম $0। এগুলো প্রকাশিত price এবং সময়ের সঙ্গে পরিবর্তিত হতে পারে। তাই যেকোনো একটির ওপর budget পরিকল্পনা করার আগে বর্তমান page পরীক্ষা করুন।

তাই এখন self-hosting glm-4.7-flash-এর পক্ষে cost-এর যুক্তি দুর্বল। পর্যাপ্ত RAM-সহ একটি VPS-এর জন্য প্রতি মাসে বাস্তব খরচ হয়, অথচ publisher একই model বিনামূল্যে চালায়। নিজে চালালে আপনি অন্য সুবিধা পান: আপনার prompt আপনার নিয়ন্ত্রণাধীন machine-এই থাকে, এবং আপনি পরিবর্তন না করা পর্যন্ত model version পরিবর্তিত হয় না। Self-hosting-এর পক্ষে এগুলো ভালো কারণ। তবে এই model-এর জন্য, এই price-এ cost তার মধ্যে পড়ে না।

আপনার প্রয়োজনীয় model বিনামূল্যে না হলে, অথবা আইনগত কারণে আপনার data নিজের network-এর বাইরে পাঠানো না গেলে, হিসাব বদলে যায়। GPU VPS এবং API token-এর break-even point প্রতিটি variable-এর নাম উল্লেখ করে সেই হিসাব দেখায়। আপনি যদি এখনও machine বেছে নিয়ে থাকেন, একটি VPS-এর প্রকৃত মাসিক খরচ এই হিসাবের অন্য অর্ধাংশ ব্যাখ্যা করে।

localhost-এ endpoint রাখুন

এই ধাপটি অনেকে এড়িয়ে যান। কিন্তু এটিই সবচেয়ে গুরুত্বপূর্ণ।

Ollama ডিফল্টভাবে port 11434-এ 127.0.0.1-এ bind করে। তাই এটি শুধু সার্ভার থেকেই reachable থাকে। অনুমান না করে আপনার সার্ভারে সেটি নিশ্চিত করুন।

ss -ltnp | grep 11434

আপনি 127.0.0.1:11434 দেখতে চান। 0.0.0.0:11434 বা *:11434 দেখালে বুঝতে হবে API প্রতিটি interface-এ, public interface-সহ, listening করছে।

এটি গুরুত্বপূর্ণ, কারণ Ollama API-তে কোনো authentication নেই। কোনো password নেই, token নেই, allowlist নেই। যে কেউ port 11434-এ পৌঁছাতে পারলে আপনার model-এর তালিকা দেখতে পারে, আপনার খরচে চলা hardware-এ generation চালাতে পারে, disk পূর্ণ না হওয়া পর্যন্ত নতুন model pull করতে পারে এবং আপনার থাকা model মুছে দিতে পারে। Port 11434 নির্দিষ্ট এবং বহুল পরিচিত। তাই scanner-গুলো খোলা port দ্রুত খুঁজে পায়।

OLLAMA_HOST=0.0.0.0 সেট করবেন না। আপনার laptop-এর client connect করতে না পারলে অনেক tutorial এটিকে সমাধান হিসেবে পরামর্শ দেয়। এটি ভুল সমাধান। এর বদলে port forward করুন।

ssh -N -L 11434:127.0.0.1:11434 you@your-server

এটি SSH-এর মাধ্যমে আপনার laptop-এর port 11434-কে সার্ভারের loopback address-এ map করে। ফলে http://localhost:11434-এর জন্য configured যেকোনো client পরিবর্তন ছাড়াই কাজ করবে এবং নতুন কিছু expose হবে না। একাধিক ব্যক্তি বা একাধিক machine-এর জন্য সার্ভারকে private tunnel network-এ রাখুন এবং Ollama-কে tunnel address-এ bind করুন। কখনোই 0.0.0.0-এ bind করবেন না।

সার্ভার ছাড়া অন্য কোনো স্থান থেকে যাচাই করুন। SSH tunnel বন্ধ থাকা অবস্থায় আপনার laptop থেকে চালান:

curl -m 5 http://your-server-ip:11434/api/tags

curl: (28) Connection timed out বা curl: (7) Failed to connect সঠিক ফলাফল। আপনার model-এর একটি JSON তালিকা দেখা গেলে বুঝতে হবে port Internet-এর জন্য খোলা আছে। এখনই এটি ঠিক করতে হবে। আপনার provider-এর network firewall সার্ভারে চলা firewall থেকে আলাদা নিয়ন্ত্রণ। তাই দুটিই পরীক্ষা করুন। একটি চালু রাখা machine-এর baseline নিরাপত্তা নিয়ে VPS hosting নিরাপদ কি না—এই বৃহত্তর প্রশ্ন অংশে বাকি আলোচনা আছে।

glm-4.7-flash-ও যদি এখনও বড় হয়

Q4 tag আপনার plan-এ না ধরলে context ছোট করবেন না; ছোট model ব্যবহার করুন। কোনো model চালানোর জন্য context কমালে এমন কিছু পাবেন, যা load হয় কিন্তু প্রথম দীর্ঘ prompt-এই ব্যর্থ হয়। VPS-এ 8B ও 27B-তে Qwen 3 একই install path অনুসরণ করে এবং সীমিত সক্ষমতার box-এর উপযোগী size দেয়। VPS-এ Ollama দিয়ে LLM self-hosting-এর সাধারণ নির্দেশিকা-তে আপনি যে model-ই বেছে নিন, একই থাকা অংশগুলো ব্যাখ্যা করা হয়েছে। যে model ব্যবহার করুন না কেন, tag নির্দিষ্ট করে রাখুন, নিজের plan-এ মাপ নিন এবং endpoint loopback-এ রাখুন।

FAQ

GLM 5.2 কি VPS-এ locally চালানো যায়?

না। 18 August 2026 অনুযায়ী, GLM 5.2 Ollama-এর library-তে শুধু glm-5.2:cloud হিসেবে রয়েছে। এই tag Ollama-এর নিজস্ব infrastructure-এ চলে এবং কাজ করার আগে ollama signin প্রয়োজন। মডেলটিতে 756 billion parameter রয়েছে। তাই প্রতি parameter-এ চার bit ব্যবহার করলেও শুধু weight-এর আকারই শত শত gigabyte হয়। এটি যেকোনো standard VPS plan-এর সক্ষমতার অনেক বাইরে। Downloadable weight-সহ ভাড়া করা server-এ চালানো যায় এমন GLM model হলো glm-4.7-flash।

glm-4.7-flash-এর কত RAM প্রয়োজন?

Tag-এর download size-কে ন্যূনতম সীমা হিসেবে ধরুন। এর সঙ্গে KV cache এবং operating system-এর জন্য অতিরিক্ত RAM রাখুন। Ollama Q4 tag-এর আকার 19 GB, Q8-এর আকার 32 GB এবং bfloat16 tag-এর আকার 60 GB দেখায়। সবার জন্য কোনো নির্দিষ্ট multiplier সঠিক নয়, কারণ আপনি যে context length নির্ধারণ করেন তার সঙ্গে KV cache-এর আকার বাড়ে। মডেলটি load করুন, ollama ps চালান এবং নিজের system-এর প্রকৃত মানের জন্য SIZE column দেখুন।

নিজের VPS-এ প্রতি সেকেন্ডে token-এর সংখ্যা কীভাবে মাপব?

"stream": false সহ http://localhost:11434/api/generate-এ একটি request পাঠান। এরপর response থেকে eval_count এবং eval_duration পড়ুন। প্রতি সেকেন্ডে token-এর সংখ্যা হলো eval_count / eval_duration * 1e9, কারণ eval_duration nanosecond-এ report করা হয়। প্রথম run-এর ফল বাদ দিন, কারণ সেই run-এ load_duration-এর মধ্যে disk থেকে weight পড়ার সময়ও অন্তর্ভুক্ত থাকে। একটি দীর্ঘ prompt দিয়েও আবার পরীক্ষা করুন, কারণ input length বাড়লে prompt_eval_duration বাড়ে, কিন্তু generation speed বাড়ে না।

OLLAMA_HOST-এর মান 0.0.0.0 সেট করা উচিত নয় কেন?

কারণ Ollama-এর API-তে কোনো authentication নেই। তাই এটিকে 0.0.0.0-এ bind করলে authentication-বিহীন একটি endpoint public internet-এ উন্মুক্ত হয়। Port 11434-এ পৌঁছাতে পারে এমন যে কেউ আপনার hardware ব্যবহার করে generation চালাতে এবং কোন model install করা আছে তা পরিবর্তন করতে পারে। Default 127.0.0.1 bind বজায় রাখুন। ss -ltnp | grep 11434 দিয়ে এটি পরীক্ষা করুন। ssh -N -L 11434:127.0.0.1:11434 you@your-server-এর মতো একটি SSH tunnel ব্যবহার করে laptop থেকে API-তে সংযোগ করুন।