LLM খরচ ও latency কমানো: caching, routing ও ছোট prompt

LLM অ্যাপের বিল মূলত token (ইনপুট ও আউটপুট) অনুযায়ী, আর সাড়ার সময় আউটপুটের দৈর্ঘ্য ও model-এর আকারের সাথে বাড়ে। পরীক্ষায় সস্তা ফিচার বড় পরিসরে ব্যয়বহুল হতে পারে। সুখবর: কয়েকটি অভ্যাস প্রায়ই মানের সামান্য ক্ষতিতে খরচ নাটকীয়ভাবে কমায়।

ধাপ ১: আগে মাপুন

যা মাপেন না তা অপ্টিমাইজ করা যায় না। প্রতিটি request-এ log করুন:

• ইনপুট token, আউটপুট token, model, latency ও আনুমানিক খরচ।
• কোন ফিচার বা ব্যবহারকারী এটি চালু করেছে।

তারপর সবচেয়ে বেশি খরচের জায়গা ও সবচেয়ে ধীর পথ খুঁজুন। প্রায়ই একটি ফিচারই বেশিরভাগ বিল বানায়। Provider-এর মূল্য পাতায় বর্তমান দাম দেখুন, কারণ তা বদলায়।

ধাপ ২: যা পাঠান তা ছোট করুন

ইনপুট token প্রতিটি কলে দাম দিতে হয়।

• Prompt থেকে বাড়তি লেখা ও পুনরাবৃত্ত boilerplate সরান।
• নিয়মের লম্বা তালিকার বদলে কয়েকটি ভালো উদাহরণ দিন, বা উল্টোটা, যেটি ছোট ও কাজ করে।
• RAG-এ সবকিছু নয়, কম কিন্তু ভালো chunk পাঠান।
• পুরোনো কথোপকথনের ইতিহাস সব আবার না পাঠিয়ে ছেঁটে সারাংশ করুন।
• আপনার দেওয়া data থেকে HTML, whitespace ও অপ্রাসঙ্গিক field সরান।

ধাপ ৩: আউটপুট নিয়ন্ত্রণ করুন

আউটপুট token সাধারণত ইনপুটের চেয়ে দামি ও ধীর।

• সংক্ষিপ্ত উত্তর চান এবং যুক্তিসঙ্গত max tokens দিন।
• কোড ফল ব্যবহার করলে দীর্ঘ গদ্যের বদলে ছোট field-সহ structured output ব্যবহার করুন।
• Model-কে ইনপুট ফিরিয়ে বলতে বলবেন না।
• বিস্তৃত ধাপে ধাপে যুক্তি শুধু যেখানে মাপা যায় যে সাহায্য করে সেখানে ব্যবহার করুন।

ধাপ ৪: প্রতিটি কাজে সঠিক model বাছুন

সব কাজে সবচেয়ে বড় model লাগে না।

• Model routing: সহজ কাজে (শ্রেণিবিন্যাস, নিষ্কাশন, সরল নতুন করে লেখা) ছোট, সস্তা, দ্রুত model এবং শুধু কঠিনগুলোতে বড়টি।
• Cascade: আগে ছোট model চেষ্টা করুন এবং আস্থা কম বা যাচাই ব্যর্থ হলে বড়টিতে যান।
• ছোট model আপনার eval সেটে পরীক্ষা করুন। পাস করলে অনেক বাঁচালেন।
• বেশি পরিমাণ সংকীর্ণ কাজে ছোট model fine-tune বা distil করা ভাবুন (fine-tuning লেখা দেখুন)।

ধাপ ৫: Cache করুন

• Response caching: একই (বা স্বাভাবিকীকরণের পর একই) request আবার এলে সংরক্ষিত উত্তর দিন। FAQ ও নির্ণায়ক কাজে দারুণ। উত্তর ব্যক্তিগত data-নির্ভর হলে এক ব্যবহারকারীর উত্তর অন্যকে দেবেন না।
• Semantic caching: embedding দিয়ে একই অর্থের প্রশ্নে উত্তর পুনর্ব্যবহার করুন। ভুল মেলা এড়াতে কড়া সাদৃশ্য সীমা রাখুন।
• Prompt (prefix) caching: অনেক provider পুনরাবৃত্ত হুবহু একই prompt prefix-এ ছাড় বা গতি দেয়। স্থির অংশ (নির্দেশ, উদাহরণ, নথি) শুরুতে এবং বদলানো ব্যবহারকারী ইনপুট শেষে রাখুন। Provider-এর নিয়ম ও ন্যূনতম আকার দেখুন।

ধাপ ৬: দ্রুত মনে করান

• Streaming: তৈরি হওয়ার সাথে সাথে উত্তর দেখান। মোট সময় একই, কিন্তু ব্যবহারকারী সঙ্গে সঙ্গে অগ্রগতি দেখে।
• স্বাধীন কল সমান্তরালে চালান।
• সস্তা ধাপ আগে করুন এবং অপ্রয়োজনীয় কলের শিকল এড়ান।
• বিকল্প থাকলে ব্যবহারকারীর কাছের region-এর model ব্যবহার করুন।
• অনুমানযোগ্য request-এর ফল আগে থেকে তৈরি রাখুন।

ধাপ ৭: batch ও পিছিয়ে দিন

জরুরি নয় এমন কাজে (আর্কাইভ সারাংশ, কনটেন্টে tag), provider-এর batch বিকল্প থাকলে ব্যবহার করুন, যা সাধারণত ধীর ফেরতের বিনিময়ে ছাড়ে পাওয়া যায়, বা queue দিয়ে অফ-পিক সময়ে চালান।

ধাপ ৮: ছুটে যাওয়া খরচ ঠেকান

• Rate limit ও প্রতি-ব্যবহারকারী কোটা দিন।
• প্রতি request-এ ইনপুটের আকার ও max tokens সীমিত করুন।
• Agent-এর ধাপ ও টুল কল সীমিত করুন (agents লেখা দেখুন)।
• Provider-এ ও নিজের dashboard-এ budget ও alert দিন।
• LLM আউটপুট অন্তহীনভাবে আরেকটি LLM কল চালু করে এমন loop ঠেকান।
• Public endpoint authentication ও bot protection দিয়ে অপব্যবহার থেকে রক্ষা করুন, কারণ আক্রমণকারী আপনার credit শেষ করে দিতে পারে।

সাধারণ ভুল

• সবকিছুতে সবচেয়ে বড় model।
• প্রতি দফায় পূর্ণ ইতিহাস আবার পাঠানো।
• Prompt-এর শুরুতে বদলানো অংশ রাখা, যা prefix caching ভাঙে।
• ব্যবহার log না করা, ফলে বিল চমক।
• Eval আবার না চালিয়ে খরচ অপ্টিমাইজ করে অজান্তে মান কমানো।

মূল কথা: token ও খরচ মাপুন, ইনপুট ও আউটপুট ছোট করুন, সহজ কাজ সস্তা model-এ পাঠান, যা পুনরাবৃত্ত হয় তা cache করুন, অনুভূত গতির জন্য stream করুন, এবং কড়া সীমা ও alert বসান। প্রতিটি বদলের পর eval আবার চালান।

---

AI ও LLM সিরিজ, পর্ব ২ (মান, agent ও খরচ): 4 নম্বর (মোট 5)। আগের লেখা: AI agent ও tool use: function calling সহজ ভাষায়.