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

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

VPS-এ 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 এবং সংখ্যা 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 হিসেবে মনে থাকতে পারে। এছাড়া একটি qwen3.5:27b রয়েছে। এটি আগের release-এর একই Q4_K_M build। কোনো command copy করার আগে Ollama qwen3.6 tag page-এ বর্তমান তালিকা পরীক্ষা করুন। পরে প্রকৃত qwen3.8 প্রকাশিত হলেও এখানে দেওয়া হিসাব প্রযোজ্য থাকবে। কারণ এই হিসাব version number-এর ওপর নয়, parameter count এবং প্রতি weight-এর bits-এর ওপর নির্ভর করে।

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

অস্তিত্বহীন 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-এর জন্য library-তে বেশি precision-এর qwen3.6:27b-q8_0 এবং qwen3.6:27b-bf16-ও আছে। এছাড়া 35b-a3b tag-গুলোর একটি সেট রয়েছে, যেগুলো MoE (mixture of experts) model এবং CPU-তে সম্পূর্ণ ভিন্নভাবে কাজ করে। সেগুলো সম্পর্কে নিচে আরও বলা হয়েছে।

প্যারামিটার সংখ্যা × প্রতি ওয়েটের বাইট

[
  {
    "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"
  }
]

সূত্রটি এক লাইনের। ওয়েটের বাইট = প্যারামিটার × প্রতি ওয়েটে বিট / 8। ঠিক 4 বিট হলে, 27.8 billion প্যারামিটারের আকার 13.9 GB হবে। প্রকাশিত Q4_K_M tag-এর আকার 17 GB, অর্থাৎ বাস্তবে প্রতি ওয়েটে 4.89 বিট।

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

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

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 ব্যবহার করে window-এর আকার ইচ্ছাকৃতভাবে বাড়াতে হবে। ধাপে ধাপে বাড়ান এবং প্রতিটি পরিবর্তনের পরে 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-ও set করুন এবং এটি প্রয়োগ হয়েছে ধরে না নিয়ে ollama ps-এ কমে যাওয়া মান নিশ্চিত করুন। OLLAMA_NUM_PARALLEL=1-ও সমান গুরুত্বপূর্ণ। Ollama একসঙ্গে একাধিক request পরিবেশন করতে পারে। প্রতিটি slot context-এর নিজস্ব অংশ পায়। তাই parallelism ডিফল্ট অবস্থায় রাখলে আপনার নির্ধারিত cache নীরবে বহুগুণ হয়ে যায়। একাধিক ব্যক্তি এই মেশিন ব্যবহার করলে সমস্যার শুরু সেখানেই হয়। self-hosted model একসঙ্গে যতজন ব্যবহারকারীকে পরিবেশন করতে পারে তা 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": 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."
  }
]

দুটি সংখ্যাকে weights-এর পাশাপাশি f16 cache-এ রাখা যায় এমন হাজার token context হিসেবে পড়ুন। এটি প্রায় 1.5 GB operating system এবং সামান্য অতিরিক্ত margin রেখে একটি headless Linux VPS-এর হিসাব। কোনো মান 0 হলে 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 এই স্তরে একেবারেই fit করে না।

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

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

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

[
  {
    "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-এর জন্য তাত্ত্বিক সর্বোচ্চ গতি কখনোই পুরোপুরি পাওয়া যায় না। দুই-channel DDR4-3200 VPS-এর সর্বোচ্চ সীমা প্রতি সেকেন্ডে 3 token, তাই বাস্তবে প্রায় 2 token আশা করুন। দুই-channel DDR5-4800 server-এর সর্বোচ্চ সীমা 4.5, তাই বাস্তবে প্রায় 3 token আশা করুন।

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

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

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

dense 27B model খুব ধীর হলে 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 ঘণ্টা ভাড়া নেওয়া ভালো

[
  {
    "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 per second দিতে পারে। একটি বর্তমান data centre card-এ এই মান 197 পর্যন্ত পৌঁছায়। Thread count সমন্বয় করে এই ব্যবধান দূর করা যায় না। সেখানে card-এর memory 1008 GB/s গতিতে চলে, আর আপনার VPS-এ গতি থাকে প্রতি সেকেন্ডে কয়েক দশক GB।

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

খরচের তুলনাটি প্রথম দেখায় যতটা সরল মনে হয়, ততটা নয়। Model loaded থাকুক বা না থাকুক, 64 GB VPS মাসের প্রতিটি ঘণ্টার জন্য billing করে। অন্যদিকে, GPU instance আপনি যত ঘণ্টা চালু রাখেন, শুধু সেই ঘণ্টাগুলোর জন্য billing করে। আপনার প্রকৃত ব্যবহার যদি দিনে 2 ঘণ্টা হয়, rented GPU একই সঙ্গে দ্রুততর এবং সস্তা হতে পারে। আগে duty cycle হিসাব করুন, তারপর খরচ নির্ধারণ করুন। GPU-সহ VPS বেছে নেওয়া instance-এ কী কী যাচাই করতে হবে তা ব্যাখ্যা করে। আর GPU-তে concurrent requests পরিবেশন করলে vLLM Ollama-কে ছাড়িয়ে যায় কারণ vLLM সেগুলো সঠিকভাবে 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 কলামে 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-এই আপনার প্রয়োজনীয় পরিমাপ রয়েছে। generation চলাকালে আপনার tokens per second হলো eval rate। prefill speed হলো prompt eval rate। disk থেকে weights পড়তে যত সময় লেগেছে, তা হলো load duration। তাই OLLAMA_KEEP_ALIVE=60m সেট করা হয়েছে। CPU-তে প্রতিটি request-এর সময় disk থেকে 17 GB weights আবার পড়তে যে সময় লাগে, তা request প্রক্রিয়া করার সময়ের চেয়েও বেশি।

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

ollama ps

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

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

মডেল load হতে অস্বীকার করে। Ollama উভয় figure-এর নামসহ model requires more system memory (18.6 GiB) than is available (15.2 GiB)-এর আকারে একটি line print করে। এটিই ভালো ধরনের 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-টিকে terminate করেছে। 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 কমানো বা loaded model-এর সংখ্যা কমানোই এর সমাধান। swap activity না থাকা অবস্থায় স্থায়ীভাবে বেশি wa মানে memory-mapped weight disk থেকে বারবার পড়া হচ্ছে। অর্থাৎ weight-গুলো আসলে memory-তে পুরোপুরি fit করছে না।

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

শুধু CPU-তে চলা 27B মডেলটি বাস্তবে কোন কাজে উপযোগী

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

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

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

FAQ

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

না। 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 দেখুন। সর্বশেষ released 27B চাইলে qwen3.6:27b pull করুন। অস্তিত্বহীন tag ব্যবহার করলে Error: pull model manifest: file does not exist error হয়।

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

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

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

আপনার memory bandwidth-কে weights-এর আকার দিয়ে ভাগ করুন। এরপর প্রাপ্ত ফলের 50 থেকে 70 শতাংশ ধরুন। দুই-channel DDR4-3200 VPS-এর ceiling প্রায় 3 token per second, এবং বাস্তবে এটি প্রায় 2 দেয়। দুই-channel DDR5-4800 machine-এর ceiling প্রায় 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 কী করতে পারে তা বদলায়, শুধু কীভাবে বাক্য গঠন করে তা নয়।

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

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