Model Artifact Mesh, Build Variants و Replicas

1. مسئله واقعی: نام مدل، هویت اجرایی نیست

در یک سامانه AI ممکن است همه درباره «atlas-7b» حرف بزنند، اما همین نام می‌تواند به revisionهای مختلف، quantizationهای مختلف، فرمت‌های متفاوت و buildهای مخصوص runtimeهای مختلف اشاره کند. اگر فقط نام فایل یا alias ذخیره شود، دیگر نمی‌توان ثابت کرد کدام بایت‌ها qualify شده‌اند. این درس یک Model Artifact Mesh می‌سازد که هویت immutable هر build را از نام‌های mutable جدا می‌کند.

2. خروجی محدود این درس

خروجی ما Model Artifact Mesh Manifest & Replica Integrity Record v1 است. این رکورد source repo، source revision، build recipe، variant، format، precision/quantization، digest، size، runtime compatibility، hardware constraint، qualification binding و وضعیت هر replica را نگه می‌دارد. این درس transport resumable، مجوز حقوقی، انتخاب node و telemetry را مالک نیست.

3. سه لایه هویت: Source، Build، Replica

Source identity می‌گوید build از کدام repository و revision آمده است. Build identity می‌گوید با چه recipe و چه فرمت/precision/quantization ساخته شده و digest نهایی آن چیست. Replica identity می‌گوید کدام کپی از همان build در کدام location قرار دارد و digest مشاهده‌شده آن چیست. قاطی‌کردن این سه لایه audit را از بین می‌برد.

4. Content address به‌جای filename

در OCI Content Descriptor، digest به‌عنوان content identifier و size به‌عنوان اندازه مورد انتظار ثبت می‌شود؛ برای محتوای دریافت‌شده از منبع غیرقابل‌اعتماد، verify کردن digest و size توصیه شده است. در این درس از همین الگو برای model artifact استفاده می‌کنیم، بدون اینکه ادعا کنیم artifactهای MAKNOW الزاماً OCI image هستند. filename تنها metadata است؛ digest هویت decisive است.

5. Revision upstream باید pin شود

در Hugging Face Hub می‌توان download را به revision مشخص، از جمله full commit hash، pin کرد و snapshot نیز زیر مسیر مربوط به همان commit materialize می‌شود. این pinning برای provenance مهم است، اما به‌تنهایی build محلی شما را هویت‌دهی نمی‌کند. build حاصل از همان revision ممکن است FP16، Q4، Q5 یا runtime-specific باشد و هرکدام digest مستقل لازم دارند.

6. Build Variant چیست؟

Build variant فقط یک برچسب مانند «Q4» نیست. حداقل باید format، precision یا quantization، build recipe version، runtime compatibility و hardware constraint را همراه digest/size داشته باشد. تغییر هر عامل decisive که بایت‌های خروجی یا قابلیت اجرا را عوض می‌کند، باید variant جدید بسازد؛ variant جدید حق ندارد identity قبلی را overwrite کند.

7. Mesh و الگوی Index

OCI Image Index نمونه‌ای استاندارد از یک manifest سطح بالاتر است که به چند manifest اشاره می‌کند و می‌تواند variantهای platform را بیان کند. در MAKNOW از این مفهوم به‌عنوان الگوی طراحی استفاده می‌کنیم: یک artifact family می‌تواند چند build immutable داشته باشد. اما quantization و runtime constraint مدل‌ها metadata اختصاصی خود ما هستند و نباید با platform fields استاندارد OCI یکی فرض شوند.

8. Alias متغیر، Pointer است نه Identity

atlas-7b:prod می‌تواند امروز به digest FP16 و فردا به digest Q4 اشاره کند. بنابراین audit record قدیمی باید digest را ذخیره کند، نه فقط alias را. repoint شدن alias نباید باعث شود qualification یا replica record تاریخی به artifact جدید منتقل شود. alias برای discovery خوب است؛ برای اثبات هویت کافی نیست.

9. Qualification باید به digest bind شود

Qualification باید دقیقاً به digest build، source revision و در صورت نیاز build recipe bind شود. اگر Q5 جدیدی از همان source revision ساخته شد، حتی اگر نام family یکی باشد، qualification مربوط به Q4 یا FP16 به آن منتقل نمی‌شود. وضعیت درست تا زمان qualification مستقل، BLOCKED یا DEFER است—not silently qualified.

10. Replica چگونه AVAILABLE می‌شود؟

Replica فقط وقتی AVAILABLE است که expected digest و expected size build را داشته باشیم، digest/size مشاهده‌شده replica match شوند، provenance conflict نداشته باشیم، evidence بیش از حد قدیمی نباشد و qualification binding به همان digest اشاره کند. اگر digest متفاوت باشد، حتی با filename و alias یکسان، replica باید QUARANTINED شود.

11. UNKNOWN، STALE و QUARANTINED را حفظ کن

اگر digest replica اندازه‌گیری نشده، وضعیت UNKNOWN است؛ «احتمالاً سالم» جای evidence را نمی‌گیرد. اگر verify قدیمی‌تر از freshness window باشد، وضعیت STALE است. اگر digest یا size conflict دارد، QUARANTINED است. تبدیل این stateها به boolean success، یکی از خطرناک‌ترین shortcutهای production است.

12. سناریوی Atlas-7B

ما upstream revision r42 داریم. build اول GPU/FP16/safetensors است و دو replica روی gpu-a و gpu-b دارد. build دوم CPU/Q4/GGUF روی edge-c است. alias atlas-7b:prod به build FP16 اشاره می‌کند. بعد از mirror refresh، gpu-b همان filename را دارد اما digest آن تغییر کرده است. فقط gpu-a می‌تواند AVAILABLE بماند؛ gpu-b باید QUARANTINED شود.

13. تست تغییر زمینه: Q5 جدید

از همان revision r42 یک Q5 ساخته می‌شود. source یکی است، اما build recipe/quantization/digest جدیدند. رکورد Q5 باید کنار Q4 و FP16 اضافه شود؛ هیچ رکورد قبلی mutate نمی‌شود. qualification قدیمی و replicaهای قبلی نیز خودکار به Q5 تعلق نمی‌گیرند. این تست نشان می‌دهد mesh واقعاً content-bound است.

14. مرز با درس‌های بعدی

AIE-014 bytes را chunked/resumable منتقل می‌کند؛ AIE-015 permission policy را بررسی می‌کند؛ AIE-016 node را براساس capability/policy انتخاب می‌کند؛ AIE-017 telemetry runtime را می‌سنجد. AIE-013 فقط هویت، provenance، build variants، alias binding و replica integrity را مالک است. این separation مانع false success می‌شود.

15. چک‌لیست تصمیم و تحویل

برای هر build بپرس: source revision دقیق چیست؟ recipe کدام نسخه است؟ variant و format/precision/quantization چیست؟ digest و size کدام‌اند؟ qualification به چه digestی bind شده؟ برای هر replica: observed digest/size چیست، evidence تازه است، provenance conflict دارد یا نه، و state نهایی AVAILABLE/UNKNOWN/STALE/QUARANTINED/BLOCKED چیست؟ پاسخ باید از رکورد قابل audit بیاید، نه از حدس یا reasoning پنهان.