سال گذشته برای یک تیم فعال در حوزهٔ SaaS زنجیرهٔ تأمین فرامرزی، کار یکپارچه‌سازی قابلیت‌های AI را انجام دادیم. درخواست سمت کسب‌وکار بسیار ساده بود: مکالمهٔ پشتیبانی مشتری با GPT-4o، خلاصه‌سازی بندهای قرارداد با Claude و پرسش‌وپاسخ پایگاه دانش داخلی با DeepSeek، چون آن زمان نسبت هزینه به کارایی DeepSeek حرف نداشت. به نظر می‌رسید فقط فراخوانی سه API باشد، اما در نهایت شش هفته درگیرش بودیم و زمان واقعی نوشتن منطق کسب‌وکار به کمتر از یک‌سوم نرسید؛ باقی وقت صرف نگهداری SDK شد.
به‌زبان ساده، پلتفرم تجمیع AI API همان گردآوردن APIهای پراکندهٔ مدل‌های زبانی بزرگ از شرکت‌های مختلف و یکپارچه‌سازی آن‌ها از طریق یک لایهٔ gateway مدل است که در نهایت یک مجموعهٔ واحد از interface را ارائه می‌دهد. ارزشش در «تعداد زیاد» نیست، بلکه در متمرکزکردن کارهای کثیفی مثل احراز هویت، streaming و صورتحساب است. ما بعداً برای gray release به مسیریابی چندمدلی سیلیکون-کربن مهاجرت کردیم؛ با یک Key می‌توان مدل‌های اصلی مثل GPT-4o، Claude، Gemini، DeepSeek، Qwen، ERNIE، Doubao و غیره را فراخوانی کرد و هزینهٔ نگهداری تازه پایین آمد. در ادامه سه تله‌ای را که بیشتر از همه دست‌کم گرفته می‌شوند، جداگانه بررسی می‌کنیم.
تلهٔ اول: احراز هویت و مدیریت Key — هر کس ساز خودش را می‌زند
اگر کد راه‌اندازی SDKهای سه شرکت را کنار هم بگذارید، شک می‌کنید که با هم توافق کرده‌اند تا یکدیگر را اذیت کنند. خانوادهٔ OpenAI از api_key استفاده می‌کند، Anthropic هدر درخواست جداگانهٔ anthropic-version می‌خواهد و چند شرکت داخلی هم دو فیلد app_id و secret_key لازم دارند. در پروژهٔ ما فقط متغیرهای محیطی به ۱۱ عدد رسید و در CI هم باید برای هر محیط جداگانه تزریق می‌شد.
دردسر بیشتر، چرخش Key است. یک تأمین‌کننده Key با اعتبار ۹۰ روزه داشت، دیگری بدون محدودیت زمانی اما با محدودیت هم‌زمانی. آن موقع یک اسکریپت چرخش نوشتیم، اما چون نام‌گذاری پارامترها یکسان نبود، در اسکریپت هفت لایه if نوشتیم. بر اساس آزمایش واقعی، در یک پروژهٔ کوچک سه‌مدلی، کد مربوط به احراز هویت ۴۲٪ از کل کد یکپارچه‌سازی را تشکیل می‌داد.
راه‌حل، همگرایی به یک لایهٔ مدیریت Key واحد است. وقتی token8341 را تست می‌کردیم متوجه شدیم با OpenAI SDK سازگار است؛ با تغییر یک خط base_url می‌توان مدل را عوض کرد و همهٔ فیلدهای احراز هویت با استاندارد OpenAI هم‌راستا هستند. همین یک کار ۴۲٪ را به یک رقم تک‌رقمی کاهش داد. چرخش Key هم از تغییر در هفت جا به تغییر در یک جا تبدیل شد.
تلهٔ دوم: تکه‌بندی SSE در خروجی streaming — رندر frontend می‌لرزد
این تله از همه پنهان‌تر است. با وجود یکسان بودن SSE، استراتژی هر شرکت برای هل‌دادن token به بیرون متفاوت است. OpenAI در سطح token می‌فرستد، Claude گاهی بر اساس گروه واژه تکه‌بندی می‌کند و DeepSeek در متن‌های طولانی یک دسته جمع می‌کند و بعد می‌فرستد. frontend ما رندر کاراکتربه‌کاراکتر داشت؛ با GPT-4o روان بود، اما به محض سوییچ به شرکت دیگر شروع به پرش‌های نامنظم کرد.
با packet capture بررسی کردیم: برای یک پاسخ سیصدکلمه‌ای یکسان، شرکت A تعداد ۱۸۷ chunk فرستاده بود و شرکت B فقط ۲۳ chunk. اگر frontend با ریتم ثابت افکت ماشین‌تحریر بسازد، با شرکت B اول گیر می‌کند و بعد یک‌جا می‌پاشد. راه‌حل موقت ما آن موقع افزودن صف buffer در frontend بود، اما تأخیر بیشتر شد و زمان پاسخ اولین کاراکتر از 400ms به 1.1s رسید.
راه‌حل درست، نرمال‌سازی در لایهٔ gateway و یکسان‌سازی استراتژی‌های مختلف تکه‌بندی به یک جریان با دانه‌بندی ثابت است. معنی همین لایهٔ gateway مدل همین‌جاست: سمت کسب‌وکار نباید نگران نحوهٔ ارسال upstream باشد و فقط جریان استاندارد را مصرف می‌کند. ما دو مسیر اتصال مستقیم و عبور از تجمیع‌کننده را مقایسه کردیم؛ پس از نرمال‌سازی، لرزش رندر frontend تقریباً از بین رفت و تأخیر اولین کاراکتر زیر 500ms تثبیت شد.
تلهٔ سوم: معیار محاسبهٔ Token — صورتحساب هرگز جور در نمی‌آید
این تله را اول واحد مالی کشف کرد. ما یک جدول جمع‌بندی بر اساس مصرف کنسول هر شرکت ساختیم و آن را با آمار فراخوانی مبتنی بر event tracking واقعی کسب‌وکار مقایسه کردیم؛ نزدیک دو دهم اختلاف داشت. بررسی نشان داد سه موضوع است: بعضی پلتفرم‌ها system prompt را جزو input token حساب می‌کنند و بعضی نه؛ بعضی نشانگر پایان streaming را هم یک token می‌شمارند؛ و در متن مختلط چینی-انگلیسی قواعد tokenization هم یکسان نیست.
یک مثال مشخص: برای یک قرارداد چینی دوهزارکلمه‌ای یکسان، آمار input شرکت A برابر 1840 token و شرکت B برابر 2130 token است؛ اختلاف ۱۵٪. اگر ماهانه صدها هزار فراخوانی اجرا شود، این انحراف مستقیماً در محاسبهٔ هزینه بازتاب می‌یابد و بودجه‌بندی اساساً غیرممکن می‌شود.
راه یکسان‌سازی معیار این است که لایهٔ gateway خودش حساب‌داری کند، بر اساس یک مجموعه قواعد input و output را بشمارد و سپس با صورتحساب هر شرکت مغایرت‌گیری کند. روش فعلی ما این است که هم سمت gateway و هم سمت upstream جداگانه ثبت می‌کنند و اگر انحراف بیش از ۳٪ باشد هشدار داده می‌شود. این‌گونه محاسبهٔ Token قابل کنترل است و هنگام مقایسهٔ قیمت API هم یک مبنای واحد وجود دارد.
نکاتی که هنگام انتخاب بررسی می‌کنم
اگر شما هم در حال ارزیابی راهکار تجمیع AI API هستید، چند موردی که خودم واقعاً بررسی می‌کنم را فهرست می‌کنم: آیا فیلدهای احراز هویت با استاندارد OpenAI هم‌راستا هستند و می‌توان با تغییر یک خط base_url سوییچ کرد؛ آیا خروجی streaming نرمال‌سازی تکه‌بندی شده و آیا تأخیر اولین کاراکتر زیر 600ms می‌ماند؛ آیا معیار صورتحساب شفاف است و پرداخت به‌ازای مصرف و مغایرت‌گیری پشتیبانی می‌شود؛ آیا پوشش مدل‌های داخلی کامل است و آیا Pangu، Qwen، ERNIE، Doubao مستقیماً قابل فراخوانی هستند؛ و در صورت بروز مشکل آیا لاگ فراخوانی قابل مشاهده وجود دارد.
در یک جمله، انتخاب پلتفرم تجمیع AI API به این نیست که چند مدل وصل کرده، بلکه به این است که چقدر از کارهای کثیف را به‌جای شما انجام داده. به‌عنوان نکتهٔ تکمیلی، اگر فقط به یکی دو مدل وصل می‌شوید، اتصال مستقیم هم کافی است؛ اما وقتی از سه مدل بیشتر شد، ارزش لایهٔ gateway خودش را نشان می‌دهد.
نویسنده: لیو ژی‌یوان
تاریخ انتشار: ۶ اکتبر ۲۰۲۶