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

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

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

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

কোনো command copy করার আগে tag যাচাই করুন, এখানকার command-গুলোর ক্ষেত্রেও। Ollama-এর library কোনো notice ছাড়াই পরিবর্তিত হতে পারে। glm-4.7-flash tag list খুলে tag-টি এখনও আছে কি না নিশ্চিত করুন। নতুন কোনো GLM release-এ local weights থাকলে সেটি অগ্রাধিকার দিন এবং বাস্তবে কোন 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 আছে, এবং কোনটি নির্দিষ্ট করে ব্যবহার করবেন

এখানে তিনটি official GLM entry গুরুত্বপূর্ণ। glm-5.2 এবং glm-5.1 শুধু cloud-এ ব্যবহার করা যায়। glm-4.7-flash হলো local entry। এর প্রকাশিত 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-এ প্রকাশিত তথ্য, নিজস্ব measurement নয়। latest এবং q4_K_M উভয়ের download size 19 GB হিসেবে তালিকাভুক্ত। তাই latest বর্তমানে Q4 build-এ resolve হয়। পরবর্তী republish-এ এটি পরিবর্তিত হতে পারে। তাই script বা Dockerfile-এ কখনো সরাসরি ollama pull glm-4.7-flash লিখবেন না। Quantisation-এর নাম উল্লেখ করুন। সবচেয়ে বড় tag, bf16, হলো 60 GB-এর download, যাতে unquantised bfloat16 weights রয়েছে।

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

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

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

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

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

systemctl status ollama --no-pager

Active: active (running) এর অর্থ API port 11434-এ listening করছে। Unit না থাকলে installer সাধারণ binary install-এ fallback করেছে। এ ক্ষেত্রে হাতে তৈরি করার জন্য 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-এ প্রকাশিত 19 GB-এর কাছাকাছি size-সহ glm-4.7-flash:q4_K_M দেখানোর কথা। Pull মাঝপথে ব্যর্থ হলে runnable কিছু অবশিষ্ট থাকে না। তাই একই command আবার চালান। ছোট plan-এ pull ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ network সমস্যা নয়, full disk। কারণ model-টি root filesystem-এর /usr/share/ollama/.ollama/models-এ লেখা হয়। শুরু করার আগে df -h /usr/share/ollama দিয়ে পরীক্ষা করুন।

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

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

সবার জন্য সঠিক এমন কোনো একক multiplier নেই। কারণ আপনি যে context length অনুমতি দেন, KV cache সেই অনুযায়ী বাড়ে। এ ছাড়া runtime version ভেদে বাকি memory usage-ও পরিবর্তিত হয়। তাই অনুমান না করে মাপুন। একটি সাধারণ 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 না হলে failure নীরবে ঘটে এবং এর দুটি রূপ দেখা যায়। Swap enabled থাকলে load সফল হয়েছে বলে মনে হয়, কিন্তু generation অত্যন্ত ধীর হয়ে যায়। কারণ প্রতিটি token-এর জন্য page disk এবং RAM-এর মধ্যে সরানো হয়। 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 সাধারণ chat-এর তুলনায় বেশি ক্ষতিগ্রস্ত হয়। Q4, Q8 এবং FP16 বাস্তবে কীভাবে আলাদা model ব্যবহারের সিদ্ধান্ত নেওয়ার আগে পড়ে নেওয়া ভালো। কারণ CPU-only VPS-এ quantisation নির্বাচনই সাধারণত ঠিক করে model আদৌ চলবে কি না।

CPU-শুধু VPS-এ কী ঘটে

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

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

এর একটি ব্যবহারিক ফল আছে: একই core count এবং একই RAM থাকা দুটি plan-এ generation speed লক্ষণীয়ভাবে ভিন্ন হতে পারে, কারণ তাদের memory subsystem ভিন্ন। একটি shared plan-এ দ্বিতীয় একটি পরিবর্তনশীলও থাকে, কারণ অন্য ব্যবহারকারীর অতিরিক্ত ব্যবহারের কারণে 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 হলো প্রতি second-এ token-এর সংখ্যা। prompt_eval_duration আপনার prompt পড়তে যে সময় লাগে তা দেখায়। ব্যবহারকারীর কাছে প্রথম token প্রদর্শিত হওয়ার আগের অপেক্ষার সময় হিসেবে এটিই দেখা যায়। load_duration disk থেকে model load করতে ব্যয় হওয়া সময়। তাই restart-এর পর প্রথম call-এ এটি বেশি থাকে এবং পরের call-এ প্রায় শূন্য থাকে।

এটি তিনবার চালান এবং দ্বিতীয় ও তৃতীয় ফলাফল রাখুন, কারণ প্রথম ফলাফলে model load করার সময় অন্তর্ভুক্ত থাকে। এরপর অনেক দীর্ঘ prompt দিয়ে আবার চালান, কারণ prompt processing-এর সময় input-এর দৈর্ঘ্যের সঙ্গে বাড়ে, কিন্তু 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 weight রাখার মতো মেমরি আছে, অতিরিক্ত 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-এর মান দেখাবে। যদি এটি একটি খালি Environment= দেখায়, তাহলে override file-টি ভুল directory-তে আছে অথবা reload করা হয়নি। পরের model load-এর পরে, ollama ps-এ 4096-এর তুলনায় দৃশ্যত বড় SIZE দেখা উচিত। ধাপে ধাপে মান বাড়ান এবং প্রতিবার ওই সংখ্যাটি পর্যবেক্ষণ করুন। num_ctx দিয়ে Ollama-এর context length নির্ধারণ-এ এই সেটিং কীভাবে keep-alive এবং parallel request-এর সঙ্গে কাজ করে তা ব্যাখ্যা করা হয়েছে; উভয় ক্ষেত্রেই একই খরচ বহুগুণ হয়।

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

Self-hosting স্বয়ংক্রিয়ভাবে সস্তা নয়। এই 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-এ যে model-টি locally চালানো হয়, সেই GLM-4.7-Flash-এর জন্য উভয় দিকেই দাম $0। এগুলো প্রকাশিত price এবং পরিবর্তিত হতে পারে। তাই যেকোনো একটির ওপর budget পরিকল্পনা করার আগে বর্তমান page পরীক্ষা করুন।

তাই এই মুহূর্তে self-hosting-এর পক্ষে glm-4.7-flash খরচের যুক্তি দুর্বল। পর্যাপ্ত 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 করে। তাই এটি শুধু সার্ভার থেকেই ব্যবহারযোগ্য থাকে। অনুমান না করে আপনার সার্ভারে এটি নিশ্চিত করুন।

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 সংযোগ করতে না পারলে অনেক 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-এর জন্য server-কে 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 পৃথক নিয়ন্ত্রণব্যবস্থা। তাই দুটিই পরীক্ষা করুন। VPS hosting নিরাপদ কি না—এই বিস্তৃত প্রশ্ন-এ চালু রাখা কোনো machine-এর baseline security নিয়ে বাকি বিষয়গুলো ব্যাখ্যা করা হয়েছে।

glm-4.7-flash এখনও বেশি বড় হলে

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

FAQ

GLM 5.2 কি VPS-এ স্থানীয়ভাবে চালানো যায়?

না। 18 August 2026 অনুযায়ী, Ollama-এর library-তে GLM 5.2 শুধু glm-5.2:cloud হিসেবে রয়েছে। এই tag Ollama-এর নিজস্ব infrastructure-এ চলে এবং কাজ করার আগে ollama signin প্রয়োজন। মডেলটিতে 756 billion parameter রয়েছে। তাই প্রতি parameter-এ চার bit ব্যবহার করলেও শুধু weight-এর আকারই কয়েকশ gigabyte হয়। এটি যেকোনো standard VPS plan-এর সক্ষমতার অনেক বাইরে। Downloadable weight-সহ rented 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 tag-এর আকার 32 GB এবং bfloat16 tag-এর আকার 60 GB দেখায়। সবার জন্য একই fixed multiplier সঠিক নয়, কারণ আপনি যে context length নির্ধারণ করেন তার সঙ্গে KV cache-এর আকার বাড়ে। মডেল load করুন, ollama ps চালান এবং নিজের box-এ প্রকৃত মান জানতে 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 করলে public internet-এ একটি unauthenticated endpoint প্রকাশিত হয়। 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-তে সংযোগ করুন।