LLM গেটওয়ে কীভাবে কাজ করে? ইঞ্জিনিয়ারিং দলগুলোর জন্য একটি ব্যবহারিক গাইড
LLM গেটওয়ে হলো একটি রিভার্স প্রক্সি, যা আপনার মডেল কলগুলো রাউট, অথেনটিকেট, ক্যাশ ও লগ করে; এই গাইডে একটি গেটওয়ের ভেতর দিয়ে একটি রিকোয়েস্টের যাত্রা অনুসরণ করা হয়েছে, পরিকল্পনায় রাখার মতো নিরাপত্তা ও নির্ভরযোগ্যতার ঝুঁকিগুলো তুলে ধরা হয়েছে, এবং নিজে তৈরি করা, সেলফ-হোস্টিং, ম্যানেজড ও API-গেটওয়ে বিকল্পগুলোর তুলনা করা হয়েছে।

একটি LLM গেটওয়ে আপনার অ্যাপ্লিকেশন এবং এর মাধ্যমে সংযুক্ত মডেল প্রোভাইডারদের মাঝখানে থাকে, ফলে ক্রেডেনশিয়াল পরিচালনা ও ব্যবহার ট্র্যাক করার জন্য আপনি একটিমাত্র জায়গা পান।
“এই মুহূর্তে অবস্থা একেবারে লেজেগোবরে,” ২০২৬ সালের সেপ্টেম্বরে একজন ইঞ্জিনিয়ার Reddit-এর r/LLMDevs-এ লিখেছিলেন।
“Claude, OpenAI, AWS Bedrock এবং আমরা যত ইনফারেন্স প্রোভাইডার ব্যবহার করি, সবগুলোর জন্য প্রত্যেকের কাছে আলাদা আলাদা কী রয়েছে।”
llm-proxy-tk নিয়ে BigGo-র প্রতিবেদনে এই হালকা FastAPI গেটওয়েটির সেটআপকে LLM-কে “কর্পোরেট কলের পানি”-তে পরিণত করার সঙ্গে তুলনা করা হয়েছে, যেখানে গেটওয়েটি হলো ভবনের প্রধান ভালভ।
তবে এই পাইপ-ব্যবস্থার ওপর এতটা ভরসা করার আগে চলুন দেখে নিই, আপনি আসলে কী বসাচ্ছেন।
LLM গেটওয়ে কী?
LLM গেটওয়ে হলো মডেল কলের জন্য একটি রিভার্স প্রক্সি। আপনার অ্যাপ্লিকেশনগুলো সরাসরি OpenAI, Anthropic, Google বা আপনার ব্যবহৃত অন্য কোনো LLM প্রোভাইডারের কাছে না পাঠিয়ে এর কাছে অনুরোধ পাঠায়। গেটওয়ে সেই অনুরোধগুলো ফরোয়ার্ড করে এবং পথে আপনার নিয়মগুলো প্রয়োগ করে।
প্রতিটি LLM প্রোভাইডারের নিজস্ব API আছে: এর অনুরোধের নিজস্ব কাঠামো, নিজস্ব অথেন্টিকেশন এবং ত্রুটি ফেরত দেওয়ার নিজস্ব পদ্ধতি রয়েছে। প্রত্যেকটির রেট লিমিট ও ব্যর্থতার ধরনও আলাদা। এখন, এগুলোর সামনে যদি কোনো অভিন্ন স্তর না থাকে, তবে প্রোভাইডারকে কল করা প্রতিটি অ্যাপ্লিকেশন সবকিছু নিজেই করে, এবং প্রত্যেকে একটু ভিন্নভাবে করে।
কলের পানির উপমাটি একটা সীমা পর্যন্তই খাটে, তবে অন্তত এটুকু বোঝায়—প্রোভাইডারগুলোকে একবারই, গেটওয়েতে, সংযুক্ত করা হয়। এরপর থেকে প্রতিটি অ্যাপ্লিকেশন নিজস্ব মিটারযুক্ত সংযোগ পায়, ফলে কে কী ব্যবহার করছে তা আপনি দেখতে পারেন এবং অন্যগুলোতে হাত না দিয়েই যেকোনো একটি লাইন বন্ধ করে দিতে পারেন।
LLM, AI, MCP এবং API গেটওয়ে: পার্থক্য কী?
গেটওয়ে | এটি কীসের সামনে থাকে? | এটি কী সিদ্ধান্ত নেয়? | এর দৃষ্টির সীমাবদ্ধতা |
API গেটওয়ে | আপনার সার্ভিস ও অন্যান্য ব্যাকএন্ড API | এই ক্লায়েন্ট কি অথেন্টিকেটেড, এবং এটি কি রেট লিমিটের মধ্যে আছে? | অনুরোধের বডি পরীক্ষা করতে পারে, তবে টোকেনের হিসাব ও অন্যান্য মডেল-নির্দিষ্ট নিয়ন্ত্রণের জন্য অতিরিক্ত সাপোর্ট প্রয়োজন। |
LLM গেটওয়ে | মডেল প্রোভাইডার | এই অনুরোধটি কোন মডেলে যাবে, এর খরচ কে বহন করবে, এবং উত্তর ফিরে এসেছে কি? | মডেলের রেসপন্সে প্রস্তাবিত টুল কলগুলো দেখতে পায়, কিন্তু সেই ট্র্যাফিকও এর মধ্য দিয়ে না গেলে সেগুলোর এক্সিকিউশন দেখতে পায় না। |
MCP গেটওয়ে | যেসব টুল ও ডেটা সোর্সের সঙ্গে একটি এজেন্ট MCP-এর মাধ্যমে সংযুক্ত হয় | এই এজেন্ট কি এই আর্গুমেন্টগুলো দিয়ে এই টুলটি কল করতে পারবে? | যে মডেল কল থেকে টুল অনুরোধটি তৈরি হয়েছে, সেটি স্বয়ংক্রিয়ভাবে দেখতে পায় না। |
ভেন্ডর যা কিছু একসঙ্গে যুক্ত করেছে: মডেল, এবং ক্ষেত্রবিশেষে টুল ও এজেন্ট-টু-এজেন্ট ট্র্যাফিক | পণ্যের ওপর নির্ভর করে উপরের বিষয়গুলোর একটি সমন্বয় | এটি কোন কোন সংযোগ পরিচালনা করে, তার ওপর নির্ভর করে। |
LLM গেটওয়ে কীভাবে কাজ করে?
আপনার অ্যাপ্লিকেশন থেকে মডেল পর্যন্ত এবং সেখান থেকে ফিরে আসা একটি অনুরোধের পথ অনুসরণ করুন।
- অনুরোধটি গেটওয়েতে পৌঁছায়: আপনার অ্যাপ্লিকেশন গেটওয়ের এন্ডপয়েন্টে সাধারণ দেখতে একটি চ্যাট অনুরোধ পাঠায়, যা প্রায়ই OpenAI-সামঞ্জস্যপূর্ণ ফরম্যাটে থাকে। অ্যাপ্লিকেশনের দৃষ্টিকোণ থেকে, মডেলের কাছে পৌঁছাতে এটিই সেই ঠিকানা, যেখানে সে কল করে।
- গেটওয়ে যাচাই করে কে অনুরোধ করছে এবং তার কী করার অনুমতি আছে: অনুরোধ ফরোয়ার্ড করার আগে এটি ক্রেডেনশিয়াল যাচাই করে। প্রায়ই সেটি কোনো টিম বা পণ্যকে দেওয়া একটি ভার্চুয়াল কী। আপনি যদি ইনপুট গার্ডরেইল যুক্ত করে থাকেন, তবে প্রম্পটে সংবেদনশীল ডেটা বা মডেলের নির্দেশনা ওভাররাইড করার চেষ্টা আছে কি না, তাও স্ক্যান করা যায়।
- গেটওয়ে যাচাই করে উত্তরটি আগে থেকেই তার কাছে আছে কি না: ক্যাশিং চালু থাকলে, মিলে যাওয়া কোনো যোগ্য অনুরোধের উত্তর প্রোভাইডারকে আবার কল না করেই সংরক্ষিত রেসপন্স থেকে দেওয়া যায়। কিছু গেটওয়ে সিমান্টিক ক্যাশিংও দেয়, যা হুবহু একই নয় বরং যথেষ্ট সাদৃশ্যপূর্ণ বলে বিবেচিত অনুরোধ খোঁজে। এটি FAQ-ধরনের ট্র্যাফিকের জন্য উপযুক্ত হতে পারে।
- গেটওয়ে ঠিক করে অনুরোধটি কোথায় যাবে: অনুরোধে কোনো নির্দিষ্ট মডেল বা একটি অ্যালিয়াসের নাম থাকতে পারে। গেটওয়ে আপনার কনফিগারেশনে মিলে যাওয়া রুটটি খুঁজে নেয়। আপনি একটি ব্যাকআপ রুটও কনফিগার করতে পারেন। প্রোভাইডার A টাইম আউট হলে গেটওয়ে প্রোভাইডার B ব্যবহার করে দেখতে পারে।
- গেটওয়ে কলটি প্রস্তুত করে এবং রেসপন্স ফেরত দেয়: গেটওয়ে আপনার অনুরোধকে নির্বাচিত প্রোভাইডারের ফরম্যাটে রূপান্তর করে এবং বহির্গামী কলটি অথেন্টিকেট করে। রেসপন্স পাওয়ামাত্রই সেটিকে আপনার অ্যাপ্লিকেশনের প্রয়োজনীয় ফরম্যাটে রূপান্তর করা হয়।
- গেটওয়ে যা ঘটেছে তা রেকর্ড করে: লগিং চালু থাকলে গেটওয়ে কে কলটি করেছে, কোন মডেল সেটি সার্ভ করেছে, টোকেন সংখ্যা, লেটেন্সি এবং খরচসহ বিভিন্ন বিবরণ রেকর্ড করে। ভূমিকায় উল্লিখিত Reddit ইঞ্জিনিয়ারের কাছে ঠিক এই লগটিই ছিল না।
গেটওয়ে প্রোডাকশনে নেওয়ার আগে যে ৪টি বিষয় আপনার জানা দরকার
উপরের অংশে বর্ণিত সবকিছুই সম্ভব, কারণ গেটওয়ে তার মধ্য দিয়ে রাউট হওয়া প্রতিটি অনুরোধ দেখতে পায়। এটাই মূল আকর্ষণ। কিন্তু এটি একই সঙ্গে সেই অ্যাটাক সারফেস এবং ভেন্ডর-নির্ভরতারও বর্ণনা, যার জন্য আপনাকে পরিকল্পনা করতে হবে।
গেটওয়ে এখন আপনার AI স্ট্যাকের সবচেয়ে মূল্যবান অংশ
গেটওয়ে অ্যাক্সেসকে কেন্দ্রীভূত করে। আর সে কারণেই এটি অনেক ক্রেডেনশিয়ালকে একটিমাত্র সার্ভিসের নাগালে এনে দেয়। একটি LiteLLM ডিপ্লয়মেন্ট কী কী ধারণ বা সংগ্রহ করতে পারে, Microsoft-এর নিরাপত্তা দল তার তালিকা দিয়েছে: প্রোভাইডারের API কী, এর নিজস্ব মাস্টার কী, ভার্চুয়াল-কী রেকর্ড, ডেটাবেস কানেকশন স্ট্রিং, রাউটিং সেটিংস এবং টেন্যান্ট পলিসি।
২০২৬ সালের অক্টোবরে LiteLLM-এ Check Point Research দুটি উচ্চ-ঝুঁকিপূর্ণ দুর্বলতা প্রকাশ করে:
- CVE-2026-35029-এর কারণে অথেন্টিকেটেড ব্যবহারকারীরা, এমনকি শুধু-পঠন (read-only) ব্যবহারকারীরাও, প্রশাসনিক ফাংশনে পৌঁছাতে এবং ইনস্ট্যান্সটির নিয়ন্ত্রণ নিতে পারত।
- CVE-2026-59823-এর কারণে ব্যবহারকারীরা নিজেদের নিয়ন্ত্রিত কোনো সার্ভারে অনুরোধ রিডাইরেক্ট করে প্রোভাইডার কী-গুলো হাতিয়ে নিতে পারত।
দুটিই সংস্করণ 1.83.9-এ ঠিক করা হয়েছে। যে অ্যাপ্লিকেশন গেটওয়ে ব্যবহার করে, সেটির গেটওয়ের সেটিংস পরিবর্তন করার সক্ষমতা থাকা উচিত নয়।
আপনার গার্ডরেইলের জন্য একটি ব্যর্থতা নীতি দরকার
Pillar Security-এর ৪ অক্টোবর, ২০২৬ তারিখের একটি পর্যালোচনায় LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management এবং Apigee-সহ প্রধান গেটওয়েগুলোর থার্ড-পার্টি গার্ডরেইল ইন্টিগ্রেশন নথিভুক্ত করা হয়েছে। (Pillar নিজেই গার্ডরেইল বিক্রি করে, তাই এর সুপারিশগুলো পড়ার সময় বিষয়টি মাথায় রাখুন।)
হুক হলো অনুরোধের পথের এমন একটি বিন্দু, সাধারণত প্রম্পট মডেলে যাওয়ার আগে বা রেসপন্স ফিরে আসার পরে, যেখানে গেটওয়ে কনটেন্টটি সিদ্ধান্তের জন্য একটি বাহ্যিক স্ক্যানারের কাছে পাঠাতে পারে। একটি ব্লকিং চেক ট্র্যাফিককে এগোতে দেওয়ার আগে সেই সিদ্ধান্তের জন্য অপেক্ষা করে। Portkey-এর ডকুমেন্টেশনে এগুলোকে before_request_hooks এবং after_request_hooks বলা হয়; TrueFoundry চারটি চালায়, যেখানে MCP টুল কলের আগে ও পরেও চেক যুক্ত করা হয়।
এখন দুটি বিষয় যাচাই করুন:
- স্ক্যানার নিজেই ব্যর্থ হলে কী হয়? অনুরোধ ব্লক করলে যাচাই-না-করা ট্র্যাফিক থামবে, কিন্তু আপনার অ্যাপ্লিকেশন বিঘ্নিত হতে পারে। আর যেতে দিলে আপনার অ্যাপ্লিকেশন সেই চেক ছাড়াই চলতে থাকবে। ব্যর্থতার লগ পরে আপনাকে দেখাবে যে চেকটি বাদ পড়েছিল, যা কাজের, কিন্তু চেকটি আসলে চালানোর সমান নয়।
- আপনি কি স্ক্যানারটি বদলাতে পারবেন? অন্য কোনো প্রোভাইডার সমর্থিত না হলে আপনাকে হয়তো অ্যাপ্লিকেশন আপডেট করতে হবে বা সংযোগের জন্য আরেকটি প্রক্সি ব্যবহার করতে হবে।
TrueFoundry-এর MCP হুকগুলো গেটওয়ের পরিসর মডেল অনুরোধ থেকে টুল কল পর্যন্ত বিস্তৃত করে। কিন্তু এটি কেবল নিজের মধ্য দিয়ে যাওয়া ট্র্যাফিকই পরীক্ষা করতে পারে। ডেভেলপারের মেশিনে কমান্ড চালানো কোনো কোডিং এজেন্ট সেই দৃষ্টিসীমার বাইরে থাকতে পারে।
Perplexity-এর ওপেন-সোর্স Numbat সেই দিকটিতে কাজ করে। Numbat লোকাল হুকের মাধ্যমে সমর্থিত এজেন্টগুলোর সঙ্গে সংযুক্ত হয় এবং শেল কমান্ড বা ফাইল লেখার মতো পরিকল্পিত কাজগুলো চালানোর আগেই পরীক্ষা করতে পারে। ব্লকিং ফিচারটি ঐচ্ছিক এবং ডিফল্টভাবে বন্ধ থাকে। গেটওয়ে তার মধ্য দিয়ে রাউট হওয়া মডেল ট্র্যাফিক দেখে। আর এজেন্ট উত্তরটি নিয়ে কী করছে, Numbat সেটি দেখার সুযোগ করে দেয়।
গেটওয়ের নিয়ন্ত্রণ কোথায় শেষ হয়, তা আপনাকে জানতে হবে
Forkast News ভিন্ন ভিন্ন দিক থেকে গেটওয়ের দিকে এগিয়ে আসা তিনটি ধারা চিহ্নিত করেছে:
- LLM-কেন্দ্রিক গেটওয়ে: LiteLLM ও Portkey শুরু করেছিল মডেল কল দিয়ে—প্রোভাইডারদের মধ্যে ফরম্যাট রূপান্তর, অনুরোধ রাউটিং এবং টোকেন ট্র্যাকিং। এখন এগুলো টুল কলের জন্যও নিয়ন্ত্রণ যুক্ত করছে।
- API ম্যানেজমেন্ট প্ল্যাটফর্ম: Kong, Google-এর Apigee এবং Azure API Management শুরু করেছিল অথেন্টিকেশন, অনুমতি ও ট্র্যাফিক ব্যবস্থাপনা দিয়ে, তারপর মডেল ও AI-নির্দিষ্ট নিয়মের সাপোর্ট যুক্ত করেছে।
- এজেন্ট-নেটিভ ইনফ্রাস্ট্রাকচার: উদাহরণস্বরূপ, agentgateway তৈরি করা হয়েছে মডেল, টুল এবং অন্যান্য এজেন্টের সঙ্গে এজেন্টদের যোগাযোগকে কেন্দ্র করে, যার মধ্যে MCP ও A2A-এর মাধ্যমে যোগাযোগও রয়েছে।
বাছাইয়ের মূল প্রশ্ন হলো, আপনি কী রাউট করছেন:
- শুধু মডেল কল? শুরু করার জন্য LLM-কেন্দ্রিক একটি গেটওয়ে ভালো বিকল্প।
- এমন প্রতিষ্ঠানের ভেতরে মডেল কল, যেখানে আগে থেকেই API নিয়মের ছড়াছড়ি? আপনার হাতে থাকা প্ল্যাটফর্ম দিয়েই শুরু করুন।
- এজেন্ট টুল কল করছে, আর টুল কল করছে মডেল? নিশ্চিত করুন যে সেই সংযোগগুলোও এর আওতায় আছে।
আপনি ব্যর্থতার একটি অভিন্ন বিন্দু তৈরি করছেন
ধরুন, আপনার সাপোর্ট চ্যাটবট OpenAI ব্যবহার করে আর আপনার গবেষণা টুল ব্যবহার করে Anthropic—দুটিই একই গেটওয়ের মাধ্যমে সংযুক্ত। কিন্তু সেই গেটওয়ে কাজ করা বন্ধ করলে, OpenAI ও Anthropic স্বাভাবিকভাবে চললেও দুটি টুলই তাদের মডেলের অ্যাক্সেস হারাবে।
এমনটা সত্যিই ঘটেছে। ১২ জুন, ২০২৫-এর বিভ্রাটের সময় Cloudflare-এর AI Gateway-এর ত্রুটির হার সর্বোচ্চ ৯৭%-এ পৌঁছেছিল। গেটওয়েটি সেটিংসের জন্য Cloudflare-এর Workers KV স্টোরেজ সার্ভিসের ওপর নির্ভর করত, আর সেই সার্ভিসটিই তখন ব্যর্থ হচ্ছিল।
আপনি নিজে গেটওয়ে চালালে আরেকটি কপি চালু রাখুন, যাতে একটি ব্যর্থ হলে অন্যটি দায়িত্ব নিতে পারে। অন্য কেউ আপনার গেটওয়ে হোস্ট করলে জিজ্ঞেস করুন, ব্যর্থতার সময় তারা কীভাবে এটি চালু রাখে এবং পুনরুদ্ধারের সময় আপনার অনুরোধগুলোর কী হয়।
LLM গেটওয়েতে যে মূল ফিচারগুলো খুঁজবেন
আপনি গেটওয়েকে সবার ক্রেডেনশিয়ালের অ্যাক্সেস দিতে যাচ্ছেন, তাই বিনিময়ে এটি কী করে, সে বিষয়ে আপনার প্রত্যাশা কড়া হওয়া উচিত।
- একাধিক প্রোভাইডারের সামনে একটি API: আপনার কোড একটি ফরম্যাটে কথা বলে, প্রায়ই OpenAI-সামঞ্জস্যপূর্ণ কোনো ফরম্যাটে, আর গেটওয়ে সেটি অনুবাদ করে। LLM প্রোভাইডাররাও এতে অর্ধেক পথ এগিয়ে আসে। উদাহরণস্বরূপ, Perplexity-এর Agent API OpenAI-এর Responses API ইন্টারফেস সমর্থন করে, ফলে টিমগুলো বিদ্যমান OpenAI ক্লায়েন্ট লাইব্রেরি পুনরায় ব্যবহার করতে পারে।
- নিয়মসহ ভার্চুয়াল কী: প্রতিটি টিম বা পণ্য নিজস্ব কী পায়, যার সঙ্গে অনুমোদিত মডেল, অনুরোধের সীমা ও খরচ নিয়ন্ত্রণের নিয়ম যুক্ত থাকে।
- রাউটিং ও ফলব্যাক: গেটওয়ে আপনার সেটিংস অনুযায়ী অনুরোধগুলো মডেলে পাঠায়, যেখানে খরচ, গতি বা নির্দিষ্ট কোনো প্রোভাইডারকে অগ্রাধিকার দেওয়া হতে পারে। কোনো কল ব্যর্থ হলে এটি অন্য একটি চেষ্টা করতে পারে। Perplexity-এর Agent API আপনাকে বিভিন্ন প্রোভাইডারের মডেলসহ সর্বোচ্চ পাঁচটি মডেল আপনার পছন্দের ক্রমে তালিকাভুক্ত করতে দেয়।
- ক্যাশিং: সংরক্ষিত একটি রেসপন্স আপনাকে প্রোভাইডারকে আরেকবার কল করা থেকে বাঁচাতে পারে। কিছু গেটওয়ে হুবহু একই অনুরোধ মেলায়; অন্যগুলো কাছাকাছি অর্থের অনুরোধও মেলাতে পারে। যাচাই করুন ক্যাশ করা রেসপন্স ব্যবহারকারী বা টিম অনুযায়ী আলাদা রাখা যায় কি না, এবং ব্যক্তিগতকৃত বা সময়-সংবেদনশীল উত্তরের জন্য ক্যাশিং বন্ধ করা যায় কি না।
- স্ট্রিমিং ও সামঞ্জস্যপূর্ণ ত্রুটি: রেসপন্স তৈরি হওয়ার সঙ্গে সঙ্গেই পৌঁছায়, এবং প্রোভাইডারের ত্রুটিগুলো এমন ফরম্যাটে অনুবাদ করা হয়, যা আপনার অ্যাপ্লিকেশন সামলাতে পারে। AI গার্ডরেইল যোগ করলে কী হয়, তা যাচাই করুন।
- লগিং ও খরচের দায় নির্ধারণ: গেটওয়ে রেকর্ড করে কে কল করেছে, কোন মডেল সেটি সার্ভ করেছে, কত টোকেন ব্যবহার হয়েছে, কত সময় লেগেছে এবং কলটির আনুমানিক খরচ কত। যাচাই করুন লগে প্রম্পট ও রেসপন্স অন্তর্ভুক্ত থাকে কি না এবং সেগুলো কতদিন সংরক্ষণ করা হয়।
- গার্ডরেইল হুক: এগুলো অনুরোধের পথের এমন কিছু বিন্দু, যেখানে গেটওয়ে সিদ্ধান্তের জন্য কনটেন্ট একটি বাহ্যিক স্ক্যানারে পাঠাতে পারে। সাধারণত এগুলো মডেল অনুরোধের আগে বা এর রেসপন্সের পরে থাকে। যাচাই করুন স্ক্যানার ব্যর্থ হলে অনুরোধগুলো থেমে যায় নাকি চলতে থাকে, এবং আপনি ভিন্ন কোনো স্ক্যানার সংযুক্ত করতে পারেন কি না।
- লক করা যায় এমন অ্যাডমিন ইন্টারফেস: গেটওয়ে প্রোভাইডারের ক্রেডেনশিয়াল এবং সবার ব্যবহৃত নিয়মগুলোর অ্যাক্সেস পরিচালনা করে। নিশ্চিত করুন যে অ্যাপ্লিকেশন ট্র্যাফিক থেকে আলাদাভাবে অ্যাডমিন অ্যাক্সেস সীমিত করা যায় এবং শুধু-পঠন ব্যবহারকারীরা সেটিংস পরিবর্তন করতে পারে না। প্রধান ভালভে একটি তালা থাকা চাই।
আপনার LLM গেটওয়ে তৈরি করতে কোন কোন টুল ব্যবহার করতে পারেন?
বাজারজুড়ে বিভিন্ন পণ্যের ফিচার তালিকা একটি আরেকটির সঙ্গে মিলে যায়। অভ্যন্তরীণ মডেল অ্যাক্সেস নিয়ে Reddit-এর একটি থ্রেডে পোস্টদাতা জানতে চেয়েছিলেন: কোন গেটওয়ের জন্য একজন ডেডিকেটেড ইঞ্জিনিয়ার লাগবে না?
আমাদের মতে এটিই সঠিক প্রশ্ন, এবং কাজের কতটুকু দায়িত্ব আপনি নিজে নিতে চান, তার ওপর নির্ভর করে এর চারটি উত্তর আছে।
নিজেই লিখুন
একটি ন্যূনতম গেটওয়ে অল্প কয়েকটি কাজ সামলায়—অনুরোধ গ্রহণ করা, কলারের কী যাচাই করা, প্রোভাইডারের ক্রেডেনশিয়াল যোগ করা, কলটি ফরোয়ার্ড করা এবং ফলাফল লগ করা। কিন্তু বিভিন্ন প্রোভাইডারের ফরম্যাট সমর্থন করতে বাড়তি কাজ লাগে। পুরো ব্যবস্থাটি সচল রাখাটাও তেমনই বাড়তি কাজ।
আপনি যদি আগে থেকেই Envoy চালান, তবে এর external-processing ফিল্টার দিয়ে এমন একটি সার্ভিস সংযুক্ত করতে পারবেন, যা অনুরোধ ও রেসপন্স পরীক্ষা ও পরিবর্তন করে। তবে সেই সার্ভিসটি আপনাকেই তৈরি করে চালাতে হবে।
গেটওয়ে খরচ কমায় কি না, তা নিয়ে r/LLMDevs-এর একটি থ্রেডে u/QuanTradin জানান, প্রতিটি কলে টোকেন ও একটি cache-hit ফ্ল্যাগ লগ করার ফলে তারা এমন দুটি কাজ খুঁজে পেয়েছিলেন, যেগুলো হুবহু একই প্রম্পটের জন্য পুরো দাম দিচ্ছিল।
“...যেকোনো রাউটিং স্তর যতটা কাজে আসত, সেটি ঠিক করা তার চেয়ে অনেক বেশি মূল্যবান ছিল।”
এটি একজনের জানানো অভিজ্ঞতা, এবং শুরু করার জন্য ভালো জায়গা। রাউটিংয়ের জটিল ব্যবস্থা তৈরির আগে জেনে নিন আপনি আসলে কীসের জন্য টাকা দিচ্ছেন।
একটি ওপেন-সোর্স গেটওয়ে নিজে হোস্ট করুন
এখানে LiteLLM একটি প্রচলিত পছন্দ: এটি OpenAI-সামঞ্জস্যপূর্ণ, বিস্তৃত পরিসরের প্রোভাইডার সমর্থন করে এবং এর একটি বড় কমিউনিটি আছে। Bifrost একটি বিকল্প, যা প্রতি অনুরোধে কম ওভারহেডের জন্য তৈরি। আপনার ফিচার তালিকার শীর্ষে যদি অবজারভেবিলিটি থাকে, তবে Helicone দেখে নেওয়া উচিত।
যেকোনো পণ্যের মতোই LiteLLM-এরও কিছু টিমের জন্য সীমাবদ্ধতা আছে। নিজে তৈরি করার বিকল্পগুলো নিয়ে r/aiagents-এর একটি থ্রেডে u/Own_Bar_920 জানান, LiteLLM রাউটিং ভালোভাবেই সামলেছিল, কিন্তু টিমজুড়ে প্রম্পট ভার্সনিং এবং মডেল বদলানোর সময় নিরবচ্ছিন্ন ইভ্যালুয়েশনের ক্ষেত্রে তাদের প্রয়োজন মেটাতে পারেনি, ফলে তাদের আলাদা একটি টুলের দিকে যেতে হয়।
এগুলো সাধারণ গেটওয়ে রাউটিংয়ের বাইরের বিষয়, আর সেটাই আসল কথা—রাউটিং যদি মূল প্রয়োজন হয়, তবে LiteLLM তাদের জন্য ভালোই কাজ করেছে।
আপনি একটি তৈরি ফিচার তালিকা পান, যার কিছু ফিচার এডিশনের ওপর নির্ভর করে, এবং গেটওয়েটি আপনার নেটওয়ার্কের ভেতরেই রাখতে পারেন। তবে প্যাচিংয়ের দায়িত্বও আপনার, যা আগে উল্লিখিত Check Point-এর প্রকাশিত তথ্য স্পষ্ট করে দিয়েছে, এবং গেটওয়ের প্রাপ্যতার দায়িত্বও আপনার, যা ব্যর্থতার অভিন্ন বিন্দু সংক্রান্ত অংশে স্পষ্ট হয়েছে।
তবে এর দায়িত্ব নেওয়ার জন্য কাউকে রাখার বাজেট করুন। অভ্যন্তরীণ অ্যাক্সেসের গেটওয়ে নিয়ে r/LLMDevs-এর একটি থ্রেডে একটি উদ্বেগ ছিল রক্ষণাবেক্ষণ। u/Informal-Writer9685 এমন কিছু চেয়েছিলেন, যা “রক্ষণাবেক্ষণের জন্য ডেডিকেটেড ইঞ্জিনিয়ার লাগে না”, এবং জানতে চেয়েছিলেন LiteLLM-এর আপগ্রেড-সংক্রান্ত যে অস্থিরতার কথা শোনা যায়, তা তাদের পরিসরে সত্যিকারের সমস্যা, নাকি কেবল প্রোডাকশনের ক্ষেত্রেই উদ্বেগের বিষয়।
একটি ম্যানেজড গেটওয়ে ব্যবহার করুন
Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter এবং Portkey-এর হোস্টেড গেটওয়ে আপনার হয়ে সার্ভিসটি চালায়। সামঞ্জস্যপূর্ণ কোনো অ্যাপ্লিকেশনের ক্ষেত্রে প্রথম অনুরোধটি পাঠাতে হয়তো একটি URL পরিবর্তন আর একটি API কী-র চেয়ে বেশি কিছু লাগবে না।
এখানে আপসটি হলো, প্রতিটি প্রম্পট এখন প্রোভাইডারের কাছে পৌঁছানোর আগে একটি থার্ড-পার্টির মধ্য দিয়ে যায়। এর মানে আপনার কমপ্লায়েন্স কাগজপত্রে আরও একটি ডেটা প্রসেসর যুক্ত হলো, এবং গেটওয়ের নিজস্ব বিভ্রাট একটি ভেন্ডরের ঘটনা—এটি ঠিক করা আপনার হাতে নেই।
উদাহরণস্বরূপ, ২০২৬ সালের ১৭ ও ১৯ ফেব্রুয়ারি একটি ক্যাশিং ডিপেন্ডেন্সি ব্যর্থ হওয়ার পর OpenRouter-এ যথাক্রমে ৩৮ ও ৩৫ মিনিট স্থায়ী বিভ্রাট ঘটে। কিছু গ্রাহক “User not found” ত্রুটি পান এবং সম্পূর্ণ বৈধ API কী ডিবাগ করতে সময় ব্যয় করেন। ত্রুটিটি ছিল গেটওয়ের ইনফ্রাস্ট্রাকচারে।
তবে OpenRouter-এর প্রশংসা প্রাপ্য, কারণ তারা একটি বিস্তারিত পোস্টমর্টেম প্রকাশ করেছে এবং ক্যাশ ব্যর্থতা যাতে তাদের ডেটাবেসকে অচল করে না দেয়, সে জন্য সুরক্ষাব্যবস্থা যুক্ত করেছে। OpenRouter-এর মতো একটি ম্যানেজড গেটওয়ে অ্যাক্সেস সহজ করতে পারে, কিন্তু r/LLMDevs-এ u/QuanTradin যেমন উল্লেখ করেছেন, বিলগুলো একত্র করলেই খরচ আপনাআপনি কমে না।
আপনার বিদ্যমান API গেটওয়েকে সম্প্রসারিত করুন
Kong, Apigee বা Azure API Management যদি আগে থেকেই আপনার সার্ভিসগুলোর সামনে থাকে, তবে প্রতিটিরই AI-নির্দিষ্ট সক্ষমতা আছে: Kong AI Gateway, Apigee-র AI গেটওয়ে পলিসি এবং Azure API Management-এর AI গেটওয়ে। আপনার বিদ্যমান অথেন্টিকেশন, নেটওয়ার্ক নিয়ম ও পরিচালন পদ্ধতির ওপর ভিত্তি করে প্লাগইন বা পলিসির মাধ্যমে মডেল নিয়ন্ত্রণ যুক্ত করতে পারেন।
বড় কোনো প্রতিষ্ঠানে এটি সাংগঠনিকভাবে সবচেয়ে কম বাধার পথ হতে পারে। স্বতন্ত্র গেটওয়েগুলোর তুলনায় এদের AI ফিচারগুলো নতুন। আপনি যে প্লাগইন বা পলিসিগুলো ব্যবহারের পরিকল্পনা করছেন, তার পুরো সেট দিয়ে টোকেন-ভিত্তিক রেট লিমিটিং ও স্ট্রিমিং অবশ্যই পরীক্ষা করে নিন।
তাই অবশ্যই মাস্টার ভালভটি বসান—সেই সর্বশক্তিমান গেটওয়ে। তবে ভূমিকায় উল্লিখিত ইঞ্জিনিয়ারের কথাতেও যুক্তি আছে। কোনো কোম্পানির মডেল অ্যাক্সেস এমন কারও ওপর নির্ভর করা উচিত নয়, যার ড্রয়ারে ঘটনাচক্রে সঠিক চাবিটি রয়েছে।
গেটওয়ে সেই চাবিগুলোকে কেন্দ্রীয় নিয়ন্ত্রণে এনে এই সমস্যার সমাধান করে, যার ফলে ড্রয়ার খোলা রেখে দেওয়ার ঝুঁকি বরং আরও বেড়ে যায়। ড্রয়ারটি কার, তা আপনাকে জানতেই হবে।
LLM গেটওয়ে সম্পর্কে সাধারণ জিজ্ঞাসা
LLM গেটওয়ে কি বিনামূল্যে পাওয়া যায়?
আপনি যদি সামগ্রিকভাবে এই ধরনের টুলের কথা বোঝাতে চান, তাহলে বলা যায়, কিছু LLM গেটওয়ের বিনামূল্যের সংস্করণ রয়েছে।
LLM গেটওয়ের পরিসর বিনামূল্যের ওপেন-সোর্স সফটওয়্যার থেকে শুরু করে মাসে প্রায় $50 থেকে শুরু হওয়া পেইড প্ল্যান পর্যন্ত বিস্তৃত, আর এন্টারপ্রাইজ ডিপ্লয়মেন্টের জন্য রয়েছে কাস্টম মূল্য নির্ধারণ। আবার কিছু গেটওয়ে এর বদলে একটি নির্দিষ্ট শতাংশ চার্জ করে; উদাহরণস্বরূপ, OpenRouter-এর Standard প্ল্যান ক্রেডিট কেনার ওপর 5.5% যোগ করে।
কোন LLM গেটওয়েটি সেরা?
কোন কাজের দায়িত্ব আপনি নিজে নিতে রাজি?
- আপনি যদি নিজে হোস্ট করতে এবং কনফিগারেশন নিয়ন্ত্রণ করতে চান, তাহলে Bifrost বা Helicone দেখে নিন।
- যেসব দল চায় পরিষেবাটি অন্য কেউ চালাক, তাদের জন্য OpenRouter বা Vercel AI Gateway-এর মতো একটি ম্যানেজড বিকল্প উপযুক্ত।
- আপনি যদি ইতিমধ্যেই Kong বা Azure API Management ব্যবহার করেন, তাহলে আগে সেগুলোর AI সক্ষমতা যাচাই করে দেখুন।
সংক্ষিপ্ত তালিকায় থাকা বিকল্পগুলো নিজের রিকোয়েস্ট দিয়ে পরীক্ষা করুন, কোনো প্রোভাইডার ব্যর্থ হলে কী ঘটে সেটিও যাচাই করে নিন।
AWS-এর কি কোনো LLM গেটওয়ে আছে?
হ্যাঁ। Amazon Bedrock AgentCore Gateway এমন একটি ব্যবস্থার মাধ্যমে মডেল কল সমর্থন করে, যাকে AWS “inference targets” বলে। এগুলোর সাহায্যে অ্যাপ্লিকেশনগুলো একটিমাত্র এন্ডপয়েন্ট ব্যবহার করে Amazon Bedrock, OpenAI ও Anthropic-সহ বিভিন্ন প্রোভাইডারের কাছে পৌঁছাতে পারে, আর প্রোভাইডারের ক্রেডেনশিয়াল ও রাউটিং সামলায় গেটওয়ে নিজেই।