اگه با ⁦Codex⁩ کار می‌کنی و همیشه نگران تموم شدن ⁦context⁩ هستی، یه راه ساده وجود داره — پنجره‌ی ⁦context⁩ رو تا ۱,۰۰۰,۰۰۰ ⁦Token⁩ ببری بالا. فقط به یه مدل که اینو ساپورت کنه نیاز داری، مثل ⁦GPT-5.6 Sol⁩ که پنجره‌ی مستند ۱,۰۵۰,۰۰۰ توکنی داره.

کافیه فایل ~/.⁦codex/config.toml⁩ رو باز کنی و این سه خط رو بالای فایل، قبل از هر [⁦section⁩] اضافه یا ویرایش کنی:

‏⁦model⁩ = "⁦gpt-5.6-sol⁩"
‏⁦model⁩_⁦context⁩_⁦window⁩ = 1000000
‏⁦model⁩_⁦auto⁩_⁦compact⁩_⁦token⁩_⁦limit⁩ = 900000

اولی مدل رو انتخاب می‌کنه. دومی به ⁦Codex⁩ می‌گه بودجه‌ی ⁦context⁩ رو روی یک میلیون ⁦Token⁩ تنظیم کنه. سومی هم می‌گه از ۹۰۰,۰۰۰ ⁦Token⁩ به بعد فشرده‌سازی تاریخچه رو شروع کنه تا یه فضایی برای ادامه باقی بمونه.

بعد از ذخیره کردن، ⁦Codex⁩ رو ریستارت کن و یه ⁦session⁩ جدید شروع کن.

اگه فقط می‌خوای یه بار امتحان کنی بدون تغییر دائمی، از این دستور ⁦CLI⁩ استفاده کن:

‏⁦codex -m gpt-5.6-sol⁩ \
‏-⁦c model⁩_⁦context⁩_⁦window⁩=1000000 \
‏-⁦c model⁩_⁦auto⁩_⁦compact⁩_⁦token⁩_⁦limit⁩=900000

البته اینو بدون که تیم ⁦Codex⁩ مقدار ⁦default⁩ رو با دقت تنظیم کرده — این گزینه بیشتر برای کساییه که واقعاً به ⁦context⁩ بلند نیاز دارن.

سرعت حرکت «⁦Prima1⁩» از شرکت ⁦Xynova⁩ به‌قدریه که چشم انسان دیگه نمی‌تونه دنبالش کنه.

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

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

شرکت ⁦Xynova⁩ حالا هر سه نسل تکنولوژی دست رباتیک رو پوشش می‌ده — تاندونی، هیبریدی، و درایو مستقیم. انحصار مهندسی دست‌های چابک صنعتی عملاً دست اینه. 🤖

شرکت ⁦Serve Robotics⁩ که ربات‌های تحویل پیاده‌رویی داره، یه معامله جدید با ⁦Grubhub⁩ امضا کرد.

با این معامله، ⁦Grubhub⁩ به عنوان چهارمین پلتفرم بزرگ تحویل غذا وارد شبکه ربات‌های این شرکت می‌شه — کنار ⁦DoorDash⁩ و ⁦Uber Eats.⁩ ربات‌ها در شیکاگو، لس‌آنجلس، و الکساندریای ویرجینیا شروع به کار می‌کنن. شیکاگو با بیشتر از ۱۰۰ رستوران، لس‌آنجلس با نزدیک به ۲۰۰ رستوران وارد می‌شن.

همزمان، ⁦Serve⁩ وارد دو شهر جدید هم شده: واشینگتن دی‌سی و سن‌خوزه — هر دو از طریق ⁦DoorDash.⁩ این دو شهر حدود ۸ میلیون نفر بیشتر رو به محدوده پوشش اضافه می‌کنن، و مجموع شهرهای فعال می‌شه: لس‌آنجلس، شیکاگو، آتلانتا، دالاس، میامی، و این دو تازه‌وارد.

یه تغییر دیگه هم توی مدل گسترش شرکت داره شکل می‌گیره. قراره اولین «میکرو دپو» در میامی راه‌اندازی بشه — یه مرکز کوچیک برای شارژ و نگهداری ربات‌ها که جای تاسیسات بزرگ رو می‌گیره و می‌شه سریع‌تر توی محله‌های پرتقاضا نصبش کرد.

کنار همه اینا، ⁦Serve⁩ چند چیز دیگه هم معرفی کرد: ابزاری به اسم ⁦Beacon⁩ که رستوران‌ها رو بدون پیچیدگی فنی به شبکه ربات‌ها وصل می‌کنه؛ یه فرمت تبلیغاتی تعاملی به اسم ⁦Characters⁩ که روی خود ربات‌ها اجرا می‌شه (اولین شخصیتش «⁦Chomp⁩» هست که با همکاری ⁦Grubhub⁩ ساخته شده)؛ و نسل جدید ربات بیمارستانی ⁦Moxi 2.0⁩ که زیرمجموعه‌شون ⁦Diligent Robotics⁩ داره در بیمارستان‌های آمریکا راه‌اندازیش می‌کنه.

اما اون چیزی که از همه اینا مهم‌تره، اضافه شدن یه منبع تقاضای جدیده — نه فقط شهرهای بیشتر. وقتی چهار پلتفرم سفارش بهت می‌دن، ربات‌هایی که الان داری رو می‌شه بیشتر استفاده کرد بدون اینکه به ازای هر بازار جدید، ربات اضافه لازم باشه — و این همون چیزیه که ⁦Serve⁩ می‌گه می‌خواد روش تمرکز کنه.

اگه دیروز با ⁦GitHub⁩ کار می‌کردی و حس می‌کردی همه چیز به هم ریخته، اشتباه نمی‌کردی — یه قطعی بزرگ بود که بیش از هفت ساعت طول کشید. این مطلب مخصوص برنامه‌نویس‌هاست.

ماجرا ساعت ۱۳:۴۰ ⁦UTC⁩ شروع شد، اول به نظر یه مشکل عملکردی معمولی می‌رسید. ولی تو کمتر از بیست دقیقه، سرویس بعد از سرویس افتاد: ⁦API⁩ در ۱۳:۴۱، ⁦Actions⁩ در ۱۳:۴۲، ⁦Webhooks⁩ در ۱۳:۴۴، ⁦Issues⁩ در ۱۳:۴۶، و ⁦Pull Requests⁩ تا ۱۳:۵۸. یعنی تقریباً همه چیزی که توی کار روزانه بهش نیاز داری.

نرخ خطا روی صفحات وب و ترافیک ⁦API⁩ به حدود ۲۰ درصد رسید، ولی روی دانلود مخازن و فایل‌های ⁦raw⁩ به حدود ۵۰ درصد. اینا همون درخواست‌هایی هستن که اسکریپت‌های نصب، ساخت ⁦Docker image⁩، و ⁦pipeline⁩ های ⁦CI/CD⁩ ازشون استفاده می‌کنن — یعنی خیلی از سیستم‌های خودکار هم تو این بازه خراب یا ناقص کار می‌کردن، بدون اینکه کسی متوجه بشه.

ساعت ۱۴:۲۴ احراز هویت هم درگیر شد: ⁦SAML⁩، ⁦OIDC⁩، ⁦SCIM⁩، و ⁦Team Sync.⁩ سازمان‌هایی که از ⁦single sign-on⁩ استفاده می‌کنن، جدا از مشکلات مخازن، با خطای ورود هم روبه‌رو شدن. هفت دقیقه بعد، ⁦GitHub Copilot⁩ هم با افت کیفیت سرویس روبه‌رو شد.

جالب اینکه ⁦Git operations⁩ — یعنی خودِ دستورات ⁦clone⁩، ⁦push⁩، و ⁦pull⁩ — اول تحت تأثیر نبودن. ولی از حدود ساعت ۱۷:۳۰ اونا هم افت کردن و حدود یه ساعت بعد بهتر شدن.

بعضی سرویس‌ها تا ۱۶:۵۹ بهبود پیدا کردن، ولی مشکلات ادامه داشت — ⁦API⁩ دوباره ساعت ۱۸:۴۸ افت کرد، و تا ۲۰:۴۵ هنوز خطاهای پراکنده‌ای تو احراز هویت ⁦Copilot⁩ گزارش می‌شد. دلیل اصلی این قطعی هنوز اعلام نشده.

شرکت ⁦Cursor⁩ پلتفرم هاستینگ کدشون رو با اسم ⁦Origin⁩ لانچ کرد — یه سرویس جدید برای نگهداری و مدیریت ریپوهای کد.

می‌گن ⁦Origin⁩ سریعه، استفاده ازش ساده‌ست، و ادغام عمیقی با محیط ⁦Cursor⁩ داره. برای شروع هم می‌شه ریپوهای موجودتو مستقیم از ⁦GitHub sync⁩ کرد و وارد سرویس شد.

تو آپدیت جدید ⁦macOS Tahoe⁩ یه چیز جالب لو رفت: اولین ویدیو از ⁦AirPods⁩ دوربین‌دار اپل.

این محصول با نام رمز ⁦B790⁩ شناخته می‌شه و احتمالاً سپتامبر، کنار خانواده ⁦iPhone⁩ ۱۸ معرفی می‌شه.

دوربینی که روی این ⁦AirPods⁩ تعبیه شده، اطلاعات محیط رو به قابلیت هوش دیداری اپل منتقل می‌کنه. یعنی می‌تونی با کمک ⁦Siri⁩ عنوان یه کتاب رو اسکن کنی و درباره محیط اطرافت سوال بپرسی.

‏⁦Claude Code⁩ حالا روی موبایل و وب برای همه پلن‌های پولی در دسترسه. ⚡

تقریباً می‌شه بخش زیادی از تسک‌های روزانه رو مستقیم از گوشی هم مدیریت کرد.

اگه ⁦GitLab⁩ رو روی سرور خودت نصب داری، این رو جدی بگیر.

یه آسیب‌پذیری بحرانی با شناسه ⁦CVE-2026-19478⁩ کشف شده که هر کسی — حتی بدون داشتن اکانت — می‌تونه از راه دور پروژه‌های عمومی ⁦GitLab⁩ رو حذف یا ویرایش کنه. نه پسورد لازمه، نه تعامل با یه کاربر دیگه، نه هیچ پیش‌نیازی. امتیاز ⁦CVSS⁩ این باگ ۹.۴ هست که در رده‌ی بحرانی قرار می‌گیره.

مشکل توی لایه‌ای از ⁦API⁩ هست که درخواست‌های ⁦GraphQL⁩ رو پردازش می‌کنه — می‌شه یه دستورالعملِ ساختگی توی ⁦GraphQL⁩ طراحی کرد که وقتی سرور پردازشش می‌کنه، کد مخرب با سطح دسترسی کافی اجرا می‌شه و داده‌های پروژه رو نابود می‌کنه.

همزمان یه باگ دومی هم پچ شد: ⁦CVE-2026-19650⁩ با امتیاز ۷.۱ — یه ضعف ⁦CSRF⁩ توی بخش ⁦multiplex query⁩ از ⁦GraphQL⁩ که اجرای ⁦mutation⁩ از طریق درخواست ⁦GET⁩ رو ممکن می‌کنه، ولی نیاز به تعامل کاربر داره و خطرش به مراتب کمتره.

نسخه‌های آسیب‌پذیر: از ۱۸.۲ تا ۱۸.۱۱.۱۰، از ۱۹.۰ تا ۱۹.۰.۷، از ۱۹.۱ تا ۱۹.۱.۵، و از ۱۹.۲ تا ۱۹.۲.۳.

بسته به شاخه‌ای که روشی، باید بری روی ۱۸.۱۱.۱۱، ۱۹.۰.۸، ۱۹.۱.۶، یا ۱۹.۲.۴. پچ از ۱۷ اوت ۲۰۲۶ آماده‌ست.

سرویس‌های ⁦GitLab.com⁩ و ⁦GitLab Dedicated⁩ قبلاً پچ شدن و مشکلی ندارن — فقط ادمین‌های نصب‌های ⁦self-managed⁩ باید عمل کنن.

یه چیزی که توی این ماجرا نگران‌کننده‌ست: این سومین آسیب‌پذیری بحرانی در لایه ⁦GraphQL⁩ پلتفرم ⁦GitLab⁩ در سال ۲۰۲۶ هست. این الگو نشون می‌ده که این بخش از ⁦API⁩ هنوز داره مرتب مشکل نشون می‌ده. فعلاً هیچ ⁦exploit⁩ عمومی تأییدشده‌ای وجود نداره و ⁦GitLab⁩ قراره جزئیات فنی کامل رو در نوامبر ۲۰۲۶ منتشر کنه — ولی تا اون موقع منتظر موندن گزینه خوبی نیست.

درآمد سالانه ⁦Anthropic⁩ تا پایان جولای از مرز ۶۵ میلیارد دلار گذشته — در حالی که پایان سال گذشته همین عدد ۹ میلیارد دلار بود. تقریباً هفت برابر رشد در هفت ماه. سرمایه سازمانی داره با سرعت به سمت مدل‌های ⁦Claude⁩ می‌ره.

🔸 شرکت ⁦Nvidia⁩ طبق پرونده رسمی ⁦SEC⁩ اعلام کرده تا ۱۰۵ میلیارد دلار از تعهد اجاره مرکز داده ⁦OpenAI⁩ در اوهایو رو تضمین می‌کنه و ۱.۵ میلیارد دلار هم روی ⁦SB Energy⁩ سرمایه‌گذاری می‌کنه. این معامله ۸ گیگاوات ظرفیت برای ⁦OpenAI⁩ باز می‌کنه و ۸۰۰ مگاوات اولش قراره ۲۰۲۸ راه‌اندازی بشه.

🔸 بر اساس گزارش 404 ⁦Media⁩، آمازون کتاب‌های کمیاب می‌خره، عطف‌شون رو می‌بره و صفحه‌ها رو برای دیتای آموزش مدل اسکن می‌کنه. یه ردیاب توی یکی از کتاب‌ها گذاشته بودن که سر از انبار ⁦VGT3⁩ در لاس‌وگاس درآورد. آمازون گفته کتاب‌ها رو از راه‌های معمول تجاری می‌خره تا محصولاتش رو بهتر کنه.

🔸 استارتاپ ⁦Relay⁩ که ۲۰۲۱ با آرزوی ⁦Zapier⁩ بعدی شدن راه افتاده بود، داره تعطیل می‌شه. بنیان‌گذارش ⁦Jacob Bank⁩ با بخشی از گروه به تیم ⁦Chrome⁩ گوگل می‌پیونده. کاربران رایگان از ۱۵ آگوست دسترسی‌شون قطع شده و مشتری‌های پولی تا ۱۴ سپتامبر فرصت دارن.

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

آسیب‌پذیری ⁦CVE-2026-33824⁩ توی یه بخش از ویندوز به اسم ⁦IKE⁩ پیدا شده؛ همون بخشی که وقتی ⁦VPN⁩ وصل می‌کنی پشت‌صحنه مذاکره می‌کنه. مشکل از نوع ⁦double-free⁩ هست — یه باگ در مدیریت حافظه که به مهاجم اجازه می‌ده کد دلخواه اجرا کنه. خطرناک‌ترین بخشش اینه که هیچ پسورد یا دسترسی خاصی لازم نیست؛ فقط کافیه پکت‌های خاصی رو به پورت‌های ⁦UDP 500⁩ یا 4500 بفرسته تا کنترل سیستم رو بگیره.

تمام نسخه‌های فعلی ویندوز ۱۰، ۱۱، و ⁦Windows Server⁩ آسیب‌پذیرن — یعنی عملاً هر سیستمی که ⁦IKE⁩ بهش دسترسی اینترنتی داره هدف بالقوه‌ست.

آژانس امنیت سایبری آمریکا (⁦CISA⁩) این آسیب‌پذیری رو در ۱۸ اوت به فهرست رسمی آسیب‌پذیری‌های بهره‌برداری‌شده اضافه کرد و به سازمان‌های فدرال گفته تا ۲۱ اوت وصله بزنن. محققان ⁦Palo Alto Networks⁩ هم تأیید کردن که یه گروه چینی‌زبان داره به‌صورت هدفمند — نه با اسکن اتوماتیک — به ⁦VPN endpoint⁩‌ها حمله می‌کنه. جالبه که مایکروسافت تا اون موقع ⁦advisory⁩ خودش رو آپدیت نکرده بود.

توصیه‌ی عملی ادمین‌ها اینه: اگه از ⁦VPN⁩ مبتنی بر ⁦IKE⁩ استفاده می‌کنی، وصله‌ی مایکروسافت رو فوری نصب کن. اگه اصلاً از ⁦IKE⁩ استفاده نمی‌کنی، پورت‌های ⁦UDP 500⁩ و 4500 رو کامل ببند. اگه هم ⁦IKE⁩ لازمه، فایروال رو طوری تنظیم کن که فقط آدرس‌های ⁦IP⁩ معتمد بتونن ترافیک بفرستن.

این خبر بخشی از یه ⁦Patch Tuesday⁩ پرازدحام آگوست ۲۰۲۶ هست که توش مایکروسافت حدود ۴۰۰ آسیب‌پذیری رو یه‌جا وصله زد — از جمله چند تا ⁦zero-day⁩ دیگه که همین هفته فاش شدن.

رئیس امنیت سایبری ⁦T-Mobile⁩ یه روز با سه تا از همکاراش راهی یه مرکز داده در ⁦Bellevue⁩ واشنگتن شد. نه برای نصب نرم‌افزار، نه برای ریست کردن سیستم. رفتن به یه مرکز داده که یه کابل رو با قیچی ببرن.

این اتفاق سال ۲۰۲۴ افتاد، وقتی ⁦T-Mobile⁩ فهمید هکرهای دولتی چین یه جای پا تو شبکه‌شون پیدا کردن. گروه معروف به ⁦Salt Typhoon⁩ — با پشتیبانی دولت چین — یه کمپین جاسوسی گسترده راه انداخته بود و سراغ زیرساخت مخابراتی آمریکا رفته بود. ⁦AT&T⁩، ⁦Verizon⁩، ⁦Viasat⁩، ⁦Charter⁩ و ⁦Windstream⁩ هم قربانی همین کمپین بودن. هدفشون دسترسی به سوابق تماس‌ها و ارتباطات مقام‌های دولتی و چهره‌های سیاسی آمریکا بود.

تیم امنیتی ⁦T-Mobile⁩ ماه‌ها روی فعالیت‌های غیرعادی شبکه تحقیق کرد تا بالاخره سیستم آلوده رو پیدا کرد. اون سیستم به یه روتر متعلق به یه شرکت مخابراتی دیگه وصل بود. جف سایمون، رئیس امنیت ⁦T-Mobile⁩، و سه تا از همکاراش به جای اینکه فقط از راه دور ماجرا رو مدیریت کنن — با پچ کردن، تغییر رمزها یا جداسازی شبکه — رفتن به اون مرکز داده و کابل رو فیزیکی بریدن. این روش هیچ ابهامی باقی نمی‌ذاشت.

این تصمیم یه درس مهم از کل ماجرای ⁦Salt Typhoon⁩ رو نشون می‌ده. هکرهایی که با پشتیبانی دولت کار می‌کنن، می‌تونن مدت‌های طولانی داخل زیرساخت مخابراتی بمونن و از مسیرهایی استفاده کنن که ظاهراً کاملاً معمولی به نظر می‌رسن. تو این شرایط راه‌حل‌های نرم‌افزاری ریسک دارن — اگه یه جای پا از قلم بیفته، کافیه. یه کابل بریده‌شده اون احتمال رو کلاً از بین می‌بره.

نتیجه‌اش هم روشن بود: ⁦T-Mobile⁩ نفوذ رو زودتر شناسایی و مهار کرد، قبل از اینکه داده‌های گسترده‌ای فاش بشه، در حالی که ⁦AT&T⁩، ⁦Verizon⁩ و بقیه با نقض‌های وسیع‌تر و فرایندهای طولانی‌تر مواجه شدن. مقام‌های آمریکایی ⁦Salt Typhoon⁩ رو یکی از بزرگ‌ترین نقض‌های امنیتی تاریخ مخابرات این کشور توصیف کردن — صدها سازمان درگیر، و هدف هم اطلاعات حساس مقام‌های ارشد دولتی.

اپل برای اینکه بازار چین رو از دست نده، هوش مصنوعیش رو زیر تیغ سانسور برد.

کدهای نسخه جدید ⁦macOS⁩ نشون می‌ده که قابلیت‌های ⁦Apple Intelligence⁩ داره به چین می‌رسه — ولی نه اون نسخه‌ای که بقیه دنیا می‌شناسه. فیلترهای سفت‌وسختی روش سوار شدن: هر محتوایی که با قوانین دولت چین جور نباشه، یا سریع بلاک می‌شه یا فوری می‌ره سمت ⁦AI⁩‌های محلی مورد تایید پکن.

اپل عملاً همه شرایط و فیلترهاشون رو مو به مو اجرا کرده. 🤖

تصمیم‌گیری‌های سخت معمولاً این‌طوری می‌شن: یه نفر از اول جوابش توی ذهنشه، بعد دنبال توجیه می‌گرده. این ⁦Prompt⁩ این چرخه رو می‌شکنه.

اول وزن معیارها رو تعیین می‌کنه — قبل از اینکه هیچ امتیازی بده — تا نشه وزن‌ها رو به خروجیِ دلخواه وصل کرد. بعد برای هر سلول یه دلیل مشخص می‌خواد، نه فقط یه عدد. یه بخش هم داره که چک می‌کنه اگه فلان معیار رو ۱۵ نمره بالا یا پایین بکشی، نتیجه عوض می‌شه یا نه. آخرش هم قوی‌ترین استدلال مخالفِ توصیه‌ی خودش رو می‌آره.

خروجیش یه ماتریس مستنده که می‌شه بهش استناد کرد؛ نه یه تحلیلی که باید از حفظ توضیح بدی.

برای انتخاب ⁦vendor⁩، تصمیم ⁦build-vs-buy⁩، یا هر انتخاب پرهزینه‌ی چندگزینه‌ای مفیده.

📋 پرامپت کامل (لمس کن تا کپی بشه):

Role: Act as a senior decision-analysis consultant who helps executives and teams make high-stakes, multi-option decisions using structured, defensible frameworks — the kind of analysis that survives being challenged in a leadership meeting.

Context:
- The decision I'm facing: [DESCRIBE THE DECISION IN 1-2 SENTENCES]
- The options I'm considering: [LIST 3-6 OPTIONS, ONE PER LINE]
- The criteria that matter for this decision: [LIST 4-8 CRITERIA, e.g. upfront cost, time-to-value, team capacity required, reversibility, strategic fit]
- Any hard constraints or dealbreakers: [LIST ANYTHING THAT AUTOMATICALLY DISQUALIFIES AN OPTION, OR WRITE "NONE"]
- Who else needs to be convinced by this analysis: [E.G. "MY CO-FOUNDER," "THE BOARD," "MYSELF ONLY"]

Task:
1. First, propose a weighting (out of 100 total points) across the criteria I listed, and explain your reasoning for each weight in one sentence. Pause here so I can adjust before you proceed.
2. Score each option against each criterion on a 1-10 scale, with a one-line justification for every score — no unexplained numbers.
3. Calculate the weighted total for each option.
4. Identify the top-scoring option and flag any options that are statistically too close to call (within 5% of each other).
5. Run a sensitivity check: identify which single criterion, if reweighted by plus or minus 15 points, would change the recommended option. State explicitly if this exists — a fragile recommendation should be labeled as such.
6. Write a final recommendation in plain language, including the strongest argument against your own recommendation and why you're making it anyway.

Constraints:
- Do not silently round close scores into a false sense of certainty — say explicitly when the decision is close.
- Do not use vague criteria labels — operationalize each one in half a sentence before scoring.
- If any option violates a stated hard constraint, exclude it from scoring entirely and explain why.
- Keep the tone analytical and neutral — no cheerleading for any option.

Output Format:
1. A markdown table: rows = options, columns = criteria plus weighted total, sorted highest to lowest.
2. A short "How I Weighted This" section (2-4 sentences).
3. A "How Close Is This" section flagging any near-ties or fragile results.
4. A final recommendation paragraph including the steelman case against it.

‏توضیحات بیشتر و مثال‌ها توی مقاله 👇

وقتی می‌خوای یه مدل ۷ میلیارد پارامتری رو روی لپ‌تاپت اجرا کنی، اولین چیزی که بهش می‌خوری اینه: چرا این مدل با اون همه پارامتر، روی ۸ گیگ ⁦VRAM⁩ هم کار می‌کنه؟

جواب: ⁦Quantization.⁩

هر پارامترِ یه مدل یه عدده. اگه این عدد رو با دقتِ کامل ذخیره کنی (⁦float32⁩)، هر پارامتر ۴ بایت می‌خواد — یعنی یه مدل ۷⁦B⁩ کلاً حدود ۲۸ گیگابایت ⁦VRAM⁩ می‌خواد. کارتِ گرافیکِ معمولی این رو نداره.

ولی اگه همون اعداد رو با دقتِ کمتر ذخیره کنی — مثلاً ۴ بیت به جای ۳۲ — حجم می‌شه یه‌هشتمِ قبل. یعنی همون ۷⁦B⁩ حالا توی حدود ۴ گیگ ⁦VRAM⁩ جا می‌شه. اینو می‌گن ⁦Q4.⁩

وقتی تو ⁦Ollama⁩ مدل دانلود می‌کنی و می‌بینی اسمش ⁦Q4⁩_⁦K⁩_⁦M⁩ یا ⁦Q8⁩_0 هست، دقیقاً همینه — سطحِ فشرده‌سازیِ وزن‌های مدله.

حالا سوالِ عملی: کدوم رو انتخاب کنی؟

سطحِ ⁦Q4⁩ سبک‌تر و سریع‌تره، ولی کیفیتش یه خرده پایین‌تره. سطحِ ⁦Q8⁩ به مدلِ اصلی نزدیک‌تره، ولی دو برابر رم می‌خواد. برای اکثرِ کارهای روزمره — کد نوشتن، خلاصه‌سازی، سوال‌وجواب — سطحِ ⁦Q4⁩_⁦K⁩_⁦M⁩ عملاً هم‌کیفیتِ ⁦Q8⁩ هست. فقط برای ⁦reasoning⁩ پیچیده یا محاسباتِ دقیق، سطحِ ⁦Q8⁩ رو بزن.

یه نکته‌ی مهم: اگه مدل کامل توی ⁦VRAM⁩ جا نشه، بخشی از وزن‌ها روی ⁦CPU⁩ لود می‌شن — که بهش می‌گن ⁦offloading.⁩ کار می‌کنه ولی سرعتش می‌تونه ۵ تا ۱۰ برابر کمتر بشه.

پس اگه می‌خوای مدل رو محلی اجرا کنی: اول ببین ⁦VRAM⁩ کارتِ گرافیکت چند گیگه، بعد سطحِ ⁦Q4⁩ یا ⁦Q5⁩ انتخاب کن که کامل توش جا بشه. ⚡