اکثر پروژه‌ها همین‌طور شروع میشن: یک سرور ساده روی یک VPS معمولی، کاربر کم، همه‌چیز روبه‌راه. مشکل معمولاً از جایی شروع میشه که یک اتفاق باعث میشه ترافیک چند برابر بشه — یک پست وایرال، یک کمپین تبلیغاتی، یا فقط رشد طبیعی کاربر — و همون یک سرور شروع میکنه به کند شدن و timeout دادن. راه‌حلی که خیلی‌ها اول امتحان میکنن اضافه‌کردن منابع به همون سرور است: رم بیشتر، CPU بیشتر. این کار یک‌مدت جواب میده، ولی زیاد طول نمیکشه که همون مشکل دوباره برگرده. نکته اینه که این مسیر یک سقف داره، و لود بالانسر دقیقاً همون‌جایی وارد میشه که این سقف رو کنار میزنه: به‌جای یک سرور بزرگ‌تر، چند سرور کوچک‌تر که ترافیک بینشون تقسیم بشه.

قبل از لود بالانسر: مقیاس عمودی

قبل از این‌که مفهوم load balancing جا بیفته، راه‌حل رایج برای مقابله با ترافیک بالا چیزی بود به اسم مقیاس عمودی یا vertical scaling: سرور موجود رو قوی‌تر میکردی. رم بیشتر، هسته‌ی پردازشی بیشتر، دیسک سریع‌تر. این روش یک مشکل بزرگ داره: یک سقف فیزیکی وجود داره. حتی اگه پول بی‌نهایت هم داشته باشی، یک سرور فیزیکی یا مجازی یک جایی به حداکثر ظرفیتش میرسه. علاوه بر این، این مدل یک نقطه‌ی شکست واحد داره؛ اگه همون یک سرور بخوابه، کل سرویس از دسترس خارج میشه.

بعد از لود بالانسر: مقیاس افقی

لود بالانسر اومد تا یک مسیر جایگزین باز کنه: مقیاس افقی یا horizontal scaling. به‌جای یک سرور قوی، چند سرور معمولی رو کنار هم میذاری و یک لایه‌ی جلویی به اسم load balancer درخواست‌های ورودی رو بینشون پخش میکنه. کاربر اصلاً نمیفهمه پشت صحنه چند سرور داره کار میکنه؛ فقط یک آدرس یا دامنه میبینه.

نتیجه‌ی این تغییر دو چیزه: اول، دیگه سقف فیزیکی وجود نداره — هر وقت ترافیک بالا رفت، یک سرور دیگه اضافه میکنی. دوم، دیگه نقطه‌ی شکست واحد نداری؛ اگه یکی از سرورها بخوابه، لود بالانسر خودش میفهمه و ترافیک رو به بقیه‌ی سرورها هدایت میکنه، بدون این‌که کاربر چیزی متوجه بشه.

لایه‌ی ۴ در مقابل لایه‌ی ۷

لود بالانسرها معمولاً روی دو سطح کار میکنن. لود بالانسر لایه‌ی ۴ (L4) روی سطح transport کار میکنه، یعنی فقط IP و پورت رو میبینه و بدون این‌که وارد محتوای درخواست بشه، ترافیک رو پخش میکنه. سریع‌تره چون کار کمتری انجام میده، ولی هوشمندی کمتری داره.

لود بالانسر لایه‌ی ۷ (L7) روی سطح application کار میکنه، یعنی میتونه محتوای درخواست HTTP رو ببینه — مسیر URL، هدرها، کوکی‌ها — و بر همون اساس تصمیم بگیره کدوم سرور جواب بده. مثلاً میتونی بگی درخواست‌هایی که مسیرشون با /api شروع میشه برن سراغ یک گروه از سرورها، و درخواست‌های /static برن سراغ یک گروه دیگه. این انعطاف هزینه داره: کمی کندتر از L4 است چون باید محتوای درخواست رو parse کنه.

الگوریتم‌های تقسیم ترافیک

خود لود بالانسر باید یک قانون داشته باشه که تصمیم بگیره کدوم درخواست بره کدوم سرور. رایج‌ترینش round robin است: درخواست‌ها به‌ترتیب و دوره‌ای بین سرورها پخش میشن، بدون توجه به این‌که هر سرور الان چقدر مشغوله. ساده‌ست ولی همیشه منصفانه نیست — اگه یک درخواست سنگین‌تر باشه و روی یک سرور طول بکشه، اون سرور همچنان درخواست بعدی رو هم میگیره.

الگوریتم least connections این مشکل رو حل میکنه: درخواست جدید میره سراغ سروری که الان کمترین تعداد کانکشن فعال رو داره. برای ترافیکی که مدت زمان پردازش درخواست‌هاش خیلی متفاوته (مثلاً بعضی درخواست‌ها سریع جواب داده میشن، بعضی طول میکشن)، این روش عادلانه‌تره.

یک روش دیگه IP hash است، جایی که بر اساس IP کاربر یک هش محاسبه میشه و همیشه همون کاربر به همون سرور فرستاده میشه. این برای موقعیت‌هایی مفیده که session کاربر روی یک سرور خاص ذخیره شده و باید همیشه همون کاربر به همون سرور برسه — البته این خودش یک ضعف داره، چون اگه توزیع IP ها نامتوازن باشه، بعضی سرورها بیشتر از بقیه بار میگیرن.

ابزارهای واقعی

اگه بخوای خودت یک لود بالانسر راه بندازی، دو تا از رایج‌ترین گزینه‌ها Nginx و HAProxy هستن. یک تنظیم ساده‌ی Nginx برای پخش ترافیک بین سه سرور backend این‌شکلیه:

upstream backend_servers {
    least_conn;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
    }
}

اینجا least_conn مشخص میکنه از الگوریتم least connections استفاده بشه، و هر درخواستی که به این سرور برسه بین این سه backend پخش میشه. HAProxy هم همین کار رو میکنه، ولی معمولاً برای سناریوهای پیچیده‌تر و ترافیک بسیار بالا انتخاب اول خیلی از تیم‌هاست، چون از ابتدا برای همین کار طراحی شده و قابلیت‌های health check و مانیتورینگش قوی‌تره.

اگه نخوای خودت این لایه رو مدیریت کنی، سرویس‌های ابری مثل Cloudflare یک لود بالانسر مدیریت‌شده ارائه میدن که هم روی لایه‌ی DNS کار میکنه (یعنی حتی قبل از رسیدن ترافیک به سرورهات، بین چند دیتاسنتر جغرافیایی پخشش میکنه) و هم health check خودکار داره؛ اگه یک سرور جواب نده، خودش به‌صورت خودکار از چرخه خارجش میکنه تا برگرده.

چند لود بالانسر مرجع که ارزش دیدن دارن

تا اینجا از Nginx و HAProxy و Cloudflare گفتم، ولی چند تا نمونه‌ی دیگه هست که دیدنشون برای یک مهندس نرم‌افزار واقعاً جالبه، چون هرکدوم یک مسئله‌ی متفاوت رو حل کردن.

اولیش Maglev گوگله. این یک لود بالانسر لایه‌ی ۴ نرم‌افزاریه که گوگل خودش ساخته و یک مقاله‌ی مهندسی دربارش منتشر کرده. نکته‌ی جالب Maglev اینه که به‌جای این‌که از هش معمولی استفاده کنه، از یک روش به اسم consistent hashing با یک جدول lookup بزرگ استفاده میکنه. چرا این مهمه؟ چون وقتی یک backend اضافه یا حذف میشه، اکثر connection های موجود همچنان به همون backend قبلی‌شون میرسن — فقط بخش کوچیکی جابه‌جا میشه. توی یک لود بالانسر ساده با mod hash، اضافه‌کردن یا حذف یک سرور میتونه تقریباً همه‌ی mapping ها رو به‌هم بریزه، که برای سرویس‌هایی که connection طولانی دارن فاجعه‌ست.

دومی Envoy Proxy است، که اولین بار توی Lyft ساخته شد و بعد به یکی از پروژه‌های اصلی CNCF تبدیل شد. چیزی که Envoy رو خاص میکنه اینه که configuration اش رو میشه به‌صورت داینامیک و از راه دور، از طریق یک API به اسم xDS، تغییر داد، بدون این‌که پروسه ری‌استارت بشه. این دقیقاً همون چیزیه که service mesh هایی مثل Istio بهش نیاز دارن: هزاران sidecar proxy که هر کدوم کنار یک سرویس نشستن، و باید بتونن بدون downtime روت‌ها و policy هاشون رو آپدیت کنن.

سومی AWS است، که سه نوع لود بالانسر جدا ارائه میده و این خودش نشونه‌ی خوبیه که چرا تفکیک لایه‌ها مهمه: Network Load Balancer (NLB) برای لایه‌ی ۴ با تأخیر خیلی پایین، Application Load Balancer (ALB) برای لایه‌ی ۷ با قابلیت‌هایی مثل روتینگ بر اساس path یا host header، و Classic Load Balancer که نسخه‌ی قدیمی‌تر و امروز کمتر توصیه‌شده‌ست. این‌که AWS این سه رو جدا از هم نگه داشته، نشون میده هیچ لود بالانسر «همه‌کاره» ای وجود نداره؛ انتخاب درست کاملاً به نوع ترافیک بستگی داره.

چهارمی که شاید برای خیلی از دولوپرها آشناتر باشه، خود Kubernetes است. سرویس‌های Kubernetes از یک کامپوننت به اسم kube-proxy استفاده میکنن که روی هر node اجرا میشه و ترافیک بین Pod ها رو با استفاده از iptables یا IPVS پخش میکنه. جالبیش اینه که این لود بالانسینگ کاملاً decentralized اتفاق میفته — هیچ نقطه‌ی مرکزی وجود نداره که همه‌ی ترافیک از اون رد بشه، برخلاف مدل سنتی که یک لود بالانسر جلوی همه‌چیز میشینه.

اگه بخوای یک قدم عمیق‌تر بری، سراغ Linux Virtual Server (LVS) و IPVS برو — این تکنولوژی مستقیم توی kernel لینوکس پیاده‌سازی شده و پایه‌ی خیلی از لود بالانسرهای بزرگ‌مقیاس دنیا از جمله همون kube-proxy است. چیزی که این رو برای یک مهندس جالب میکنه اینه که کل تصمیم‌گیری لود بالانسینگ توی kernel space اتفاق میفته، نه توی user space، که یعنی سربار (overhead) به‌شدت پایین‌تر از یک reverse proxy معمولیه.

نکته‌ای که معمولاً فراموش میشه

چیزی که خیلی از تیم‌ها موقع راه‌اندازی اولین لود بالانسرشون فراموش میکنن، مدیریت session است. اگه اپلیکیشنت session رو توی حافظه‌ی خود سرور نگه میداره (نه توی یک دیتابیس یا Redis مشترک)، وقتی کاربر بار دوم درخواست بده و لود بالانسر اون رو به یک سرور دیگه بفرسته، session گم میشه و کاربر عملاً logout میشه. راه‌حل درست این نیست که مجبور کنی کاربر همیشه به همون سرور برسه (چون این کار انعطاف لود بالانسر رو از بین میبره)؛ راه‌حل درست اینه که session رو از حافظه‌ی محلی سرور جدا کنی و توی یک storage مشترک بین همه‌ی سرورها نگه داری. این یکی از اون نکاتیه که تا خودت باهاش برخورد نکنی، احتمالاً موقع طراحی اولیه بهش فکر نمیکنی.

امروز، جمعه ۲ مرداد (۲۴ ژوئیه ۲۰۲۶)، آنتروپیک رسماً Claude Opus 5 رو معرفی کرد. این چهارمین مدلیه که آنتروپیک توی کمتر از دو ماه منتشر میکنه — بعد از Mythos 5، Fable 5، و Sonnet 5 که همه توی ژوئن اومده بودن. ولی نکته‌ای که Opus 5 رو از بقیه متمایز میکنه اینه که آنتروپیک این بار داستان رو حول محور «هوش خام» نچیده؛ حول محور اقتصاد مصرف روزانه چیده.

پیام اصلی: نزدیک به Fable 5، با نصف قیمت

آنتروپیک خودش Opus 5 رو این‌طور توصیف کرده: مدلی متفکر و proactive که به هوش Fable 5 —قوی‌ترین مدل فعلی آنتروپیک— نزدیک میشه، اون‌هم با نصف هزینه. این جمله رو باید دقیق خوند: آنتروپیک ادعا نکرده Opus 5 از Fable 5 جلو زده. Fable همچنان مدل مرجع برای پروژه‌های سنگین و کارهایی که قراره روزها بدون دخالت انسان به‌صورت خودکار ادامه پیدا کنن باقی می‌مونه. Opus 5 برای یک رده‌ی متفاوت ساخته شده: کارهای روزمره‌ای که حجمشون بالاست ولی نیازی به سقف مطلق هوش ندارن.

قیمت هم دقیقاً همینو نشون میده: $5 روی هر میلیون توکن ورودی و $25 روی خروجی، یعنی دقیقاً همون قیمت Opus 4.8. آنتروپیک مدل قوی‌تری داده بدون این‌که قیمت رو تغییر بده، به‌جای این‌که مثل قبل با هر نسخه‌ی جدید قیمت رو ببره بالا.

چرا این تغییر مسیر مهمه

طبق گزارش‌های چند رسانه از جمله Fortune، این جابه‌جایی به یک نگرانی واقعی توی بازار برمیگرده: مشتری‌های سازمانی این چند ماه از هزینه‌ی بالای مدل‌های frontier، مخصوصاً Fable 5، گله داشتن. Fable روی بعضی کارها burn rate بالایی داشت، یعنی برای رسیدن به یک جواب توکن زیادی مصرف میکرد، و همین باعث میشد بودجه‌ی تخصیص‌داده‌شده زودتر از موعد تموم بشه. Opus 5 دقیقاً جواب همین مشکله.

برای همین آنتروپیک روی Opus 5 یک قابلیت effort گذاشته: تنظیمی که بهت اجازه میده بین سرعت/هزینه و عمق استدلال مدل جابه‌جا بشی. اگه کار ساده و تکراریه، effort رو پایین میاری و توکن کمتری خرج میشه؛ اگه کار پیچیده‌ست، effort رو بالا میبری. این دقیقاً همون فلسفه‌ای‌یه که این چند وقت پشت Gemini 3.6 Flash هم دیدیم: به‌جای این‌که مدل رو یک بلوک یکپارچه در نظر بگیری، هزینه رو بر اساس واقعی‌بودن نیاز تنظیم میکنی.

جایگاه Opus 5 توی خانواده‌ی Claude

Opus 5 حالا مدل پیش‌فرض روی Claude Max شده و قوی‌ترین مدل در دسترس روی Claude Pro. یعنی برای اکثر کاربرهای پولی، این مدلیه که پیش‌فرض باهاش کار میکنن، نه Fable 5. آنتروپیک گفته Opus 5 نسبت به نسل قبل با رفت‌وبرگشت کمتری کار رو تموم میکنه — کار خودش رو راستی‌آزمایی میکنه و بدون دخالت اضافه از خطا برمیگرده، که برای کسی که داره روی workflow های agentic کار میکنه (دقیقاً مثل چیزی که ما با Hermes Agent دنبالش هستیم) نکته‌ی قابل توجهیه.

دو تغییر جانبی که کمتر دیده شد

همراه با Opus 5، آنتروپیک دو تغییر دیگه هم روی پلتفرمش اعمال کرده که شاید برای دولوپرها حتی مهم‌تر از خود مدل باشه:

اول، امکان تغییر ابزارهای در دسترس مدل وسط یک مکالمه، بدون این‌که prompt cache باطل بشه. تا قبل از این، اگه توی یک کانورسیشن میخواستی لیست ابزارها رو عوض کنی، کش مکالمه از بین می‌رفت و هزینه‌ی پردازش دوباره بالا می‌رفت. حالا این محدودیت برداشته شده.

دوم، قابلیت fallback خودکار روی API. اگه یک درخواست توسط کلاسیفایرهای ایمنی روی Opus 5 یا Fable 5 پرچم بخوره، به‌جای این‌که درخواست رد بشه، میتونی تنظیم کنی که به‌صورت خودکار به بهترین مدل جایگزین در دسترس هدایت بشه. این یعنی کمتر پیش میاد یک اپلیکیشن production به‌خاطر یک ریجکشن مقطعی از کار بیفته.

زمینه‌ی رقابتی

این عرضه توی بحبوحه‌ی یک رقابت شدید بین‌المللی اتفاق افتاده. طبق گزارش BigGo Finance، چند روز قبل از Opus 5، مدل Kimi K3 معرفی شده بود، و علی‌بابا هم Qwen 3.8 Max Preview رو با ۲.۴ تریلیون پارامتر رونمایی کرده. Z.AI هم از GLM 5.5 —با بیش از یک تریلیون پارامتر و context window یک میلیون توکنی— برای عرضه در آگوست خبر داده. نکته‌ی مهم این مدل‌های چینی اینه که اغلب به‌صورت open-weight منتشر میشن، یعنی هرکسی میتونه دانلودشون کنه و شخصی‌سازی کنه؛ چیزی که آنتروپیک و OpenAI معمولاً ازش پرهیز میکنن.

جمع‌بندی: باید سوییچ کنیم؟

اگه الان روی Opus 4.8 کار میکنی، مهاجرت به Opus 5 هزینه‌ی اضافه‌ای نداره چون قیمت‌گذاری عوض نشده، و طبق ادعای آنتروپیک کیفیت بالاتر رفته. اگه پروژه‌ای داری که واقعاً به سقف مطلق هوش نیاز داره —مثل کاری که قراره روزها بدون نظارت جلو بره— همچنان باید سراغ Fable 5 بری. ولی برای اکثر کارهای روزمره، از تولید محتوا گرفته تا کدنویسی و اتوماسیون، Opus 5 دقیقاً همون رده‌ایه که آنتروپیک میخواد بشه پیش‌فرض همه: قوی به اندازه‌ی کافی، ولی نه به قیمتی که مجبورت کنه هر درخواست رو دو بار فکر کنی.

چند وقتیه منتظر Gemini 3.5 Pro هستیم. گوگل توی رویداد I/O امسال قول داده بود این مدل رو «ماه بعد» عرضه کنه، ولی آن ماه گذشت، ماه بعدی هم گذشت، و به‌جاش این هفته سه مدل دیگه اومد که هیچ‌کدومشون Pro نبودن: Gemini 3.6 Flash، Gemini 3.5 Flash-Lite، و یک مدل عجیب به اسم Gemini 3.5 Flash Cyber. به نظرم خود همین انتخاب —این‌که گوگل ترجیح داده مدل‌های سبک‌تر رو زودتر بفرسته و flagship رو بذاره بپزه— داستانی به همون اندازه‌ی خود مدل‌ها جالبه.

چرا Pro دیر شده

طبق گزارش‌هایی که این چند هفته منتشر شده، Gemini 3.5 Pro توی تست‌های داخلی گوگل روی بنچمارک‌های کدنویسی اون‌طور که باید عمل نکرده و تیم مهندسی مجبور شده دوباره برگرده سراغ retraining. گوگل رسماً تأیید کرده که مدل الان دست چند پارتنر و چند نهاد دولتیه برای تست، ولی تاریخ دقیقی برای عرضه‌ی عمومی نداده. این یعنی حداقل فعلاً، اگه دنبال جایگزین GPT یا Claude توی رده‌ی سنگین‌وزن گوگل بودی، باید صبر کنی.

Gemini 3.6 Flash: جایگزین workhorse قبلی

این مدل قراره جانشین 3.5 Flash بشه، و نکته‌ای که واقعاً به چشم میاد کارایی تُکنه. گوگل میگه روی Artificial Analysis Index، این مدل تقریباً ۱۷ درصد کمتر از 3.5 Flash توکن خروجی مصرف می‌کنه، و برای کارهای چندمرحله‌ای هم تعداد reasoning step و tool call کمتری لازم داره. این برای کسی که داره agent میسازه خیلی مهمه، چون هزینه‌ی واقعی یک agent معمولاً از تعداد round-trip ها میاد، نه فقط از قیمت هر توکن.

قیمت‌گذاری هم جالبه: ورودی همون $1.50 روی هر میلیون توکن مونده، ولی خروجی از $9 به $7.50 اومده پایین. یعنی گوگل مدل جدید و به‌ظاهر قوی‌تر رو ارزون‌تر از قبلی عرضه کرده، که کار غیرمعمولیه — معمولاً نسخه‌ی جدید گرون‌تر میشه.

از نظر کدنویسی هم گوگل ادعا میکنه 3.6 Flash خطاهای کمتری توی edit کد تولید میکنه و execution loop کمتری داره، یعنی کمتر پیش میاد مدل بین چند راه‌حل اشتباه گیر کنه و دور بزنه. روی DeepSWE عدد ۴۹ درصد رو اعلام کرده که نسبت به نسخه‌ی قبلی جهش قابل توجهیه.

Gemini 3.5 Flash-Lite: برای حجم بالا

اگه پروژه‌ات نیاز به throughput بالا داره — مثلاً ترجمه‌ی حجم زیادی متن، یا پردازش batch اسناد — این مدل برای همین ساخته شده. قیمتش $0.30 روی ورودی و $2.50 روی خروجیه، یعنی از نسخه‌ی قبلی (3.1 Flash-Lite) کمی گرون‌تر شده، ولی گوگل میگه کیفیتش قابل مقایسه نیست. روی Terminal-Bench 2.1 عدد ۵۴ درصد در مقابل ۳۱ درصد نسخه‌ی قبلی گزارش شده که فاصله‌ی زیادیه. روی long-context هم (GDM-MRCR v2) از ۶۰ درصد به ۷۲ درصد رسیده.

نکته‌ای که به نظرم برای کار خودمون توی این بلاگ مهمه: اگه داری pipeline ترجمه یا پردازش متن فارسی میسازی و هزینه برات مهمه، این مدل دقیقاً همون‌جاییه که باید نگاهش کنی. برای کارهایی که Pro واقعی لازم نیست ولی حجم بالاست، معمولاً Flash-Lite گزینه‌ی منطقی‌تریه تا این‌که بخوای برای هر درخواست پول یک مدل سنگین رو بدی.

Gemini 3.5 Flash Cyber: تخصصی و محدود

این یکی جالب‌ترین معرفیه، چون هدفش عمومی نیست. مدلی fine-tune شده روی پایه‌ی Flash، مخصوص پیدا کردن و patch کردن آسیب‌پذیری‌های امنیتی کد. فعلاً فقط در اختیار دولت‌ها و پارتنرهای منتخب گوگل قرار میگیره، نه توسعه‌دهنده‌ی عادی. این حرکت رو خیلی‌ها به رقابت گوگل با آنتروپیک در حوزه‌ی امنیت کد مرتبط میدونن، جایی که آنتروپیک با مدل‌های سری Mythos یک قدم جلوتر بوده.

چیزی که بین خط‌ها نوشته شده

گوگل همزمان با این عرضه گفته که pretraining نسل بعدی، یعنی Gemini 4، رو شروع کرده. یعنی درحالی که همه منتظر Pro هستن، تیم گوگل عملاً یک نسل جلوتر داره کار میکنه. این الگو رو قبلاً هم دیده بودیم — وقتی یک مدل میانی دیر میشه، شرکت‌ها به‌جای نگه داشتن کاربر توی خلأ، یک لایه‌ی سبک‌تر و ارزون‌تر رو زودتر میفرستن تا هم بازار رو نگه دارن هم فشار رقابتی رو کم کنن.

برای من به‌عنوان کسی که مدام بین مدل‌های مختلف API سوییچ میکنه، نکته‌ی عملی این خبر اینه: اگه الان روی 3.5 Flash کار میکنی، مهاجرت به 3.6 Flash احتمالاً بدون درد سره — قیمت پایین‌تره و بنچمارک‌ها بهتره. ولی اگه منتظر Pro بودی که یک جهش واقعی توی reasoning بدی، هنوز باید صبر کنی، و با توجه به سابقه‌ی این تأخیرها بعید نیست چند هفته‌ی دیگه هم طول بکشه.