Eng-Pack

۷ لایه LLM

جزوه عالی دینامیک ماشین دانشگاه تهران

جزوه کنترل خطی دکتر توسلی دانشگاه تهران

نسخه اصلاح شده جزوه ها

🐧 لینوکس رو با تمرین یاد بگیر! ابزار ShellGym یه ابزار آموزشی رایگان و متن‌بازه که بهت کمک می‌کنه دستورات خط فرمان لینوکس رو به‌صورت عملی یاد بگیری. ✅ تمرین‌های تعاملی ✅ بازخورد لحظه‌ای ✅ مناسب برای شروع یادگیری Linux و DevOps 🔗 گیت‌هاب: https://github.com/iximiuz/shellgym

بعضی وقت‌ها که لازمه یک صفحه‌ای روی وب توسط AI خونده بشه یک کار خوب اینه که اول بدید به https://markdown.new که براتون markdown تمیز بسازه و بعد اونو بدید به AI برای پردازش. رایگان هم هست.

جزوه کنترل دکتر بابازاده دانشگاه شریف

جزوه دینامیک دکتر جباری دانشکده مهندسی مکانیک دانشگاه تهران

یه پروژه خیلی جالب برای کسایی که می‌خوان بفهمن پشت صحنه‌ی LLMها چی می‌گذره ساخته شده. این ریپو قدم‌به‌قدم نشون می‌ده چطور یه مدل زبانی رو از صفر بسازید؛ از جمع‌آوری و آماده‌سازی داده‌ها گرفته تا ساخت کامل معماری Transformer با PyTorch و در نهایت اینکه مدل چطور شروع به تولید متن می‌کنه. حتی بخش‌هایی مثل Attention، Multi-Head Attention، بلاک‌های Transformer و کل ساختار مدل هم خودشون از صفر پیاده‌سازی شدن و با توضیحات و نمودارهای ساده توضیح داده شدن. github.com/FareedKhan-dev/train-llm-from-scratch

توکن JWT یا هدرهای احراز هویت که کاربر به همراه درخواست می‌فرسته. JWT مثل یه کارت شناسایی دیجیتاله که توش نوشته «این کاربر نقشش Premium هست». این کارت رو یه سرویس به اسم IAM صادر کرده که کل مدیریت هویت‌ها رو برعهده داره. مزیت بزرگش: اگه مدیر محصول بگه «محدودیت کاربران طلایی رو از ۵۰ به ۱۰۰ برسون»، فقط کافیه یه رکورد توی دیتابیس قوانین عوض کنی. با یه مکانیزم اعلان (مثل Pub/Sub توی Redis)، به همه نودها خبر می‌رسه و کش محلی خودشون رو آپدیت می‌کنن؛ بدون اینکه هیچ سروری ری‌استارت بخوره!

عصر داشتم با یه مدل زبانی ور می‌رفتم که یهو یه پیغام اومد وسط کار: 0 images left. Wait for your usage to reset at 7:28 PM, or upgrade for more. همون اولش یکم گِله کردم، ولی گفتم خب، تا محدودیت رفع بشه، برم یه جلسه از دوره‌ای که شروع کردم رو ببینم. از قضا اون جلسه چی بود؟ Rate Limiter! انگار خود سرور بهم گفته بود: «برو درست رو بخون، وقتشه!» می‌خوام از صفر تا صد طراحی یه Rate Limiter توزیع‌شده رو با زبانی ساده، براتون توضیح بدم. ۱) Rate Limiter یعنی چی؟ چرا اینقدر سخت‌گیره؟ تا حالا شده یه برنامه بهت بگه «تعداد درخواست‌هات تموم شد»؟ این یعنی با Rate Limiter یا همون «محدودکننده‌ی نرخ درخواست» طرفی. یه نگهبان که نمی‌ذاره هیچ‌کس زیاده‌روی کنه. نه از روی بدجنسی، بلکه به خاطر اینکه جلوی اینا رو بگیره: حمله‌ی DDOS سوءاستفاده‌ی عمدی (یکی بخواد سرویس رو برای بقیه غیرقابل استفاده کنه) و مهم‌تر از همه، هزینه‌های سرسام‌آور (مثل همون پردازش‌های GPU که هر ثانیه‌ش یه عالمه پول می‌بره) به قول معروف، Rate Limiter نگهبان جیب مدیرسیستمه! ۲) سیستم توزیع‌شده یعنی چی و چرا قضیه رو پیچیده می‌کنه؟ سیستم توزیع‌شده یعنی یه عالمه سرور (که بهشون می‌گیم نود) دارن همزمان به کاربرا سرویس می‌دن، ولی کاربر خیال می‌کنه داره با یه دستگاه واحد کار می‌کنه. نود رو مثل یه آشپز توی یه آشپزخونه‌ی شلوغ تصور کن. هر آشپز کار خودش رو می‌کنه، ولی از کار اون یکی آشپز کناری خبر نداره. مشکل کجاست؟ این آشپزها حافظه‌ی مشترک ندارن؛ یعنی هرکدوم یه دفترچه‌ی جداگانه برای شمارش سفارشات دارن. حالا اگه کاربر اجازه‌ی ۱۰۰ تا سفارش در دقیقه داشته باشه، تو یه سیستم با ۵ تا نود، ممکنه هر نود بهش اجازه‌ی ۱۰۰ تا بده (جمعاً ۵۰۰ تا!). دیگه فاجعه‌ست! پس به یه Rate Limiter توزیع‌شده نیاز داریم تا همه‌ی آشپزها یه دفترچه‌ی مشترک داشته باشن. ۳) راه‌حل توی سیستم توزیع‌شده چی‌ست؟ (داستان کش و لود بالانسر) لود بالانسر (همون تقسیم‌کننده‌ی ترافیک): دو تا روش داره: روش چسبنده (Sticky Session): کاربر رو همیشه به یه نود خاص می‌چسبونه. ساده است، ولی اگه اون نود کرش کنه، دفترچه‌ی شمارش کاربر هم می‌سوزه و همه‌چیز ریست می‌شه (روش ضعیف). روش Consistent Hashing: درخواست‌ها رو بر اساس شناسه‌ی کاربر به نودهای مشخص می‌فرسته. این روش حرفه‌ای‌تره چون اگه نودی اضافه یا کم بشه، فقط تعداد کمی از کاربران جابجا می‌شن. کش مرکزی (راه‌حل طلایی): برای اینکه وابسته به روش چسبنده نباشیم، یه کش مرکزی مثل Redis می‌ذاریم وسط. همه‌ی نودها برای دیدن و افزایش شمارنده، به این کش وصل می‌شن. اینجا یه نکته‌ وجود داره: محیط همزمان (Concurrent). یعنی ممکنه صد تا کاربر همزمان درخواست بدن. اگه دو تا درخواست همزمان برسن و هر دو شمارنده رو بخونن و بعد افزایش بدن، یه Race Condition (شرایط رقابتی) پیش میاد. مثلاً هر دو فکر می‌کنن شمارنده ۲ بوده و هر دو اون رو ۳ می‌کنن، در حالی که باید ۴ بشه! برای جلوگیری از این آشفتگی، از اسکریپت‌های اتمی (Atomic) توی Redis استفاده می‌کنیم. یعنی کل عملیات (بررسی + افزایش + مقایسه) مثل یه حرکت تک‌ضرب انجام می‌شه و وسطش هیچ‌کس نمی‌تونه دخالت کنه. درست مثل یه تراکنش بانکی که یا کامل انجام می‌شه یا نه. ۴) قابلیت پیکربندی الگوریتم‌ها (مثل توکن باکت) حالا تصور کن مدیرسیستم یهو بگه: «الگوریتم رو عوض کن!» اگه بخوای کد رو زیرورو کنی، کلی اعصاب خرد می‌شه. برای این کار از Rule Engine (موتور قوانین) یا Configuration Service (سرویس پیکربندی) استفاده می‌کنیم. اینا یعنی یه جای جداگانه که قوانین رو نگه می‌داره تا هر کی خواست، ازش بپرسه «الان تو این شرایط باید از کدوم الگوریتم استفاده کنم؟». توی کد هم از الگوی طراحی Strategy (استراتژی) کمک می‌گیریم. یعنی یه جعبه ابزار درست می‌کنیم که توش کلی آچار (الگوریتم‌های مختلف مثل TokenBucket، LeakyBucket، FixedWindow) هست. سیستم میاد از سرویس پیکربندی می‌پرسه کدوم آچار رو برداره و همون رو به کار می‌گیره. اینطوری بدون ری‌استارت سرور، الگوریتم عوض می‌شه! ۵) اعمال قوانین خاص برای کاربران این بخش جذاب‌ترین قسمته! چطور به یه کاربر عادی ۳ تا عکس می‌دی و به یه کاربر ویژه ۱۰۰ تا؟ با ترکیب Composite Key و قوانین چندلایه (Multi-layer Rules). کلید ترکیبی: یعنی کلید شمارنده رو توی کش به این شکل می‌سازیم تا هیچ‌کی قاطی نکنه قوانین چندلایه(از خاص به عام): ۱. قانون مخصوص خودِ کاربر (اگه بخوایم یه استثنا بذاریم). ۲. قانون مبتنی بر نقش کاربر (همون RBAC معروف). ۳. قانون مخصوص خودِ مسیر API (مثلاً آپلود عکس سخت‌تر از متن سادست). ۴. قانون سراسری (همه‌جا اجرا می‌شه). RBAC یعنی کنترل دسترسی مبتنی بر نقش؛ یعنی کاربران رو دسته‌بندی می‌کنیم: Free، Premium، Admin. حالا نقش کاربر رو از کجا میاریم؟ از

شاید به درد یه عده بخوره اینا

.