عاملان هوش مصنوعی به طور فزایندهای کارهای روتین را به عهده میگیرند: قیمتهای رقبای خود را پارس میکنند، حسابهای اجتماعی را مدیریت میکنند و کمپینهای تبلیغاتی را آزمایش میکنند. اما هر نوع اتوماسیون یک هزینه پنهان دارد — ترافیک پروکسی. ما سه اندازهگیری در وظایف معمول انجام دادیم و مشخص کردیم که عامل هوش مصنوعی در یک ساعت و یک ماه چقدر گیگابایت "مصرف" میکند تا شما بتوانید به طور دقیق بودجه پروکسی را محاسبه کنید و از پرداخت اضافی جلوگیری کنید.
چرا اندازهگیری ترافیک عامل هوش مصنوعی مهم است
بیشتر پروکسیهای مقیم و موبایل بر اساس حجم ترافیک فروخته میشوند، نه بر اساس تعداد IP یا زمان. این به طور اصولی آنها را از تعرفههای مرکز داده متمایز میکند، جایی که معمولاً قیمت ثابتی برای پورت وجود دارد. وقتی صحبت از کار دستی میشود — یک نفر در حال مرور Instagram یا بررسی قیمتها در Ozon است — مصرف ترافیک قابل پیشبینی و کم است. اما وقتی وظیفه به عهده عامل هوش مصنوعی قرار میگیرد، تصویر به طور کلی تغییر میکند.
عامل هوش مصنوعی بدون وقفه کار میکند، اغلب صفحات را به طور کامل باز میکند (با تمام تصاویر، اسکریپتها، و ردیابها)، میتواند به طور همزمان دهها جلسه را مدیریت کند و درخواستهای بیشتری نسبت به یک انسان در همان زمان تولید کند. بدون اندازهگیری قبلی، به راحتی میتوان به وضعیتی افتاد که بسته ترافیک خریداری شده در عرض چند روز به جای یک ماه تمام میشود و اتوماسیون به دلیل کمبود محدودیت متوقف میشود.
ما تصمیم گرفتیم این شکاف را پر کنیم و اندازهگیریهایی را در سه سناریو انجام دهیم که بیشتر در میان آربیتراژکنندگان، متخصصان SMM و فروشندگان بازارها که از عاملان هوش مصنوعی برای اتوماسیون از طریق مرورگرهای ضد تشخیص Dolphin Anty، AdsPower و Octo Browser استفاده میکنند، رایج است.
متدولوژی اندازهگیری: چه چیزی و چگونه محاسبه شد
برای حفظ خلوص آزمایش، ما از یک ترکیب یکسان استفاده کردیم: مرورگر ضد تشخیص AdsPower با پروکسیهای مقیم متصل، شمارشگر ترافیک در سطح سرور پروکسی و ثبت درخواستها از طریق مانیتور شبکه داخلی مرورگر. عامل هوش مصنوعی به عنوان یک اسکریپت مبتنی بر مرورگر بدون سر با ماژول LLM برای تصمیمگیری (معادل ترکیب Playwright + GPT-agent) پیادهسازی شد که از طریق یک جلسه پروکسی یکسان در طول کل آزمایش اجرا شد.
هر سناریو سه بار در زمانهای مختلف روز اجرا شد تا خطاهای ناشی از بارگذاری دینامیک محتوا و وزن متفاوت بنرهای تبلیغاتی در وبسایتها را حذف کند. اعداد نهایی — میانگین ارزش در سه اجرا است. ما موارد زیر را ثبت کردیم: حجم کل دادههای منتقل شده (ترافیک ورودی + خروجی)، تعداد درخواستهای HTTP، زمان اجرای وظیفه و حجم ترافیک برای هر "عمل" عامل (یک مشاهده محصول، یک پست، یک راهاندازی تبلیغ).
نکته مهم: ما بارگذاری تصاویر و رسانهها را مسدود نکردیم، زیرا در وظایف واقعی، عامل هوش مصنوعی اغلب نیاز به تجزیه و تحلیل محتوای بصری دارد — اسکرینشاتهای صفحات، پیشنمایش کارتهای محصولات، و مینیاتورهای ویدیو. این مصرف ترافیک را در مقایسه با پارس کردن متنی از طریق API افزایش میدهد، اما شرایط واقعی کار اکثر عاملانی که از طریق مرورگر کار میکنند را به دقت منعکس میکند.
سناریو 1: پارس کردن قیمتها در Wildberries و Ozon
وظیفه عامل: دور زدن 500 کارت محصول در دستهبندی مشخص، ثبت قیمت، موجودی و رتبهبندی، مقایسه با قیمتهای رقبای دیگر و تهیه گزارش. چنین وظیفهای برای فروشندگانی که بهطور همزمان قیمتها را در بازارها زیر نظر دارند، معمول است.
نتیجه اندازهگیری: پردازش 500 کارت محصول 42 دقیقه طول کشید و 1.3 گیگابایت ترافیک مصرف کرد. به ازای هر کارت — تقریباً 2.6 مگابایت، که برای دادههای کاملاً متنی نسبتاً زیاد است. دلیل آن این است که Wildberries و Ozon مجموعه کامل تصاویر محصول، نظرات با عکس و بلوکهای تبلیغاتی را در هر صفحه بارگذاری میکنند، حتی اگر عامل فقط به قیمت نیاز داشته باشد.
ما بهینهسازی را آزمایش کردیم: بارگذاری تصاویر و ویدیوها را در سطح مرورگر خاموش کردیم و فقط HTML و پاسخهای JSON API بازار را نگه داشتیم. مصرف به 340 کیلوبایت در هر کارت کاهش یافت — تقریباً 8 برابر. اما در عین حال، Wildberries بیشتر CAPTCHA را در جلسات "سبکتر" بدون مجموعه استاندارد منابع نشان میداد، که باعث میشد عامل درخواستهای تکراری از طریق IP جدید انجام دهد و بخشی از صرفهجویی در ترافیک را مصرف کند.
در صورت گسترش به کل کاتالوگ 10,000 محصول و بهروزرسانی روزانه دادهها، مصرف ترافیک حدود 26 گیگابایت در روز بدون بهینهسازی و حدود 3.4 گیگابایت با خاموش کردن رسانهها است. برای پارس کردن چنین حجمی، پروکسیهای مرکز داده مناسبتر هستند — آنها در مقایسه با گیگابایت ارزانتر هستند و سرعت بالاتری را فراهم میکنند، که در صورت وجود تعداد زیادی جریان موازی حیاتی است.
سناریو 2: پست خودکار و گرم کردن در Instagram/TikTok
وظیفه عامل: شبیهسازی رفتار یک کاربر زنده — مرور 15-20 پست در فید، لایک کردن 5-7 مورد از آنها، گذاشتن 2 نظر، مشاهده 3 استوری و انتشار یک پست با عکس. این سناریو برای آژانسهای SMM که حسابهای جدید مشتریان را قبل از راهاندازی تبلیغات گرم میکنند یا به تبلیغات ارگانیک میپردازند، معمول است.
اندازهگیری نشان داد: یک چرخه کامل گرم کردن یک حساب 8-11 دقیقه طول میکشد و 180-240 مگابایت ترافیک مصرف میکند. مصرف اصلی — ویدیوها در استوریها و Reels: حتی یک ویدیو کوتاه 15 ثانیهای به طور میانگین 12-18 مگابایت در حین پخش خودکار با کیفیت پیشفرض وزن دارد. انتشار یک پست عکس با پردازش از طریق فیلتر 15-20 مگابایت دیگر به بارگذاری و تأیید اضافه میکند.
اگر آژانس 30 حساب را با گرم کردن روزانه مدیریت کند، مجموع مصرف حدود 6-7 گیگابایت در روز خواهد بود، یعنی حدود 180-210 گیگابایت در ماه برای کل مجموعه حسابها. این رقم قابل توجهی است که باید از قبل در بودجه پروکسی لحاظ شود — بهویژه اگر برای هر حساب از IP جداگانه استفاده شود تا از ممنوعیتهای زنجیرهای در حسابهای چندگانه جلوگیری شود.
برای این وظیفه، ما پروکسیهای موبایل را توصیه میکنیم — Instagram و TikTok به طور قابل توجهی نسبت به IPهای موبایل اپراتور کمتر تهاجمی هستند، زیرا بیشتر کاربران واقعی از این طریق وارد میشوند. این امر فرکانس بررسیهای اضافی و CAPTCHA را کاهش میدهد که همچنین مصرف ترافیک را به دلیل تلاشهای تکراری برای ورود افزایش میدهد.
سناریو 3: آزمایش خلاقیتها در Facebook Ads
وظیفه عامل: ورود به 10 پنل تبلیغاتی Facebook Ads Manager، راهاندازی 3 تبلیغ با خلاقیتهای مختلف در هر کدام، پیگیری وضعیت تأیید هر 20 دقیقه به مدت 2 ساعت و جمعآوری آمار اولیه در مورد نمایشها و کلیکها. این سناریو برای آربیتراژکنندگان که به طور همزمان دهها ترکیب را آزمایش میکنند، معمول است.
Ads Manager — یکی از "سنگینترین" رابطها از میان تمام آزمایششدهها است: فقط بارگذاری داشبورد یک پنل با آمار 8-12 مگابایت مصرف میکند به دلیل تعداد زیاد اسکریپتهای JS، نمودارها و ردیابهای Meta Pixel. چرخه کامل — ورود به 10 پنل، انتشار 30 تبلیغ با تصاویر، به علاوه 6 چرخه بررسی وضعیت — 890 مگابایت ترافیک در 2 ساعت کار مداوم مصرف کرد.
در صورت محاسبه برای یک ماه با کار روزانه با چنین حجمی از پنلها، مصرف حدود 26-27 گیگابایت خواهد بود. اگر آژانس یا تیم آربیتراژ بیش از 50 حساب تبلیغاتی را از طریق مرورگر ضد تشخیص مانند Dolphin Anty یا Multilogin مدیریت کند، مجموع ترافیک به راحتی به 100-150 گیگابایت در ماه فقط برای یک فعالیت نظارت و راهاندازی کمپینها میرسد.
در اینجا ثبات و "پاکی" IP حیاتی است: Facebook به طور تهاجمی حسابها را در صورت تغییر مشکوک آدرس یا کار با IPهای مرکز داده که به راحتی به عنوان پروکسی شناسایی میشوند، ممنوع میکند. گزینه بهینه — پروکسیهای مقیم با پیوند یک IP پایدار به هر حساب: آنها مانند اتصالات خانگی معمولی به نظر میرسند و خطر مسدود شدن را در فعالیت عامل هوش مصنوعی کاهش میدهند.
جدول خلاصه مصرف ترافیک
در زیر — اعداد خلاصهای از هر سه سناریو برای محاسبه سریع حجم ترافیک مورد نیاز هنگام برنامهریزی کارهای عاملان هوش مصنوعی.
| سناریو | ترافیک برای 1 عمل | ترافیک در روز (حجم معمولی) | نوع پروکسی توصیه شده |
|---|---|---|---|
| پارس کردن Wildberries/Ozon (10,000 کارت) | 2.6 مگابایت / 340 کیلوبایت بدون رسانه | 26 گیگابایت / 3.4 گیگابایت بدون رسانه | مرکز داده |
| گرم کردن/پست خودکار Instagram (30 حساب) | 180-240 مگابایت در هر چرخه | 6-7 گیگابایت | موبایل |
| Facebook Ads (10 پنل، 30 تبلیغ) | 890 مگابایت در 2 ساعت | 10-13 گیگابایت (در 2-3 چرخه) | مقیم |
چگونه مصرف ترافیک عامل هوش مصنوعی را کاهش دهیم
اندازهگیریها نشان داد که بخش عمدهای از ترافیک توسط تصاویر، ویدیوها و اسکریپتهای ردیابی مصرف میشود، نه خود دادههای مفید که برای عامل لازم است. در اینجا روشهای معتبر برای کاهش مصرف بدون از دست دادن کیفیت اتوماسیون آورده شده است:
- بارگذاری رسانهها را در جاهایی که ممکن است خاموش کنید. برای وظایف پارس کردن قیمتها و ویژگیهای محصولات، تصاویر لازم نیست — صرفهجویی به 80-85% میرسد.
- از API بازارها و شبکههای اجتماعی به جای بارگذاری کامل صفحه استفاده کنید، اگر مرورگر ضد تشخیص و قوانین پلتفرم اجازه دهد — این امر وزن درخواست را به شدت کاهش میدهد.
- فرکانس بررسی وضعیت را محدود کنید. در سناریوی Facebook Ads، بررسی هر 20 دقیقه در مقابل هر 5 دقیقه مصرف ترافیک برای نظارت را تقریباً 4 برابر کاهش میدهد بدون از دست دادن بهروزرسانی دادهها.
- منابع ایستا را در جلسه کش کنید — لوگوها، آیکونهای رابط، فایلهای CSS — تا عامل هر بار که راهاندازی جدیدی انجام میدهد، آنها را دوباره دانلود نکند.
- کیفیت ویدیو در استوریها/Reels را به حداقل تنظیم کنید برای وظایف خودکار مشاهده، اگر این امر بر اجرای وظیفه اصلی عامل تأثیر نگذارد.
ترکیب این روشها در آزمایشهای ما مصرف کل ترافیک را بسته به سناریو 40-60% کاهش داد، در حالی که سرعت اجرای وظیفه توسط عامل به دلیل وزن کمتر صفحات حتی کمی افزایش یافت.
کدام نوع پروکسی را برای وظیفه انتخاب کنیم
نوع پروکسی به طور مستقیم نه تنها بر هزینه ترافیک بلکه بر ثبات کار عامل هوش مصنوعی تأثیر میگذارد. برای پارس کردن انبوه بازارها، جایی که بررسیهای سختگیرانهای بر "انسانی بودن" IP وجود ندارد، پروکسیهای مرکز داده بهینه هستند — آنها سریع، ارزانتر در مقایسه با گیگابایت و مناسب برای حجمهای بزرگ درخواستهای مشابه هستند.
برای کار با شبکههای اجتماعی و پنلهای تبلیغاتی، جایی که پلتفرمها به طور فعال با اتوماسیون و حسابهای چندگانه مبارزه میکنند، اولویت با IPهای مقیم و موبایل است. آنها مانند اتصالات کاربری معمولی به نظر میرسند، که فرکانس CAPTCHA و مسدود شدنها را کاهش میدهد و به این ترتیب به طور غیرمستقیم ترافیک را به دلیل کاهش تعداد تلاشهای تکراری و احراز هویت مجدد صرفهجویی میکند.
نکته عملی: یک بسته بزرگ ترافیک "برای همه" خریداری نکنید — وظایف را بر اساس نوع پروکسی به تناسب طبیعت آنها تقسیم کنید. این هم ارزانتر و هم برای کار پایدار عامل هوش مصنوعی در درازمدت قابل اعتمادتر است.
نتیجهگیری
اندازهگیریهای ما نشان داد که مصرف ترافیک عامل هوش مصنوعی به شدت به نوع وظیفه بستگی دارد: پارس کردن بازارها بدون بهینهسازی میتواند دهها گیگابایت در روز مصرف کند، پست خودکار در شبکههای اجتماعی — واحدهای گیگابایت برای مجموعه حسابها، و کار با پنلهای تبلیغاتی Facebook Ads — تا 10-13 گیگابایت در حین نظارت فعال. درک این اعداد به برنامهریزی دقیقتر بودجه پروکسی و جلوگیری از وضعیتی که در آن ترافیک زودتر از موعد تمام میشود، کمک میکند.
اگر عامل هوش مصنوعی شما در حال پارس کردن حجم زیادی از دادهها در Wildberries یا Ozon است، به پروکسیهای مرکز داده توجه کنید — آنها بهترین نسبت سرعت به هزینه ترافیک را ارائه میدهند. برای گرم کردن و اتوماسیون در Instagram و TikTok، پروکسیهای موبایل مناسبتر هستند، و برای کار پایدار با پنلهای تبلیغاتی و حسابهای چندگانه — پروکسیهای مقیم با IP ثابت برای هر حساب.