Cloudflare Workers یا Vercel؛ پهنای باند می‌تواند هزینه را ۳۲ برابر کند

برای API و وب‌هوک پرترافیک با پردازش سبک، Cloudflare Workers در نمونهٔ محاسبه‌شده هزینهٔ کمتری دارد؛ برای برنامه‌ای که Next.js SSR را با تنظیمات کمتر می‌خواهد، Vercel مسیر ساده‌تری است. در شبیه‌سازی هزینهٔ Morph، صد میلیون درخواست و ده ترابایت انتقال ماهانه حدود ۵۱٫۴۰ دلار برای Workers و ۱۶۲۵ دلار برای Vercel Pro با CDN مصرفی هزینه دارد؛ نسبت دو رقم، با گرد کردن، نزدیک به ۳۲ برابر است. این نتیجه به فرض‌های همان API تعلق دارد و هزینهٔ حافظهٔ تابع Vercel را در بر نمی‌گیرد.

انتخاب مدل CDN نتیجه را عوض می‌کند. شرایط Flat Rate CDN در Vercel ردهٔ ماهانهٔ ۳۰۰ دلاری را با ظرفیت ۱۵۰ میلیون درخواست CDN و ۵۰ ترابایت انتقال برای تیم‌های Pro نشان می‌دهد؛ اما این مدل برای توزیع انبوه فایل یا بارکاری‌ای که انتقال داده کارکرد اصلی آن است، واجد شرایط نیست. بنابراین API معمولی، صفحهٔ SSR و سرویس دانلود فایل را نمی‌توان با یک فرض مشترک دربارهٔ CDN قیمت‌گذاری کرد.

در صورتحساب هر پلتفرم چه چیزی شمرده می‌شود؟

در تعرفهٔ رسمی Cloudflare Workers، طرح پولی از ماهانه ۵ دلار آغاز می‌شود، ده میلیون درخواست و ۳۰ میلیون میلی‌ثانیه CPU را شامل می‌شود و برای هر میلیون درخواست اضافه ۰٫۳۰ دلار و هر میلیون میلی‌ثانیه CPU اضافه ۰٫۰۲ دلار می‌گیرد. خود Workers در این مدل متر جداگانه‌ای برای خروج داده به اینترنت ندارد. زمان انتظار برای پاسخ پایگاه داده، مصرف فعال CPU نیست؛ در عوض استفاده از محصولاتی مانند فضای ذخیره‌سازی می‌تواند هزینهٔ جداگانه ایجاد کند.

تعرفهٔ Vercel طرح‌های Hobby، Pro و Enterprise را جدا می‌کند: Pro ماهانه ۲۰ دلار است، یک جایگاه مجاز به استقرار و ۲۰ دلار اعتبار مصرف دارد؛ فراخوانی تابع، CPU فعال و حافظهٔ تخصیص‌یافته نیز مترهای مستقل‌اند. نرخ آغازین فراخوانی اضافه ۰٫۶۰ دلار برای هر میلیون، CPU فعال ۰٫۱۲۸ دلار برای هر ساعت و حافظهٔ تخصیص‌یافته ۰٫۰۱۰۶ دلار برای هر گیگابایت‌ساعت است. نرخ محاسبه و انتقال مصرفی با منطقه تغییر می‌کند؛ مبلغ نهایی ممکن است هزینهٔ CDN، خدمات جانبی و مالیات را هم در بر بگیرد.

تمایز میان درخواست CDN و اجرای تابع در هر دو پلتفرم مهم است. در Vercel پاسخ ذخیره‌شده در کش همچنان یک درخواست CDN ایجاد می‌کند، ولی تابع را دوباره فرا نمی‌خواند؛ در Workers نیز درخواست عبوری از Worker می‌تواند مشمول متر درخواست باشد، حتی اگر پاسخ از کش آن برگردد، در حالی که اجرای دوبارهٔ کد می‌تواند مصرف CPU را تغییر دهد. بنابراین شمار بازدیدها به‌تنهایی تعداد اجرای تابع یا زمان پردازش را مشخص نمی‌کند. برای مقایسهٔ قابل‌استفاده باید درخواست‌های ورودی، فراخوانی‌های واقعی، میانگین CPU هر فراخوانی و حجم دادهٔ تحویل‌شده جدا باشند.

سه مقیاس ترافیک چگونه نتیجه را تغییر می‌دهند؟

مبنای ارقام زیر یک بارکاری فرضی API است: هر درخواست یک تابع را اجرا می‌کند، هر اجرا به‌طور میانگین ده میلی‌ثانیه CPU فعال مصرف می‌کند و تابع Vercel در منطقهٔ iad1 قرار دارد. محاسبه برای یک جایگاه Pro انجام شده است. هزینهٔ حافظهٔ تخصیص‌یافتهٔ Vercel کنار گذاشته شده، زیرا بدون دانستن مدت عمر نمونهٔ تابع و هم‌زمانی درخواست‌ها نمی‌توان گیگابایت‌ساعت آن را به‌دست آورد؛ در پروژهٔ واقعی این قلم ممکن است رقم Vercel را بالا ببرد.

• در یک میلیون درخواست و ۱۰۰ گیگابایت انتقال ماهانه، Workers به حداقل ۵ دلار طرح پولی می‌رسد و Vercel Pro حدود ۲۰ دلار می‌ماند؛ مصرف تابع در اعتبار ماهانهٔ Pro جا می‌گیرد.
• در ده میلیون درخواست و یک ترابایت انتقال، برآورد Workers برابر ۶٫۴۰ دلار است: ۵ دلار پایه و ۱٫۴۰ دلار CPU مازاد. برآورد Vercel هنوز حدود ۲۰ دلار است، چون مصرف محاسبه‌شده در اعتبار طرح می‌گنجد.
• در صد میلیون درخواست و یک ترابایت انتقال، Workers به ۵۱٫۴۰ دلار می‌رسد: ۵ دلار پایه، ۲۷ دلار درخواست و ۱۹٫۴۰ دلار CPU. مجموع برآورد Vercel با CDN مصرفی حدود ۲۷۵ دلار است.

اگر در مقیاس سوم حجم انتقال از یک به ده ترابایت برسد و تعداد درخواست و CPU ثابت بماند، برآورد Workers همان ۵۱٫۴۰ دلار می‌ماند، ولی رقم منتشرشده برای Vercel با هزینهٔ انتقال مازاد به حدود ۱۶۲۵ دلار می‌رسد. در این مقیاس، هزینهٔ پایهٔ یک جایگاه Pro و اعتبار مصرفی هم‌مقدارند و اثر یکدیگر را خنثی می‌کنند؛ رقم نهایی مجموع مترهای مصرفی محاسبه‌شده است. کوچک‌ترشدن پاسخ، فشرده‌سازی آن یا کاهش فراخوانی تابع به‌کمک کش می‌تواند نتیجه را تغییر دهد.

برای خروجی حجیم، Flat Rate CDN چه فرقی می‌کند؟

اگر همان صد میلیون درخواست و ده ترابایت انتقال مربوط به پاسخ‌های یک برنامهٔ واجدشرایط باشد، ظرفیت ردهٔ ثابت ۳۰۰ دلاری از هر دو مقدار بیشتر است. با حفظ فرض ده میلی‌ثانیه CPU برای هر فراخوانی، هزینهٔ تقریبی Vercel پیش از حافظه به ۳۹۵ دلار می‌رسد: ۳۰۰ دلار برای CDN، حدود ۵۹٫۴۰ دلار فراخوانی و ۳۵٫۵۶ دلار CPU؛ هزینهٔ پایهٔ Pro با اعتبار مصرفی آن خنثی می‌شود. این یک محاسبهٔ شرطی از نرخ‌هاست، نه صورتحساب تضمین‌شدهٔ همان پروژه. هزینهٔ حافظه، منطقهٔ واقعی مصرف، خدمات دیگر و شرایط قرارداد همچنان اثر دارند.

برای سرویس دانلود یا تحویل عمدهٔ فایل، فرض واجدشرایط‌بودن برای Flat Rate CDN مناسب نیست؛ چنین بارکاری‌ای در محدودیت‌های این مدل آمده است. در سمت Workers نیز «خروج دادهٔ بدون هزینهٔ جداگانه» به معنای رایگان‌بودن کل مسیر فایل نیست: اگر فایل از محصول ذخیره‌سازی خوانده شود، ذخیره‌سازی و عملیات آن محصول باید به حساب افزوده شود. از همین رو نتیجهٔ API سبک را نمی‌توان بی‌تغییر به سامانهٔ توزیع فایل تعمیم داد.

Next.js SSR روی کدام مسیر ساده‌تر اجرا می‌شود؟

Vercel برای برنامه‌ای که به رندر سمت سرور، بازتولید تدریجی صفحه، بهینه‌سازی تصویر و پیش‌نمایش استقرار تکیه دارد، مسیر یکپارچه‌تری فراهم می‌کند. در Workers هم اجرای Next.js ممکن است، اما سازگاری برنامه با مسیر استقرار انتخابی بخشی از تصمیم است. راهنمای Next.js در Cloudflare، vinext را مسیر پیشنهادی معرفی می‌کند؛ این ابزار در مرحلهٔ بتا است، از SSR و بسیاری از قابلیت‌های رایج پشتیبانی می‌کند و پشتیبانی بهینه‌سازی تصویر در آن جزئی است. OpenNext نیز برای برنامه‌های موجودی که هنوز امکان مهاجرت به vinext ندارند، مسیر مستند دیگری است.

برای SSR، هزینهٔ هر درخواست فقط بخشی از انتخاب است. صفحه‌ای که برای هر بازدید دوباره ساخته می‌شود، نسبت به صفحه‌ای که پاسخ آن از کش می‌آید، فراخوانی تابع و CPU بیشتری مصرف می‌کند. نزدیکی تابع به پایگاه داده، زمان ساخت HTML و قابلیت‌های مورد استفادهٔ برنامه نیز بر تأخیر تجربه‌شده اثر می‌گذارند. اگر جابه‌جایی به Workers مستلزم بازبینی رندر، کش یا تصویر باشد، صرفه‌جویی در تعرفه باید در کنار این کار فنی سنجیده شود؛ برای برنامهٔ ساده‌تر ممکن است همین مانع بسیار کوچک باشد.

تأخیر شروع و سقف اجرا کجا اهمیت پیدا می‌کنند؟

Workers کد را در ایزوله‌های سبک اجرا می‌کند و Vercel در Fluid Compute از گرم‌سازی و استفادهٔ دوباره از نمونهٔ تابع بهره می‌برد. از این تفاوت معماری نمی‌توان یک عدد ثابت برای تأخیر شروع همهٔ APIها یا صفحه‌های SSR استخراج کرد. درخواست کش‌شده ممکن است اصلاً تابع را اجرا نکند؛ درخواست پویا می‌تواند بیشتر وقت خود را در انتظار پایگاه داده یا سرویس دیگری بگذراند. برای کاربر، مجموع زمان شبکه، شروع اجرا، پردازش و دسترسی به داده مهم است.

در Workers Paid می‌توان سقف CPU هر فراخوانی را برای مهار مصرف ناخواسته تنظیم کرد، اما این سقف همان زمان سپری‌شده هنگام انتظار برای شبکه نیست. در Vercel، CPU فعال و حافظهٔ تخصیص‌یافته جداگانه محاسبه می‌شوند؛ وب‌هوکی که بیشتر منتظر پاسخ بیرونی است با صفحهٔ SSR پردازش‌محور، حتی در شمار درخواست برابر، الگوی هزینهٔ یکسانی ندارد. اگر بار اصلی API سبک است، مزیت تعرفهٔ Workers روشن‌تر می‌شود؛ اگر ارزش اصلی برنامه در قابلیت‌های Next.js و استقرار کم‌دردسر است، هزینهٔ Vercel باید همراه با آن منفعت سنجیده شود.

بیشتر بخوانید:

• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• Codex یا Claude Code؛ سرعت بیشتر در برابر کنترل مجوزها
• Cloudflare R2 یا Amazon S3؛ خروج داده می‌تواند صورت‌حساب را عوض کند