PageSift: ۱۸۸ مگابایت حافظه در برابر ۹ گیگابایت Spider در تست ۱۰۰ هزار دامنه

یک خزنده‌ی وب تک‌باینریِ رست، ۱۰۰ هزار دامنه‌ی زنده را با حافظه‌ی اوج ۱۸۸ مگابایتی پیمود — در حالی که رقیب رست‌اش، Spider (Spider)، به ۹ گیگابایت رسید و توسط OOM killer متوقف شد. این شکاف ۴۸ برابری، قواعد بازی برای خط لوله‌های هوش مصنوعی زاینده (Generative AI) را بازنویسی می‌کند.

خزیدن وب برای خط لوله‌های LLM مدتی است بین پشته‌های سنگین و خروجی‌های شکننده گیر کرده است. Firecrawl (Firecrawl) برای استقرار پیش‌فرض هفت سرویس زیر AGPL می‌طلبد — مثل یک آشپزخانه‌ی صنعتی که برای یک تاچین ساده هفت زیرمجموعه می‌خواهد. Crawl4AI (Crawl4AI) محیط پایتون ۸۴۷ مگابایتی می‌خواهد قبل از اولین درخواست — مثل حمل یک کامیون بار برای یک بسته‌ی کوچک. هر دو تمایل دارند صفحات کپچا را به‌عنوان محتوا ذخیره کنند. PageSift (PageSift) به‌عنوان یک باینری واحد بدون Redis، بدون پایگاه داده، و بدون صف پیام می‌آید.

نویسنده یک محصول کوچک هوش مصنوعی زاینده (Generative AI) اجرا می‌کند. خزیدن وب مدام آسیب می‌زد:

• Firecrawl استقرار پیش‌فرض = ۷ سرویس، مجوز AGPL
• Crawl4AI = پایتون + Playwright + Node + Chromium، ۸۴۷ مگابایت venv قبل از شروع
• صفحات کپچا و میانی در پایگاه داده به‌عنوان محتوای جعلی می‌افتادند

PageSift در مواجهه با سایت‌های مسدودکننده خطای صریح ACCESS_BARRIER برمی‌گرداند به‌جای صفحه‌ی جعلی.

تست ۱۰۰ هزار زنده
چیدمان: سرور AMD EPYC (۳۲ هسته، ۱۲۸ گیگابایت RAM)، دامنه‌های ترانکو تاپ ۱۰۰ هزار زنده، شرایط یکسان برای هر دو موتور:

• ۷۶۸ همزمانی ناهمگام (async concurrency)
• ۳.۵ ثانیه اتصال / ۱۰ ثانیه مهلت کل
• دیداپ Blake3
• استخراج مارک‌داون جریان‌دار (Streaming Markdown extraction)

مجموعه داده و اسکریپت‌های کامل: bench/results/final/BENCHMARK_100K_PAGESIFT_VS_SPIDER.md

کیفیت استخراج و سرعت

• استخراج محتوای اصلی: ۰.۸۵ میلی‌ثانیه در صفحه (p50)، F1 ۰.۷۱۶ بر مجموعه داده برچسب‌گذاری شده Firecrawl — crw ۰.۷۱۱، Crawl4AI ۰.۶۷۰
• روی زیرمجموعه ۵۴۵ صفحه کالیبره شده WebMainBench (WebMainBench) در میانگین بر Essence (Essence) برتری دارد، و همچنان در ۱۱۷ صفحه باخته است. نمرات در سطح صفحه منتشر شده‌اند؛ نویسنده ترجیح می‌دهد باخت‌ها را نشان دهد نه دانه‌گزینی کردن
• PDF → مارک‌داون: ۷۱.۰ بر olmOCR-bench (olmOCR-bench)، فرمول‌ها به‌عنوان LaTeX با ۴۴.۳٪ بازیابی شده (pymupdf4llm: ۰٪)، در ۳.۴ میلی‌ثانیه در صفحه در برابر ۳۲۰ میلی‌ثانیه
• RAG (RAG): فیلتر پرسش BM25 (BM25) در ۱.۳۵ میلی‌ثانیه در پرسش جواب می‌دهد، ۹۳٪ متن جواب را در ~۱,۱۵۰ کلمه نگه می‌دارد در حالی که فیلتر Crawl4AI ۶۷٪ را در ۱۳,۵۰۰ کلمه حفظ می‌کند فیلتر BM25 داخلی PageSift که ۹۳٪ متن پاسخ را در حدود ۱,۱۵۰ کلمه حفظ می‌کند، می‌تواند نقاط شکست در لوله‌های RAG را کاهش دهد.

چرا سریع است

• پارسر HTML صفرکپی (Zero-copy HTML parser): متن و مقادیر ویژگی از رشته منبع قرض می‌کنند؛ تنها قطعات حاوی موجودیت رمزگشایی می‌شوند
• بازپیاده‌سازی خوانایی (Readability) پاراگراف‌ها را در یک گذر بر آمارهای متنی پیش‌محاسبه شده نمره می‌دهد — بدون جهش DOM (DOM mutation)، بدون محاسبه مجدد طول
• اسکنرهای دست‌نوشته به‌جای رگکس (Regex) در مسیرهای داغ (تصنيف کلمه class/id یک تطابق زمان کامپایل با بافر پشته است)
• فضای کار forbid(unsafe_code) است — با دقیقاً یک استثنا: یک فراخوانی mallopt که آستانه mmap glibc را می‌کشد تا بافرهای اندازه صفحه به OS بازگردند به‌جای انباشت RSS. آن یک فراخوانی اوج RSS را در تست‌های محلی خزیدن از ۱۸۸ مگابایت به ~۷۵ مگابایت کاهش داد

بازی با قوانین

• robots.txt و Crawl-delay را محترم می‌دارد
• نرخ را بر میزبان محدود می‌کند
• User-Agent صریح استفاده می‌کند
• هیچ دور زدن ضد ربات: اثر انگشت TLS، حل کپچا، چرخش پراکسی نیست
• PRهای اضافه کردن ویژگی‌های پنهان پذیرفته نمی‌شوند احترام PageSift به robots.txt و محدودیت نرخ بر میزبان، با بررسی دسترسی خزنده‌های هوش مصنوعی به وب‌سایت‌ها همسو است.

محدودیت‌های صریح

• ۱۷ دسته قابلیت همچنان در انبار نویسنده جزئی علامت‌گذاری شده‌اند
• تعامل مرورگر پایدار و گردش کار عامل‌های خودمختار (agentic workflows) صریحاً خارج از حوزه هستند
• مجوز AGPL-۳.۰ + گزینه تجاری. کاملاً باز برای میزبانی شخصی؛ محصولات کد‌بسته نیاز به مجوز تجاری دارند

شروع سریع

docker run -d -p 3002:3002 \
  -e PAGESIFT_API_KEYS=change-me ghcr.io/yolow92/pagesift:0.50.0
# یا
cargo install pagesift
pagesift serve

API سازگار با Firecrawl روی :3002.

import pagesift
doc = pagesift.scrape("https://example.com")
print(doc.markdown)

همچنین در دسترس: بسته Node بومی (@pagesift/node)، سرور MCP برای عامل‌ها، و رندر JS که فقط وقتی صفحه واقعاً نیاز دارد فعال می‌شود (Lightpanda → moli → Chrome، بر اساس میزبان انتخاب می‌شود).

مخزن: https://github.com/YOLOW92/pagesift — مستندات به انگلیسی، چینی، ژاپنی و Español.

اگر Firecrawl یا Crawl4AI را در تولید اجرا می‌کنید، نویسنده واقعاً می‌پرسد: چه چیزی اول برای شما می‌شکند؟

همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی حافظه در استنتاج LLM اشاره کردیم، مدیریت بافرهای سطح سیستم می‌تواند تفاوت بین یک سرویس مقیاس‌پذیر و یک فاجعه OOM باشد.

گام بعدی شما

• PageSift را در یک محیط استیج (staging) با ترافیک واقعی خود تست کنید و نمودار RSS را در برابر Spider یا Firecrawl بسنجید
• اگر از Crawl4AI استفاده می‌کنید، هزینه‌ی حافظه ۸۴۷ مگابایت پیش‌نیاز را در صورت‌حساب محاسبه کنید — PageSift آن را حذف می‌کند
• برای خط لوله‌های RAG، فیلتر BM25 داخلی PageSift را با ۱.۳۵ میلی‌ثانیه پرسش و ۹۳٪ حفظ متن ارزیابی کنید

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