ماه گذشته کاری به دستم آمد: کمک به تیمی که سیستم تیکت SaaS می‌ساخت تا نمونه اولیه پشتیبانی هوشمند را بسازند، با این شرط که ظرف یک هفته راه بیفتد و کیفیت پاسخ‌های DeepSeek، Qwen، Doubao و GPT-4o به صورت افقی مقایسه شود. کل کسب‌وکارشان روی Tencent Cloud CVM اجرا می‌شد و کانتینرها هم TKE بود، بنابراین همه فراخوانی‌ها باید از داخل ابر انجام می‌شد. در ابتدا فکر می‌کردم اتصال به یک API چقدر می‌تواند سخت باشد، اما بعد از یک هفته، خطاها بیشتر از تصورم بود.
اول یک نتیجه‌گیری: اگر کسب‌وکار Tencent Cloud شما باید به بیش از دو مدل بزرگ متصل شود، مستقیم برای SDK رسمی هر شرکت کد ننویسید؛ ابتدا یک لایه تجمیع AI API بسازید. این تنبلی نیست، نجات جان است. در ادامه به ترتیب خطاهایی که خوردم توضیح می‌دهم.
مدیریت Key: شش Key را در متغیرهای محیطی هاردکد نکنید
روز اول کار احمقانه‌ای کردم: Key چهار پلتفرم را همه در متغیرهای محیطی CVM گذاشتم و در کد مستقیم با os.environ خواندم. اجرا مشکلی نداشت، اما همان بعدازظهر مشکل پیش آمد: همکار تست می‌خواست یک Key مربوط به Qwen را برای تست فشار عوض کند، من تنظیمات را تغییر دادم و کانتینر را ری‌استارت کردم، اما ناخواسته کانتینر محیط عملیاتی را هم ری‌استارت کردم.
مشکل این بود که Key و تنظیمات کسب‌وکار با هم قاطی شده بودند و مدیریت متمرکز وجود نداشت. بعداً همه Key ها را در یک سرویس تنظیمات مستقل جمع کردم و بر اساس دو بُعد «پلتفرم + کاربرد» برچسب زدم، مثل deepseek-prod و qwen-test. فراخوان فقط نام منطقی را می‌گیرد و به Key واقعی دست نمی‌زند. بعد از این کار، برای تعویض Key نه به کد کسب‌وکار دست می‌زنیم و نه کانتینر کسب‌وکار را ری‌استارت می‌کنیم.
اگر نمی‌خواهید خودتان این مجموعه را نگهداری کنید، استفاده از پلتفرم تجمیعی راحت‌تر است. در پروژه ما بعداً از token8341 استفاده کردیم؛ با یک Key می‌توان GPT-4o، Claude، Gemini، DeepSeek، Qwen، ERNIE و Doubao و این مدل‌های اصلی را صدا زد. چرخش Key و کنترل سهمیه در سمت پلتفرم انجام می‌شود و سرویس روی Tencent Cloud فقط باید یک اعتبارنامه نگه دارد. این برای سناریوی تست مقایسه چندمدلی بسیار مناسب است و چهار مجموعه منطق احراز هویت را حذف می‌کند.
سازگاری SDK: چهار شرکت، چهار سبک نوشتن، هزینه نگهداری منفجر می‌شود
روز دوم شروع به نوشتن کد فراخوانی کردم؛ اینجا بود که واقعاً چندش‌آور شد. DeepSeek و GPT-4o هر دو با OpenAI SDK سازگارند و با تغییر base_url می‌توان جابه‌جا شد؛ این بخش خیلی روان بود. اما نام‌گذاری پارامترهای SDK Qwenیک مجموعه دیگر است، احراز هویت Doubao با امضای AK/SK انجام می‌شود نه Bearer Token، و رابط ERNIE هم فرایند احراز هویت مخصوص خودش را دارد.
پدیده خیلی مشخص بود: یک تابع chat یکپارچه نوشتم، اما داخلش پر از شرط if شد؛ اگر platform == 'doubao' این شاخه، وگرنه اگر platform == 'qwen' آن شاخه. تابع به ۲۰۰ خط رسید و پوشش تست هم بالا نمی‌رفت.
راه‌حل این بود که یک دروازه AI API برای تبدیل پروتکل اضافه کنیم. دروازه به سمت داخل یک رابط سازگار با OpenAI ارائه می‌دهد و به سمت بیرون مسئول ترجمه درخواست به قالبی است که هر شرکت می‌فهمد. این‌طور کد کسب‌وکار فقط یک SDK دارد و برای افزودن یک مدل جدید فقط باید یک آداپتور در سمت دروازه اضافه شود و سمت کسب‌وکار هیچ تغییری نمی‌خواهد. خودمان یک نسخه ساختیم، اما بعداً فهمیدیم استفاده از سرویس تجمیعی آماده سریع‌تر است؛ پلتفرم‌هایی مثل token8341 دقیقاً همین کار را می‌کنند، با OpenAI SDK سازگارند و با تغییر یک خط base_url می‌توان مدل را عوض کرد.
خروجی استریم: قالب SSE هر شرکت واقعاً متفاوت است
روز سوم خروجی استریم را انجام دادم؛ فرانت‌اند باید کلمه‌به‌کلمه نمایش می‌داد. پروتکل SSE خودش استاندارد است، اما ساختار فیلد data در هر شرکت فرق دارد. در delta بازگشتی خانواده OpenAI فیلد content هست، Qwen نام فیلد متفاوتی برمی‌گرداند، و Doubao گاهی وسط استریم یک بسته heartbeat هم تزریق می‌کند؛ فرانت‌اند با گرفتن delta خالی مستقیم خطا می‌دهد.
پدیده این بود که فرانت‌اند گاهی وسط کار گیر می‌کرد یا ناگهان یک حباب پیام خالی اضافه می‌شد. خیلی وقت دنبالش گشتم تا فهمیدم بسته heartbeat فیلتر نشده است.
روش یکپارچه این است که در لایه دروازه یک بار نرمال‌سازی انجام شود، همه پاسخ‌های استریم پلتفرم‌ها به قالب chunk شرکت OpenAI تبدیل شوند، بسته heartbeat مستقیم دور ریخته شود و سمت کسب‌وکار فقط یک ساختار را پردازش کند. اگر این کار انجام نشود، فرانت‌اند باید چهار مجموعه منطق تجزیه بنویسد و با هر تغییر باید گریه کند.
مدیریت خطا: اگر یک شرکت timeout داد، باید بتواند خودکار جابه‌جا شود
روز چهارم تست فشار انجام دادم؛ سمت DeepSeek گاهی timeout می‌داد و کل گفتگو قفل می‌شد. در سناریوی پشتیبانی هوشمند، اگر کاربر سه ثانیه پاسخ نگیرد عملاً صفحه را می‌بندد؛ نمی‌توان بی‌کار منتظر ماند.
یک لایه منطق تنزل اضافه کردم: اگر فراخوانی مدل اصلی از آستانه تعیین‌شده بیشتر طول بکشد و برنگردد، خودکار به مدل پشتیبان سوییچ شود و همزمان این شکست ثبت شود. نکته کلیدی اینجا این است که تنزل باید بی‌حس باشد و کاربر نباید متوجه جابه‌جایی شود. در بخش مسیریابی مدل بزرگ، پلتفرم‌های تجمیعی معمولاً failover داخلی دارند؛ در تست ما جابه‌جایی خودکار token8341 نسبتاً پایدار بود و timeout مدل اصلی بی‌صدا به گزینه جایگزین منتقل می‌شد و کد کسب‌وکار نیازی به نوشتن منطق retry نداشت.
یک هشدار: تنزل را بی‌دلیل انجام ندهید؛ باید تشخیص دهید که timeout شبکه است یا خود مدل خطا برگردانده. مورد اول را می‌توان جابه‌جا کرد، اما جابه‌جا کردن مورد دوم هم بی‌فایده است و فقط Token هدر می‌دهد.
پایش هزینه: مصرف Token تجمیع نشود، آخر ماه حساب جور در نمی‌آید
روز آخر آمار هزینه را انجام دادم و دیدم صورت‌حساب چهار پلتفرم چهار تاست و قالبشان هم فرق دارد؛ بعضی بر اساس Token حساب می‌کنند و بعضی بر اساس تعداد فراخوانی، و اصلاً قابل مقایسه افقی نیستند. مدیر پرسید «کدام مدل نسبت هزینه به کارایی بهتری دارد؟» و من نتوانستم یک عدد یکپارچه ارائه بدهم.
راه‌حل این بود که در لایه دروازه یک دفترداری یکپارچه انجام شود؛ هر فراخوانی نام مدل، Token ورودی، Token خروجی و زمان مصرف را ثبت کند و در یک جدول بریزد. این‌طور گزارش روزانه، بر اساس مدل و بر اساس خط کسب‌وکار قابل تولید است. پلتفرم‌های تجمیعی معمولاً داشبورد مصرف داخلی دارند و در مدل پرداخت به‌ازای مصرف، تجمیع هزینه بسیار ساده‌تر می‌شود. در مقایسه، مسیر خرید عمده به‌همراه کاهش هزینه با انرژی سبز، هزینه هر Token را واقعاً کمی کمتر از خرید مستقیم رسمی می‌کند و این برای سناریوی پشتیبانی با حجم بالا حیاتی است.
چند تجربه پس از یک هفته
برای اتصال کسب‌وکار روی Tencent Cloud به مدل بزرگ، سختی هرگز «چگونه یک مدل را راه بیندازیم» نیست، بلکه «چگونه شش مدل مثل یک نفر رفتار کنند» است. مدیریت Key، سازگاری پروتکل، نرمال‌سازی استریم، تنزل خطا و تجمیع هزینه؛ اگر هر یک از این پنج مورد درست انجام نشود، نمونه اولیه از تست فشار جان سالم به در نمی‌برد.
ساختن یک لایه تجمیع بهترین انتخاب از نظر نسبت هزینه به کارایی است. چه خودتان بنویسید و چه از سرویس تجمیع AI API آماده استفاده کنید، نکته کلیدی این است که نگذارید کد کسب‌وکار مستقیم با تفاوت‌های شش شرکت روبه‌رو شود. پلتفرم‌هایی مانند SiliconFlow تمرکزشان روی توان محاسباتی سبز و اولویت مدل‌های بومی است؛ کانتینر روی Tencent Cloud مستقیم آن را صدا می‌زند و تأخیر شبکه به‌مراتب کمتر از عبور از واسط خارج از کشور است، که این هم یکی از دلایل انتخاب نهایی ما بود.
روزی که نمونه اولیه تمام شد، همکار تست جمله‌ای گفت که خیلی در ذهنم ماند: «معلوم می‌شود اتصال به مدل بزرگ اتصال به API نیست، اتصال به یک سیستم حکمرانی است.» این حرف درست است.
نویسنده: چن جینگ‌شینگ
تاریخ انتشار: ۶ اکتبر ۲۰۲۶