Cloudflare OS: محدودیت ۴۰۹۶ توکنی عامل‌های AI را فلج کرد

۱۶ هزار توکن و ۹۰ دقیقه زمان؛ این بهای سنگینی است که برای ساخت یک بازی ساده دوز (Tic-Tac-Toe) با یک مدل زبانی محلی پرداخت شد. این شکست نه از ضعف در کدنویسی، بلکه حاصل برخورد خاموش میان الزامات معماری Cloudflare OS و تنظیمات پیش‌فرض موتورهای استنتاج محلی بود. در دفاع از خود باید بگویم که این برنامه روی یک کامپیوتر گیمینگ با مدل محلی اجرا می‌شد، به این معنی که تنها متری که در حال حرکت بود، کنتور برق بود؛ آرامش خاصی در تماشای یک هوش مصنوعی وجود دارد که دور خودش می‌چرخد، وقتی که همزمان در حال خالی کردن حساب بانکی شما نیست.

شرکت کلودفلر (Cloudflare) در اوت ۲۰۲۶، سیستم Cloudflare OS را به‌صورت متن‌باز منتشر کرد. این محیط، همان فضای داخلی است که هزاران کارمند این شرکت برای خودکارسازی وظایف، نوشتن مستندات و ساخت اپلیکیشن‌ها از آن استفاده می‌کنند. اگرچه این پلتفرم برای استقرار روی Cloudflare Workers طراحی شده، اما دستور pnpm run-local به توسعه‌دهندگان اجازه می‌دهد کل این پشته را روی سخت‌افزار شخصی خود اجرا کنند. این حالت محلی، هزینه‌های API و محدودیت‌های نرخ درخواست را حذف می‌کند، اما مجموعه‌ای از گلوگاه‌های سخت‌افزاری را معرفی می‌کند که می‌تواند جریان‌های کاری عامل‌محور (Agentic Workflows) را به‌طور کامل مختل کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه فایل‌های ساختاریافته مانند llms.txt به موتورهای جست‌وجوی AI کمک می‌کنند اشاره کردیم، محیط Cloudflare OS گامی به سوی فضاهای کاری بسیار ساختاریافته و ایزوله (Sandboxed) برای عامل‌ها است. با این حال، تست عملی روی یک سیستم گیمینگ با کارت گرافیک RTX 5060 (۸ گیگابایت VRAM) نشان داد که «محلی بودن» همیشه به معنای «یکپارچگی» نیست.

محیط تست

برای درک دقیق اینکه دیوارها کجا قرار دارند، باید به محدودیت‌های سخت‌افزاری خاص این پیکربندی نگاه کنیم:

• سیستم‌عامل: ویندوز ۱۱
• سخت‌افزار: RTX 5060 (VRAM 8GB) / RAM 32GB
• نرم‌افزار: Node.js 24.13.0 / pnpm 11.15.1
• نسخه Cloudflare OS: نسخه دسترسی زودهنگام (v2) منتشر شده در اوت ۲۰۲۶ (تحت لایسنس Apache-2.0)
• مدل‌ها: اولاما (Ollama) + qwen3:8b (در ابتدا)، سپس تغییر به qwen3:30b-a3b در اواسط مسیر

Cloudflare OS چیست؟

این سیستم یک سیستم‌عامل سنتی برای کامپیوتر نیست، بلکه یک «سیستم‌عامل» برای بهره‌وری AI است که طراحی شده تا بارهای کاری هوش مصنوعی را مشابه مدیریت پردازش‌های محاسباتی در OSهای معمولی مدیریت کند. این پلتفرم یک رابط چت برای عامل‌ها فراهم می‌کند که پیش‌فرض با دانش سازمانی بارگذاری شده و محیطی ایزوله برای ساخت «گجت‌ها» (Gadgets) ارائه می‌دهد.

دو مؤلفه اصلی معماری آن عبارتند از:

• گجت‌ها (Gadgets): اپلیکیشن‌های کوچکی که برای هر کاربر یک نمونه خصوصی (Private Instance) در یک محیط ایزوله اجرا می‌شود. به جای یک SaaS مشترک، یک کپی اختصاصی در داخل سندباکس تولید می‌شود. این ساختار تضمین می‌کند که اگر کاربری کدهای داخلی را بازنویسی کند، این تغییرات بر هیچ‌کس دیگری اثر نگذارد.
• درگاه (Gatekeeper): واسطی برای سرویس‌های خارجی (مثل گیت‌هاب یا گوگل) است که دامنه دسترسی را محدود کرده، عملیات‌ها را ثبت (Log) می‌کند و برای عملیات‌هایی که اثرات جانبی (Side-effect) دارند، تأیید انسانی می‌طلبد. نکته جالب این است که Gatekeeper عامل را در حین انتظار برای تأیید متوقف نمی‌کند؛ بلکه یک نتیجه شبیه‌سازی‌شده برمی‌گرداند تا عامل بتواند به کار خود ادامه دهد و انسان بعداً عملیات را بررسی کند. این رویکرد در مدیریت ابزارهای متعدد، یادآور راهکار رجیستری ویژگی‌های Vararuchi است که برای سازماندهی مقیاس‌پذیر ابزارهای AI طراحی شده بود.

شکاف سازگاری با ویندوز

راه‌اندازی این محیط روی ویندوز ۱۱ بلافاصله با یک مانع مواجه شد. اسکریپت pnpm run-local با خطای ENOENT شکست می‌خورد زیرا سعی می‌کند pnpm را مستقیماً اجرا کند، در حالی که ویندوز به pnpm.cmd نیاز دارد. متد execFileSync در Node.js شل (Shell) را دور می‌زند، به این معنی که پسوندهای .cmd را به‌طور خودکار شناسایی نمی‌کند.

برای رفع این مشکل، توسعه‌دهندگان باید یا دستورات نصب و بیلد را به‌صورت دستی اجرا کنند یا کد منبع را با افزودن shell: process.platform === 'win32' به فراخوانی‌های execFileSync در سه فایل آسیب‌دیده اصلاح کنند: run-dev-server.js و packages/gatekeeper-context/build-app.mjs و packages/gatekeeper-scheduler/build-app.mjs.

در صورت عدم تمایل به اصلاح کد، توالی دستی به این صورت است:
۱. pnpm install
۲. pnpm --filter @gadgets/typed-storage build
۳. pnpm --filter @gadgets/workshop-frontend exec vite build
۴. node run-dev-server.js --serve-frontend-assets

این فرآیند محیط را در http://localhost:8787 فعال می‌کند. جالب است که بیلد محلی از احراز هویت ساده نام‌کاربری/رمز عبور با پیش‌فرض ADMINS=["admin"] استفاده می‌کند که به کسانی که با این نام ثبت‌نام می‌کنند، دسترسی مدیریتی فوری می‌دهد. علاوه بر این، Wrangler تشخیص می‌دهد که نشست در داخل یک عامل AI در حال اجرا است و یک Local Explorer API در آدرس http://127.0.0.1:8787/cdn-cgi/local/explorer/api راه می‌اندازد تا بتوان KV، D1 و Durable Objects را از طریق HTTP بازرسی کرد.

اتصال مدل‌های محلی

سیستم Cloudflare OS از پنج ارائه‌دهنده مدل پشتیبانی می‌کند: Anthropic، OpenAI، Google، Cloudflare Workers AI و Ollama. ارائه‌دهنده Ollama در واقع به عنوان یک قلاب (Hook) برای هر نقطه انتهایی (Endpoint) سازگار با OpenAI عمل می‌کند. در این تست از مدل qwen3:8b با کوانتش ۴ بیتی (حدود ۵.۲ گیگابایت) استفاده شد که در VRAM ۸ گیگابایتی جای می‌گرفت.

انتخاب یک مدل محلی مانند Qwen 3 سه مزیت اصلی دارد: هزینه نهایی صفر برای اجرا، حریم خصوصی کامل و اجتناب کامل از محدودیت‌های نرخ درخواست (Rate Limits) دلخواه. در حالی که ارائه‌دهندگان رسمی ممکن است محدودیت‌های سخت‌گیرانه در پنجره‌های ۵ ساعته داشته باشند، یک سیستم استنتاج محلی این سقف‌ها را به‌طور کامل حذف می‌کند. این تلاش برای بهینه‌سازی هزینه‌ها، مشابه استراتژی جولز روبینو در جایگزینی مدل‌های 7B برای کاهش هزینه‌های استنتاج در وظایف ساده‌تر است.

مالیات دسکتاپ روی VRAM

یکی از مهم‌ترین یافته‌ها مربوط به حافظه قابل استفاده است. در حالی که یک ماشین ممکن است ۸ گیگابایت VRAM داشته باشد، «مالیات دسکتاپ ویندوز» — یعنی پردازش‌های پس‌زمینه مانند کروم، دیسکورد و منوی استارت — بیش از ۱ گیگابایت را مصرف می‌کند.

در شرایط واقعی، کاربری با کارت ۸ گیگابایتی تنها حدود ۶.۶ گیگابایت VRAM قابل استفاده دارد. این یک تله رایج است؛ اکثر بنچمارک‌ها در محیط‌های استریل اجرا می‌شوند، اما کارهای واقعی در حالی انجام می‌شوند که اسلک و ده‌ها تب کروم باز هستند. این سربار در یک لینوکس بدون رابط گرافیکی (Headless) تقریباً به صفر می‌رسد و ویندوز را به یک نقطه ضعف برای سیستم‌های اختصاصی AI تبدیل می‌کند.

به همین ترتیب، RAM سیستم به‌طور کامل در دسترس نیست. در یک ماشین ۳۲ گیگابایتی، ردپای پایه (Baseline Footprint) پیش از بارگذاری مدل نشان داد که ۱۵.۶ گیگابایت در حال استفاده است. Edge WebView2 (۲.۴۸ گیگابایت)، کروم (۲.۰۱ گیگابایت)، VS Code (۱.۲۲ گیگابایت) و فشرده‌سازی حافظه (۴.۹۹ گیگابایت) تنها حدود ۱۶ گیگابایت را برای بارگذاری فعال مدل باقی می‌گذارند.

پاک‌سازی خاموش زمینه (Context Purge)

مخرب‌ترین شکست به دلیل پنجره زمینه (Context Window) پیش‌فرض در Ollama رخ داد. برای GPUهایی با حافظه کمتر از ۲۳ گیگابایت VRAM، اولاما به‌طور پیش‌فرض طول زمینه را روی ۴۰۹۶ توکن تنظیم می‌کند.

از آنجا که پرامپت سیستمی Cloudflare OS و تعاریف ابزارها به تنهایی نزدیک به ۴۰۰۰ توکن را اشغال می‌کنند، پنجره زمینه در همان لحظه شروع گفتگو سرریز می‌شود. بحرانی‌ترین نکته این است که تنظیم n_keep = 4 در اولاما فقط ۴ توکن اول را محافظت می‌کند، به این معنی که حیاتی‌ترین دستورات سیستمی اولین مواردی هستند که حذف می‌شوند.

این منجر به یک «شکست خاموش» می‌شود؛ جایی که مدل ناگهان غیرمنطقی رفتار می‌کند، نام بایندینگ‌ها را فراموش می‌کند یا پارامترهای ابزار را به‌هم می‌ریزد بدون اینکه هیچ خطایی صادر شود. برای مثال، عامل ممکن است نام بایندینگ گجتی را که همین حالا ساخته فراموش کند یا به جای filename از path برای writeFile استفاده کند. تنها راه حل، تنظیم دستی متغیر محیطی OLLAMA_CONTEXT_LENGTH روی ۱۶۳۸۴ یا بالاتر است، هرچند این کار مصرف VRAM را برای KV cache افزایش می‌دهد. برای مثال، مصرف حافظه qwen3:8b پس از این تغییر از ۵.۲ گیگابایت به ۷.۸ گیگابایت جهش کرد و سیستم را به یک اجرای ترکیبی (Hybrid) با ۲۷٪ CPU و ۷۳٪ GPU سوق داد.

مشکل «اتاقی بدون زنگ در»

در حین ساخت بازی دوز، عامل در حلقه‌ای گیر کرد تا یک خطای Content Security Policy (CSP) را با اعمال نادرست هدرهای CORS رفع کند. عامل ۱۰ دقیقه همین اشتباه را تکرار کرد چون Cloudflare OS فاقد یک ماشه «شکست مکرر» (Repeated Failure Trigger) است تا عامل را متوقف کرده و به انسان هشدار دهد.

تحلیل فایل packages/workshop-backend/src/agent.ts نشان می‌دهد که منطق shouldStopAfterTurn تنها در صورتی فعال می‌شود که:

• انسان دکمه Stop را بزند.
• حد نوبت‌ها به ۳۰ برسد.
• در انتظار تأیید برای اتصال به یک منبع خارجی باشد.
• در انتظار تأیید برای یک عملیات تغییر وضعیت (State-changing) باشد.

هیچ بررسی برای شکست‌های تکراری وجود ندارد. علاوه بر این، ابزار giveUp تنها برای کال‌بک‌های پس‌زمینه (if (callbackInitiated)) فعال است، نه برای نشست‌های چت استاندارد. در یک چت زنده، عامل تنها دو گزینه دارد: یا کورکورانه به پیشروی ادامه دهد یا نوبت را تمام کند. این موضوع یک ریسک «تخلیه اعتبار» برای کسانی است که از APIهای پولی استفاده می‌کنند، هرچند برای کاربران محلی صرفاً هزینه برق است. این با فلسفه «برو یک قهوه بخور» در سیستم Gatekeeper در تضاد است؛ در حالی که اثرات جانبی غیرهمزمان هستند، مدیریت خطا همچنان به انسانی وابسته است که فعالانه صفحه را تماشا می‌کند.

یادگیری معکوس توسعه وب

تمام شکست‌ها در این فرآیند پنج‌مرحله‌ای ناشی از اعمال منطق «استاندارد» توسعه وب در یک محیط محدود بود. عامل سعی کرد از fetch برای تماس‌های شبکه استفاده کند و فایل‌های index.html بسازد که هر دو در معماری گجت‌های Cloudflare OS ممنوع یا غیرضروری هستند.

• گجت‌ها: اپلیکیشن‌های کوچکی که در محیط ایزوله اجرا می‌شوند و تمام ارتباطات خارجی باید از طریق درگاه (Gatekeeper) و با استفاده از بایندینگ‌ها عبور کند.
• درگاه (Gatekeeper): به عنوان واسطی برای سرویس‌هایی مانند گیت‌هاب یا گوگل عمل می‌کند، دامنه دسترسی را محدود کرده و تأیید انسانی را برای عملیات‌های حساس درج می‌کند.
• محدودیت‌ها: متدهای استاندارد مانند ذخیره‌سازی سمت کلاینت، مسیرهای مستقیم HTTP یا فراخوانی‌های fetch به‌طور فیزیکی توسط دستور connect-src 'none' در CSP مسدود شده‌اند.
• راه درست: راه حل همیشه ساده‌ترین مسیر است: استفاده از RPC stubهای ارائه شده (مثلاً await gadget.method()) و استفاده از نام کلاس اجباری Gadget که از DurableObject ارث‌بری می‌کند.

عملکرد مدل‌های MoE

جالب است که مدل Qwen 3:30B-a3B با معماری ترکیب خبره‌ها (Mixture of Experts) به‌طور قابل توجهی بهتر از مدل متراکم (Dense) ۸ میلیاردی عمل کرد. با وجود اندازه ۱۹ گیگابایتی، این مدل با تقسیم بار کاری (۶۸٪ CPU و ۳۲٪ GPU) به سرعت ۲۸ توکن بر ثانیه رسید. این زیبایی MoE است؛ یک مدل متراکم ۳۰ میلیاردی با سرعت چند توکن در ثانیه می‌خزید. این نشان می‌دهد برای محیط‌های عامل محلی، ارتقای RAM سیستم اغلب به‌صرفه‌تر از تعقیب VRAMهای رده‌بالا است، زیرا هسته‌های پردازشی مکرراً در انتظار پهنای باند حافظه بیکار می‌مانند.

کالبدشکافی پنج مرحله شکست

برای به تصویر کشیدن این جدال، در اینجا جزئیات فرآیند ساخت بازی دوز آمده است:

۱. دور اول: مدل سعی کرد نام بایندینگ سمت سرور TIC_TAC_TOE را به عنوان یک متغیر جهانی در مرورگر ارجاع دهد که منجر به ReferenceError شد.
۲. دور دوم: مدل به سمت استفاده از fetch برای فراخوانی یک نقطه انتهایی HTTP تغییر مسیر داد که بلافاصله توسط CSP مسدود شد.
۳. دور سوم: مدل خطای CSP را به‌اشتباه به عنوان مشکل CORS تشخیص داد و ۱۰ دقیقه در یک حلقه، هدرهای Access-Control-Allow-Origin را اسپم کرد.
۴. دور چهارم: پس از اینکه به او گفته شد از متغیر gadget استفاده کند، نام کلاس سمت سرور را به جای Gadget (که الزامی است)، TIC_TAC_TOE گذاشت و باعث خطای «متد یافت نشد» شد.
۵. دور پنجم: پس از ارائه یک اسکلت کد آماده (Boilerplate) با استفاده از DurableObject توسط کاربر، مدل موفق شد منطق بازی و دستکاری DOM را پیاده‌سازی کند.

این آزمایش ثابت می‌کند در حالی که APIهای پیشرو (Frontier) نقص‌های طراحی محیطی را از طریق هوش محض می‌پوشانند، مدل‌های محلی ضعیف‌تر به عنوان یک «تست استرس» عمل می‌کنند که نقص‌های معماری را افشا می‌کنند. طراحی‌ای که روی یک مدل ضعیف کار کند، همیشه روی مدل قوی کار می‌کند، اما عکس آن صادق نیست. اگر قصد استقرار عامل‌های محلی را دارید، اولین قدم شما باید بازبینی تنظیمات پنجره زمینه و ارائه یک لیست سخت‌گیرانه از «اقدامات ممنوعه» به مدل باشد تا از تلاش برای اجرای الگوهای استاندارد وب در یک محیط ایزوله جلوگیری شود.

گام بعدی شما

• اگر از Ollama استفاده می‌کنید، فوراً متغیر OLLAMA_CONTEXT_LENGTH را بررسی و بر اساس اندازه پرامپت‌های سیستمی خود افزایش دهید.
• در طراحی عامل‌ها، مکانیزم «توقف در صورت شکست مکرر» (Repeated Failure Trigger) را پیاده‌سازی کنید تا از حلقه‌های بی‌‌پایان جلوگیری شود.
• برای مدل‌های محلی، فهرستی از محدودیت‌های محیطی (مانند ممنوعیت fetch) را مستقیماً در پرامپت سیستمی بگنجانید.

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