- LiteLLM централізує доступ до кількох моделей штучного інтелекту через уніфікований проксі-сервер, сумісний зі стандартом OpenAI.
- Це дозволяє створювати віртуальні ключі для призначення певних бюджетів, лімітів токенів та контролю доступу для кожного користувача або пристрою.
- Він пропонує інструменти спостереження та інтелектуальної маршрутизації для оптимізації витрат та забезпечення доступності послуг.
Уявіть, що ваша компанія вирішує повністю впровадити штучний інтелект, і за одну ніч половина вашої команди тестує різні моделі. Проблема полягає в тому, що кожен постачальник має свій власний метод оплати, власні API, і якщо ви не будете обережні, рахунок наприкінці місяця може стати величезним шоком. Можливість… Встановіть ліміти витрат на користувача в LiteLLM Це особливо цікаво. Ми пояснимо це нижче.
Цей інструмент — це не просто бібліотека для програмістів, а й стратегічний шлюзЗамість того, щоб кожна програма зберігала власні секретні ключі OpenAI або Anthropic, все проходить через одну контрольну точку. Це не лише робить код чистішим, але й дає вам можливість вирішувати, хто скільки витрачає І в якій моделі, без необхідності переписувати жодного рядка вашої програми, коли ви хочете змінити провайдерів.
Що ж таке LiteLLM?
Щоб уникнути плутанини, перше, що потрібно зрозуміти, це те, що LiteLLM Він доступний у двох форматах. З одного боку, у нас є SDK для Pythonяка є легкою бібліотекою, ідеальною для прототипів або особистих проектів, де ви просто хочете викликати різні моделі, не заглиблюючись у документацію для кожного API. З іншого боку, є Проксі-серверякий є перлиною для професійного середовища. Цей сервер зазвичай розгортається з Docker і дозволяє керувати централізоване управління, рекорд вартості та обмеження швидкості.
Магія полягає в тому, що він стандартизує понад 100 моделей у форматі OpenAI. Тож, якщо завтра вийде нова модель, яка буде вдвічі дешевшою та вдвічі швидшою, вам просто потрібно... змінити рядок у налаштуваннях Проксі-сервер та всі ваші програми почнуть використовувати його автоматично, без жодних зусиль розробникам.
Встановлення лімітів витрат та контроль користувачів
Найпотужнішою функцією для адміністраторів, які хочуть встановити ліміти витрат для кожного користувача в LiteLLM, безсумнівно, є управління віртуальні ключіЗамість того, щоб ділитися головним ключем вашого облікового запису Лазур Або ж, за допомогою Bedrock для всієї команди, ви генеруєте окремі ключі для кожного користувача чи проекту. Ви можете призначити... кожному з цих ключів максимальний бюджет (наприклад, 10 доларів США на місяць) та певний термін.
- Бюджетні обмеження: Ви можете визначити точну суму. Коли користувач досягає ліміту, LiteLLM відключає доступ, повертаючи помилку HTTP 401, таким чином запобігаючи несподіванкам у рахунку.
- Контроль токенів та швидкість: Можливо встановити обмеження RPM (запитів за хвилину) і TPM (токени за хвилину), що життєво важливо для запобігання перевантаженню квоти API одним користувачем і залишенню решти команди без обслуговування.
- Обмежений доступ: Не всім користувачам потрібен доступ до найдорожчої моделі. Ви можете налаштувати ключ, щоб дозволити доступ лише до бюджетних моделей (таких як Llama 3 Local) та заблокувати доступ до GPT-4o для тих, кому він не потрібен.
Важливо зазначити, що для того, щоб відстеження витрат працювало в режимі реального часу, проксі-сервер повинен спиратися на базу даних. PostgreSQL зберегти записи та в Redis надшвидко керувати лічильниками кешу та обмеження швидкості.
Стратегії маршрутизації та економії
Окрім встановлення лімітів витрат на користувача в LiteLLM, можна розробляти стратегії оптимізації через інтелектуальна маршрутизаціяОдна з найкорисніших функцій – це резервні варіантиВи можете налаштувати систему таким чином, щоб у разі збою основної моделі або її недостатньої вартості для простого завдання запит автоматично перенаправлявся на дешевшу резервну модель.
Також існує концепція резервні_контекстні_вікнаЯкщо користувач надсилає дуже великий запит, який перевищує можливості дешевої моделі, система, замість того, щоб викликати помилку, надсилає його моделі з більшим контекстним вікном. Щоб перевірити, чи відбувається це, просто перевірте заголовки відповідейзокрема x-litellm-model-idякий точно підкаже, яка модель зрештою відповіла на запит.
Технічне впровадження та розгортання
Щоб реалізувати це у виробничому середовищі, найкраще використовувати VPS з Ubuntu та Docker ComposeСерцем усього цього є архів. config.yaml, де ви визначаєте список моделей, їхні псевдоніми (наприклад, називаючи модель «стандартною» або «преміумною») та ключі API, які будуть зчитуватися зі змінних середовища для забезпечення безпеки.
Критичним моментом, який багато хто не враховує, є безпека розгортання. Порт 4000 не повинен бути безпосередньо підключений до Інтернету. В ідеалі, зворотний проксі-сервер, такий як Nginx або Caddy Це дозволяє керувати SSL-сертифікатами та, що дуже важливо, вимикати їх. proxy_bufferingЯкщо залишити буферизацію ввімкненою, відповіді в режимі потокове передавання (де текст відображається слово в слово) не дійде до користувача, доки відповідь не буде надано повністю, що порушить взаємодію з користувачем.
Порівняння: самостійно розміщені та керовані рішення
Самостійне використання LiteLLM дає вам повний контроль над даними І це безкоштовно з точки зору ліцензування, але це пов'язано з операційним навантаженням. Вам доведеться керувати резервними копіями бази даних, оновлювати контейнер і контролювати диск Postgres, щоб запобігти його заповненню журналами ресурсів. Для дуже невеликих команд або експертів DevOps це ідеальний варіант.
Однак для компаній, які не хочуть мати проблеми з інфраструктурою, існують альтернативи, такі як TrueFoundryЦі платформи пропонують функціональність шлюзу, але позбавляють необхідності вручну налаштовувати Redis або Postgres, інтегруючи корпоративні функції, такі як... SSO (єдиний вхід) та RBAC (керування доступом на основі ролей), який у безкоштовній версії LiteLLM більш обмежений або вимагає версії Enterprise.
Ліміти витрат LiteLLM на одного користувача дозволяють організаціям масштабувати свої розгортання, не боячись перевищення бюджетів або погрози безпеці своїх облікових даних. Централізуючи трафік, організації отримують повну видимість фактичного використання моделі, що дозволяє їм коригувати витрати на основі конкретних даних, а не припущень, зберігаючи при цьому гнучкість у зміні постачальників послуг у міру розвитку ринку.
Редактор, що спеціалізується на технологіях та питаннях Інтернету з більш ніж десятирічним досвідом роботи з різними цифровими медіа. Я працював редактором і творцем контенту для компаній електронної комерції, комунікацій, онлайн-маркетингу та реклами. Я також писав на веб-сайтах з економіки, фінансів та інших секторів. Моя робота також є моєю пристрастю. Тепер через мої статті в Tecnobits, я намагаюся вивчати всі новини та нові можливості, які щодня пропонує нам світ технологій для покращення нашого життя.