معامله واقعی
استنتاج محلی معمولاً به عنوان بهینه‌سازی تأخیر معرفی می‌شود. اما فقط این نیست. وقتی مدلی روی دستگاه اجرا می‌شود، ورودی هرگز از دستگاه خارج نمی‌شود. این یک تصمیم خروج داده با پیامدهای حریم خصوصی، انطباق و رفتار آفلاین است و اتفاقاً زمان رفت و برگشت را نیز کاهش می‌دهد.
معامله ساختاری است، نه تدریجی.
استنتاج محلی به دست می‌آورد:
- داده‌ای که در مرز دستگاه باقی می‌ماند؛
- عملیات بدون شبکه، که برای ابزارهای میدانی، وسایل نقلیه، محیط‌های بالینی و هر چیزی که در زیرزمین استفاده می‌شود اهمیت دارد؛
- هزینه قابل پیش‌بینی به ازای هر درخواست پس از پرداخت هزینه سخت‌افزار؛
- عدم وابستگی به دسترس‌پذیری یا محدودیت نرخ یک نقطه پایانی دور.
استنتاج محلی هزینه دارد:
- توانمندی: تعداد پارامترهای کمتر، کوانتیزه‌سازی تهاجمی و پنجره‌های زمینه محدود عمق استدلال، قابلیت اطمینان استفاده از ابزار و پردازش اسناد طولانی را کاهش می‌دهد؛
- بودجه حافظه و حرارتی، که محدود می‌کند کدام مدل‌ها می‌توانند همزمان با بقیه برنامه اجرا شوند؛
- یک پشته استنتاج دوم برای ارزیابی، نسخه‌بندی و عرضه؛
- تکرار کندتر، زیرا به‌روزرسانی یک مدل روی دستگاه یک مسئله توزیع است، نه یک فرمان استقرار.
استنتاج دور همه اینها را معکوس می‌کند. توانمندی را می‌خرد — مدل‌های بزرگ‌تر، زمینه طولانی‌تر، هماهنگی قوی‌تر ابزار — به قیمت انتقال داده از مرزی که محصول کنترل نمی‌کند، به علاوه وابستگی سخت به اتصال و به زمان کارکرد یک شخص ثالث.
اکثر سیستم‌های مفید به هر دو نیاز دارند. بنابراین سؤال مهندسی «محلی یا دور» نیست، بلکه «مرز کجاست و چه چیزی تصمیم می‌گیرد که یک درخواست معین به کدام سمت برود» است.
ترسیم مرز
اشتباه رایج مسیریابی بر اساس اطمینان مدل است: به صورت محلی اجرا کن، و اگر مدل محلی مطمئن نبود، ارتقا بده. این وسوسه‌انگیز است زیرا ابزارگذاری آن آسان است، و به دو دلیل اشتباه است. اول، امتیازات اطمینان از مدل‌های کوچک کوانتیزه به خوبی کالیبره نشده‌اند، بنابراین محرک ارتقا به طور غیرقابل پیش‌بینی فعال می‌شود. دوم، و مهم‌تر، بر اساس متغیر اشتباه مسیریابی می‌کند. اینکه آیا یک بار داده می‌تواند از دستگاه خارج شود، خاصیت داده است، نه سختی سؤال.
به جای آن بر اساس کلاس داده مسیریابی کنید. کلاس‌ها را صریحاً تعریف کنید و به هر کدام یک مکان اجرای مجاز اختصاص دهید:
class examples locus
--------------- -------------------------------- ------------------
regulated-pii identifiers, health notes local only
device-private raw sensor frames, local files local only
user-content drafts, transcripts, messages local default,
remote on consent
derived embeddings, redacted summaries remote allowed
public docs, reference material remote preferred
مرحله طبقه‌بندی قبل از استنتاج، روی ورودی اجرا می‌شود و در صورت امکان قطعی است: بررسی طرح‌واره، برچسب‌های سطح فیلد، منشأ منبع. جایی که طبقه‌بندی به مدل نیاز دارد، از یک طبقه‌بند کوچک محلی استفاده کنید که تنها وظیفه‌اش صدور یک برچسب کلاس است — نه پاسخ به کاربر.
یک الگوی مفید این است که استدلال را محلی و فراخوانی ابزار را دور نگه دارید، جایی که بار داده خصوصی است. مدل محلی تصمیم می‌گیرد چه کاری و با کدام آرگومان‌ها انجام دهد؛ فراخوانی دور فقط حداقل مجموعه آرگومان را حمل می‌کند، هرگز زمینه کامل را. یک جستجوی تقویم به یک بازه تاریخ نیاز دارد، نه به مکالمه‌ای که آن را تولید کرده. یک فراخوانی بازیابی به یک رشته پرس‌وجو و یک فضای نام نیاز دارد، نه به پیش‌نویس کاربر. این توانمندی سرویس‌های دور را برای بخش‌هایی که از آنها سود می‌برند حفظ می‌کند — داده تازه، نمایه‌های بزرگ، محاسبات سنگین — در حالی که مواد خصوصی روی دستگاه می‌مانند.
اینجاست که معامله صادقانه نهفته است. جدا کردن استدلال از فراخوانی ابزار به قیمت از دست دادن توانایی مدل دور برای دیدن زمینه کامل تمام می‌شود، که دقیقاً همان چیزی است که مدل‌های دور را در وظایف مبهم و چندمرحله‌ای خوب می‌کند. شما مقداری کیفیت پاسخ را با سطح خروجی کوچک‌تر معاوضه می‌کنید. این معامله باید به طور عمدی، به ازای هر کلاس، انجام و ثبت شود.
برای عملیات تخریب‌شده به عنوان یک حالت درجه اول طراحی کنید، نه به عنوان یک مسیر خطا. 
ent:
- کدام درخواست‌ها به صورت محلی با کیفیت کاهش‌یافته سرو می‌شوند؛
- کدام‌ها صف می‌شوند و هنگام بازگشت اتصال دوباره پخش می‌شوند، و چگونه پخش مجدد با idempotency تعامل دارد؛
- کدام‌ها کاملاً رد می‌شوند، با پیامی که دلیل را می‌گوید؛
- رابط کاربری چه چیزی را منتقل می‌کند، تا کاربر بتواند خروجی تخریب‌شده را از خروجی کامل تشخیص دهد.
سیستمی که بی‌صدا پاسخ‌های بدتر در حالت آفلاین تولید می‌کند، بدون علامت‌دهی، سخت‌تر از سیستمی است که می‌گوید همین حالا نمی‌تواند کاری را انجام دهد.
اندازه‌گیری شکاف
وقتی مرز وجود دارد، به ابزارگذاری نیاز دارد. سه اندازه‌گیری بیشترین وزن را دارند.
اول، کسر سرویس محلی: سهم درخواست‌هایی که کاملاً روی دستگاه سرو می‌شوند، به تفکیک کلاس داده. یک عدد تجمیعی واحد چیزی را که برایتان مهم است پنهان می‌کند، زیرا کسر محلی بالا که ناشی از درخواست‌های بی‌اهمیت است چیزی درباره اینکه آیا کلاس‌های حساس واقعاً محلی می‌مانند نمی‌گوید. آن را به ازای هر کلاس ردیابی کنید، و آن را در طول نسخه‌های مدل و برنامه ردیابی کنید، زیرا یک تغییر prompt می‌تواند مسیریابی را جابه‌جا کند.
دوم، دلتای کیفیت به ازای هر کلاس. برای هر کلاس، یک مجموعه ارزیابی کوچک نگه دارید و آن را در برابر هر دو مسیر محلی و دور اجرا کنید. دلتا به شما می‌گوید مرز چه هزینه‌ای در کیفیت پاسخ دارد. اگر دلتا در یک کلاس ناچیز است، مسیر محلی می‌تواند گسترده‌تر شود. اگر بزرگ است، دلیلی مستند برای شکاف فعلی دارید — و یک نامزد برای بهبود هدفمند به جای ارتقای یکجا.
سوم، تأخیر رفت و برگشت که به صورت سرتاسری اندازه‌گیری می‌شود، شامل سریال‌سازی زمینه. اینجاست که مقایسه‌های محلی در برابر دور بیشترین اشتباه را می‌کنند. یک فراخوانی دور فقط زمان شبکه نیست؛ مونتاژ prompt، توکن‌سازی، سریال‌سازی، انتقال، صف در نقطه پایانی، prefill، decode و deserialisation است. یک فراخوانی محلی سربار خود را دارد: بارگذاری مدل، فشار حافظه و هزینه رقابت با بقیه برنامه. هر دو را از یک نقطه شروع اندازه‌گیری کنید — لحظه‌ای که ورودی در دسترس است — وگرنه مقایسه بی‌معنی است.
سپس مراقب ارتقای بی‌صدا باشید. این حالت شکست زمانی است که یک fallback محلی، تحت شرایطی، prompt کامل را به یک نقطه پایانی دور ارسال می‌کند. معمولاً از طریق یکی از چند مکانیسم ظاهر می‌شود: یک پوشش retry که بار داده اصلی را دوباره ارسال می‌کند نه بار کاهش‌یافته را؛ یک مسیر logging یا tracing که ورودی‌های خام را به یک بک‌اند observability می‌فرستد؛ یک آداپتور tool-call که کل مکالمه را به عنوان زمینه ارسال می‌کند زیرا API دور یک لیست پیام انتظار دارد؛ یا یک feature flag که یک کلاس را از محلی به دور تغییر می‌دهد بدون تغییر متناظر در سیاست خروج.
دفاع این است که خروج را صریح و قابل حسابرسی کنید. هر بار داده خروجی باید توسط یک مؤلفه واحد ساخته شود که کلاس داده را می‌داند و فقط می‌تواند فیلدهای مجاز برای آن کلاس را منتشر کند. در تست‌ها روی آن assert کنید: با یک ورودی regulated-pii، بار داده خروجی باید هیچ فیلدی از مجموعه ممنوعه نداشته باشد. کلاس و نام فیلدهایی که خارج شده‌اند را ثبت کنید، نه مقادیر را. اگر سیاست در یک نقطه اختناق اجرا شود نه در هر محل فراخوانی، ارتقای بی‌صدا به یک شکست تست تبدیل می‌شود نه یک حادثه تولید.
خلاصه عملی: ورودی‌ها را بر اساس حساسیت طبقه‌بندی کنید، بر اساس آن طبقه‌بندی مسیریابی کنید، بارهای داده خصوصی را روی دستگاه نگه دارید در حالی که توانمندی دور را برای بخش‌هایی که به آن نیاز دارند قرض می‌گیرید، رفتار آفلاین را به ازای هر کلاس تعریف کنید، و شکاف را ابزارگذاری کنید تا کسر محلی، دلتای کیفیت و سطح خروج همه قابل مشاهده باشند. تأخیر مزیتی است که کاربران متوجه می‌شوند. خروج داده چیزی است که تصمیم می‌گیرد آیا سیستم اصلاً قابل استقرار است یا نه.