تفاوت ۶ برابری در هزینه؛ مدل صورت‌حساب orkestr در برابر AWS Lambda

اگر امروز برای اجرای کدهای تولیدشده توسط هوش مصنوعی در محیط‌های ایزوله هزینه می‌پردازید، باید بدانید که انتخاب زیرساخت می‌تواند صورت‌حساب ماهانه شما را تا ۶ برابر تغییر دهد. تفاوت در اینجا نه در قدرت سخت‌افزاری، بلکه در نحوه محاسبه «زمان تفکر» عامل‌هاست.

بر اساس مستندات فنی، یک محیط ایزوله با ۱ پردازنده مجازی (vCPU) و ۲ گیگابایت رم که ۱۷۶ ساعت در ماه فعال باشد، در orkestr حدود ۱۳ یورو هزینه دارد، اما همان پیکربندی در AWS Lambda MicroVM تقریباً ۲۷ دلار قیمت می‌زند. این شکاف قیمتی نشان‌دهنده یک تفاوت بنیادین در نحوه صورت‌حساب زمان‌های بیکار (Idle) است که صنعت در حال گذار از آن است.

در ۲۳ ژوئن ۲۰۲۶، AWS سرویس Lambda MicroVMs را عرضه کرد تا محیط‌های جداگانه برای اجرای کدهایی که توسط کاربر یا هوش مصنوعی تولید شده‌اند، فراهم کند. این سرویس‌ها برخلاف توابع بدون وضعیت (Stateless) معمولی، ماشین‌های مجازی قابل آدرس‌دهی هستند که می‌توان آن‌ها را از طریق API اجرا، متوقف یا بازگرداند. طبق اعلام AWS، هر ماشین مجازی یک نقطه اتصال HTTPS اختصاصی دارد. این حرکت عملاً تایید کرد که غول زیرساخت جهان، الگوی «سندباکس عامل» (Agent Sandbox) — که پیش از این توسط بازیگران کوچک‌تری مثل E2B و Modal استفاده می‌شد — را به رسمیت شناخته است. این عرضه سیگنالی بود مبنی بر اینکه صنعت بر سر یک اصل اولیه (Primitive) توافق کرده است: نیاز به ماشین‌های مجازی کوتاه‌مدت، یک‌بارمصرف اما دارای وضعیت (Stateful) که قادر به اجرای کدهای غیرقابل اعتماد باشند. این تحول در زیرساخت، مکمل پیشرفت‌های دیگر AWS است؛ برای مثال، مدل‌های عامل AWS Bedrock اکنون با سرعت بسیار بیشتری مستقر می‌شوند تا زمان رسیدن ایده به اجرا کاهش یابد.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، ایزولاسیون سخت‌افزاری در اینجا حیاتی است. برای توسعه‌دهندگان، تکنولوژی زیربنایی هر دو سرویس یکسان است؛ هر دو از مجازی‌ساز Firecracker استفاده می‌کنند. در مستندات AWS صراحتاً ذکر شده است: «Lambda MicroVMs این قابلیت‌های اصلی را از طریق مجازی‌سازی Firecracker ارائه می‌دهند.» این امر تضمین می‌کند که هر سندباکس یک ماشین مجازی با ایزولاسیون سخت‌افزاری، دارای هسته (Kernel) و سیستم فایل ریشه مجزا باشد، نه یک کانتینر که هسته میزبان را به اشتراک می‌گذارد. این تمایز زمانی حیاتی می‌شود که یک مدل زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — دستوراتی برای محیط شِل (Shell) بنویسد که هنوز توسط انسان بررسی نشده‌اند و ممکن است برای سیستم میزبان خطرناک باشند.

سازوکار بنیادین

چرخه حیات هر دو سیستم تقریباً یکسان است: ایجاد سندباکس، اجرای دستورات، خواندن و نوشتن فایل‌ها، توقف (Pause)، بازگشت (Resume) و در نهایت تخریب (Terminate). برای درک سادگی این رابط، یک سندباکس در orkestr به این شکل مقداردهی می‌شود:

from orkestr import Sandbox
with Sandbox.create(template="python-3.12") as sbx:
    sbx.files.write("/workspace/main.py", "print(sum(range(1_000_000)))")
    result = sbx.exec("python /workspace/main.py")
    print(result.stdout) # 499999500000

سقف زیرساختی

در مقابل، AWS در مقیاس عمودی خام و یکپارچگی با اکوسیستم پیشتازی می‌کند. طبق گزارش رسمی AWS، Lambda MicroVMs قابلیت‌های زیر را پشتیبانی می‌کنند:

• پردازنده: تا ۱۶ vCPU
• حافظه: تا ۳۲ گیگابایت رم
• ذخیره‌ساز: تا ۳۲ گیگابایت دیسک
• Bursting: قابلیت جهش ۴ برابری (Vertical Burst) فراتر از خط پایه پیکربندی شده

در مقابل، orkestr سقف سندباکس‌های خود را روی ۴ vCPU و ۸ گیگابایت رم محدود کرده است. اگر عامل شما نیاز به کامپایل یک درخت عظیم C++ یا نگه داشتن یک دیتافریم ۲۰ گیگابایتی در حافظه دارد، AWS تنها گزینه عملی است. همچنین، AWS یکپارچگی عمیقی با IAM، اتصال به VPC، سرویس S3 و CloudWatch فراهم می‌کند که آن را به گزینه پیش‌فرض برای عامل‌هایی تبدیل می‌کند که باید به منابع خصوصی AWS دسترسی داشته باشند. AWS حتی یک راهنمای خاص برای استفاده از Lambda MicroVMs به عنوان سندباکس برای Claude Managed Agents منتشر کرده است. این رقابت در سطح زیرساخت، بخشی از نبرد گسترده‌تر برای مدیریت عامل‌هاست، همان‌طور که رقابت بین OpenClaw و Hermes برای تسلط بر لایه کنترلی این سیستم‌ها نشان می‌دهد.

مقیاس و قابلیت اطمینان

موضوع دیگر، حجم تاییدشده و فشار کاری است. AWS سرویس Firecracker را برای بیش از ۱۵ تریلیون فراخوانی Lambda در هر ماه اجرا می‌کند. اگر الگوی کاری شما به گونه‌ای است که نیاز دارید ۱۰ هزار سندباکس را هم‌زمان در ساعت ۰۹:۰۰ صبح یک دوشنبه اجرا کنید، AWS مقیاسی را در سطحی ثابت کرده است که ارائه‌دهندگان کوچک‌تر صرفاً نمی‌توانند با آن رقابت کنند.

شکاف حاکمیت و صلاحیت قانونی

در حالی که AWS در زمان عرضه پنج منطقه (Region) داشت — شرق ایالات متحده (ویرجینیا شمالی، اوهایو)، غرب ایالات متحده (اورگان)، آسیا-پاسیفیک (توکیو) و اروپا (ایرلند) — تنها یکی از آن‌ها در اروپا قرار داشت. orkestr در سه منطقه اروپایی (آلمان، فنلاند و فرانسه) فعالیت می‌کند. این یک واقعیت فنی درباره تأخیر (Latency) و محدوده اثر (Blast-radius) است: قرار دادن سندباکس نزدیک‌تر به کاربری که در انتظار پاسخ است، لگ را کاهش می‌دهد و مانع از این می‌شود که کل محصول شما را روی یک منطقه واحد شرط‌بندی کنید.

اما موضوع فراتر از جغرافیاست و به اپراتور قانونی مربوط می‌شود. ایرلند در اتحادیه اروپاست و تصمیم مربوط به کفایت «چارچوب حریم خصوصی داده‌های اتحادیه اروپا و ایالات متحده» پابرجا است، چرا که در سپتامبر ۲۰۲۵ از چالش در دادگاه عمومی جان سالم به در برد. بنابراین، اجرای سندباکس‌ها در ایرلند قانونی است و نقض GDPR محسوب نمی‌شود.

با این حال، قانون CLOUD آمریکا (18 U.S.C. §2713) مانع متفاوتی ایجاد می‌کند. این قانون، ارائه‌دهندگان آمریکایی را موظف می‌کند داده‌هایی را که در «مالکیت، حضانت یا کنترل» آن‌هاست، بدون توجه به اینکه آن داده‌ها در کجای جهان ذخیره شده‌اند، ارائه دهند. در اینجا معیار، «کنترل شرکتی» است، نه نام شهر. یک منطقه اروپایی در یک ابر-سرویس‌دهنده آمریکایی، داده‌ها را در خاک اروپا نگه می‌دارد، اما آن‌ها را از دسترس یک حکم قضایی ایالات متحده خارج نمی‌کند. orkestr یک موجودیت اروپایی بدون شرکت مادر آمریکایی است و لایه‌ای از حفاظت برای بررسی‌های خرید (Procurement reviews) فراهم می‌کند که در آن‌ها دسترسی قانونی آمریکا یک «خط قرمز» یا Deal-breaker است. این دغدغه‌های حریم خصوصی و محدودیت‌های قانونی اغلب توسعه‌دهندگان را به سمت راهکارهای جایگزین سوق می‌دهد، مشابه مواردی که هزینه‌های گزاف سخت‌افزار برای جایگزینی مدل‌های ابری به دلیل محدودیت‌های NDA ایجاد می‌کند.

اقتصاد زمان‌های بیکار

مهم‌ترین تفاوت در شمارنده صورت‌حساب (Billing Meter) است. AWS یک نرخ پایه (Baseline rate) را برای کل مدت زمان روشن بودن ماشین مجازی محاسبه می‌کند. اگر یک عامل ۹۰ ثانیه دستور اجرا کند و سپس ۱۰ دقیقه در حالی که مدل «فکر» می‌کند بیکار بماند، AWS هزینه آن ۱۰ دقیقه CPU بیکار را می‌گیرد. در این مدل، «روشن بودن یعنی هزینه» و زمان بیکاری همان قیمت کار فعال را دارد.

orkestr صورت‌حساب را تفکیک کرده و هر بخش را در هر ثانیه می‌سنجد:

• CPU: فقط بر اساس زمان واقعی پردازش روی CPU (On-CPU time) محاسبه می‌شود.
• RAM: بر اساس مقدار حافظه‌ای که عملاً اشغال شده محاسبه می‌شود.

برای تجسم این موضوع، یک ساعت کار با سندباکس ۱ vCPU / ۱ گیگابایت رم را در نظر بگیرید که تنها ۱۳ دقیقه آن کار واقعی انجام شده است. AWS هزینه کل ۶۰ دقیقه را می‌گیرد (حدود ۰.۱۵۵ دلار). اما orkestr هزینه CPU را فقط برای همان چهار فوران فعالیت (۱۳ دقیقه) و هزینه RAM را برای کل یک ساعت می‌گیرد. این منجر به مجموع حدود ۰.۰۱۲ یورو برای CPU و ۰.۰۱۵ یورو برای RAM می‌شود که در مجموع تقریباً ۰.۰۲۵ یورو است.

مقایسه قیمت‌ها (تقریبی):

• AWS Lambda MicroVMs: حدود ۰.۱۲۳ دلار برای هر vCPU-hour (ایرلند، x86) و ۰.۰۱۶ دلار برای هر GB-hour. هزینه پایه در تمام مدت محاسبه می‌شود.
• orkestr: ۰.۰۴۵ یورو برای vCPU-hour و ۰.۰۱۵ یورو برای GiB-hour. پردازنده فقط در زمان مصرف (Burn) محاسبه می‌شود.

این یعنی در حالی که یک سندباکس بیکار کاملاً رایگان نیست (چون همچنان هزینه رم را می‌پردازید)، اما حدود ۶ برابر ارزان‌تر از معادل آن در Lambda است. شمارنده رم به این دلیل فعال می‌ماند که ماشین مجازی پس از لمس گیگابایت‌های تخصیص‌یافته، آن‌ها را بدون توجه به سطح فعالیت نگه می‌دارد. از آنجا که گردش کارهای عامل-محور با توقف‌های طولانی شناخته می‌شوند، این تفاوت در سنجش هزینه، محرک اصلی قیمت است.

پایداری و چرخه حیات

محدودیت‌های زمان اجرا (Runtime limits) و مدیریت وضعیت (State management) نیز به شدت متفاوت است. Lambda MicroVMs سقف کل زمان اجرا را ۸ ساعت قرار داده است. orkestr اجازه می‌دهد سندباکس‌ها تا ۲۴ ساعت زنده بمانند. برای یک عامل کدنویسی طولانی‌مدت یا یک اجراکننده CI که در حال پردازش یک monorepo عظیم است، سقف ۸ ساعته AWS می‌تواند منجر به مشکلات پیچیده «دوختن» (Stitching) برای حفظ تداوم شود.

مدیریت وضعیت در لحظه تخریب نیز متفاوت است:

• AWS: تخریب باعث آزاد شدن تمام منابع می‌شود. Suspend/Resume حافظه و دیسک را حفظ می‌کند، اما پس از تخریب، وضعیت کاملاً از بین می‌رود.
• orkestr: حجم‌های پایدار (Persistent volumes) را از طریق یک Volume ext4 که در مسیر /persist سوار شده است فراهم می‌کند. این حجم‌ها در فضای ذخیره‌سازی شیء (Object Storage) اروپا Checkpoint می‌شوند و پس از تخریب نیز باقی می‌مانند. این ویژگی به عامل اجازه می‌دهد پس از یک هفته، دوباره به همان محیط کاری که رها کرده بود متصل شود. توجه داشته باشید که کپی ذخیره‌سازی شیء تنها به اندازه آخرین Checkpoint به‌روز است، بنابراین از دست دادن یک باکس می‌تواند منجر به از دست رفتن نوشته‌های پس از آخرین آپلود شود.

تجربه توسعه‌دهنده و راه‌اندازی

جریان کاری برای ساخت ایمیج‌ها بر اساس پیچیدگی متفاوت است. در Lambda، شما کد و Dockerfile را در یک zip بسته‌بندی کرده، در S3 آپلود می‌کنید و API را برای ساخت ایمیج فراخوانی می‌کنید؛ فرآیندی که چندین دقیقه زمان می‌برد.

orkestr از یک API مستقیم‌تر به نام Template استفاده می‌کند. توسعه‌دهندگان لیستی از مراحل شِل را تعریف می‌کنند:

from orkestr import Template
Template.create(
    name="agent-py",
    base_template="python-3.12",
    recipe=[
        "apt-get update && apt-get install -y ripgrep",
        "pip install pandas duckdb",
    ],
)

سیستم فایل ریشه در زمان اجرا قابل نوشتن است. اجرای دستور apt-get install در یک سندباکس فعال فوراً نتیجه می‌دهد، هرچند این تغییرات در یک لایه Overlay مبتنی بر RAM قرار می‌گیرند که با تخریب سندباکس ناپدید می‌شوند.

خلاصه مقایسه‌ای

تحلیل: این رودررو proves می‌کند که «بزرگ‌ترین» همیشه برای گردش کارهای عامل-محور «بهترین» نیست. AWS برای سازمان‌های بزرگ (Enterprise) می‌سازد — جایی که IAM و ۱۶ vCPU نیازهای اصلی هستند. orkestr برای «جلسه عامل» (Agent Session) می‌سازد — جایی که بهره‌وری هزینه در زمان‌های بیکار و حاکمیت قانونی محرک‌های اصلی هستند.

برای کیف پول توسعه‌دهنده، مدل «CPU بیکار رایگان است» یک تغییر بازی (Game-changer) محسوب می‌شود. از آنجا که بارهای کاری عامل‌ها با توقف‌های طولانی بین فوران‌های فعالیت شناخته می‌شوند، پرداخت برای CPU رزرو شده یک مالیات غیرضروری است. تغییر به سمت اپراتورهای بومی اروپا همچنین نشان می‌دهد که «اقامت داده‌ها» (Data Residency) در حال تکامل به «حاکمیت اپراتور» (Operator Sovereignty) است.

برای بررسی این محدودیت‌ها، توسعه‌دهندگان می‌توانند با لایه رایگان orkestr شروع کنند. تأیید ایمیل، ۱۰ یورو اعتبار بدون نیاز به کارت (یا ۱۰۰ یورو با کارت) فراهم می‌کند. لایه رایگان شامل ۱۰ گیگابایت حجم ذخیره‌شده است. ایمیج‌های پایه شامل python-3.12، python-3.12-bare، node-22 و debian-12 (نسخه کامل Debian bookworm) هستند. همچنین یک سرور MCP برای یکپارچگی مستقیم با Claude Code یا Cursor از طریق pip install orkestr در دسترس است.

گام بعدی شما

• اگر از عامل‌های کدنویس استفاده می‌کنید، هزینه CPU-hour خود را با مدل «پرداخت بر اساس مصرف واقعی» در orkestr مقایسه کنید.
• برای پروژه‌هایی با حساسیت بالای حریم خصوصی، بررسی کنید آیا تابع «حاکمیت اپراتور» در اروپا برای استانداردهای امنیتی شما اولویت دارد یا خیر.
• اگر با Claude Code یا Cursor کار می‌کنید، سرور MCP ارکستر را از طریق pip install orkestr نصب کرده و محیط ایزوله را تست کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.