Homebench: ابزاری برای سنجش سرعت و کیفیت مدل‌های محلی در یک دستور

تصور کنید ساعت‌ها وقت صرف دانلود مدل‌های ۱۰ گیگابایتی می‌کنید، اما در نهایت متوجه می‌شوید مدل روی لپ‌تاپ شما بیش از حد کند است یا در پاسخ به سوالات ساده توهم می‌زند. Homebench که در ۴ اوت ۲۰۲۶ عرضه شد، این حدس و گمان‌ها را با یک دستور واحد به داده‌های دقیق تبدیل می‌کند. این ابزار یک رابط کاربری متنی (TUI) است که سرعت، اثر حافظه و کیفیت مدل‌هایی را که از طریق اولاما (Ollama)، ال‌ام استودیو (LM Studio)، لاماسی‌پلاس‌پلاس (llama.cpp) و vLLM اجرا می‌شوند، اندازه‌گیری می‌کند.

در حالی که پذیرش مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در محیط‌های محلی شدت گرفته، کاربران برای یافتن روشی یکپارچه جهت سنجش عملکرد با مشکل مواجه بودند. اکثر ابزارهای موجود تنها بر یک معیار تمرکز دارند؛ برای مثال llama-bench (که در داخل llama.cpp قرار دارد) فقط سرعت را می‌سنجد، در حالی که lm-evaluation-harness بر کیفیت تمرکز دارد اما تجربه کاربری (UX) صیقل‌خورده‌ای برای لپ‌تاپ ندارد و بر اساس اجراکننده‌های مدلی (Model Runners) که اکثر مردم در محیط محلی استفاده می‌کنند، ساخته نشده است. Homebench این شکاف را با ترکیب هر دو جنبه در یک تجربه بدون نیاز به تنظیمات (Zero-config) و محلی‌محور پر می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی چالش‌های استدلال مدل‌ها در داده‌های جدولی به دلیل ابعاد بالا اشاره کردیم، انتخاب مدل مناسب به شدت به سخت‌افزار وابسته است. Homebench به توسعه‌دهندگان اجازه می‌دهد تست کنند که آیا کوانتش‌های (Quantizations) خاص یا معماری‌های مدل‌های مختلف، واقعاً شکاف‌های استدلالی را روی ماشین شخصی آن‌ها حل می‌کنند یا خیر. این ابزار پاسخی سریع و در یک نگاه به این سوال می‌دهد که: «کدام یک از مدل‌های محلی من واقعاً خوب است و روی این لپ‌تاپ با چه سرعتی اجرا می‌شود؟»

معیارهای کلیدی و نحوه اندازه‌گیری

طبق مستندات این پروژه، Homebench سه بعد اصلی عملکرد را ردیابی می‌کند:

• سرعت: اندازه‌گیری توکن در ثانیه (Tokens per second) و زمان تا نخستین توکن (TTFT). توکن در ثانیه از تقسیم تعداد توکن‌های خروجی بر زمان تولید به دست می‌آید. برای مدل‌های Ollama، این ابزار از زمان‌بندی ارزیابی سمت سرور استفاده می‌کند؛ اما برای بک‌اندهای سازگار با OpenAI، زمان استریم توکن‌ها در سمت کلاینت محاسبه می‌شود. TTFT نیز زمان واقعی (Wall-clock time) تا رسیدن اولین توکن استریم شده است، که در صورتی که اجراکننده گزارش دهد، زمان بارگذاری مدل از آن کسر می‌شود. هر دو معیار، پردازش اولیه پرامپت (Prompt Processing) را نادیده می‌گیرند.
• حافظه: حجم مدل در حافظه (Resident size) از طریق APIهای بومی (مانند /api/ps در اولاما یا /api/v0 در LM Studio) استخراج شده و اوج مصرف حافظه (Peak-RSS) فرآیندهای پس‌زمینه به عنوان یک معیار تخمینی ثبت می‌شود.
• کیفیت: اجرای مجموعه‌ای از ۳۱ تکلیف با نمره دهی قطعی (Deterministically-graded) که حوزه‌های ریاضی، استدلال، بازیابی حقایق، پیروی از دستورات/خروجی‌های ساختاریافته، استخراج داده‌ها و درک کد را پوشش می‌دهد. در این راستا، ابزارهایی مانند GnLOLot برای استخراج منطق استدلالی از داده‌های متنی تلاش کرده‌اند تا مدل‌های محلی کوچک‌تر را در زمینه تفکر استدلالی بهینه کنند.

پیاده‌سازی فنی و تجربه کاربری

به نقل از مستندات github.com، این ابزار برای سرعت و بازتولیدپذیری طراحی شده است. برای تمام تست‌های کیفیت، دمای (Temperature) روی صفر و بذر (Seed) ثابت تنظیم شده تا نتایج تصادفی نباشند و هر بار تکرار شود. برای جلوگیری از انتظار طولانی در لپ‌تاپ‌ها، Homebench به‌طور پیش‌فرض یک «مجموعه سریع» (Fast suite) شامل تقریباً ۸ تکلیف از تمامی دسته‌ها و ۳ مدل کوچک‌تر شناسایی شده را اجرا می‌کند (مدل‌ها از کوچک‌ترین به بزرگ‌ترین پردازش می‌شوند تا نتایج سریع‌تر ظاهر شوند).

سیستم کشینگ (Caching) یکی از ویژگی‌های مرکزی است. نتایج در مسیر ~/.homebench ذخیره می‌شوند؛ بنابراین اجرای مجدد مدل‌های تغییرنیافته به‌جای چندین دقیقه، تنها چند ثانیه زمان می‌برد. این قابلیت باعث می‌شود اولین اجرای کامل تمام مدل‌ها و مجموعه کامل تکالیف (که می‌تواند ۱۵ تا ۲۵ دقیقه طول بکشد) در اجراهای بعدی به فرآیندی ۱ تا ۲ دقیقه‌ای و سپس به چند ثانیه تبدیل شود. کاربران می‌توانند با پرچم --refresh-cache اجبار به محاسبه مجدد کنند یا با --no-cache سیستم کشینگ را کاملاً غیرفعال نمایند.

یکپارچگی با سرویس‌دهنده‌ها و اتصال

Homebench طیف گسترده‌ای از اجراکننده‌های محلی را پشتیبانی می‌کند و به‌صورت خودکار ترتیب زیر را برای شناسایی بررسی می‌کند: اول ابتدا Ollama، سپس LM Studio، سپس llama.cpp و در نهایت vLLM. کاربران می‌توانند با استفاده از پرچم --provider یک سرویس‌دهنده خاص را اجبار کنند.

• Ollama: اتصال به http://localhost:11434 (یا متغیر OLLAMA_HOST).
• LM Studio: اتصال به http://localhost:1234 (یا متغیر LMSTUDIO_HOST) و غنی‌سازی متاداده‌ها از طریق /api/v0.
• llama.cpp: اتصال به llama-server روی http://localhost:8080 (یا متغیر LLAMACPP_HOST).
• vLLM: اتصال به http://localhost:8000 (یا متغیر VLLM_HOST). کاربران در صورت نیاز سرور می‌توانند VLLM_API_KEY را تنظیم کنند.
• سازگار با OpenAI: فراهم‌کننده openai اجازه اتصال به هر سرور /v1 (مانند LocalAI، TGI یا Jan) را با ارسال پرچم --host یا تنظیم OPENAI_BASE_URL می‌دهد. برای مدیریت بهینه این اتصالات و کاهش هزینه‌ها، می‌توان از راهکارهای مسیریابی ترافیک مانند Foreman استفاده کرد تا دسترسی به مدل‌های مختلف به صورت متمرکز مدیریت شود.

قابلیت‌های پیشرفته بنچمارک

برای کسانی که از سرورهای دسته‌ای (Batching) مانند vLLM، llama.cpp (با قابلیت continuous batching) یا Ollama (با تنظیم OLLAMA_NUM_PARALLEL > 1) استفاده می‌کنند، Homebench قابلیت سنجش توان عملیاتی (Throughput sweep) را دارد. با دستور homebench throughput می‌توان سطوح هم‌زمانی (Concurrency) مختلف را تست کرد (مثلاً homebench throughput --concurrency 1,2,4,8 --provider vllm) تا مشخص شود سرعت کلی (Aggregate tok/s) چگونه مقیاس می‌یابد.

در این حالت، ابزار تعداد N درخواست را در هر سطح هم‌زمانی ارسال می‌کند (به‌طور پیش‌فرض ۳ برابر مقدار هم‌زمانی). سپس سرعت مجموع (کل توکن‌های خروجی تقسیم بر زمان واقعی)، میزان بهبود نسبت به حالت تک-درخواست (Concurrency 1)، میانگین نرخ هر درخواست و تأخیر (میانگین و p95) را گزارش می‌دهد. در سیستم‌های غیر-دسته‌ای، این تست نشان می‌دهد که توان عملیاتی مجموع ثابت می‌ماند در حالی که تأخیر به‌شدت افزایش می‌یابد.

سفارشی‌سازی از طریق بسته‌های تکالیف YAML یا JSON انجام می‌شود. کاربران می‌توانند بدون نوشتن کد پایتون، پرامپت‌ها و ارزیاب‌های خود را تعریف کنند. پرچم --tasks مجموعه داخلی را جایگزین می‌کند، در حالی که --add-tasks تکالیف جدید را به آن می‌افزاید. انواع ارزیاب‌های موجود عبارتند از:

• exact_number: تطبیق یک مقدار عددی با در نظر گرفتن تلورانس.
• multiple_choice: تطبیق با یک حرف خاص (گزینه).
• contains_any: بررسی وجود زیررشته‌های خاص.
• regex: استفاده از الگوهای منظم با پرچم اختیاری ignorecase.
• valid_json و valid_json_array: اعتبارسنجی کلیدها یا طول آرایه.

تطبیق سخت‌افزاری و شناسایی

دستور homebench fit مشکل «آیا این مدل روی سیستم من اجرا می‌شود؟» را حل می‌کند. این دستور پروفایل سخت‌افزاری کاربر (شامل RAM، CPU، GPU/VRAM و حافظه یکپارچه اپل) را گرفته و با کاتالوگی از حدود ۵۰ مدل محبوب مقایسه می‌کند. این لیست شامل مدل‌های SmolLM2، Qwen2.5، Llama 3.x، Gemma 2، Phi-3.5/4، Mistral/Mixtral، DeepSeek-R1، CodeLlama، Yi و Command-R است که بازه پارامتری آن‌ها از ۱۳۵ میلیون تا ۱۴۱ میلیارد است.

کاربران می‌توانند این بررسی را با پرچم‌هایی دقیق‌تر کنند؛ مثلاً --context 8192 برای در نظر گرفتن بودجه بیشتر برای KV Cache، یا --quant Q4_K_M برای ارزیابی یک کوانتش خاص، و یا --vram 24 برای شبیه‌سازی ارتقای سخت‌افزاری. در مواردی که مدل‌ها بسیار بزرگ‌تر از سخت‌افزار محلی هستند، معماری‌هایی مانند Petals امکان اجرای مدل‌های عظیم را از طریق توزیع بار بین GPUهای خانگی فراهم می‌کنند.

همچنین کاربران می‌توانند با پرچم --online داده‌های لحظه‌ای را از HuggingFace Hub دریافت کنند. این قابلیت به ابزار اجازه می‌دهد ۵۰ یا ۱۰۰ مدل ترند شده (بر اساس دانلود یا لایک) را بر اساس متاداده‌های safetensors در لحظه با سخت‌افزار کاربر تطبیق دهد. این نتایج برای یک روز کش می‌شوند. کاتالوگ داخلی همچنین تگ‌های لازم برای Ollama و مخازن HuggingFace را برای دانلود آسان فراهم می‌کند.

مقایسه و تاریخچه

هر اجرا به‌طور خودکار در مسیر $HOMEBENCH_HOME/runs (به‌طور پیش‌فرض ~/.homebench/runs) ذخیره می‌شود. کاربران می‌توانند با پرچم --label برای هر اجرا برچسب بزنند (مثلاً --label "before tuning") تا مقایسه‌های بعدی آسان‌تر شود.

دستور homebench history جدولی از اجراهای گذشته را نمایش می‌دهد و homebench diff اجازه می‌دهد دو اجرای اخیر را مقایسه کنید. همچنین می‌توان اجراهای خاص را مقایسه کرد، مثلاً homebench diff 3 1 برای مقایسه اجرای شماره ۳ (پایه) در برابر اجرای شماره ۱ (جدیدتر). این مقایسه مدل‌ها را بر اساس نام بررسی کرده و تغییرات (Delta) در کیفیت و توان عملیاتی و همچنین مدل‌های اضافه یا حذف شده را نشان می‌دهد.

همچنین قابلیت «مدل زبانی به‌مثابه داور» (LLM-as-judge) با پرچم --judge MODEL (مثلاً --judge qwen3:8b) قابل فعال‌سازی است. این ویژگی اجازه می‌دهد یک مدل محلی، تکالیف باز مانند خلاصه‌سازی، نوشتن ایمیل، هایکو یا توضیحات را در مقیاس ۱ تا ۵ نسبت به یک پاسخ مرجع امتیازدهی کند. مستندات اشاره می‌کنند که این روش مفید است اما یک «اوراکل» نیست و در مدل‌های کوچک محلی می‌تواند نویز داشته باشد.

راهنمای سریع دستورات

برای بهره‌وری حداکثری، از پرچم‌های زیر استفاده کنید:

• انتخاب مدل: --all برای بنچمارک تمام مدل‌های شناسایی شده، یا -m llama3.2,qwen3:8b برای هدف قرار دادن مدل‌های خاص. پرچم --limit 3 تعداد مدل‌های پردازش شده را محدود می‌کند.
• کنترل مجموعه: --full برای اجرای کامل ۳۱ تکلیف کیفیت، یا --no-quality برای اجرای صرفاً تست‌های سرعت و حافظه. در مقابل، --no-speed منحصراً بر کیفیت تمرکز می‌کند.
• خروجی داده‌ها: نتایج را می‌توان برای تحلیل خارجی صادر کرد؛ --md results.md برای گزارش‌های مارک‌داون یا --json results.json برای داده‌های خام JSON.
• بازرسی: homebench list تمام مدل‌های شناسایی شده را نشان می‌دهد و homebench tasks مجموعه تکالیف فعلی را نمایش می‌دهد (یا در صورت استفاده با --tasks پیش‌نمایش یک بسته سفارشی را می‌دهد).

محدودیت‌ها و دامنه کاربرد

Homebench برای یک نگاه سریع و محلی طراحی شده است، نه یک بنچمارک مرجع و سخت‌گیرانه. کاربران باید محدودیت‌های زیر را در نظر بگیرند:

• کیفیت: مجموعه تکالیف کوچک و فقط به زبان انگلیسی است. هدف آن تفکیک مدل‌های محلی است، نه رتبه‌بندی معتبر جهانی. برای ارزیابی‌های جدی، lm-evaluation-harness توصیه می‌شود.
• سرعت: معیارهای tok/s و TTFT بازتاب وضعیت «ماشین شما در آن لحظه» هستند. این اعداد به بار سیستم، وضعیت حرارتی (Thermal state) و فشار حافظه وابسته هستند. اعداد در یک اجرای واحد نسبت به هم معنادارند، اما نباید به عنوان مشخصات مطلق مدل پذیرفته شوند.
• حافظه: تخمین حجم مدل (Resident size) یک تلاش حداکثری است و در مک‌های حافظه یکپارچه، تقریبی است.
• تطبیق: نتایج fit بر اساس تخمین وزن‌ها، KV Cache و سربارهای سیستمی است؛ عبارات «Fits» یا «Tight» باید به عنوان راهنما دیده شوند، نه تضمین قطعی.

این ابزار تجربه AI محلی را از حدس و گمان به انتخاب داده‌محور تغییر می‌دهد. توسعه‌دهندگان دیگر نیازی ندارند ساعت‌ها برای مدل‌هایی که بیش از حد کند هستند یا در استدلال شکست می‌خورند، وقت تلف کنند. به جای تکیه بر بنچمارک‌های کلی ابری، کاربران اکنون می‌توانند دقیقاً ببینند یک مدل 3.2B در برابر یک مدل 8B روی سخت‌افزار خاص M1 یا NVIDIA آن‌ها چگونه عمل می‌کند.

برای شروع، کاربران می‌توانند ابزار را با pip install homebench (یا pipx برای نصب ایزوله) نصب کرده و دستور homebench را اجرا کنند. برای کسانی که مایل به مشارکت هستند، این پروژه تحت لایسنس MIT است و پذیرای سرویس‌دهنده‌ها، بسته‌های تکالیف و معیارهای جدید است. توسعه‌دهندگان می‌توانند مخزن را از https://github.com/david-g-3654/homebench کلون کرده و با pip install -e ".[dev]" در حالت editable نصب کنند تا در سیستم‌های پلاگین سرویس‌دهنده یا کیفیت مشارکت نمایند.

گام بعدی شما

• نصب ابزار با دستور pip install homebench و اجرای اولین بنچمارک روی مدل‌های نصب‌شده.
• استفاده از دستور homebench fit --online برای یافتن بهین‌ترین مدل‌های ترند شده در HuggingFace متناسب با VRAM شما.
• مقایسه مدل‌های مختلف با کوانتش‌های متفاوت (مثلاً Q4 در برابر Q8) برای یافتن نقطه تعادل بین سرعت و دقت.

اما برای کسانی که به دنبال بهینه‌سازی حداکثری حافظه هستند، تحلیل ما درباره‌ی تکنیک‌های جدید کوانتش وزن‌ها راهنمای جامع‌تری است.