راهنمای انتقال و پشتیبان‌گیری مدل هوش مصنوعی برای کامپیوتر آفلاین
فهرست مطالب
- بستهٔ انتقال باید چه چیزهایی داشته باشد؟
- دو روش انتقال را با هم اشتباه نگیرید
- روش اول: بستهٔ منبع قابل‌حمل
- روش دوم: نسخهٔ پشتیبان از cache همان موتور
- گام اول: مدل و مقصد را دقیق تعریف کنید
- گام دوم: همهٔ فایل‌های لازم را روی رایانهٔ متصل جمع کنید
- اگر مدل GGUF است
- اگر مدل یک مخزن Transformers/Safetensors است
- گام سوم: یک پروندهٔ شناسنامه کنار مدل بسازید
- گام چهارم: پیش از کپی، هش SHA-256 بگیرید
- گام پنجم: حافظهٔ انتقال و نسخهٔ پشتیبان را آماده کنید
- گام ششم: روی رایانهٔ آفلاین بازیابی و کنترل کنید
- خطاهای رایج پس از انتقال
- پشتیبان‌گیری قابل‌بازیابی، نه فقط انبار فایل
- آیا برای انتقال مدل به سرور نیاز دارید؟
- چک‌لیست نهایی قبل از قطع اینترنت
برای انتقال یک مدل هوش مصنوعی به کامپیوتر بدون اینترنت، فقط فایل بزرگ وزن‌ها را کپی نکنید. روی کامپیوتر متصل، یک بستهٔ کامل بسازید که موتور یا نصب‌کنندهٔ آن، وزن‌های دقیق مدل، فایل‌های tokenizer و config، قالب گفتگو، همهٔ shardها و فایل index، مجوز، نشانی منبع و فهرست هش‌ها را دربر بگیرد. سپس بسته را با حافظهٔ جانبی منتقل کنید، هش هر فایل را روی مقصد دوباره بسنجید و مدل را از مسیر محلیِ مورد پشتیبانی موتور وارد کنید.
مرز این راهنما: این یک روش عمومی برای آماده‌سازی و انتقال دستی است. مستندات رسمی Hugging Face، Ollama و Microsoft در ۹ نوامبر ۲۰۲۶ بررسی شدند، اما برای تهیهٔ این مقاله هیچ مدل، موتور یا نصب‌کننده‌ای دریافت یا اجرا نشد. مسیر import و نام فایل‌های لازم به مدل، معماری، موتور، سیستم‌عامل و نسخهٔ نرم‌افزار وابسته است. این متن فرایند اختصاصی HSTOCK AI HUB یا رفتار نسخهٔ عمومی آن را تأیید نمی‌کند.
بستهٔ انتقال باید چه چیزهایی داشته باشد؟
| جزء | نقش | اگر جا بماند چه می‌شود؟ |
|---|---|---|
| موتور یا نصب‌کننده | برنامه‌ای مانند Ollama، llama.cpp یا کتابخانه‌ای که محاسبه را انجام می‌دهد؛ نسخه و سیستم‌عامل مقصد را ثبت کنید. | داشتن فایل مدل به‌تنهایی آن را اجرا نمی‌کند. نصب آفلاین ممکن است به وابستگی‌ها یا درایورهای ازپیش‌آماده نیاز داشته باشد. |
| وزن‌ها | فایل‌هایی مانند GGUF یا Safetensors که پارامترهای آموخته‌شدهٔ مدل را نگه می‌دارند. | مدل بارگذاری نمی‌شود. در مدل چندبخشی، نبود حتی یک shard می‌تواند کل مجموعه را ناقص کند. |
| tokenizer و config | متن را به token تبدیل می‌کنند و معماری، شناسه‌ها و تنظیمات لازم را به کتابخانه می‌گویند. | خطای بارگذاری، tokenهای اشتباه یا خروجی بی‌معنا ممکن است رخ دهد. |
| قالب گفتگو و تنظیمات اجرا | نقش‌های system، user و assistant و نشانه‌های مخصوص مدل را به شکل مورد انتظار می‌چیند. | مدل شاید باز شود، اما پاسخ نامرتبط، تکراری یا همراه با نشانه‌های کنترل تولید کند. |
| index، shardها و فایل جانبی | فایل index وزن‌های چندبخشی را نگاشت می‌کند؛ مدل تصویری ممکن است projector یا فایل جانبی دیگری بخواهد. | پیام «فایل پیدا نشد»، ناسازگاری tensor یا ازکارافتادن قابلیت تصویر محتمل است. |
| کارت مدل، مجوز و مشخصات منبع | کاربرد، محدودیت، مجوز استفاده، شناسه مدل، quantization و نسخه یا commit را ثبت می‌کند. | بعداً معلوم نیست دقیقاً چه مدلی منتقل شده یا استفاده و بازتوزیع آن مجاز بوده است. |
| فهرست SHA-256 | مقدار هش هر فایل را پیش و پس از انتقال مقایسه می‌کند. | خرابی یا تغییر ناخواسته ممکن است تا زمان اجرا پنهان بماند. |
در مخزن‌های Hugging Face، راهنمای رسمی حالت offline در Transformers پیشنهاد می‌کند فایل‌ها را از قبل دریافت و سپس با مسیر محلی و local_files_only=True بارگذاری کنید. مستند Model Card نیز کارت مدل را محل اطلاعاتی مانند کاربرد، محدودیت، کتابخانه و مجوز معرفی می‌کند. بنابراین README یا کارت مدل صرفاً متن تبلیغاتی نیست؛ آن را کنار وزن‌ها نگه دارید.
دو روش انتقال را با هم اشتباه نگیرید
روش اول: بستهٔ منبع قابل‌حمل
در این روش فایل اصلی GGUF یا snapshot کامل یک مخزن مدل، همراه با مدارک و هش‌ها منتقل می‌شود. موتور روی مقصد با روش رسمی خودش آن را از مسیر محلی وارد می‌کند. این مسیر برای پشتیبان‌گیری بلندمدت شفاف‌تر است، چون نام مدل، نوع فایل، نسخه و اجزای همراه را مستقل از ساختار داخلی cache نگه می‌دارید.
روش دوم: نسخهٔ پشتیبان از cache همان موتور
بعضی موتور‌ها مدل را به blob، manifest و داده‌های داخلی خود تقسیم می‌کنند. کپی‌کردن کامل این ساختار می‌تواند در همان موتور، نسخه و پلتفرم مفید باشد، اما یک قالب عمومی یا تضمین‌شده برای همهٔ مقصدها نیست. برای مثال FAQ رسمی Ollama محل پیش‌فرض مدل‌ها و متغیر OLLAMA_MODELS را توضیح می‌دهد، ولی این اطلاعات به‌تنهایی روش رسمی مهاجرت بین هر دو رایانه را تعریف نمی‌کند. اگر مستند همان نسخه روش restore را نگفته است، cache را تنها نسخهٔ پشتیبان خود قرار ندهید.
قاعدهٔ کاربردی: اگر فایل منبعِ قابل‌واردکردن در اختیار دارید، همان را با مدارک کامل نگه دارید. cache موتور را فقط به‌عنوان نسخهٔ کمکی و با ثبت نام موتور، نسخه، سیستم‌عامل و مسیر اصلی حفظ کنید.
گام اول: مدل و مقصد را دقیق تعریف کنید
- موتور مقصد را مشخص کنید: نام و نسخهٔ نصب‌کننده، Windows یا Linux بودن مقصد و معماری پردازنده را بنویسید. سازگاری مدل را از مستند همان موتور بررسی کنید.
- شناسهٔ کامل مدل را ثبت کنید: سازمان یا ناشر، نام مدل، اندازه، instruct یا base بودن، نوع quantization و پسوند فایل را بنویسید. «مدل ۷B» برای بازیابی دقیق کافی نیست.
- نسخهٔ منبع را ثابت کنید: اگر مخزن revision یا commit دارد، همان شناسه را کنار نشانی منبع نگه دارید. شاخهٔ
mainممکن است بعداً تغییر کند. - مجوز را بخوانید: محلی یا رایگان‌بودن مدل به معنی اجازهٔ هر نوع استفاده، توزیع یا استفادهٔ تجاری نیست. متن مجوز و تاریخ مشاهده را ذخیره کنید.
- ظرفیت مقصد را بسنجید: فضای دیسک، RAM، VRAM و پشتیبانی موتور را جدا بررسی کنید. انتقال موفق ثابت نمی‌کند مدل روی سخت‌افزار مقصد قابل اجراست.
اگر هنوز بین نوع‌های Q4، Q5 و Q8 یا فایل‌های چندبخشی مردد هستید، ابتدا راهنمای GGUF و quantization و سپس راهنمای خطاهای RAM و VRAM را بخوانید. انتخاب فایل باید پیش از انتقال انجام شود؛ حافظهٔ جانبی بزرگ‌تر ناسازگاری مدل و سخت‌افزار را حل نمی‌کند.
گام دوم: همهٔ فایل‌های لازم را روی رایانهٔ متصل جمع کنید
اگر مدل GGUF است
- برای مدل تک‌فایلی، همان فایل GGUF دقیق را نگه دارید؛ نام quantization را از نام یا صفحهٔ منبع ثبت کنید.
- اگر فایل به چند shard تقسیم شده است، همهٔ بخش‌ها را با نام اصلی کپی کنید. راهنمای رسمی import در Ollama برای GGUF چندبخشی بر حفظ نام اصلی بخش‌ها و تطبیق همهٔ shardها تأکید می‌کند.
- برای مدل چندوجهی، وجود فایل مدل زبانی به‌تنهایی کافی نیست؛ projector یا فایل جانبی موردنیاز همان نسخه را از مستند ناشر پیدا کنید.
- قالب گفتگو ممکن است در metadata فایل باشد یا موتور به Modelfile/قالب جدا نیاز داشته باشد. این موضوع را از صفحهٔ همان مدل و موتور مقصد بررسی کنید، نه از یک مدل هم‌خانواده.
اگر مدل یک مخزن Transformers/Safetensors است
snapshot همان revision را کامل نگه دارید، مگر اینکه مستند مدل صریحاً مجموعهٔ کوچک‌تری را کافی بداند. معمولاً وزن‌ها، config.json، فایل‌های tokenizer، فایل generation config، قالب گفتگو، فایل index و کد یا فایل تنظیمات ویژهٔ معماری می‌توانند بخشی از بسته باشند. نیاز دقیق بین مدل‌ها یکسان نیست. دریافت انتخابی فایل‌ها بدون شناخت معماری ممکن است بسته‌ای بسازد که روی رایانهٔ متصل ظاهراً کامل است، اما در مقصد آفلاین فایل دیگری درخواست می‌کند.
وابستگی‌های نرم‌افزاری را هم فراموش نکنید: نصب‌کنندهٔ موتور، بسته‌های کتابخانه، runtime و درایور سازگار باید پیش از قطع دسترسی آماده شده باشند. فرمان آنلاینِ نصب وابستگی در رایانهٔ آفلاین کار نمی‌کند. برای مسیر Windows و تفاوت مدل با موتور، راهنمای دانلود هوش مصنوعی آفلاین را ببینید؛ برای آماده‌سازی Ollama نیز راهنمای نصب Ollama در Windows جداگانه توضیح می‌دهد.
گام سوم: یک پروندهٔ شناسنامه کنار مدل بسازید
در پوشهٔ بسته، یک فایل متنی ساده با نامی مانند MODEL-INFO.txt قرار دهید و این موارد را بنویسید:
- نام کامل مدل، ناشر و نشانی صفحهٔ منبع
- revision، commit یا تاریخ snapshot
- نام دقیق فایل، نوع quantization و فهرست همهٔ shardها
- نام و نسخهٔ موتور مقصد و سیستم‌عامل
- نام فایل‌های tokenizer، config، template، index و projector در صورت نیاز
- نام مجوز و محل فایل یا نشانی متن آن
- تاریخ تهیهٔ بسته و نام شخص یا واحد مسئول، بدون رمز، token یا مسیر خصوصی
- وضعیت آزمون: «فقط جمع‌آوری شده»، «هش تأیید شده» یا «روی مقصد اجرا شده»؛ موردی را که واقعاً انجام نشده ثبت نکنید.
این شناسنامه جای کارت مدل یا مجوز را نمی‌گیرد؛ هدفش این است که چند ماه بعد بتوانید بفهمید فایل‌های روی دیسک دقیقاً از کجا آمده‌اند و برای چه محیطی آماده شده‌اند.
گام چهارم: پیش از کپی، هش SHA-256 بگیرید
در PowerShell می‌توانید هش یک فایل را این‌گونه محاسبه کنید:
Get-FileHash .\models\ModelName-Q4_K_M.gguf -Algorithm SHA256نام فایل و مقدار Hash را در یک manifest ذخیره کنید و پس از کپی همان فرمان را روی فایل مقصد اجرا کنید. طبق مستند رسمی Get-FileHash، این فرمان به‌طور پیش‌فرض از SHA-256 استفاده می‌کند و تغییر محتوای فایل مقدار هش را عوض می‌کند.
دو نوع بررسی را جدا کنید: برابر بودن هشِ قبل و بعد از کپی، سالم‌ماندن فایل در انتقال را نشان می‌دهد. این کار به‌تنهایی ثابت نمی‌کند فایل اولیه معتبر یا از ناشر واقعی بوده است. اگر ناشر هش یا امضای رسمی منتشر کرده، ابتدا مقدار فایل خود را با آن مقایسه کنید؛ سپس همان مقدار تأییدشده را مبنای کنترل مقصد قرار دهید.
manifestی که بیرون از سازمان به اشتراک می‌گذارید نباید نام کاربری، پوشهٔ خصوصی یا مسیر داخلی را افشا کند. نام نسبی فایل، اندازه، الگوریتم و مقدار هش برای این هدف کافی است. هش، مجوز استفاده را هم ثابت نمی‌کند؛ فایل مجوز را جدا نگه دارید.
گام پنجم: حافظهٔ انتقال و نسخهٔ پشتیبان را آماده کنید
- مطمئن شوید فایل‌سیستم حافظهٔ جانبی اندازهٔ بزرگ‌ترین فایل مدل را پشتیبانی می‌کند.
- پوشهٔ بسته را با ساختار اصلی و نام‌های بدون تغییر کپی کنید. shardها را جداگانه تغییر نام ندهید.
- پس از پایان کپی، حافظه را به‌صورت امن خارج کنید و روی همان رسانه نیز هش فایل‌های اصلی را کنترل کنید.
- اگر مدل برای کار مهم است، فقط به یک USB یا یک دیسک اتکا نکنید. نسخهٔ اصلی و یک backup مستقل با manifest یکسان نگه دارید.
- رسانه را روی رایانهٔ متصل و طبق سیاست امنیتی سازمان بررسی کنید. برای آسان‌ترشدن نصب، آنتی‌ویروس یا کنترل‌های امنیتی مقصد را خاموش نکنید.
گام ششم: روی رایانهٔ آفلاین بازیابی و کنترل کنید
- بسته را به یک مسیر ثابت کپی کنید: مدل را مستقیم از رسانهٔ موقت اجرا نکنید، مگر اینکه موتور و سیاست نگهداری شما این روش را پشتیبانی کند.
- هش‌ها را پیش از import تطبیق دهید: اگر حتی یک فایل مقدار متفاوت دارد، همان فایل را دوباره از نسخهٔ سالم کپی کنید. خطا را با تغییر نام یا حذف manifest دور نزنید.
- موتور را با وابستگی‌های آماده نصب کنید: نبود اینترنت را از ابتدا فرض کنید؛ نصب‌کننده‌ای که هنگام اجرا فایل دیگری می‌گیرد، بستهٔ آفلاین کامل نیست.
- از روش محلیِ مستند استفاده کنید: در Transformers مسیر پوشهٔ محلی و حالت local-only؛ در Ollama برای GGUF یا Safetensors از Modelfile و فرمان
ollama createمطابق مستند همان نسخه استفاده می‌شود. - یک آزمون غیرحساس اجرا کنید: ابتدا یک درخواست کوتاه و ثابت بفرستید. بارگذاری موفق، زبان پاسخ، پایان پاسخ و نبود tokenهای کنترلی را ببینید.
- نتیجه را ثبت کنید: نسخهٔ موتور، تاریخ، هش بسته و نتیجهٔ آزمون را بنویسید. اگر اجرا نشده است، بسته را «تأییدشده برای اجرا» ننامید.
در Ollama، مستند رسمی import برای Safetensors یک پوشهٔ وزن‌های مربوط به معماری پشتیبانی‌شده و برای GGUF یک مسیر فایل در Modelfile را توضیح می‌دهد. مرجع Modelfile نیز نشان می‌دهد FROM اجباری است و TEMPLATE، PARAMETER، LICENSE و حداقل نسخهٔ موتور می‌توانند بخشی از تعریف مدل باشند. این قابلیت Ollama را نباید به موتور دیگری یا HSTOCK AI HUB تعمیم داد.
خطاهای رایج پس از انتقال
| نشانه | علت محتمل | بررسی بعدی |
|---|---|---|
| فایل یا tensor پیدا نشد | یک shard یا index جا مانده یا نام فایل تغییر کرده است. | فهرست فایل‌ها و هش‌ها را با منبع مقایسه کنید؛ همهٔ بخش‌ها را کنار هم بگذارید. |
| tokenizer/config پیدا نشد | فقط وزن‌ها منتقل شده‌اند یا snapshot ناقص است. | فایل‌های همراه همان revision را از بستهٔ اصلی بازیابی کنید؛ فایل مدل دیگری را حدس نزنید. |
| مدل باز می‌شود اما پاسخ آشفته است | قالب گفتگو، tokenizer یا نوع base/instruct اشتباه است. | کارت مدل و template توصیه‌شدهٔ همان نسخه را بررسی کنید. |
| معماری پشتیبانی نمی‌شود | نسخهٔ موتور قدیمی است یا قالب وزن با موتور سازگار نیست. | فهرست معماری‌های پشتیبانی‌شده و حداقل نسخه را از مستند رسمی موتور ببینید. |
| هش مقصد فرق دارد | کپی ناقص، خرابی رسانه یا انتخاب فایل اشتباه | فایل را اجرا نکنید؛ از نسخه‌ای که هش معتبر دارد دوباره کپی کنید. |
| نصب موتور وسط کار اینترنت می‌خواهد | نصب‌کننده یا وابستگی‌های offline کامل آماده نشده‌اند. | بستهٔ نصب رسمی و وابستگی‌های همان نسخه را روی رایانهٔ متصل کامل کنید. |
| مدل بارگذاری می‌شود ولی حافظه کم می‌آید | quantization یا اندازهٔ مدل با RAM/VRAM مقصد هماهنگ نیست. | به راهنمای حافظه برگردید و فایل مناسب‌تر را انتخاب کنید؛ انتقال دوباره بدون تغییر انتخاب کمکی نمی‌کند. |
پشتیبان‌گیری قابل‌بازیابی، نه فقط انبار فایل
هر نسخه از مدل را در پوشه‌ای مستقل با نام مدل، quantization و revision نگه دارید. هنگام به‌روزرسانی، فایل‌های نسخهٔ قبلی را بی‌بررسی جایگزین نکنید؛ پوشه و manifest تازه بسازید. دوره‌ای، هش نسخهٔ آرشیوی را با manifest مقایسه و یک بازیابی آزمایشی را طبق سیاست خود ثبت کنید. اگر فقط فهرست فایل‌ها را دارید و هرگز امکان import آن بررسی نشده، هنوز از بازیابی‌پذیری مطمئن نیستید.
مدل یا دادهٔ تنظیم‌شده ممکن است دارایی سازمانی یا مشمول محدودیت مجوز باشد. رسانهٔ انتقال را مانند یک فایل عادی رها نکنید: دسترسی، نگهداری، رمزگذاری مجاز و امحای نسخه‌های قدیمی باید با سیاست سازمان هماهنگ باشد. رمز، token دسترسی به مخزن خصوصی یا کلید API را داخل پوشهٔ مدل نگذارید.
آیا برای انتقال مدل به سرور نیاز دارید؟
خیر. همین فرایند را می‌توان برای یک کامپیوتر شخصی سازگار انجام داد. سرور زمانی منطقی‌تر می‌شود که چند کاربر به یک موتور مرکزی نیاز دارند، چند مدل و نسخه باید مدیریت شود یا ذخیره‌سازی و backup سازمانی مهم است. در آن حالت نیز مدل، RAM، GPU، فضای ذخیره‌سازی و تعداد کاربران باید جداگانه سنجیده شوند؛ نام «سرور» تضمین سازگاری یا سرعت نیست. برای دیدن گزینه‌های سخت‌افزاری می‌توانید صفحهٔ خرید سرور HP و سایر سرورها را بررسی کنید، اما برای یک آزمون شخصی الزام به خرید سرور وجود ندارد.
چک‌لیست نهایی قبل از قطع اینترنت
- موتور، نسخه، نصب‌کننده و وابستگی‌های مقصد آماده‌اند.
- وزن‌ها، همهٔ shardها، index و فایل جانبی لازم کامل‌اند.
- tokenizer، config و قالب گفتگو مربوط به همان revision هستند.
- کارت مدل، مجوز، نشانی منبع و شناسهٔ نسخه ذخیره شده‌اند.
- هش SHA-256 پیش از انتقال ثبت و پس از انتقال برابر شده است.
- نام‌های فایل و ساختار پوشه بدون تغییر باقی مانده‌اند.
- رسانهٔ دوم یا backup مستقل برای بستهٔ مهم وجود دارد.
- روش import محلی از مستند همان موتور و همان نسخه مشخص است.
- هیچ رمز، token، کلید API یا مسیر خصوصی در بسته یا گزارش اشتراکی نیست.
- وضعیت آزمون صادقانه ثبت شده و اجرای انجام‌نشده به‌عنوان موفق گزارش نشده است.
اگر این ده مورد کامل باشد، بسته فقط «چند فایل روی USB» نیست؛ شناسنامه، مجوز، کنترل سلامت و مسیر بازیابی مشخص دارد. چنین بسته‌ای احتمال دانلود دوباره و خطای ناشی از فایل ناقص را کم می‌کند، اما آزمون واقعی روی سخت‌افزار مقصد همچنان آخرین مرحلهٔ تأیید است.
دیدگاه‌ها
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید.