Ollama দিয়ে VPS-এ Qwen 3.8 27B চালাবেন কীভাবে

GPU ছাড়া VPS-এ Qwen 3.8 27B চালানো যাবে কি?

Qwen 3.8 27B চালাতে প্রথমে বিদ্যমান একটি model tag প্রয়োজন। 4 August 2026 অনুযায়ী Ollama library-তে qwen3.8 নামে কোনো entry নেই। বর্তমানে প্রকাশিত সবচেয়ে কাছের 27B tag হলো qwen3.6:27b: এতে 27.8 billion parameter, Q4_K_M quantisation এবং Apache 2.0 licence রয়েছে। নিচের প্রতিটি command এবং number Ollama v0.32.5-এ ওই tag ব্যবহার করে লেখা হয়েছে। এই version 27 July 2026-এ প্রকাশিত হয়েছে।

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

3.8 সংখ্যাটি কোথা থেকে এসেছে? সবচেয়ে সম্ভাব্য কারণ হলো parameter count। qwen3.6:27b-এর Ollama page-এ 27.8B parameters উল্লেখ করা হয়েছে। পরে মনে করার সময় 27.8 সহজেই 3.8 হিসেবে মনে হতে পারে। আগের release-এর একই Q4_K_M build-এর জন্য একটি qwen3.5:27b-ও রয়েছে। কোনো command copy করার আগে Ollama qwen3.6 tag page-এর live list পরীক্ষা করুন। পরে প্রকৃত qwen3.8 প্রকাশিত হলেও এখানে দেওয়া হিসাব প্রযোজ্য থাকবে। কারণ এই হিসাব version number-এর ওপর নয়, parameter count এবং প্রতি weight-এ ব্যবহৃত bit-এর ওপর নির্ভর করে।

কোন Ollama tag টানবেন এবং কীভাবে যাচাই করবেন

যে tag নেই, সেটি pull করলে স্পষ্ট error দেখা যায়। তাই সরাসরি সার্ভারেই এটি দ্রুত যাচাই করা যায়।

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show আপনার কাছে থাকা tag-এর architecture, parameter count, context length এবং quantisation দেখায়। parameter line-এ 27.8B এবং quantisation line-এ Q4_K_M থাকলে, আপনি এই গাইডে ব্যবহৃত build-টি পেয়েছেন। একই weights-এর higher precision সংস্করণের জন্য library-তে qwen3.6:27b-q8_0 এবং qwen3.6:27b-bf16-ও রয়েছে। এছাড়া 35b-a3b tag-গুলোর একটি সেট আছে, যেগুলো MoE (mixture of experts) model এবং CPU-তে এদের আচরণ একেবারেই ভিন্ন। সেগুলো সম্পর্কে নিচে আরও জানানো হয়েছে।

Parameter count অনুযায়ী bytes per weight

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

সূত্রটি এক লাইনের। Weights-এর bytes = parameters * bits per weight / 8। নিখুঁত 4 bits হলে 27.8 billion parameters-এর জন্য 13.9 GB লাগত। সরবরাহ করা Q4_K_M tag-এর আকার 17 GB, যা বাস্তবে প্রতি weight-এ 4.89 bits-এর সমান।

এই পার্থক্যটি কোনো ত্রুটি নয়। K-quant format-গুলো প্রতিটি tensor-কে nominal width-এ সংরক্ষণ করে না। Compression-এ যেসব tensor-এর quality সবচেয়ে বেশি কমে, সেগুলো 5 বা 6 bits-এ রাখা হয়। Token embedding এবং output layer সাধারণত Q6_K বা Q8_0-এ রাখা হয়। Format-এর নামটি একটি average বোঝায়, এবং সেই average প্রায় 4.9-এ এসে দাঁড়ায়। একই প্রভাব scale-এর অন্য প্রান্তেও দেখা যায়: BF16-এর জন্য 56 GB হলো প্রতি weight-এ 16.1 bits, সরাসরি 16 নয়। কারণ file-এ metadata এবং একটি full-precision embedding table-ও থাকে।

এই model-এর জন্য Q5_K_M-এর কোনো published tag নেই। তাই 19.8 GB row-টি মাপা মান নয়; এই format-এর প্রচলিত প্রতি weight-এ 5.7 bits ধরে এটি গণনা করা হয়েছে। Q8_0 প্রায় Q4-এর আকার দ্বিগুণ করে 30 GB হয়। শুধু CPU ব্যবহার করা box-এ এই দ্বিগুণ আকার প্রতি token-এ memory traffic-ও দ্বিগুণ করে। ফলে tokens per second-ও আনুমানিক অর্ধেক হয়ে যায়। এই কারণেই এখানে Q4_K_M ডিফল্ট হিসেবে উপযুক্ত।

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

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

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

এই হিসাবটি এই আকারের সাম্প্রতিক dense model-গুলোতে Qwen যে গঠন ব্যবহার করেছে, সেটির ওপর ভিত্তি করে করা: 64টি layer, GQA (grouped-query attention)-এর অধীনে 8টি key/value head এবং 128-এর head dimension। ফলে f16-এ প্রতি token-এর জন্য 256 KiB লাগে। তাই 32k token-এ 8 GB এবং 128k token-এ 32 GB লাগে। নিজের মেশিনের ক্ষেত্রে এই হিসাব অন্ধভাবে ব্যবহার করবেন না। Model load করে ollama ps-এর SIZE column পড়ুন। সেখানে weights, cache এবং overhead একসঙ্গে একটি সংখ্যায় দেখানো হয়।

এই কারণেই model card-এ দেওয়া 256K context একটি headline, বাস্তব পরিকল্পনা নয়। f16-এ এটি সম্পূর্ণ পূরণ করতে weights-এর অতিরিক্ত 64 GB cache লাগবে। অথচ মেশিনটি ইতিমধ্যে weights-এর জন্য 17 GB ব্যবহার করেছে। Ollama ডিফল্টভাবে আপনাকে সম্পূর্ণ window দেয় না। এটি অনেক ছোট একটি window load করে। OLLAMA_CONTEXT_LENGTH ব্যবহার করে আপনি ইচ্ছাকৃতভাবে সেটি বাড়াতে পারেন। ধাপে ধাপে বাড়ান এবং প্রতিটি পরিবর্তনের পরে ollama ps পরীক্ষা করুন।

দুটি setting cache-এর আকার অর্ধেক বা তারও কম করে। OLLAMA_KV_CACHE_TYPE=q8_0 cache-কে 16 bit-এর বদলে 8 bit-এ সংরক্ষণ করে। এতে 32k token-এর cache 8 GB থেকে কমে 4 GB হয়। এর জন্য flash attention প্রয়োজন। তাই OLLAMA_FLASH_ATTENTION=1 সেট করুন এবং এটি কার্যকর হয়েছে ধরে না নিয়ে ollama ps-এ কমেছে কি না নিশ্চিত করুন। OLLAMA_NUM_PARALLEL=1-ও সমান গুরুত্বপূর্ণ। Ollama একসঙ্গে একাধিক request পরিবেশন করতে পারে। প্রতিটি slot context-এর নিজস্ব অংশ পায়। তাই parallelism ডিফল্ট অবস্থায় রাখলে আপনার হিসাব করা cache-এর প্রয়োজন চুপিসারে বহুগুণ বেড়ে যায়।

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": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

দুটি সংখ্যাকে এমন হাজার token-এর context হিসেবে পড়ুন, যা weights-এর পাশাপাশি f16 cache-এ, প্রায় 1.5 GB অপারেটিং সিস্টেমের জন্য রেখে এবং অতিরিক্ত সামান্য margin-সহ একটি headless Linux VPS-এ রাখা যায়। শূন্যের অর্থ weights-ই fit করে না, তাই কোনো context fit করে না।

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 পড়তে হয়। সিস্টেমে iowait বেশি থাকে এবং প্রতি সেকেন্ডে 1 token-এরও কম তৈরি হয়।

32 GB হলো ব্যবহারের সর্বনিম্ন স্তর। Weights 17 GB নেয় এবং প্রায় 13 GB অবশিষ্ট থাকে। এই পরিমাণে margin-সহ প্রায় 32k token-এর f16 context রাখা যায়। 30 GB-এর Q8_0 weights এই tier-এ একেবারেই fit করে না।

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

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

একটি dense model থেকে একটি token তৈরি করতে হলে প্রতিটি weight একবার করে memory থেকে পড়তে হয়। কিছু weight নয়। সব weight। তাই গতি নির্ধারণ করে core-এর সংখ্যা নয়; memory bandwidth-কে weight-এর আকার দিয়ে ভাগ করলে যে মান পাওয়া যায়, সেটিই সীমা। 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-এর ceiling 3 tokens per second, তাই প্রায় 2 আশা করুন। দুই-channel DDR5-4800 server-এর ceiling 4.5, তাই প্রায় 3 আশা করুন।

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

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

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

Dense 27B যদি খুব ধীর হয়, CPU ব্যবহারের সিদ্ধান্ত নেওয়ার আগে qwen3.6:35b-a3b tag দেখুন। এগুলো প্রতি token-এ সব 27.8 billion parameter-এর বদলে প্রায় 3 billion parameter সক্রিয় করে। ফলে disk-এ file বড় হলেও প্রতি token-এর memory traffic প্রায় এক order of magnitude কমে যায়। এর বিনিময়ে RAM footprint বাড়ে। এখানে runtime নির্বাচনও গুরুত্বপূর্ণ। একই underlying 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-এ একই সূত্র প্রয়োগ করলে ভিন্ন ধরনের উত্তর পাওয়া যায়। 24 GB-এর একটি consumer card এই weights-এ প্রতি সেকেন্ডে সর্বোচ্চ 59 tokens দিতে পারে। বর্তমান data centre card-এ এই সংখ্যা 197। Thread count সামঞ্জস্য করে এই ব্যবধান দূর করা যায় না। আপনার VPS যেখানে প্রতি সেকেন্ডে কয়েক দশ GB memory bandwidth দেয়, সেখানে card-টি 1008 GB/s-এ memory চালায়।

তাই পছন্দের ভিত্তিতে নয়, workload-এর ভিত্তিতে সীমা নির্ধারণ করুন। কাজটি asynchronous হলে এবং কেউ output-এর জন্য অপেক্ষা না করলে CPU inference উপযুক্ত: যেমন রাতভর একগুচ্ছ document summarisation করা, অথবা আপনি ঘুমানোর সময় nightly classification job চালানো। কোনো ব্যক্তি output-এর জন্য অপেক্ষা করলে, অথবা প্রতি 30 সেকেন্ডে একটির বেশি request এলে GPU ভাড়া নিন। CPU-only machine-এ batching-এর অতিরিক্ত সক্ষমতা থাকে না, তাই queue ক্রমেই বড় হয়।

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

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

Ollama ইনস্টল করুন এবং নিজের সার্ভারের পরিমাপ নিন

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

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

ollama --version-এ 0.32.5 বা পরবর্তী সংস্করণ দেখা উচিত। কিছু pull করার আগে free -g পরীক্ষা করুন। Mem লাইনের total column-এ 32-এর কম থাকলে এখানেই থামুন এবং ছোট model বেছে নিন। কারণ চালানো সম্ভব নয় এমন 17 GB model pull করতে এক ঘণ্টা এবং অনেক disk space নষ্ট হবে।

Runtime option 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.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose output-এ আপনার প্রয়োজনীয় measurement দেখা যায়। Generation চলাকালে আপনার tokens per second হলো eval rate। Prefill speed হলো prompt eval rate। Disk থেকে weights পড়তে যত সময় লাগে তা হলো load duration। তাই OLLAMA_KEEP_ALIVE=60m সেট করা হয়েছে। CPU-তে প্রতিটি request-এর সময় disk থেকে 17 GB reload করতে request process করার চেয়েও বেশি সময় লাগে।

Model লোড থাকা অবস্থায় দ্বিতীয় terminal থেকে memory footprint পরীক্ষা করুন।

ollama ps

SIZE column-এ KV cache-সহ প্রকৃত memory footprint দেখা যায়। এটি weights-এর পরিমাণ এবং KV chart-এ আপনার context length-এর row-এর কাছাকাছি থাকা উচিত। 8192 token এবং 8-bit cache ব্যবহার করলে weights-এর অতিরিক্ত প্রায় এক gigabyte memory প্রয়োজন হবে। Cache f16 থাকলে প্রয়োজন হতো 2 GB। PROCESSOR column-এ 100% CPU দেখা উচিত। অন্য কিছু দেখা গেলে কোনো GPU resource ব্যবহার করছে। সে ক্ষেত্রে এই guide-এর speed number আপনার সার্ভারের জন্য প্রযোজ্য নয়।

ব্যর্থতার ধরন এবং আপনি যে নির্দিষ্ট string দেখতে পাবেন

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

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

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

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

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

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

আশার ভিত্তিতে নয়, সংখ্যার ভিত্তিতে প্রত্যাশা নির্ধারণ করুন। প্রতি সেকেন্ডে 2 থেকে 4 tokens গতিতে 500 tokens-এর একটি উত্তর পেতে 2 থেকে 4 মিনিট সময় লাগে। চ্যাটের জন্য এটি ব্যবহার অনুপযোগী, কিন্তু queue-ভিত্তিক কাজের জন্য যথেষ্ট কার্যকর। Document summarisation, bulk tagging, backlog-এ থাকা ফাইল থেকে field extraction এবং unattended code review-এর মতো কাজ এতে করা যায়, কারণ এসব ক্ষেত্রে উত্তরের জন্য কোনো ব্যবহারকারী অপেক্ষা করছে না।

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

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

FAQ

Ollama-তে কি Qwen 3.8 27B model আছে?

না। 4 August 2026 পর্যন্ত Ollama library-তে কোনো qwen3.8 namespace নেই। বিদ্যমান 27B tag হলো qwen3.5:27b এবং qwen3.6:27b। দুটিই 27.8 billion parameter-এর dense model-এর Q4_K_M build। Search term-এ থাকা 3.8 সম্ভবত version number হিসেবে মনে থাকা 27.8B parameter count। বর্তমান তালিকার জন্য https://ollama.com/library/qwen3.6/tags দেখুন। সর্বশেষ প্রকাশিত 27B model চাইলে qwen3.6:27b pull করুন। অস্তিত্বহীন tag ব্যবহার করলে Error: pull model manifest: file does not exist দিয়ে ব্যর্থ হয়।

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

Q4_K_M-এর জন্য 32 GB বাস্তবসম্মত সর্বনিম্ন পরিমাণ। Weights-এর আকার 17 GB। Operating system-এর জন্য প্রায় 1.5 GB প্রয়োজন। f16-এ context-এর প্রতি 4000 token-এ KV cache আরও প্রায় 1 GB যোগ করে। 16 GB plan-এ weights রাখার মতো জায়গাই নেই। Swap ব্যবহার করেও উপকার হবে না, কারণ file-টি memory-mapped থাকে এবং kernel প্রতিটি token-এর সময় disk থেকে সেটি আবার পড়ে। 64 GB নিলে দীর্ঘ context ব্যবহার করা যায় অথবা 30 GB আকারের Q8_0 weights চালানো যায়।

CPU-তে 27B model প্রতি সেকেন্ডে কত token দেবে?

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

শুধুমাত্র CPU-ভিত্তিক VPS-এ Q4 নাকি Q8 ব্যবহার করা উচিত?

প্রায় সব ক্ষেত্রেই Q4_K_M ব্যবহার করুন। Q8_0-এর আকার 30 GB, যেখানে Q4_K_M-এর আকার 17 GB। তাই Q8_0-এর জন্য 64 GB plan প্রয়োজন। এটি প্রতি token-এ প্রায় দ্বিগুণ memory স্থানান্তর করে, ফলে tokens per second প্রায় অর্ধেক হয়ে যায়। 27B model-এ বেশিরভাগ কাজের ক্ষেত্রে Q4_K_M এবং Q8_0-এর quality difference সামান্য। অতিরিক্ত RAM দীর্ঘ context-এর জন্য ব্যবহার করুন। এতে model-এর কাজের সক্ষমতা বাড়ে, শুধু output phrasing পরিবর্তন হয় না।

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

যখন আপনার duty cycle কম থাকে অথবা কোনো ব্যক্তি output-এর জন্য অপেক্ষা করে। এই weights-এ 24 GB memory-যুক্ত GPU প্রায় 59 token প্রতি সেকেন্ডে দেয়। সাধারণ VPS-এ এটি 2 বা 3-এর কাছাকাছি। GPU শুধু চলার সময়ের জন্য bill করে। 64 GB VPS-এ model loaded থাকুক বা না থাকুক, পুরো মাসের bill দিতে হয়। প্রতিদিন বাস্তবে কত ঘণ্টা token generate করেন তা হিসাব করুন। দুই বা তিন ঘণ্টার কম হলে hourly GPU rental সাধারণত গতি ও খরচ—দুই দিক থেকেই ভালো। সবসময় চালু থাকা VPS continuous low-priority batch কাজের ক্ষেত্রে বেশি সাশ্রয়ী।