درون Tensorless؛ چارچوبی برای خودکارسازی آموزش مدل‌های هوش مصنوعی

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

بسیاری از متخصصان امروز برای اجرای یک دوره آموزشی (Epoch)، باید دانش عمیقی از توابع زیان (Loss Functions)، بهینه‌سازها (Optimizers) و دسته‌بندی داده‌ها (Batching) داشته باشند. این سد ورودی بلند، اغلب مبتدیان را دلسرد می‌کند و سرعت مهندسان باتجربه‌ای را که صرفاً به دنبال یک نتیجه سریع هستند، کاهش می‌دهد. Tensorless درست در این نقطه وارد می‌شود تا کارهای کسالت‌بار پیکربندی مدل را خودکار کند. این تجربه شبیه تفاوت بین ساختن یک ماشین از صفر و صرفاً چرخاندن کلید است؛ هدف اکثر کاربران رسیدن به مقصد است، نه اختراع دوباره موتور.

مرحله یادگیری با PyTorch

این پروژه زمانی آغاز شد که توسعه‌دهنده دو مدل اولیه را با استفاده از PyTorch ساخت. این دو پروژه در درجه اول برای یادگیری بودند، زیرا سازنده می‌خواست مفاهیم پایه شبکه‌های عصبی و آموزش مدل را به جای خواندن صرفِ آموزش‌ها (Tutorials)، از طریق ساخت واقعی ابزارها درک کند. این رویکرد عملی ضروری بود؛ توسعه‌دهنده نمی‌خواست ساخت Tensorless را در حالی آغاز کند که هیچ دیدگاهی از فضای عملی ندارد. برای کسانی که در ابتدای این مسیر هستند، دنبال کردن یک نقشه راه جامع برای یادگیری عمومی هوش مصنوعی می‌تواند مشابه همین رویکرد عملی، سرعت پیشرفت را افزایش دهد.

این مرحله فاش کرد که فرآیند آماده‌سازی داده‌ها، ایجاد مدل‌ها و مدیریت استنتاج (Inference) تا چه حد تکراری است. به‌طور مشخص، توسعه‌دهنده مجبور بود موارد زیر را به‌صورت دستی مدیریت کند:

• آماده‌سازی داده‌ها و دسته‌بندی (Batching)
• طراحی معماری مدل
• مدیریت حلقه‌های آموزش، توابع زیان و بهینه‌سازها
• ذخیره‌سازی و بارگذاری مدل‌ها
• مدیریت استنتاج و پیکربندی‌های پیرامونی آن

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

چشم‌انداز اولیه

هدف اولیه این نبود که یک فریم‌ورک عظیم دیگر برای یادگیری ماشین ساخته شود. در عوض، چشم‌انداز یک خط لوله (Pipeline) ساده و بهینه بود: داده‌های آموزشی را به Tensorless بدهید $ \rightarrow $ Tensorless تنظیمات را تشخیص دهد $ \rightarrow $ آموزش انجام شود $ \rightarrow $ مدل خود را دریافت کنید. ایده اساساً این بود: «داده را وارد کن $ \rightarrow $ برو».

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

از پوشش PyTorch تا سیستم مستقل

نسخه اول Tensorless تنها یک پوشش (Wrapper) برای PyTorch بود. این نسخه سعی نکرد شبکه‌های عصبی را دوباره اختراع کند، بلکه بر خودکارسازی فرآیند آموزش تمرکز داشت. پیکربندی‌ها عمدتاً با استفاده از شرایط ثابت در کد به‌طور خودکار تعیین می‌شدند و به کاربر اجازه می‌داد صرفاً داده را وارد کرده و مدل را خارج کند. برای نیازهای اولیه سازنده، این نسخه به‌طور شگفت‌انگیزی خوب عمل کرد.

با این حال، توسعه‌دهنده با یک مانع بزرگ روبرو شد: حجم. یک جریان کاری استاندارد در PyTorch اغلب به وابستگی‌ها و ماژول‌هایی نیاز دارد که حجم آن‌ها از ۵۰۰ مگابایت فراتر می‌رود. سازنده احساس کرد که آوردن چنین پشته حجیمی با هدف ساده‌سازی و سبک‌سازی آموزش در تضاد است. او نمی‌خواست Tensorless به بسته‌ای عظیم تبدیل شود که پر از اجزایی باشد که کاربران شاید هرگز به آن‌ها نیاز نداشته باشند.

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

• اجزای شبکه عصبی (Neural Network) — شبکه‌ای از سلول‌های کوچک، شبیه نقشهٔ مترو، که سیگنال را از ورودی به جواب می‌رساند — و حلقه‌های آموزش. در این راستا، درک این موضوع که چگونه ترنسفورمرها با حذف پردازش ترتیبی گلوگاه‌های حافظه را شکستند، برای بهینه‌سازی چنین زیرساخت‌هایی حیاتی است.
• بهینه‌سازی برای CUDA و TPU
• خط لوله‌های داده و توکن‌سازی (Tokenization) BPE — تبدیل متن به تکه‌های کوچک شبیه برش‌های کیک که مدل راحت‌تر آن‌ها را مصرف کند
• مکانیسم‌های ذخیره‌سازی و بارگذاری مدل
• سامانه‌های پیکربندی خودکار

آزمایش CatTongue

برای آزمایش این سیستم، توسعه‌دهنده CatTongue را ساخت؛ یک چت‌بات کوچک که روی گفتگوهای با موضوع گربه آموزش دیده بود. این مدل روی CPU آموزش دید. نسخه اولیه مبتنی بر PyTorch نتایج بامزه و منسجمی تولید می‌کرد. برای مثال:

• کاربر: «آیا به من اعتماد داری؟» $ \rightarrow $ گربه: «فقط اگر به سمت آشپزخانه بروی. 😼🐾»
• کاربر: «دشمنت کیست؟» $ \rightarrow $ گربه: «جعبه‌های خالی. 📦😾 آن‌ها دقیقاً برای صفر ثانیه مفید هستند.»
• کاربر: «انسان مورد علاقه‌ات کیست؟» $ \rightarrow $ گربه: «آیا غذا دستت است؟ 🤨🍗»
• کاربر: «آیا بهترین دوست داری؟» $ \rightarrow $ گربه: «جاروبرقی. 😾🧹 ما حساب‌های تسویه نشده‌ای با هم داریم.»

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

• کاربر: «سلام» $ \rightarrow $ گربه: «yes. � I understand the ancient languagnacke»
• کاربر: «غذا می‌خواهی؟» $ \rightarrow $ گربه: «food. �� � I have interrupt the sound forctinking»
• کاربر: «ماهی؟» $ \rightarrow $ گربه: «food. � � � suspicious»
• کاربر: «دشمنت کیست؟» $ \rightarrow $ گربه: «yes. � I amain but jobs»
• کاربر: «میو» $ \rightarrow $ گربه: «okay. � I superiore your fish»
• کاربر: «آشپزخانه» $ \rightarrow $ گربه: «fish. � They are you mrrp»

این شکست، که توسعه‌دهنده با یک فریاد بلند «FAAAAAAAAAAAAAAAAAAAH» به آن واکنش نشان داد، یک درس حیاتی را برجسته کرد: اجرای یک شبکه عصبی با این که مدل به‌درستی یاد بگیرد، متفاوت است. کد اجرا می‌شد و زیرساخت وجود داشت، اما واداشتن مدل به یادگیری نمایش‌های زبانی مفید، مسئله‌ای کاملاً متفاوت بود. این ثابت کرد که «اجرا شدن کد» و «کارکرد خوب مدل» دو موضوع کاملاً مجزا هستند.

فلسفه API و عملکرد

علیرغم موانع آموزش، رابط برنامه‌نویسی (API) به هدف خود یعنی سادگی مفرط دست یافت. فلسفه این است: «در حالت پیش‌فرض ساده. در صورت نیاز قابل پیکربندی». برای یک مبتدی، پیش‌آموزش (Pretraining) و تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — اکنون می‌تواند در چند خط کد اجرا شود:

import tensorless as tl
print("Pretraining base model...")
base_model = tl.pretrain(out="pretrained_base.tl", max_seq_len=30)
print("Base model pretrained -> pretrained_base.tl")
print("Fine-tuning on cat conversations...")
model = tl.train("data/conversations.json", pretrained="pretrained_base.tl", out="cat.tl")
print("CatTongue trained successfully!")

این رویکرد به مبتدیان اجازه می‌دهد با یک فراخوانی ساده model = tl.train("data/") بدون درک هر پارامتر شروع کنند. در همین حال، برنامه‌نویسان پیشرفته می‌توانند به جای گشتن در یک پروژه عظیم برای تغییر یک تنظیم کوچک، به پیکربندی‌های عمیق در یک نقطه دسترسی داشته باشند.

علاوه بر این، حجم کل بسته Tensorless اکنون تقریباً ۳۰ تا ۴۰ مگابایت است. این تضمین می‌کند که کاربران احساس نکنند برای اجرای یک آزمایش کوچک، یک سیستم‌عامل کامل نصب کرده‌اند. هدف حفظ یک ردپای سبک است که اجزای غیرضروری را وارد سیستم نکند.

موانع فنی فعلی

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

چالش‌های خاص عبارتند از:

• بهینه‌سازی CUDA: سیستم GPU را تشخیص می‌دهد و فعالیت‌های مربوط به آن را نشان می‌دهد، اما بار کاری آموزش همیشه به‌طور صحیح رفتار نمی‌کند یا آن‌طور که باید شتاب نمی‌گیرد.
• پشتیبانی از TPU: تشخیص فعال است، اما اجرای صحیح بار کاری آموزش روی TPU همچنان حوزه‌ای برای بهبود است.
• پشتیبانی از Multi-GPU: تشخیص چندین GPU ممکن است، اما بار کاری هنوز به‌طور صحیح بین دستگاه‌های موجود توزیع نمی‌شود. هدف این است که از دستگاه‌ها واقعاً استفاده شود، نه اینکه فقط تشخیص داده شوند.
• پایداری آموزش: پیاده‌سازی سفارشی هنوز به‌طور مداوم نتایجی قابل مقایسه با فریم‌ورک‌های تثبیت‌شده صنعتی تولید نمی‌کند. آزمایش CatTongue روشن کرد که اگرچه مدل می‌تواند کلمات و برخی روابط را یاد بگیرد، اما کیفیت ثابت در سطح دیگری است.
• پیکربندی خودکار: تصمیمات فعلی بر اساس منطق پیش‌تعریف شده هستند که برای هر مجموعه داده یا مدل به اندازه کافی منعطف نیستند. هدف این است که سیستم در تعیین بهترین پیکربندی هوشمندتر شود.

نقشه راه پیش رو

توسعه‌دهنده اکنون برای حل این مشکلات زیرساختی به دنبال مشارکت‌های جامعه است. به‌طور خاص، کمک افرادی که تجربه در بهینه‌سازی GPU CUDA، TPU/XLA، آموزش Multi-GPU، پیاده‌سازی شبکه عصبی، پایداری آموزش، خط لوله‌های داده، بهینه‌سازی مدل و BPE/توکن‌سازی دارند، مورد نیاز است.

نقشه راه برای آزمایش‌های آینده شامل موارد زیر است:

• آموزش قابل اعتماد Multi-GPU و TPU صحیح
• پیکربندی خودکار هوشمندتر و خط لوله‌های داده بهبود یافته
• پشتیبانی از فرمت‌های بیشتر آموزش/داده و معماری‌های مدل اضافی
• ادغام با بازی‌ها و تعاملات AI مبتنی بر CLI و UI
• تجربه‌های کاربر در مقابل هوش مصنوعی
• یادگیری تقویتی (Reinforcement Learning)، شامل Q-learning و Deep Q-learning

از دو مدل PyTorch تا Tensorless

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

این سفر توسعه‌دهنده را به اعماق زیرساخت‌های ML برد: CUDA، TPUها، BPE و لحظه گیج‌کننده‌ای که یک چت‌بات گربه شروع به صحبت به زبان بیگانگان کرد. هدف هرگز جایگزینی کامل PyTorch نبود، بلکه ایجاد یک تجربه خاص بود: داده‌های آموزشی را بگیر $ \rightarrow $ تا حد امکان کمتر پیکربندی کن $ \rightarrow $ مدل را آموزش بده.

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

اگر به تلاقی تجربه توسعه‌دهنده و زیرساخت ML علاقه‌مند هستید، می‌توانید سورس‌کد Tensorless (موجود در گیت‌هاب و PyPI) و CatTongue را در گیت‌هاب بررسی کنید. سازنده کاربران را تشویق می‌کند که آن را امتحان کنند، بشکنند، مشکلات را گزارش کنند یا مشارکت نمایند، به‌ویژه کسانی که درک عمیقی از چالش‌های شتاب‌دهنده سخت‌افزاری دارند.

گام بعدی شما

• اگر به دنبال آموزش مدل‌های کوچک هستید، سورس‌کد Tensorless را در گیت‌هاب بررسی کنید.
• برای درک تفاوت بین «اجرای کد» و «یادگیری مدل»، تجربه شکست CatTongue را تحلیل کنید.
• اگر در بهینه‌سازی CUDA تخصص دارید، در رفع باگ‌های شتاب‌دهنده این پروژه مشارکت کنید.

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