Ollama-তে VPS-এ Qwen 27B চালাতে কত RAM লাগে?

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-এ 27B dense model-এর weights সংরক্ষণ করতেই প্রায় 17 GB RAM লাগে। এর আগে context-এর একটি token-ও RAM-এ রাখা হয় না। তাই 8 GB এবং 16 GB plan পুরোপুরি বাদ পড়ে। সাধারণ two-channel DDR4 VPS-এ সর্বোচ্চ গতি প্রায় 3 token per second হতে পারে। অধিকাংশ মানুষের পড়ার গতির তুলনায় এটিও ধীর।

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

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

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

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 থাকলে, এই guide-এ ব্যবহৃত build-টিই আপনার কাছে আছে। একই weights-এর উচ্চতর precision সংস্করণের জন্য library-তে 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.1 বিটের সমান, সরাসরি 16 বিটের নয়। কারণ ফাইলটিতে metadata এবং পূর্ণ-নির্ভুলতার embedding table-ও থাকে।

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

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

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

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

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

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

একটি dense model থেকে একটি token তৈরি করতে প্রতিটি weight একবার memory থেকে পড়তে হয়। কিছু 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-গুলোর ক্ষেত্রে একটি সতর্কতা প্রযোজ্য। একটি twelve-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-এর সঙ্গে twelve-channel exclusive bandwidth থাকে না। GPU-কেন্দ্রিক guide-গুলো সাধারণত এই বিষয়টি সম্পূর্ণ বাদ দেয়। একই model-এ vCPU count অভিন্ন হলেও দুইটি VPS plan-এর গতিতে factor of three পার্থক্য হওয়ার কারণ এটিই।

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

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

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 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 tokens-এ পৌঁছায়। Thread count সমন্বয় করে এই পার্থক্য কমানো যায় না। GPU card তার memory 1008 GB/s গতিতে চালায়, যেখানে আপনার VPS-এর গতি কয়েক দশক GB/s।

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

খরচের তুলনা দেখলে যতটা সহজ মনে হয়, আসলে ততটা নয়। Model loaded থাকুক বা না থাকুক, 64 GB VPS মাসের প্রতিটি ঘণ্টার জন্য বিল করে। অন্যদিকে, GPU instance যত ঘণ্টা চালু রাখেন, শুধু সেই ঘণ্টাগুলোর জন্য বিল করে। আপনার প্রকৃত ব্যবহার যদি দিনে 2 ঘণ্টা হয়, rented GPU একই সঙ্গে দ্রুততর এবং সাশ্রয়ী হতে পারে। আগে আপনার duty cycle হিসাব করুন, তারপর খরচ নির্ধারণ করুন। GPU-সহ VPS বেছে নেওয়া instance-এ কী পরীক্ষা করতে হবে তা ব্যাখ্যা করে, আর GPU-তে concurrent requests serve করলে vLLM Ollama-কে ছাড়িয়ে যায় কারণ এটি requests সঠিকভাবে 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.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 করার চেয়েও বেশি সময় লাগে। Default idle timeout পাঁচ মিনিট। Items-এর মধ্যে বিরতি থাকা batch queue-তে এই সময়সীমা থাকলে প্রতিবার সেই load cost দিতে হয়। model resident রাখার option-গুলো প্রতি-request-এর keep_alive field এবং reboot-এর পরেও setting বজায় রাখার পদ্ধতি—দুটিই ব্যাখ্যা করে।

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

ollama ps

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

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

মডেল load হতে অস্বীকার করে। Ollama উভয় figure-এর নামসহ একটি line print করে, যার ধরন model requires more system memory (18.6 GiB) than is available (15.2 GiB)। এটি ভালো ধরনের ব্যর্থতা, কারণ 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 আনুমানিক সীমার বেশি বড় হলে এটি ঘটে। 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 swapping করছে। এর সমাধান হলো কম context ব্যবহার করা অথবা কম model load রাখা। Swap activity না থাকলেও wa ধারাবাহিকভাবে বেশি থাকলে memory-mapped weights disk থেকে বারবার read করা হচ্ছে। এর অর্থ weights পুরোপুরি memory-তে fit করছে না।

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

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

আশার ভিত্তিতে নয়, সংখ্যার ভিত্তিতে প্রত্যাশা নির্ধারণ করুন। প্রতি সেকেন্ডে দুই থেকে চারটি token হারে 500 token-এর একটি উত্তর তৈরি হতে দুই থেকে চার মিনিট লাগে। Chat-এর জন্য এটি ব্যবহার অযোগ্য, কিন্তু queue-এর জন্য যথেষ্ট কার্যকর। উত্তর দেওয়ার আগে যে model চিন্তা করে, তার ক্ষেত্রে এই হিসাব আরও খারাপ হয়। কারণ গোপন reasoning token-ও উত্তরের মতো একই ধীর গতিতে তৈরি হয়। তাই কাজ অনুযায়ী reasoning effort level নির্ধারণ করা model পরিবর্তন না করেই উত্তর সংক্ষিপ্ত করার কয়েকটি কার্যকর উপায়ের একটি। Document summarisation, bulk tagging, backlog-এ থাকা file থেকে 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-এর ক্ষেত্রে প্রতি সেকেন্ডে তিনটি token গতিতেও এর মূল্য অনেক। তবে বিকল্পটির সঙ্গে সৎভাবে তুলনা করুন: frontier-scale model self-host করতে এক order of magnitude বেশি hardware দরকার। সেই curve-এ 27B on CPU হলো সবচেয়ে কম খরচের বিন্দু, যেখানে output এখনও পড়ার মতো।

এর যেকোনোটি benchmark করতে real structured input দরকার। বেশিরভাগ public data API-তে throughput মাপার আগেই account চায়। Strasmore-এর demo endpoint (আমরাই এটি চালাই) কোনো key বা signup ছাড়াই 22 বছরের US market data-র ওপর read-only SQL-এর উত্তর দেয়। https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5-এ একটি GET করলে JSON পাওয়া যায়, যা সরাসরি prompt loop-এ pipe করা যায়। এর সঙ্গে সেই JSON তৈরির exact SQL-ও থাকে। ফলে model এমন কিছু summarise করতে পারে, যা আপনি independently check করতে পারবেন। সীমা হলো প্রতি call-এ 500 row এবং 20 second। প্রতি সেকেন্ডে দুইটি token-এ চলা একটি box যা ব্যবহার করবে, তার তুলনায় এই সীমা যথেষ্ট বেশি। সম্পূর্ণ column list https://api.strasmore.com/v1/schema-এ আছে।

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

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 দেখুন। সর্বশেষ 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-এ 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 token প্রতি সেকেন্ড দেয়। দুই-channel DDR5-4800 server-এর সর্বোচ্চ গতি প্রায় 4.5 এবং বাস্তবে প্রায় 3 token প্রতি সেকেন্ড দেয়। বেশি-channel server platform কাগজে অনেক ভালো দেখায়। তবে host-এর সব tenant-এর মধ্যে memory bandwidth ভাগ হয়। তাই ollama run qwen3.6:27b --verbose দিয়ে নিজের VPS-এর গতি মাপুন এবং eval rate line পড়ুন।

CPU-only 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 বেশি quantization-এর জন্য ব্যবহার না করে দীর্ঘ context-এর জন্য ব্যবহার করুন। এতে model কী করতে পারে তা বদলায়, শুধু কীভাবে বাক্য তৈরি করে তা নয়।

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

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