تنها ۲۹۰۰ خط کد فاصله است بین یک برنامهنویس و توانایی مسیریابی فراخوانهای مدلهای زبانی در ۱۹ ارائهدهنده مختلف. این است litelm؛ نسخهای تراشیده شده از کتابخانه محبوب LiteLLM که در ۱۱ سپتامبر ۲۰۲۶ منتشر شد تا «حشو»های مربوط به ردیابی هزینه و سرورهای پروکسی را حذف کرده و صرفاً بر مسیر فراخوانی تمرکز کند.
بسیاری از توسعهدهندگان برای جلوگیری از وابستگی به یک شرکت خاص (Vendor Lock-in)، از کتابخانههای مسیریابی استفاده میکنند، اما این ابزارها اغلب به چارچوبهای حجیمی تبدیل میشوند. برای مثال، LiteLLM به بیش از ۱۰۰ هزار خط کد گسترش یافته است که شامل قابلیتهایی مثل بودجهبندی، گاردریلها (Guardrails) و زمانبندی است؛ قابلیتهایی که اکثر برنامههای ساده هرگز از آنها استفاده نمیکنند. این وضعیت شبیه این است که برای روشن کردن یک چراغ مطالعه، یک ژنراتور صنعتی غولپیکر بخرید.
همانطور که در تحلیلهای پیشین ما دربارهی بهینهسازی زیرساختهای مدلهای زبانی اشاره کردیم، تمایل به کاهش وابستگیهای نرمافزاری در حال افزایش است. این رویکرد با استراتژیهای کاهش هزینههای عملیاتی همسو است، مشابه آنچه در تحلیل هزینههای استقرار محلی در برابر ابری بررسی کردیم. به نقل از مخزن گیتهاب این پروژه، litelm منطق اصلی را به حدود ۲۹۰۰ خط کد کاهش داده و تنها دو وابستگی اصلی یعنی openai و httpx دارد. این کتابخانه فقط مسیر فراخوانی — شامل مسیریابی مدل، ترجمه پیامها، استریمینگ، استفاده از ابزار و بردار معنایی (Embedding) — را استخراج کرده و هر چیز دیگری را حذف کرده است. این ابزار به طور صریح کلاس Router، سرورهای پروکسی و لایههای کشینگ (Caching) را حذف کرده است.
بر اساس مستندات فنی، این ابزار توابع ضروری برای محیط عملیاتی را حفظ کرده است:
- مسیریابی مدل: تبدیل نام ارائهدهنده و مدل (با استفاده از سینتکس "provider/model-name") به نقاط اتصال (Endpoints) درست.
- ترجمه پیامها: تبدیل فرمتها بین Anthropic، Bedrock، Cloudflare و Mistral. این تمرکز بر استانداردسازی ترجمه، یادآور رویکرد Oxlo.ai در مدیریت اصطلاحات برای محیطهای تولیدی است.
- قابلیتهای کلیدی: پشتیبانی از استریمینگ (از طریق
stream_chunk_builder)، استفاده از ابزار (Function Calling) و بردار معنایی. - پشتیبانی Async: وجود نسخههای ناهمگام برای تمام توابع مانند
acompletion،aembedding،aresponsesوatext_completion. - تکمیل API: استفاده از همان نام توابع، آرگومانها و انواع پاسخهای LiteLLM.
نصب این کتابخانه به صورت ماژولار است. کاربران میتوانند با pip install litelm نسخه پایه را نصب کنند. برای SDK مربوط به Anthropic از pip install litelm[anthropic] و برای boto3 از pip install litelm[bedrock] استفاده میشود. همچنین دستور pip install litelm[all] تمام وابستگیها را نصب میکند. این کتابخانه از ۱۹ ارائهدهنده از جمله Groq، xAI، OpenRouter، DeepSeek، Perplexity و Together پشتیبانی میکند و با هر نقطه اتصال سازگار با OpenAI (مانند Ollama، vLLM یا LM Studio) از طریق پارامتر api_base کار میکند. این سازگاری با استانداردهای OpenAI به توسعهدهندگان اجازه میدهد تا مشابه تجربه Oxlo.ai در حذف تأخیر ادراکشده، زیرساختهای خود را با کمترین اصطکاک بهینه کنند.
مدیریت خطا در تمام ارائهدهندهها استاندارد شده است و شکستهای مختلف API به سلسلهمراتبی مشخص از جمله ContextWindowExceededError ،RateLimitError و AuthenticationError تبدیل میشوند. این یعنی برنامهنویس میتواند یک بلوک try-except واحد بنویسد که چه برای GPT-4o و چه برای Llama-3.1 به درستی عمل کند.
برای فراخوانی ابزار، توسعهدهندگان میتوانند لیستی از tools شامل نام توابع و پارامترها را تعریف کنند. با تنظیم tool_choice="required"، کتابخانه تضمین میکند که مدل حتماً یک فراخوانی ابزار برگرداند که سپس از طریق مسیر response.choices[0].message.tool_calls[0] قابل دسترسی است.
از منظر فنی، این تغییر نشاندهنده تقاضای فزاینده برای «میکرو-کتابخانهها» در برابر چارچوبهای «همه-در-یک» است. این نرمافزار با هدایت انسانی و کمک هوش مصنوعی توسعه یافته است؛ کدها ابتدا با Claude Code (نسخههای Opus 4.6/4.7) و سپس از ۱۴ مه ۲۰۲۶ از طریق Pi و GPT-5.5 نوشته شدهاند.
برای کسانی که از LiteLLM استفاده میکنند، انتقال بسیار ساده است و تنها با جایگزینی نام کتابخانه در importها (به صورت s/litellm/litelm/) انجام میشود. توسعهدهنده تأیید کرده که این کتابخانه ۲۶۲ تست محلی را پاس کرده و ۷ مسیر اجرایی برای یکپارچگی با DSPy (شامل Predict، CoT و typed signatures) را تأیید کرده است تا تضمین شود که به عنوان یک جایگزین مستقیم (Drop-in replacement) برای حیاتیترین مسیرها عمل میکند. این ممیزی شامل بررسی ۳۶۰ کامیت از مسیرهای اصلی LiteLLM بین بیسلاینهای 649eb2d تا 9a715df2 بوده است.
گام بعدی شما
- اگر در حال ساخت یک عامل (Agent) سبک یا یک Wrapper ساده هستید، بررسی کنید که آیا بابت قابلیتهای بلااستفاده، «مالیات وابستگی» پرداخت میکنید یا خیر.
- مخزن گیتهاب litelm را بررسی کنید تا ببینید آیا منطق ترجمه ارائهدهنده خاص شما در نسخه آلفای فعلی پوشش داده شده است یا نه.
- در صورت استفاده از LiteLLM، یک تست سریع با جایگزینی
s/litellm/litelm/در محیط توسعه انجام دهید.
اما داستان بهینهسازی کدها به اینجا ختم نمیشود؛ اثر این رویکرد «تراشیده» بر سرعت استنتاج را در گزارش بعدی بررسی خواهیم کرد.
گفتگو