مرورگر Kitesurf مصرف پردازنده را ۳.۸ برابر کاهش داد

اگر امروز برای اجرای صدها عامل هوش مصنوعی در وب هزینه می‌کنید، احتمالاً متوجه شده‌اید که مرورگرهای استاندارد برای این کار بیش از حد سنگین هستند. کلودفلر با معرفی Kitesurf ثابت کرد که می‌توان با پذیرفتن کمی کندی، هزینه‌های زیرساختی را به شدت پایین آورد. این موازنه ثابت می‌کند که مفهوم «سرعت» در توسعه هوش مصنوعی یک معیار واحد نیست، بلکه انتخابی است بین هزینه منابع و زمان واقعی اجرا.

بسیاری از توسعه‌دهندگان به عملکرد نرم‌افزار به صورت دوتایی نگاه می‌کنند: یک اپلیکیشن یا سریع است یا کند. اما در واقعیت، مهندسی نرم‌افزار مجموعه‌ای از سازش‌های آگاهانه است. وقتی شما یک منبع خاص را بهینه می‌کنید، تقریباً همیشه منبع دیگری را از دست می‌دهید.

طبق اعلام Cloudflare در ۶ اوت ۲۰۲۶، این مرورگر جدید به‌طور خاص برای عامل (Agent) — شبیه به کارمندی دیجیتال که به‌جای تماشای صفحه، فقط داده‌های لازم را استخراج می‌کند — طراحی شده است. این پروژه تنها پس از ۱۲ هفته توسعه به نسخه بتا رسید و از طریق Browser Run در دسترس قرار گرفت. Kitesurf روی Cloudflare Workers اجرا می‌شود و از یک موتور رندرینگ ماژولار به نام Blitz برای پردازش HTML و CSS استفاده می‌کند.

Kitesurf برخلاف مرورگرهای معمولی، تمام نیازهای انباشته شده برای کاربران انسانی، مانند تب‌ها، افزونه‌ها، همگام‌سازی بین دستگاه‌ها و تعاملات بصری روان را نادیده می‌گیرد. در عوض، این ابزار بر روی وظایف خاصی تمرکز می‌کند که عامل‌های هوش مصنوعی انجام می‌دهند: بارگذاری صفحات، بازرسی ساختارها، استخراج محتوا، گرفتن اسکرین‌شات و تولید فایل‌های PDF. برای این نوع فعالیت‌ها، مصرف CPU، حافظه، ایزولاسیون، مقیاس‌پذیری و خروجی‌های ماشین‌خوان بسیار مهم‌تر از یک تجربه مرور بصری روان برای انسان است.

موازنه منابع و سرعت

کلودفلر بنچمارک‌هایی را منتشر کرد که Kitesurf را در مقایسه با یک استخر گرم (Warm Pool) از Chromium روی مجموعه‌ای شامل ۱۴ آدرس وب مورد آزمایش قرار داد. این نتایج از ۵ اجرای سریع (Quick Action) در Browser Run به دست آمده است. داده‌ها تفاوت فاحشی را بین بهره‌وری منابع و سرعت اجرا نشان می‌دهند:

• بهره‌وری پردازنده: مصرف CPU برای گرفتن اسکرین‌شات ۳.۱ برابر و برای استخراج HTML حدود ۳.۸ برابر کمتر از Chromium بود.
• بهره‌وری حافظه: مصرف رم در اسکرین‌شات ۴.۷ برابر کاهش یافت و در استخراج HTML تا ۷ برابر سقوط کرد.
• بهای این بهینه‌سازی: در مقابل، Kitesurf در زمان اجرای واقعی (Wall-clock time) برای همین تسک‌ها، ۱.۷ تا ۱.۸ برابر کندتر از Chromium عمل کرد.

محدودیت‌های آگاهانه

کلودفلر صراحتاً اعلام کرده است که Kitesurf یک جایگزین همه‌منظوره برای Chromium نیست. این ابزار ساخته نشده تا در هر بُعد ممکنی «مرورگر بهتری» باشد، بلکه برای مشتریانی با نیازهای محدودتر بهینه شده است. در نتیجه، در حال حاضر Kitesurf برای چندین مورد استفاده خاص، انتخاب اشتباهی است:

• پخش ویدیو و رندرینگ WebGL.
• دست‌دادن‌های پیچیده در سیستم‌های تایید هویت ربات (Bot-challenge handshakes).
• جلسات طولانی احراز هویت که نیاز به حفظ وضعیت پایدار (Persistent State) دارند.

برای تضمین قابلیت اطمینان با وجود این حذف‌ها، تیم توسعه بیش از ۲۱۵ هزار تست از پروژه Web Platform Tests را اجرا کرد. آن‌ها این تست‌ها را با آزمون‌های یکپارچگی (Integration) و رگرسیون بصری روی وب‌سایت‌های واقعی تکمیل کردند، زیرا انطباق با استانداردهای وب به تنهایی نمی‌توانست ثابت کند که کل وظیفه عامل هوش مصنوعی به‌درستی انجام می‌شود.

قرارداد موازنه برای توسعه‌دهندگان

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

این رویکرد منجر به معماری‌های متورم و اهداف مبهم می‌شود، زیرا هر اولویت اضافی با زمان، پول، فضای رابط کاربری و هزینه‌های نگهداری رقابت می‌کند. یک تصمیم واقعی در مورد محصول، کمتر جذاب به نظر می‌رسد: مثلاً «کاهش مصرف حافظه حتی اگر یک تسک تک‌مرحله‌ای زمان بیشتری ببرد» یا «پشتیبانی عالی از یک پلتفرم، پیش از پشتیبانی ناقص از سه پلتفرم». این نوع تفکر در راستای روندهای کلیدی توسعه نرم‌افزار با هوش مصنوعی در سال ۲۰۲۶ است که بر بهینه‌سازی‌های هدفمند تأکید دارند.

برای جلوگیری از این تله، نویسنده پیشنهاد می‌کند پیش از شروع کدنویسی، یک «قرارداد موازنه» (Tradeoff Contract) برای تعریف مرزها بنویسید. این قرارداد از ۶ خط تشکیل شده است:

۱. کاربر هدف و وظیفه: چه کسی باید چه کاری را به سرانجام برساند؟
۲. بهینه‌سازی: کدام نتیجه قابل اندازه‌گیری باید بهبود یابد؟
۳. پذیرش: کدام فقدان یا محدودیت در نسخه اول قابل قبول است؟
۴. حفاظت: چه چیزی باید حتی در حین بهینه‌سازی، درست باقی بماند؟
۵. جایگزین (Fallback): وقتی مسیر بهینه شکست می‌خورد، چه اتفاقی می‌افتد؟
۶. اثبات: کدام بنچمارک کوچک نشان می‌دهد که این موازنه درست عمل کرده است؟

مثال: اپلیکیشن برنامه‌ریزی غذایی

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

• کاربر هدف و وظیفه: یک کاربر مبتدی و پرمشغله، یک برنامه غذایی هفتگی قابل ویرایش را بر اساس ترجیحات ذخیره شده خود بسازد.
• بهینه‌سازی: زمان سپری شده از باز کردن اپلیکیشن تا دریافت برنامه قابل ویرایش.
• پذیرش: نبودِ فید اجتماعی، عدم اتصال به سیستم‌های تحویل مواد غذایی یا نبود همکاری خانوادگی در نسخه اول.
• حفاظت: محدودیت‌های غذایی (مثلاً حساسیت‌ها) باید در هر برنامه تولید شده و هر ویرایش، به‌طور مطلق حفظ شوند.
• جایگزین: اگر تولید خودکار شکست خورد، ورودی‌های کاربر حفظ شده و یک قالب دستی ارائه شود.
• اثبات: ۵ کاربر تست بتوانند یک برنامه را بسازند، ویرایش کنند، ذخیره کنند، دوباره باز کنند و خروجی بگیرند.

اکنون هوش مصنوعی یک مرز تصمیم‌گیری دارد. اگر ابزار پیشنهاد دهد که یک فید اجتماعی اضافه شود، قرارداد آن را رد می‌کند. اگر برای سریع‌تر کردن تولید برنامه، بندهای محدودیت غذایی را حذف کند، قرارداد دوباره آن را رد می‌کند.

پرهیز از «تقلب در بهینه‌سازی»

موازنه آگاهانه به معنای اجازه برای حدس زدن نیست. نویسنده هشدار می‌دهد که بهینه‌سازی اغلب می‌تواند «تقلب» کند. شما می‌توانید سرعت بارگذاری صفحه را با حذف محتوایی که کاربر به آن نیاز داشت بالا ببرید، یا هزینه دیتابیس را با عدم ذخیره صحیح داده‌ها کاهش دهید. همچنین می‌توانید مراحل ورود کاربر (Onboarding) را با پنهان کردن تمام تنظیمات ساده کنید و کاربر را در مسیر پیش‌فرض به تله بیندازید.

با تعریف خطوط «حفاظت» و «اثبات» در قرارداد، توسعه‌دهندگان مانع از آن می‌شوند که هوش مصنوعی به‌طور پنهانی تعریف «پیروزی» را تغییر دهد. برای یک اپلیکیشن مبتدی، نیازی به ۲۱۵ هزار تست نیست، اما به یک مقایسه فشرده نیاز دارید:

• ثبت نتیجه فعلی برای گردش‌کار هدف.
• اعمال یک تغییر که هدفش بهبود یک شاخص خاص است.
• اجرای مجدد گردش‌کار هدف و بررسی رفتارهای حفاظتی.
• به طور عمدی فعال کردن مسیر جایگزین (Fallback).
• تثبیت تغییر تنها در صورتی که موازنه کلی هنوز منطقی باشد.

تحلیل: تغییر به سمت زیرساخت‌های تخصصی

Kitesurf نشان‌دهنده تغییری در پشته (Stack) هوش مصنوعی از ابزارهای همه‌منظوره به سمت زیرساخت‌های تخصصی است. سال‌هاست که صنعت، عامل‌های هوش مصنوعی را مجبور کرده تا از طریق نسخه‌های «بدون سر» (Headless) مرورگرهای انسانی با وب تعامل کنند. این روش از نظر محاسباتی گران و ناکارآمد است.

کلودفلر با ساخت مرورگری که پذیرفته «کند» باشد تا در عوض «سبک» شود، در حال بهینه‌سازی برای اقتصاد مقیاس است. برای شرکتی که میلیون‌ها گردش‌کار عاملی را اجرا می‌کند، کاهش ۷ برابری مصرف حافظه بسیار ارزشمندتر از افزایش ۱.۸ برابری سرعت است. این رویکرد مشابه استراتژی‌هایی است که در آن مدل‌های تخصصی متن‌باز هزینه استنتاج AI را به شدت کاهش دادند تا بهره‌وری عملیاتی را جایگزین قدرت خام کنند. Kitesurf تصمیمی را آشکار می‌کند که بسیاری از سازندگان مبتدی از پذیرش آن می‌ترسند: «سرعت» یک چیز واحد نیست؛ بلکه بستگی به این دارد که برای چه کسی سریع باشد و کدام منبع در حال اندازه‌گیری باشد.

این رویکرد معیار توسعه اپلیکیشن‌های هوش مصنوعی را تغییر می‌دهد. برنده دیگر ابزاری نیست که همه کارها را به‌طور متوسط انجام دهد، بلکه ابزاری است که صادقانه‌ترین و سودآورترین موازنه را برای یک وظیفه خاص ایجاد کند. Kitesurf مفید است چون کلودفلر تظاهر نکرد که یک مرورگر می‌تواند همزمان ارزان‌تر، سریع‌تر، سبک‌تر، سازگارتر و از نظر بصری کامل‌تر باشد.

راهنمای نهایی برای سازندگان

اگر در حال ساخت اولین اپلیکیشن هوش مصنوعی خود هستید، از درخواست «بهترین» نسخه برای هر چیز دست بردارید. یک ویژگی را صماً به این دلیل که گران است حذف نکنید؛ آن را تنها زمانی حذف کنید که کاربر هدف همچنان بتواند وظیفه وعده داده شده را انجام دهد. هزینه بک‌اند را با غیرقابل اعتماد کردن اپلیکیشن بهینه نکنید.

پیش از جلسه کدنویسی بعدی با هوش مصنوعی، قرارداد ۶ بندی خود را بنویسید. سپس از AI بخواهید پیش از نوشتن حتی یک خط کد، این قرارداد را به چالش بکشد. اگر ابزار نتواند توضیح دهد چه چیزی بهتر می‌شود، چه چیزی بدتر می‌شود و کاربر چگونه همچنان کارش را به پایان می‌رساند، ساخت پروژه آماده شروع نیست.

برای اعمال این منطق، می‌توانید از «پرامپت‌های استارتر سازنده اپلیکیشن AI» استفاده کنید تا مرزهای پروژه خود را پیش از آنکه هوش مصنوعی برای شما نیازهای خیالی اختراع کند، تعریف کنید. برای کسانی که به دنبال مسیری سازمان‌یافته از ایده تا محدوده، انتخاب پشته، پرامپت‌نویسی، QA، استقرار و انتشار هستند، راهنمای میدانی «AI App Builder From Zero» یک دستورالعمل عمیق‌تر برای ساخت گام‌به‌گام ارائه می‌دهد.

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