এআই এপিআই ফেইলওভার: একটি মডেল অদৃশ্য হয়ে গেলে অ্যাপস চালু রাখুন

একটি প্রোডাকশন AI অ্যাপ কখনোই একটি মডেলের উপর নির্ভর করে চিরকাল উত্তর দেওয়ার জন্য। মডেল অ্যাক্সেস পরিবর্তিত হতে পারে আউটেজ, রেট সীমা, মূল্য পরিবর্তন, ডিপ্রিকেশন, আঞ্চলিক নিয়ম, প্রদানকারী নীতির পরিবর্তন, বা সরকারী নিষেধাজ্ঞার কারণে। যখন এটি ঘটে, একটি ছোট রাউটিং ইভেন্ট এবং একটি প্রকৃত পণ্য ঘটনার মধ্যে পার্থক্য হল আপনার অ্যাপে ইতিমধ্যে AI API ফেইলওভার স্থাপন করা আছে কিনা।.

এই বিষয়টি স্পষ্ট হয়ে উঠেছিল যখন Anthropic তাদের জুন ২০২৬ বিবৃতি প্রকাশ করেছিল যে তারা একটি মার্কিন সরকারী নির্দেশনার কারণে বিদেশী-জাতীয় অ্যাক্সেসের সাথে জড়িত থাকার পর Fable 5 এবং Mythos 5 সমস্ত গ্রাহকদের জন্য নিষ্ক্রিয় করতে বাধ্য হয়েছিল। অন্যান্য Anthropic মডেলের অ্যাক্সেস প্রভাবিত হয়নি, তবে সরাসরি সেই মডেলগুলিতে সংযুক্ত দলগুলিকে দ্রুত প্রতিক্রিয়া জানাতে হয়েছিল।.

আপনি পরবর্তী মডেল ব্যাঘাতের পূর্বাভাস দিতে হবে না এটি ডিজাইন করার জন্য। আপনাকে একটি মডেল স্তর প্রয়োজন যা প্রদানকারীদের কঠোরভাবে নির্ভরশীলতার পরিবর্তে প্রতিস্থাপনযোগ্য রাউটিং লক্ষ্য হিসাবে বিবেচনা করে।.

AI API ফেইলওভার আসলে কী বোঝায়

AI API ফেইলওভার হল একটি অনুরোধকে প্রাথমিক মডেল থেকে ব্যাকআপ মডেলে সরানোর ক্ষমতা যখন প্রথম রুট অনুরোধটি নিরাপদে, দ্রুত বা সাশ্রয়ীভাবে পরিবেশন করতে পারে না। এটি শুধুমাত্র একটি আপটাইম কৌশল নয়। এটি একটি পণ্য ডিজাইনের পছন্দ।.

একটি কার্যকর ফেইলওভার স্তর সাধারণত পাঁচটি অংশ অন্তর্ভুক্ত করে: একটি স্থিতিশীল API পৃষ্ঠ, একটি প্রাথমিক মডেল, এক বা একাধিক ব্যাকআপ মডেল, রাউটিং লজিক, এবং পর্যবেক্ষণযোগ্যতা। অ্যাপটি যত্ন করবে না যে একটি অনুরোধ মূল মডেল দ্বারা পরিবেশন করা হয়েছে বা একটি ব্যাকআপ দ্বারা। এটি একটি বৈধ প্রতিক্রিয়া গ্রহণ করবে, যা ঘটেছে তা লগ করবে, এবং ব্যবহারকারীর অভিজ্ঞতা অক্ষুণ্ণ রাখবে।.

ব্যাকআপটি একটি র্যান্ডম সস্তা মডেল হওয়া উচিত নয়। এটি কাজের জন্য নির্বাচিত হওয়া উচিত। কোড জেনারেশনের জন্য একটি ফ্যালব্যাক গ্রাহক সহায়তা শ্রেণীবিভাজন, সারাংশ, পুনরুদ্ধার, বা উচ্চ-ভলিউম চ্যাটের জন্য একটি ফ্যালব্যাক থেকে আলাদা হতে পারে। গুণমান, লেটেন্সি, মূল্য, প্রসঙ্গ দৈর্ঘ্য, টুল সমর্থন, এবং আঞ্চলিক প্রাপ্যতা সবই গুরুত্বপূর্ণ।.

কেন একক-মডেল অ্যাপগুলি এত দ্রুত ভেঙে যায়

সরাসরি প্রদানকারী ইন্টিগ্রেশন শুরুতে সহজ মনে হয়। আপনি একটি SDK, একটি মডেল নাম, একটি কী, এবং একটি বিলিং অ্যাকাউন্ট যোগ করেন। ঝুঁকি পরে উপস্থিত হয়, যখন আরও ব্যবসায়িক লজিক ধরে নেয় যে একই প্রদানকারী সবসময় একইভাবে আচরণ করবে।.

• প্রাপ্যতার ঝুঁকি: প্রদানকারী একটি আউটেজ, ক্ষমতার সমস্যা, বা রেট-সীমা পরিবর্তন করতে পারে।.
• জীবনচক্রের ঝুঁকি: মডেলটি প্রদানকারীর সময়সূচীতে ডিপ্রিকেট বা প্রতিস্থাপিত হতে পারে।.
• নীতিগত ঝুঁকি: মডেল নির্দিষ্ট ব্যবহার ক্ষেত্র, অঞ্চল, অ্যাকাউন্ট বা গ্রাহকদের জন্য অপ্রাপ্য হয়ে যেতে পারে।.
• খরচ ঝুঁকি: মূল্য পরিবর্তন হতে পারে, অথবা উচ্চ-মানের মডেল প্রতিটি অনুরোধের জন্য অত্যন্ত ব্যয়বহুল হয়ে যেতে পারে।.
• গুণগত ঝুঁকি: একটি মডেল আপডেট প্রতিক্রিয়া শৈলী, টুল আচরণ, বা নির্দেশ অনুসরণ পরিবর্তন করতে পারে।.

ব্যর্থতা ছাড়া, এই ঝুঁকিগুলি অ্যাপ্লিকেশন কাজের মধ্যে পরিণত হয়: কোড সম্পাদনা করুন, অনুরোধ পে-লোড পরিবর্তন করুন, পরীক্ষা আপডেট করুন, একটি ডিপ্লয়মেন্ট চালান, এবং আশা করুন যে প্রতিস্থাপন মডেল যথেষ্ট কাছাকাছি আচরণ করে। এটি একটি ঘটনার সময় করার জন্য খুব বেশি।.

একটি ব্যবহারিক ব্যর্থতা স্থাপত্য

আপনার অ্যাপ্লিকেশন এবং মডেল প্রদানকারীদের মধ্যে একটি স্থিতিশীল মডেল অ্যাক্সেস স্তর স্থাপন করে শুরু করুন। আপনার পণ্যটি একটি অভ্যন্তরীণ রুট বা একটি মার্কেটপ্লেস API কল করা উচিত, যখন রাউটিং স্তর সিদ্ধান্ত নেয় কোন মডেল অনুরোধ গ্রহণ করবে।.

• কাজের স্তর সংজ্ঞায়িত করুন।. উচ্চ-যুক্তি, নিম্ন-প্রতিক্রিয়া সময়, সস্তা শ্রেণীবিভাগ, দীর্ঘ-প্রসঙ্গ, এবং ব্যাকআপ রুট আলাদা করুন।.
• প্রদানকারী-বিভিন্ন বিকল্প নির্বাচন করুন।. একই প্রদানকারীর একটি ব্যাকআপ আপনাকে অ্যাকাউন্ট, অঞ্চল, বা নীতিগত স্তরের ব্যাঘাত থেকে রক্ষা করতে পারে না।.
• পুনরায় চেষ্টা করার নিয়ম সাবধানে সেট করুন।. অস্থায়ী ব্যর্থতা পুনরায় চেষ্টা করুন, তবে অনিরাপদ প্রম্পট, ত্রুটিপূর্ণ পে-লোড, বা নির্ধারিত নীতিগত ব্লক পুনরায় চেষ্টা এড়িয়ে চলুন।.
• লগ রাউটিং ইভেন্টগুলি।. মডেল, প্রদানকারী, লেটেন্সি, খরচ, ব্যর্থতার কারণ, ফ্যালব্যাক রুট এবং চূড়ান্ত ফলাফল ট্র্যাক করুন।.
• মার্জিত অবনতি ডিজাইন করুন।. কিছু কাজ একটি ছোট মডেল, বিলম্বিত প্রতিক্রিয়া, কিউ বা সরাসরি ব্যর্থ হওয়ার পরিবর্তে মানব পর্যালোচনায় ফিরে যেতে পারে।.

এই আর্কিটেকচার মডেল পরীক্ষাকে আরও নিরাপদ করে তোলে। আপনি একটি নতুন মডেল একটি ছোট ট্রাফিক শেয়ার দিয়ে পরীক্ষা করতে পারেন, গুণমান এবং খরচ তুলনা করতে পারেন, তারপর অ্যাপ্লিকেশনটি পুনর্নির্মাণ না করেই এটি ধীরে ধীরে উন্নীত করতে পারেন।.

যেখানে ShareAI ফিট করে

ShareAI দলগুলিকে একটি বিস্তৃত মডেল মার্কেটপ্লেস অ্যাক্সেস করার জন্য একটি API প্রদান করে, ১৫০+ মডেলের মধ্যে, স্মার্ট রাউটিং এবং ফেইলওভার, পে-পার-টোকেন ব্যবহার, এবং একটি ডেভেলপার ফ্লো যা প্লেগ্রাউন্ড ট্রাফিক প্রোডাকশনে পৌঁছানোর আগে পরীক্ষা করা যেতে পারে।.

ডেভেলপারদের জন্য, এর মানে মডেল অ্যাক্সেস একটি প্রদানকারীর সাথে কম শক্তভাবে সংযুক্ত। নির্মাতাদের জন্য, এর মানে AI স্তরটি ব্যবসায়িক মডেলের অংশ হয়ে উঠতে পারে। অ্যাপটি ShareAI-এর বাইরে থাকে, যখন নির্মাতা ShareAI-এর মাধ্যমে ইনফারেন্স ট্রাফিক রুট করে, AI ব্যবহারে একটি মার্জিন সেট করে এবং গ্রাহকের ব্যবহারের উপর ভিত্তি করে মাসিক পেমেন্ট পায়।.

আপনি যদি একটি বিদ্যমান পণ্যে ফেইলওভার যোগ করছেন, তাহলে শুরু করুন ShareAI API গাইড, তারপর আপনার সবচেয়ে গুরুত্বপূর্ণ মডেল কলগুলি প্রাথমিক এবং ফ্যালব্যাক রুটে ম্যাপ করুন।.

AI API ফেইলওভার চেকলিস্ট

• প্রতিটি প্রোডাকশন মডেল কল তালিকাভুক্ত করুন এবং একজন মালিক বরাদ্দ করুন।.
• ব্যবহারকারীর প্রভাব, রাজস্ব প্রভাব এবং ব্যর্থতার সহনশীলতার দ্বারা রুটগুলিকে র‍্যাঙ্ক করুন।.
• প্রতিটি গুরুত্বপূর্ণ রুটের জন্য অন্তত একটি ফ্যালব্যাক মডেল নির্বাচন করুন।.
• পরবর্তী ঘটনার আগে বিভিন্ন প্রদানকারীর বিকল্পগুলি পরীক্ষা করুন।.
• লেটেন্সি, খরচ, ত্রুটির হার এবং বিকল্প ব্যবহারের ফ্রিকোয়েন্সি ট্র্যাক করুন।.
• কোনটি পুনরায় চেষ্টা করার যোগ্য ব্যর্থতা হিসেবে গণ্য হবে তা নির্ধারণ করুন।.
• সম্ভব হলে মডেল পরিবারের মধ্যে প্রম্পটগুলি পোর্টেবল রাখুন।.
• অ্যাপটি পুনরায় চেষ্টা করার পরিবর্তে কখন অবনমিত হওয়া উচিত তা নথিভুক্ত করুন।.
• প্রতিটি প্রদানকারী পরিবর্তনের পরে বিকল্প আচরণ পর্যালোচনা করুন।.
• আংশিক অবনমনের জন্য গ্রাহক-মুখী বার্তা প্রস্তুত রাখুন।.

সাধারণ ভুল

সবচেয়ে সাধারণ ভুল হল প্রাথমিক মডেল ব্যর্থ হওয়ার পরে কেবল একটি ব্যাকআপ যোগ করা। দ্বিতীয়টি হল শুধুমাত্র দামের ভিত্তিতে একটি বিকল্প নির্বাচন করা। একটি সস্তা বিকল্প যা আপনার নির্দেশনা অনুসরণ করতে পারে না তা স্থিতিস্থাপকতা নয়; এটি একটি লুকানো গুণগত সমস্যা।.

আরেকটি ভুল হল সবকিছু সবচেয়ে শক্তিশালী মডেলের মাধ্যমে রাউট করা কারণ এটি নিরাপদ মনে হয়। এটি খরচ বাড়ায় এবং পণ্যটিকে ফ্রন্টিয়ার-মডেলের প্রাপ্যতার প্রতি বেশি উন্মুক্ত করে তোলে। অনেক অ্যাপ টাস্ক-ভিত্তিক রাউটিংয়ের সাথে আরও ভাল কাজ করে: শ্রেণীবিন্যাসের জন্য দ্রুত মডেল, যুক্তির জন্য শক্তিশালী মডেল এবং প্রতিটি রুটের জন্য পৃথক বিকল্প।.

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

AI API ফেইলওভার কী?

AI API ফেইলওভার হল একটি মডেল অনুরোধকে ব্যাকআপ মডেল বা প্রদানকারীর কাছে পাঠানোর প্রক্রিয়া যখন প্রাথমিক রুট ব্যর্থ হয়, ধীর হয়ে যায়, খুব ব্যয়বহুল হয়ে যায় বা অনুপলব্ধ হয়ে যায়।.

কেন AI অ্যাপগুলির মডেল ফেইলওভার প্রয়োজন?

AI অ্যাপগুলি বাহ্যিক সিস্টেমের উপর নির্ভর করে যা নোটিশ ছাড়াই পরিবর্তিত হতে পারে। ফেইলওভার একটি প্রদানকারীর আউটেজ, মডেল অবসর, নীতি পরিবর্তন বা রেট সীমা অতিক্রম করার সময় পণ্যটি চালু রাখে।.

একই প্রদানকারীর ব্যাকআপ কি যথেষ্ট?

কখনও কখনও, কিন্তু সবসময় নয়। একই-প্রদানকারী ফ্যালব্যাক একটি মডেল আউটেজে সাহায্য করতে পারে, কিন্তু প্রদানকারী-বিভিন্ন ব্যাকআপগুলি অ্যাকাউন্ট, নীতি, আঞ্চলিক এবং বিক্রেতা-ব্যাপী ব্যাঘাতের জন্য আরও নিরাপদ।.

ShareAI কীভাবে ফ্যালব্যাকের সাথে সাহায্য করে?

ShareAI ডেভেলপারদের ১৫০+ মডেলের অ্যাক্সেস একটি API এর মাধ্যমে দেয়, যেখানে রাউটিং এবং ফ্যালব্যাক অপশন রয়েছে যা একটি একক মডেল প্রদানকারীর উপর নির্ভরতা কমায়।.

ফ্যালব্যাক কি AI খরচ কমায়?

এটি পারে। একবার অনুরোধগুলি একটি রাউটিং স্তরের মাধ্যমে চলে গেলে, দলগুলি সহজ কাজগুলি কম খরচের মডেলে পাঠাতে পারে এবং প্রিমিয়াম মডেলগুলি শক্তিশালী যুক্তি প্রয়োজন এমন কাজের জন্য সংরক্ষণ করতে পারে।.

AI ফ্যালব্যাকের জন্য কী লগ করা উচিত?

অনুরোধকৃত রুট, মডেল, প্রদানকারী, লেটেন্সি, টোকেন ব্যবহার, খরচ, ত্রুটির কারণ, ব্যবহৃত ফ্যালব্যাক এবং চূড়ান্ত ফলাফল লগ করুন। এই ক্ষেত্রগুলি ঘটনাগুলি ডিবাগ করতে এবং রাউটিং নিয়ম উন্নত করতে সাহায্য করে।.

ShareAI এর সাথে ফ্যালব্যাক রুটগুলি কি বিল্ডাররা অর্থায়ন করতে পারে?

হ্যাঁ। বিল্ডাররা তাদের অ্যাপের AI ট্রাফিক ShareAI এর মাধ্যমে রাউট করতে পারে, তাদের নিজস্ব AI ব্যবহারের মার্জিন সেট করতে পারে এবং পেআউট পেতে পারে যখন ShareAI গ্রাহকের AI ব্যবহারের বিলিং পরিচালনা করে।.

প্রতিটি AI অনুরোধের কি একই ফ্যালব্যাক থাকা উচিত?

না। ফ্যালব্যাকগুলি কাজের সাথে মিলতে হবে। একটি শ্রেণীবিভাজন ফ্যালব্যাক, সারাংশ ফ্যালব্যাক এবং কোড-জেনারেশন ফ্যালব্যাকের জন্য বিভিন্ন মডেল পছন্দ প্রয়োজন হতে পারে।.

ফ্যালব্যাক রুটগুলি কতবার পরীক্ষা করা উচিত?

লঞ্চের আগে, প্রদানকারী পরিবর্তনের পরে এবং একটি পুনরাবৃত্তি সময়সূচীতে সেগুলি পরীক্ষা করুন। একটি ফ্যালব্যাক যা পরীক্ষা করা হয়নি তা শুধুমাত্র একটি আশা, একটি কার্যকরী নিয়ন্ত্রণ নয়।.

একটি বিদ্যমান অ্যাপের জন্য প্রথম পদক্ষেপ কী?

আপনার প্রোডাকশন মডেল কলগুলির তালিকা তৈরি করুন, সেগুলি চিহ্নিত করুন যা ব্যবহারকারীর কর্মপ্রবাহ ভেঙে দেবে, তারপর সর্বোচ্চ-প্রভাব রুটগুলি একটি স্থিতিশীল API স্তরের পিছনে সরান যেখানে অন্তত একটি পরীক্ষিত ফ্যালব্যাক রয়েছে।.