Mistral Large বনাম Mistral Medium: প্রোডাকশন থেকে CTO-র নোটস

তিন মাস আগে, আমি একটি LLM ফিচার রিলিজ করেছিলাম। তারপর বিল এল।

আমি বুঝতে পারলাম যে আমি একটি ভুল করেছি। আমার Mistral Medium ব্যবহার করা উচিত ছিল, কিন্তু আমি Mistral Large ব্যবহার করেছি। এর ফলে আমাদের খরচ প্রয়োজনের তুলনায় প্রায় 4x বেশি হয়ে গেছে।

আপনি যদি একটি স্টার্টআপ চালান, তবে আপনি কেবল অনুমানের (vibes) ওপর ভিত্তি করে আর্কিটেকচার সংক্রান্ত সিদ্ধান্ত নিতে পারেন না। আপনাকে ROI-এর ওপর ভিত্তি করে সিদ্ধান্ত নিতে হবে।

ভুলটি খুব সাধারণ ছিল। আমি ভেবেছিলাম বড় মডেলগুলো সবসময়ই ভালো। আমি ভুল ছিলাম।

এখন আমি যেভাবে LLM খরচ নিয়ন্ত্রণ করি:

  1. কাজের জটিলতা শ্রেণীবদ্ধ করুন
  1. টোকেন ভলিউম অনুমান করুন
  1. বাস্তব ইভ্যালুয়েশনের (evals) মাধ্যমে পরিমাপ করুন

আমার ৭০% কাজের জন্য Mistral Medium-ই যথেষ্ট। এটি সাপোর্ট টিকিটের ক্লাসিফিকেশন নিখুঁতভাবে করতে পারে। এর খরচ Large-এর তুলনায় মাত্র এক-তৃতীয়াংশ। আমি উচ্চ-স্তরের রিজনিং কাজের জন্য Large মডেলটি সংরক্ষণ করি।

আমি ভেন্ডর লক-ইন (vendor lock-in) থেকেও বেঁচে থাকি। আমি অনেকগুলো মডেল অ্যাক্সেস করার জন্য একটি ইউনিফাইড এন্ডপয়েন্ট (unified endpoint) ব্যবহার করি। যদি কোনো প্রোভাইডার দাম বাড়িয়ে দেয়, আমি কয়েক মিনিটের মধ্যেই মডেল পরিবর্তন করতে পারি। এটি আমার রানওয়ে (runway) সুরক্ষিত রাখে।

CTO-দের জন্য আমার পরামর্শ:

যে কাজে ছোট হাতুড়ি প্রয়োজন, সেখানে বড় হাতুড়ি ব্যবহার করা বন্ধ করুন। দক্ষতা প্রতিযোগিতামূলক সুবিধা তৈরি করে। এটি আপনাকে আপনার ব্যবহারকারীদের আরও উন্নত ফিচার এবং কম দামে সেবা দিতে সাহায্য করে।

উৎস: https://dev.to/gentlenode/mistral-large-vs-mistral-medium-cto-notes-from-production-280f