Ollama-তে VPS-এ Qwen 3.8 27B চালাবেন কীভাবে

আপনি কি GPU ছাড়া VPS-এ Qwen 3.8 27B চালাতে পারবেন?

VPS-এ Qwen 3.8 27B চালাতে আপনার qwen3.8:27b tag প্রয়োজন। 21 October 2026 অনুযায়ী Ollama library-তে এটি স্থানীয়ভাবে pull করা যায়: এতে 27.3 billion parameter, Q4_K_M quantisation, Apache 2.0 licence, 256K context window এবং প্রায় 0.9 GB vision projector-সহ 18 GB download রয়েছে। Ollama 14 August 2026-এ প্রকাশিত v0.32.12-এ Qwen 3.8 27B support যোগ করে। তাই পুরোনো installation হলে আগে upgrade করতে হবে। 29 October 2026 অনুযায়ী সর্বশেষ stable release হলো v0.40.13, যা 28 October 2026-এ প্রকাশিত হয়েছে।

সংক্ষিপ্ত উত্তর: 32 GB বা তার বেশি RAM-এর VPS-এ এটি চালানো যায়, তবে ধীরে। Q4-এ 27B dense model-এর weights-এর জন্যই প্রায় 17 GB RAM লাগে। এতে context-এর একটি token-ও সংরক্ষিত হওয়ার আগে এই RAM প্রয়োজন হয়। তাই 8 GB এবং 16 GB plan সম্পূর্ণভাবে বাদ পড়ে। সাধারণ two-channel DDR4 VPS-এ সর্বোচ্চ গতি প্রায় 3 tokens per second হতে পারে। অধিকাংশ মানুষ যত দ্রুত পড়েন, এটি তার চেয়েও ধীর।

আগের 27B tag-গুলো এখনও library-তে রয়েছে: qwen3.6:27b এবং qwen3.5:27b দুটিই একই রকম আকারের Q4_K_M build। Qwen3.8-27B, Qwen3.6-27B-এর architecture বজায় রাখে। দুইটির official config file-এ layer layout একই। তাই নিচের memory হিসাব যেকোনোটির ক্ষেত্রেই প্রযোজ্য। কোনো command copy করার আগে live list দেখুন: Ollama qwen3.8 tag page। এখানে করা হিসাব parameter count, bits per weight এবং attention layout-এর ওপর নির্ভর করে, version number-এর ওপর নয়।

কোন Ollama tag pull করবেন এবং কীভাবে পরীক্ষা করবেন

যে tag বিদ্যমান নয়, সেটি pull করলে স্পষ্ট error দেখায়। তাই box-এই দ্রুত সিদ্ধান্ত নেওয়া যায়। কোনো tag বিদ্যমান থাকলেও সেটি স্থানীয়ভাবে চালানো নাও যেতে পারে। library-তে তালিকাভুক্ত, কিন্তু শুধু Ollama cloud থেকেই পরিবেশিত GLM 5.2 নিয়ে সমস্যা সাধারণত এখানেই হয়।

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama showআপনার কাছে থাকা tag-এর architecture, parameter count, context length এবং quantisation দেখায়। parameter line-এ 27.3B এবং quantisation line-এ Q4_K_M থাকলে, এই guide যে build ধরে লেখা হয়েছে সেটিই আপনার কাছে আছে। একই weights-এর higher precision সংস্করণের জন্য library-তে qwen3.8:27b-q8_0 এবং qwen3.8:27b-bf16, 27b-mtp variant, এবং 27b-nvfp4, 27b-mxfp8, 27b-mlx ও 27b-mlx-bf16 tag-ও রয়েছে। tags page এগুলোকে MLX হিসেবে চিহ্নিত করে। এই format Linux VPS-এর বদলে Apple Silicon-এর জন্য তৈরি। qwen3.6-এর বিপরীতে, qwen3.8 entry-তে কোনো 35b-a3b tag নেই। ওই MoE (mixture of experts) model-গুলো এখনও qwen3.6-এর অধীনে রয়েছে এবং CPU-তে সম্পূর্ণ ভিন্নভাবে কাজ করে। এগুলো সম্পর্কে নিচে আরও আলোচনা করা হয়েছে।

প্রতি weight-এ bit অনুযায়ী parameter count

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

সূত্রটি এক লাইনের। Weights-এর bytes = parameters * bits per weight / 8। নির্ভুল 4 bits হলে 27.3 billion parameters-এর জন্য 13.7 GB লাগবে। প্রকাশিত Q4_K_M tag-এর language model file-এর আকার 17 GB। বাস্তবে এটি প্রতি weight-এ 4.98 bits-এর সমান।

এই পার্থক্যটি কোনো error নয়। K-quant format-এ প্রতিটি tensor nominal width-এ সংরক্ষণ করা হয় না। যেসব tensor compression-এর কারণে সবচেয়ে বেশি quality হারায়, সেগুলোতে বেশি bits দেওয়া হয়। প্রকাশিত qwen3.8:27b file-এর Ollama tensor listing-এ এগুলো Q6_K হিসেবে দেখানো হয়েছে: output layer, feed-forward down projection-এর প্রায় অর্ধেক, প্রায় অর্ধেক full-attention layer-এর attention V projection, এবং linear-attention layer-এর fused QKV projection-এর প্রায় অর্ধেক। ছোট normalisation tensor-গুলো পূর্ণ 32-bit precision-এ থাকে। Token embedding, attention Q ও K projection এবং feed-forward gate ও up projection-গুলো model-এর বেশিরভাগ অংশের মতো Q4_K-তেই থাকে। Format-এর নামটি একটি average নির্দেশ করে, এবং average প্রায় 5-এর কাছাকাছি হয়। Scale-এর অন্য প্রান্তেও একই প্রভাব দেখা যায়: BF16-এর জন্য 55 GB মানে প্রতি weight-এ 16.1 bits, flat 16 নয়। সেখানে token embedding-সহ সবকিছু BF16-এ থাকে। সামান্য অতিরিক্ত অংশ আসে file-এর metadata, 32-bit-এ রাখা normalisation tensor এবং nearest gigabyte-এ rounded listed size থেকে।

শুধু language model file নয়, পুরো tag-এর জন্য budget নির্ধারণ করুন। qwen3.8:27b-এর প্রতিটি GGUF tag-এর সঙ্গে প্রায় 0.9 GB-এর একটি vision projector-ও প্রকাশিত হয়। তাই Q4_K_M tag-টি 18 GB হিসেবে তালিকাভুক্ত।

Official qwen3.8 library entry-তে Q5_K_M-এর কোনো published tag নেই। তাই 19.5 GB row-টি measured নয়; ওই format-এর জন্য প্রচলিত 5.7 bits per weight ধরে হিসাব করা হয়েছে। Q8_0, Q4-এর তুলনায় প্রায় দ্বিগুণ হয়ে 29 GB হয়। শুধু CPU ব্যবহার করা box-এ এই দ্বিগুণ size প্রতি token-এ memory traffic দ্বিগুণ করে, ফলে tokens per second-ও আনুমানিক অর্ধেক হয়ে যায়। এই কারণেই এখানে Q4_K_M উপযুক্ত default। Memory নয়, quality-এর দিক থেকে সিদ্ধান্তটি বুঝতে চাইলে Q4, Q8 এবং fp16-এর আরও নিবিড় তুলনা দেখুন।

Context বাড়ার সঙ্গে KV cache-এর খরচ

Weights-এর খরচ স্থির। KV cache (key ও value cache; মডেল ইতিমধ্যে দেখা প্রতিটি token-এর জন্য যে attention state সংরক্ষণ করে) context length-এর সঙ্গে সরলরেখায় বাড়ে। বাস্তবে অধিকাংশ ক্ষেত্রে RAM শেষ হয় এখানেই।

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 0.25,
    "kv_q8_gb": 0.13
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 0.5,
    "kv_q8_gb": 0.25
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  }
]

এই সংখ্যাগুলো মডেলের নিজস্ব config file থেকে নেওয়া। Qwen3.8-27B, Qwen3.6-27B-এর মতোই, একটি hybrid-attention model। এর 64টি layer-এর মধ্যে মাত্র 16টি full attention ব্যবহার করে এবং প্রতিটি token-এর সঙ্গে বাড়তে থাকা cache সংরক্ষণ করে। GQA (grouped-query attention)-এর অধীনে ওই layer-গুলোতে 4টি key/value head এবং 256-এর head dimension আছে। বাকি 48টি layer linear attention (Gated DeltaNet) ব্যবহার করে এবং এর বদলে নির্দিষ্ট আকারের state ধরে রাখে। আমার হিসাব অনুযায়ী, context যত দীর্ঘই হোক, এটি প্রতি conversation slot-এ প্রায় 150 MB। ফলে f16-এ প্রতি token-এর জন্য 64 KiB লাগে। 32k token-এ এর পরিমাণ 2 GB এবং 128k token-এ 8 GB। নিজের server-এ হিসাবটি যাচাই না করে সরাসরি ধরে নেবেন না। Model load করে ollama ps-এর SIZE column পড়ুন। সেখানে weights, cache এবং overhead একসঙ্গে একটি সংখ্যা হিসেবে দেখানো হয়।

Model card-এ উল্লেখ করা 256K context এই architecture-এ ব্যবহারযোগ্য, তবে এর জন্য অতিরিক্ত memory লাগে। f16-এ এটি পূর্ণ করতে weights-এর ওপর আরও প্রায় 16 GB cache লাগে। ওই machine-এ weights-এর জন্য ইতিমধ্যে 17 GB ব্যবহৃত হয়েছে। Ollama default হিসেবে সম্পূর্ণ window দেয় না। এর context-length documentation অনুযায়ী VRAM-এর ভিত্তিতে default হলো: 24 GiB-এর কম হলে 4k token, 24 থেকে 48 GiB হলে 32k, এবং 48 GiB বা তার বেশি হলে 256k। CPU-only VPS-এ কোনো VRAM নেই। তাই এটি 4k tier-এ থাকে এবং OLLAMA_CONTEXT_LENGTH দিয়ে আপনাকে ইচ্ছাকৃতভাবে সীমা বাড়াতে হবে। এই server-wide variable-ই একমাত্র নিয়ন্ত্রণ নয়। individual request-এ num_ctx সেট করলে অন্য সব কাজের জন্য কম খরচের default রেখে একটি দীর্ঘ কাজকে বড় window দেওয়া যায়। ধাপে ধাপে সীমা বাড়ান এবং প্রতিটি পরিবর্তনের পরে ollama ps পরীক্ষা করুন।

দুটি setting cache-এর আকার কমায়। OLLAMA_KV_CACHE_TYPE=q8_0 cache-কে 16 bit-এর বদলে 8 bit-এ সংরক্ষণ করে। এতে 32k token-এর cache 2 GB থেকে কমে 1 GB হয়। এর জন্য flash attention দরকার। তাই OLLAMA_FLASH_ATTENTION=1-ও সেট করুন এবং প্রয়োগ হয়েছে ধরে না নিয়ে ollama ps-এ কমে যাওয়া আকার নিশ্চিত করুন। আগে cache type পরিবর্তন না করে থাকলে, Ollama-এর KV cache-এ q8_0 এবং f16-এর তুলনা-তে দুটি variable সেট করা এবং পরিবর্তনের আগে ও পরে মান পড়ার পদ্ধতি দেখানো হয়েছে। OLLAMA_NUM_PARALLEL=1-ও সমান গুরুত্বপূর্ণ। Ollama একসঙ্গে একাধিক request পরিবেশন করতে পারে। প্রতিটি slot context-এর নিজস্ব অংশ পায়। তাই parallelism বাড়ালে আপনার নির্ধারিত cache-এর পরিমাণ অদৃশ্যভাবে গুণিত হয়। বর্তমান default ইতিমধ্যেই 1 এবং নিচের override সেটিকে 1-এ স্থির রাখে। একাধিক ব্যক্তি এই server ব্যবহার করলে সমস্যার শুরু হয় এই গুণিত cache থেকেই। একটি self-hosted model একসঙ্গে কতজন user-কে পরিবেশন করতে পারে তা core count-এর অনেক আগেই cache slot এবং queue depth নির্ধারণ করে।

8, 16, 32 এবং 64 GB RAM-এ কী রাখা যায়

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

দুটি সংখ্যাকে weights এবং vision projector-এর পাশাপাশি fit হওয়া context-এর হাজার token হিসেবে পড়ুন। হিসাবটি f16 cache, headless Linux VPS, operating system-এর জন্য প্রায় 1.5 GB অবশিষ্ট RAM এবং সামান্য অতিরিক্ত margin ধরে করা হয়েছে। zero-এর অর্থ weights নিজেই fit হয় না, তাই কিছুই fit হয় না; null-এর অর্থ weights fit হয়, কিন্তু ওই tier-এর জন্য ব্যবহারযোগ্য context-এর কোনো নিশ্চিত সংখ্যা নেই।

8 GB এবং 16 GB-এর ক্ষেত্রে সিদ্ধান্তটি অনিশ্চিত নয়। 17 GB weights 16 GB RAM-এ fit হবে না, এবং কোনো context setting-ই তা পরিবর্তন করতে পারে না। swap যোগ করলেও এটি সমাধান হবে না। Ollama GGUF file-টিকে memory-map করে। তাই resident pages RAM ছাড়িয়ে গেলে kernel সেগুলো evict করে আবার পড়তে শুরু করে, এবং এরপর প্রতিটি token disk থেকে gigabytes পরিমাণ data পড়ে। box-এ iowait অত্যন্ত বেড়ে যায় এবং প্রতি সেকেন্ডে এক token-এরও কম উৎপন্ন হয়।

32 GB হলো শুরু করার উপযুক্ত tier। Weights-এর জন্য 17 GB লাগে, vision projector আরও প্রায় 0.9 GB যোগ করে, এবং প্রায় 12.5 GB অবশিষ্ট থাকে। এই পরিমাণটি margin-সহ প্রায় 128k token f16 context-এর জন্য যথেষ্ট। 29 GB-এর Q8_0 weights 32 GB-এর মধ্যে fit হয়, তবে ব্যবহারযোগ্য context vision projector, cache, operating system এবং runtime memory-এর ওপরও নির্ভর করে। এই tier-এ Q8 চালানো যাবে ধরে নেওয়ার আগে আপনার box-এ মোট memory footprint পরীক্ষা করুন।

64 GB-এ যথেষ্ট অবকাশ থাকে। Q4-এর ক্ষেত্রে সম্পূর্ণ 256k window-এর জন্য জায়গা থাকে, এবং Q8_0 weights-এর পরেও সম্পূর্ণ 256k context রাখা যায়। Q8 পাওয়ার জন্য 64 GB-এর দাম দেওয়ার আগে স্পষ্টভাবে বুঝে নিন আপনি কী কিনছেন: অর্ধেক গতিতে সামান্য ভালো output, এমন একটি machine-এ যা আগেই ধীর ছিল। 32 GB plan-এ Q4 ইতিমধ্যে 128k token পর্যন্ত পৌঁছায়, এবং প্রায় সবার জন্য এটিই ভালো trade-off।

VPS-এ CPU inference কত দ্রুত?

একটি dense model থেকে একটি token তৈরি করতে প্রতিটি weight একবার memory থেকে পড়তে হয়। কিছু weight নয়। সব weight। তাই গতি নির্ধারণ করে core-এর সংখ্যা নয়; weight-এর আকার দিয়ে ভাগ করা memory bandwidth। Q4-এ প্রতি token-এ 17 GB memory traffic হয়।

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

এগুলো সর্বোচ্চ সীমা, পরিমাপ করা গতি নয়। বাস্তব output সাধারণত দেখানো সংখ্যার প্রায় 50 থেকে 70 শতাংশে থাকে। কারণ memory latency এবং অসম্পূর্ণ prefetching-এর জন্য theoretical peak-এ কখনও পৌঁছানো যায় না। দুই-channel DDR4-3200 VPS-এর সর্বোচ্চ সীমা 3 tokens per second, তাই প্রায় 2 আশা করুন। দুই-channel DDR5-4800 server-এর সর্বোচ্চ সীমা 4.5, তাই প্রায় 3 আশা করুন।

বড় server row-গুলোর ক্ষেত্রে একটি সতর্কতা আছে। বারো-channel EPYC platform-এ 460.8 GB/s memory bandwidth এবং 27.1 tokens per second-এর সর্বোচ্চ সীমা থাকে। কিন্তু আপনি পুরো EPYC ভাড়া নেন না। Memory bandwidth পুরো host-এর একটি shared resource; একই machine-এর প্রতিটি tenant এটি ব্যবহার করে। তাই 8 vCPU slice-এর সঙ্গে বারোটি channel-এর exclusive bandwidth থাকে না। GPU-কেন্দ্রিক guide-গুলো এই বিষয়টি পুরোপুরি বাদ দেয়। একই model-এ vCPU সংখ্যা অভিন্ন হলেও দুটি VPS plan-এর গতিতে তিন গুণ পার্থক্য হওয়ার কারণ এটাই।

একই কারণে বেশি vCPU খুব দ্রুত উপকার করা বন্ধ করে। Core-গুলো memory controller-এর সরবরাহক্ষমতার চেয়ে দ্রুত data চাইতে শুরু করলে অতিরিক্ত thread শুধু scheduling overhead বাড়ায়। অন্য কোনো সুবিধা দেয় না। Ollama-তে thread count-এর জন্য server-wide environment variable নেই। তাই request-এর options-এ num_thread সেট করুন আপনার physical core count অনুযায়ী, গতি মাপুন, তারপর সেই সংখ্যার অর্ধেক চেষ্টা করুন। অনেক shared plan-এ কম setting-ই দ্রুততর হয়।

Prompt processing ভিন্নভাবে কাজ করে। প্রথম token আসার আগে input-এর ওপর চালানো pass, অর্থাৎ prefill, bandwidth bound নয়; এটি compute bound। তাই core বাড়ালে এর গতি বাড়ে। বাস্তবে বড় prompt-এর ক্ষেত্রে output শুরু হওয়ার আগে দীর্ঘ বিরতি দেখা যায়। এরপর উপরের ধীর কিন্তু স্থির rate বজায় থাকে। --verbose দিয়ে দুই অংশের সময় আলাদাভাবে মাপুন। এটি প্রতিটি request-এর জন্য একটি prompt eval rate এবং একটি eval rate দেখায়।

Dense 27B model খুব ধীর হলে CPU ব্যবহারের সিদ্ধান্ত নেওয়ার আগে qwen3.6:35b-a3b tag দেখুন। এগুলো প্রতি token-এ সব 27.3 billion parameter সক্রিয় না করে প্রায় 3 billion parameter সক্রিয় করে। ফলে disk-এ file বড় হলেও প্রতি token-এ memory traffic প্রায় এক order of magnitude কমে যায়। এর বিনিময়ে RAM footprint বাড়ে, কিন্তু গতি বাড়ে। এখানে runtime নির্বাচনও গুরুত্বপূর্ণ। একই inference code-এর ওপর Ollama এবং llama.cpp ভিন্ন CPU tuning control প্রকাশ করে।

কখন GPU hour ভাড়া নেওয়া ভালো

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

প্রকাশিত GPU memory bandwidth-এ একই formula প্রয়োগ করলে উত্তরটি ভিন্ন শ্রেণির হয়। 24 GB-এর একটি consumer card এই weights-এ প্রতি সেকেন্ডে সর্বোচ্চ 59 tokens দিতে পারে। বর্তমান data centre card-এ এই হার 197 পর্যন্ত পৌঁছায়। thread count সমন্বয় করে এই ব্যবধান পূরণ করা যায় না। আপনার VPS যেখানে প্রতি সেকেন্ডে কয়েক দশ GB/s bandwidth পায়, card-টি সেখানে memory চালায় 1008 GB/s গতিতে।

তাই পছন্দের ভিত্তিতে নয়, workload-এর ভিত্তিতে সীমা নির্ধারণ করুন। কাজটি asynchronous হলে এবং কেউ output-এর জন্য অপেক্ষা না করলে CPU inference উপযুক্ত: যেমন রাতে একগুচ্ছ document summarise করা, অথবা আপনি ঘুমানোর সময় চলা nightly classification job। কোনো ব্যক্তি output-এর জন্য অপেক্ষা করলে, অথবা আপনার box যত দ্রুত request শেষ করতে পারে তার চেয়ে দ্রুত request আসতে শুরু করলে GPU ভাড়া নিন। CPU runtime একসঙ্গে শুধু একটি request-এ সীমাবদ্ধ নয়: llama.cpp server CPU এবং GPU উভয় ক্ষেত্রেই parallel decoding ও continuous batching সমর্থন করে, আর Ollama-ও parallel request serve করতে পারে, যদিও এতে বেশি cache লাগে। সিদ্ধান্ত নির্ভর করে আপনার measured serving rate এবং arrival rate-এর তুলনার ওপর। তাই নিজের box-এ বাস্তবসম্মত একটি batch-এর সময় মাপুন। request আসার হার এর চেয়ে বেশি হলে queue বাড়তে থাকবে।

খরচের তুলনা দেখলে যতটা সরল মনে হয়, আসলে ততটা নয়। একটি 64 GB VPS-এ model loaded থাকুক বা না থাকুক, মাসের প্রতিটি ঘণ্টার জন্য bill হয়। অন্যদিকে hourly GPU rental compute charge এবং storage charge আলাদা রাখে; GPU বন্ধ হওয়ার পরেও storage charge চলতে পারে। আপনার প্রকৃত ব্যবহার যদি দিনে দুই ঘণ্টা হয়, rented GPU একই সঙ্গে দ্রুততর এবং সস্তা হতে পারে। প্রথমে আপনার duty cycle নির্ধারণ করুন, তারপর খরচ হিসাব করুন। GPU-সহ VPS বেছে নেওয়া instance নিজে পরীক্ষা করার বিষয়গুলো ব্যাখ্যা করে, আর GPU-তে concurrent request serve করলে vLLM Ollama-কে ছাড়িয়ে যায় কারণ vLLM request-গুলো যথাযথভাবে batch করে।

আরেকটি বিকল্পের কথা অনেকে ভুলে যান। batch work-এর জন্য 27B-কে CPU-তে রাখুন এবং interactive path-এর সামনে একটি hosted API model ব্যবহার করুন। একই model-কে উভয় ধরনের কাজ serve করতেই হবে—এমন কোনো বাধ্যবাধকতা নেই।

নিজের মেশিনে Ollama ইনস্টল করে পরিমাপ নিন

ইনস্টল স্ক্রিপ্টটি অফিসিয়াল এবং এটি একটি dedicated ollama user হিসেবে চলা systemd service সেট আপ করে।

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

ollama --version-এ 0.32.12 বা তার পরের সংস্করণ দেখানো উচিত। এটিই Qwen 3.8 27B support থাকা প্রথম release। কোনো কিছু download করার আগে free -g পরীক্ষা করুন। এটি GiB-এ মান দেখায়। তাই 32 GB RAM হিসেবে বিজ্ঞাপিত কোনো পরিকল্পনায় total column-এ প্রায় 29 দেখা যেতে পারে। উপলভ্য memory-র সঙ্গে উপরের weights ও cache budget তুলনা করুন।

runtime options shell-এ না দিয়ে systemd override-এ নির্ধারণ করুন। model-টি service-এর ভিতরে চলে, তাই এটি আপনার interactive environment দেখতে পায় না।

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

--verbose output-এই আপনার প্রয়োজনীয় পরিমাপ রয়েছে। generation চলাকালে eval rate হলো প্রতি সেকেন্ডে আপনার tokens-এর সংখ্যা। prompt eval rate হলো prefill speed। load duration হলো disk থেকে weights পড়তে যে সময় লেগেছে। এ কারণেই OLLAMA_KEEP_ALIVE=60m সেট করা হয়েছে: CPU-তে প্রতিটি request-এর সময় disk থেকে 17 GB reload করতে হলে request প্রক্রিয়াকরণের চেয়ে বেশি সময় লাগে। default idle timeout পাঁচ মিনিট। এটি যথেষ্ট কম হওয়ায় item-গুলোর মধ্যে বিরতি থাকা batch queue বারবার এই load cost বহন করে। একটি model resident রাখার options-এ প্রতি-request keep_alive field এবং reboot-এর পরেও setting কার্যকর রাখার পদ্ধতি—দুটিই রয়েছে।

model-টি loaded থাকা অবস্থায় দ্বিতীয় terminal থেকে memory footprint পরীক্ষা করুন।

ollama ps

SIZE column-এ KV cache-সহ প্রকৃত memory footprint দেখানো হয়। এটি weights, vision projector এবং KV chart-এ আপনার context length-এর row-এর যোগফলের কাছাকাছি থাকা উচিত। 8192 tokens এবং 8-bit cache ব্যবহার করলে cache-এর বৃদ্ধি পাওয়া অংশ প্রায় এক-চতুর্থাংশ gigabyte। এটি 0.5 GB-এর তুলনায় কম, যদি cache-টি f16-এ থাকত; এর সঙ্গে fixed linear-attention state যুক্ত হয়। PROCESSOR column-এ 100% CPU দেখানো উচিত। অন্য কিছু দেখালে কোনো উপাদান GPU ব্যবহার করছে। সে ক্ষেত্রে এই guide-এর speed numbers আপনার মেশিনের ক্ষেত্রে প্রযোজ্য নয়।

ব্যর্থতার ধরন এবং আপনি যে নির্দিষ্ট স্ট্রিংগুলো দেখবেন

মডেল লোড হতে অস্বীকার করে। Ollama উভয় সংখ্যার নাম উল্লেখ করে একটি লাইন দেখায়, যার বিন্যাস model requires more system memory (18.6 GiB) than is available (15.2 GiB)। এটি ভালো ধরনের ব্যর্থতা, কারণ Ollama memory বরাদ্দের আগে পরীক্ষা করেছে এবং বিষয়টি kernel-এর ওপর ছেড়ে দেয়নি। context length কমান, ছোট tag ব্যবহার করুন, অথবা বড় plan-এ যান।

উত্তর দেওয়ার মাঝখানে process অদৃশ্য হয়ে যায়। client কোনো কার্যকর তথ্য দেখায় না, আর journalctl -u ollama -n 50 দেখায় যে service পুনরায় চালু হচ্ছে। dmesg -T | tail চালান। সেখানে Out of memory: Killed process ... (ollama) লেখা একটি লাইন থাকলে বুঝবেন kernel OOM killer process-টিকে বন্ধ করেছে। এটি ঘটে যখন pre-load পরীক্ষা সফল হয়, কিন্তু দীর্ঘ conversation চলাকালে cache-এর আকার অনুমানের চেয়ে বেড়ে যায়। context length কমান।

pull সঙ্গে সঙ্গে ব্যর্থ হয়। Error: pull model manifest: file does not exist-এর অর্থ হলো tag-টি library-তে নেই। এখনও release না হওয়া কোনো version number দিলে ঠিক এই ফল দেখা যায়। tag-এ বানান ভুল থাকলেও একই ঘটনা ঘটে। qwen3.8:27b নিজেই একটি বাস্তব tag। তাই ওই নির্দিষ্ট tag ব্যর্থ হলে প্রথমে বানান ভুল খুঁজুন। network-কে দোষ দেওয়ার আগে library page-এ tag-টি নিশ্চিত করুন। কোনো বাস্তব tag pull হলেও run না হলে ollama --version-এর সঙ্গে 0.32.12 তুলনা করুন।

সবকিছু কাজ করছে, কিন্তু গতি অসহনীয়ভাবে কম। পর্যাপ্ত RAM থাকা সত্ত্বেও কোনো মেশিনে প্রতি সেকেন্ডে এক token-এর কম গতি হলে compute-এর বদলে paging-এর সমস্যা বোঝায়। generation চলার সময় vmstat 1 চালান। si বা so column-এর মান non-zero হলে kernel swap ব্যবহার করছে। সমাধান হলো কম context ব্যবহার করা অথবা কম model loaded রাখা। swap activity না থাকলেও wa ধারাবাহিকভাবে বেশি থাকলে memory-mapped weights disk থেকে বারবার পড়া হচ্ছে। এর অর্থ weights memory-তে পুরোপুরি fit করছে না।

প্রথম token পেতে 30 seconds লাগে, তারপর output-এর গতি বেড়ে যায়। এটি prefill এবং স্বাভাবিক আচরণ। cache-এ request না থাকলে প্রতিটি request-এ দীর্ঘ system prompt প্রক্রিয়াকরণের খরচ দিতে হয়। তাই অন্য কিছু tune করার আগে system prompt সংক্ষিপ্ত করুন।

CPU-only 27B মডেল আসলে কোন কাজে উপযোগী

আশা নয়, সংখ্যার ভিত্তিতে প্রত্যাশা নির্ধারণ করুন। প্রতি সেকেন্ডে দুই থেকে চারটি token গতিতে 500 token-এর একটি উত্তর দিতে দুই থেকে চার মিনিট সময় লাগে। Chat-এর জন্য এটি ব্যবহার অনুপযোগী, কিন্তু queue-এর জন্য সম্পূর্ণ কার্যকর। কোনো model উত্তর দেওয়ার আগে চিন্তা করলে এই হিসাব আরও খারাপ হয়, কারণ hidden reasoning token-গুলোও উত্তরের মতো একই ধীর গতিতে তৈরি হয়। তাই কাজের সঙ্গে reasoning effort level মিলিয়ে নেওয়া model পরিবর্তন না করেও উত্তর দিতে সময় কমানোর কয়েকটি কার্যকর উপায়ের একটি। Document summarisation, bulk tagging, file backlog থেকে field extraction এবং unattended code review এই ধীর গতি সহ্য করতে পারে, কারণ কোনো কিছুই উত্তরের জন্য অপেক্ষা করছে না। Coding assistance ঠিক এই সীমারেখায় রয়েছে। তাই আপনার host করা model-এ coding agent নির্দেশ করা commit message এবং test scaffolding-এর মতো background job-এর জন্য কার্যকর, কিন্তু আপনি বসে থেকে অপেক্ষা করা inline suggestion-এর জন্য নয়।

আসল বিষয়টি হলো privacy। Model আপনার ভাড়া নেওয়া ও নিয়ন্ত্রণাধীন hardware-এ চলে, কোনো request সেই machine ছেড়ে যায় না, এবং প্রতি token-এর জন্য কোনো bill নেই। প্রতি সেকেন্ডে তিনটি token গতিতেও regulated data-এর ক্ষেত্রে এর মূল্য অনেক। বিকল্পটির সঙ্গে সৎভাবে তুলনা করুন: frontier-scale model self-host করতে এক order of magnitude বেশি hardware প্রয়োজন, এবং 27B CPU-তে সেই curve-এর সবচেয়ে কম খরচের বিন্দু, যেখানে output এখনও পড়ার মতো।

এর যেকোনোটি benchmark করতে real structured input দরকার। বেশিরভাগ public data API-তে throughput মাপার আগেই account তৈরি করতে হয়। Strasmore-এর demo schema (আমরা এটি চালাই) কোনো key বা signup ছাড়াই US equities ও options data-এর ওপর read-only SQL নথিবদ্ধ করে এবং database-qualified table name ব্যবহার করে: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5। Demo-র limit হলো প্রতি call-এ 500 row এবং 20 seconds; history 1 January 2025 থেকে শুরু, যা প্রতি সেকেন্ডে দুইটি token গতির box-এর ব্যবহারের তুলনায় যথেষ্ট বেশি। সম্পূর্ণ column list পাওয়া যাবে https://ai.strasmore.com/api/demo/schema-এ।

এটি যদি আপনার প্রথম Ollama install হয়, তাহলে VPS-এ Ollama চালানোর সম্পূর্ণ নির্দেশিকা service setup, HTTP API এবং এই guide-এ ধরে নেওয়া firewall rule-গুলো ব্যাখ্যা করে। Port 11434 internet-এর জন্য expose করবেন না। Ollama-র local API-তে কোনো authentication প্রয়োজন হয় না। তাই যে কোনো কিছু ওই port-এ পৌঁছাতে পারলে আপনার model ব্যবহার করতে পারে।

FAQ

Ollama-তে কি Qwen 3.8 27B মডেল আছে?

হ্যাঁ। 21 October 2026 অনুযায়ী Ollama library-তে qwen3.8 entry আছে, এবং qwen3.8:27b (যেটি latest নামেও tagged) হলো 27.3 billion parameter-এর একটি dense model-এর 18 GB Q4_K_M build, যার সঙ্গে vision projector এবং 256K context window আছে। এটি locally চলে এবং Ollama v0.32.12 বা পরবর্তী version প্রয়োজন। পুরোনো qwen3.6:27b এবং qwen3.5:27b tag-ও এখনও তালিকাভুক্ত আছে। বর্তমান তালিকার জন্য https://ollama.com/library/qwen3.8/tags দেখুন। অস্তিত্বহীন কোনো tag ব্যবহার করলে Error: pull model manifest: file does not exist error হবে।

VPS-এ Qwen 27B model চালাতে কত RAM প্রয়োজন?

Q4_K_M-এর জন্য 32 GB ব্যবহারিক minimum। Weights-এর আকার 17 GB, vision projector আরও প্রায় 0.9 GB যোগ করে, operating system-এর জন্য প্রায় 1.5 GB লাগে, এবং f16-তে প্রতি 16,000 token context-এর জন্য KV cache প্রায় 1 GB যোগ করে, কারণ model-এর 64টি layer-এর মধ্যে মাত্র 16টি ক্রমবর্ধমান cache ধরে রাখে। 16 GB plan-এ weights-ই রাখা যায় না। swap ব্যবহার করেও লাভ হয় না, কারণ file-টি memory-mapped এবং kernel প্রতিটি token-এর সময় disk থেকে সেটি আবার পড়ে। Q8_0 weights 29 GB হলেও 64 GB-তে সম্পূর্ণ 256K window ব্যবহারের জন্য যথেষ্ট জায়গা থাকে।

CPU-তে 27B model প্রতি second-এ কত token দেবে?

আপনার memory bandwidth-কে weights-এর আকার দিয়ে ভাগ করুন, তারপর তার 50 থেকে 70 শতাংশ ধরুন। দুই-channel DDR4-3200 VPS-এর ceiling প্রায় 3 token per second এবং এটি প্রায় 2 token per second দেয়। দুই-channel DDR5-4800 machine-এর ceiling প্রায় 4.5 এবং এটি প্রায় 3 token per second দেয়। বেশি channel-যুক্ত server platform কাগজে অনেক ভালো দেখায়। তবে host-এর প্রতিটি tenant-এর মধ্যে memory bandwidth ভাগ হয়। তাই ollama run qwen3.8:27b --verbose দিয়ে নিজের system মাপুন এবং eval rate line দেখুন।

CPU-only VPS-এ Q4 নাকি Q8 ব্যবহার করা উচিত?

প্রায় সব ক্ষেত্রেই Q4_K_M ব্যবহার করুন। Q8_0-এর আকার 29 GB, যেখানে Q4_K_M-এর আকার 17 GB। তাই 32 GB-তে Q8_0-এর weights রাখা যায়। তবে projector, cache, operating system এবং runtime-এর জন্য headroom খুব কম থাকে। 64 GB হলে দীর্ঘ context ব্যবহারের জন্য জায়গা থাকে। প্রতি token-এ এটি প্রায় দ্বিগুণ memory স্থানান্তর করে, ফলে আপনার tokens per second প্রায় অর্ধেক হয়ে যায়। 27B model-এ অধিকাংশ কাজের ক্ষেত্রে Q4_K_M এবং Q8_0-এর quality difference কম। অতিরিক্ত RAM দীর্ঘ context-এর জন্য ব্যবহার করুন। কারণ এতে model কী করতে পারে তা বদলায়, শুধু কীভাবে বাক্য গঠন করে তা নয়।

বড় RAM VPS-এর বদলে GPU ভাড়া করা কখন সস্তা?

আপনার duty cycle কম হলে বা কোনো ব্যক্তি অপেক্ষা করলে। 24 GB memory-যুক্ত GPU এই weights-এর ক্ষেত্রে তাত্ত্বিকভাবে প্রায় 59 token per second দিতে পারে, যেখানে সাধারণ VPS-এ আনুমানিক 2 বা 3 token per second পাওয়া যায়। Instance বন্ধ হলে hourly GPU compute charge বন্ধ হয়। তবে persistent storage-এর জন্য খরচ চলতে পারে। Model loaded থাকুক বা না থাকুক, 64 GB VPS-এর billing সারা মাস চলবে। আপনি বাস্তবে প্রতিদিন কত ঘণ্টা token generate করেন, তা হিসাব করুন। Break-even point rental rate, runtime এবং persistent storage charge-এর ওপর নির্ভর করে। সব সময় চলা low-priority batch কাজের ক্ষেত্রে always-on VPS বেশি সাশ্রয়ী।