Speaker A
Когда я начинал делать агентские системы, всё казалось простым. Берёшь модель, оборачиваешь пайплайн, погнали.
Обзор выбора между API и self-host для агентских систем с учётом регуляций, стоимости и надёжности.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Выбор между API и self-host должен базироваться на конкретных требованиях продукта и регуляциях.
- Использование гибридных решений часто оптимально для баланса надёжности и стоимости.
- Экономия на токенах может быть нивелирована затратами на инфраструктуру и поддержку.
- Региональные требования к данным могут ограничить использование облачных API.
- Надёжность системы требует продуманного fallback и роутинга.
What the video covers
- Современный ландшафт агентских систем разделён на закрытые провайдеры и open source модели.
- В продакшн обычно используются связки моделей для разных задач: генерация, роутинг, эмбеддинги, безопасность и работа с изображениями.
- Цены на токены падают, но расходы растут из-за увеличенного потребления агентами.
- Выбор между API и self-host зависит от регуляций, масштабов, бюджета и инженерных ресурсов.
- Регуляция данных и требования к хранению могут заставить использовать локальные решения или провайдеров с развёртыванием в нужном регионе.
- Масштаб нагрузки и экономическая эффективность влияют на решение о self-host или API.
- Fallback и роутинг важны для надёжности и оптимизации затрат, что может привести к гибридным решениям.
- Рассмотрена мысленная модель принятия решения с учётом всех факторов без идеологических лозунгов.
- Open source модели не всегда бесплатны, учитывая стоимость GPU и поддержку.
- Видео является частью серии о разработке агентских систем с последующими темами по безопасности и деплою.
Chapters
- 00:00Введение и обзор ландшафта агентских систем
- 00:39Закрытые провайдеры и их релизы
- 01:40Open source модели и их экосистема
- 03:01Использование связок моделей в продакшн
- 03:44Проблемы с надёжностью и fallback
- 04:32Экономика использования моделей и токенов
- 05:15Серия видео и планы на следующие части
- 06:14Выбор между API и self-host: ключевые вопросы
- 07:11Регуляция данных и её влияние на выбор
- 10:42Масштаб и экономическая эффективность
Full Transcript — Download SRT & Markdown
Speaker A
Сейчас два разных ландшафта, и в обоих них надо ориентироваться.
Speaker A
С одной стороны, закрытые фронтирпровайдеры: Anthropic, OpenAI, Google.
Speaker A
У каждого по пять-шесть тиров: Opus, Sonet, HKU, GPT Pro, Thinking Mini, Nano, Flash, Flashl и так далее.
Speaker A
Релизы происходят каждые недели.
Speaker A
Только за первый квартал двадцать шестого года крупные провайдеры выкатили больше 250 релизов.
Speaker A
С другой стороны, у нас есть open source мир и на Hugging Face 2 с лишним миллиона моделей.
Speaker A
Это, конечно, с файнтюнами, эмбедингами и дублями реально базовых foundation от серьёзных команд десятки.
Speaker A
Это Metaslama, Alibabas Cen, Mrль, Dipsic, Microsoft Fe и Google, плюс активные китайские лабы.
Speaker A
Bunshot, Zifo, Minimк.
Speaker A
И каждые несколько недель кто-то выкатывает что-то новое.
Speaker A
Это уже не один выбор.
Speaker A
У тебя в продакшн агенте обычно работает не одна модель, а связка.
Speaker A
Праймеры для основной генерации, маленькая для роутинга, эмбединги для RAG, реранкеры и ещё модели для security.
Speaker A
Если на вход попадаются картинки, то ты ещё добавишь Vision или модели, которые работают и с картинками, и с текстом.
Speaker A
А как же fallback?
Speaker A
На случай, если основной провайдер у нас лёг.
Speaker A
И каждое из этих решений — это отдельная задача.
Speaker A
Не по бенчмаркам, а потому, как модель ведёт себя на твоих данных.
Speaker A
И поверх экономика.
Speaker A
Цены за токен вроде кажется, как будто бы валятся в 10 раз за год, но счета у команд растут, потому что агенты потребляют в десятки раз больше токенов, чем обычный чат.
Speaker A
И получается, что это не выбрать ту самую модель, это построить систему выбора, которая выдержит то, что новые модели выходят каждую неделю, а твой биллинг провайдера обгоняет зарплаты у инженера, который этого агента написал.
Speaker A
У меня на канале есть серия про разработку агента.
Speaker A
Сейчас на канале уже две части.
Speaker A
Первая про построение пайплайна.
Speaker A
Вторая про память и бюджет контекст.
Speaker A
Третья будет про продакшн, безопасность, отказоустойчивость, observability и деплоймент.
Speaker A
Она у нас уже на подходе, а сейчас промежуточная часть между второй и третьей, потому что тема выбора моделей оказалась слишком большой, чтобы добавить её в блок третьей части.
Speaker A
Поэтому обсудим отдельно про API, а может быть своё или гибрид, как нам считать, как тестировать и почему правильный ответ почти никогда не будет одна модель на всё.
Speaker A
Поехали.
Speaker A
И первый вопрос.
Speaker A
Скажите честно, а вам вообще надо разворачивать своё?
Speaker A
Потому что есть такая штука: "Мы серьёзная команда, у нас на продевст звучит очень солидно".
Speaker A
А за этой солидностью часто стоит инженер, который несколько недель настраивал VLM вместо того, чтобы делать продукт, и получил то же самое, что можно было бы взять через API за 20 минут.
Speaker A
Реальная развилка.
Speaker A
И у нас есть с вами несколько вопросов.
Speaker A
Давайте посмотрим.
Speaker A
И начнём мы с вопроса, есть ли у вас в продукте чувствительные данные: персональные, банковские, медицинские, может быть, государственные, потому что почти в любой юрисдикции есть требования к тому, где эти данные хранятся и как они обрабатываются.
Speaker A
И какие именно требования, это зависит от вашего региона.
Speaker A
Но принцип везде похожий.
Speaker A
Данные не должны бесконтрольно покидать периметр.
Speaker A
Но есть небольшой нюанс.
Speaker A
Прежде чем решать, что мы поднимаем своё, давайте посмотрим.
Speaker A
Может быть, у провайдера, с которым вы работаете, можно развернуть модель в нужном вам регионе и подписать договор о защите данных.
Speaker A
Часто этого достаточно, и тогда совхост не нужен.
Speaker A
И получается, мы можем закрыть этот вопрос на уровне провайдера в нужном регионе.
Speaker A
Следующий вопрос, на который нам надо ответить, — масштаб.
Speaker A
Универсальной точки окупаемости нет, зависит слишком от многих переменных: какая модель, какая длина запроса, паттерны нагрузки, есть ли в команде инженер, который умеет совхостить железо.
Speaker A
И это всё надо рассмотреть.
Speaker A
Правильный подход — это посчитать свой кейс, прикинуть месячный счёт по API на текущей нагрузке, прикинуть стоимость GPU плюс devops время на self-host.
Speaker A
Посмотреть, как обе цифры меняются, если нагрузка вырастет в три раза.
Speaker A
Если разница на текущем масштабе мизерная, то берите.
Speaker A
Если счёт уже бьёт по бюджету и продолжает расти, есть смысл считать всерьёз.
Speaker A
Итак, если у нас будет дорого, мы посчитали и на основе расчёта понимаем, что своё железо становится ещё дороже, то мы с вами берём API.
Speaker A
Если же мы посчитали и понимаем, что с учётом роста нагрузки, с учётом того, что у нас есть нужные инженеры, мы можем позволить себе self-host, то мы берём self-host.
Speaker A
И третий вопрос.
Speaker A
Нужен ли нам с вами fallback или роутинг?
Speaker A
Это два разных вопроса, но оба часто приводят к одному ответу: нужно своё.
Speaker A
Fallback — это резерв на случай, когда основной провайдер лёг.
Speaker A
Не обязательно это будет локальная модель.
Speaker A
Может быть, это будет API у другого вендера.
Speaker A
Но если по требованиям к надёжности нам нужен второй уровень резерва вне облачного API, то это будет аргумент за своё.
Speaker A
И роутинг — это у нас про экономику.
Speaker A
Если у нас с вами разнообразный трафик и большая часть запросов простые, и вы хотите гонять их на дешёвой локальной модели, чтобы не платить фронтиры за каждый привет, это тоже аргумент за своё.
Speaker A
Давайте финально пройдёмся и проставим недостающие стрелочки.
Speaker A
Первое.
Speaker A
Регуляция данных нужна нам?
Speaker A
Да, нет, смотрим на регион, смотрим на провайдеров.
Speaker A
Можем там развернуть?
Speaker A
Если можем, то мы используем API.
Speaker A
Если же этот API нам уже бьёт по карману, мы переходим к выбору, дорого это или нет.
Speaker A
Если это дорого, то мы начинаем считать, и после расчёта мы можем понять, стоит нам использовать API либо всё-таки self-host.
Speaker A
Нужен ли нам fallback, нужен ли нам роутинг?
Speaker A
И на основе этого мы можем понять, нужен нам гибрид или нужен API.
Speaker A
Также в гибрид мы можем с вами попасть и с этих вопросов, если мы на них будем отвечать дальше, исходя из этого дерева.
Speaker A
Если же у нас с точки зрения нашей регуляции здесь у нас никак, в регионе нету никаких провайдеров, ещё ничего, то это точно у нас будет self-host.
Speaker A
Вот такая получилась интересная мысленная модель о том, как нам выбирать API или всё-таки мы хотим менеджить модели сами.
Speaker A
Вы можете придумать и добавить свои вопросы для того, чтобы понять по вашим требованиям, что подходит, что не подходит.
Speaker A
И здесь самое главное — без каких-то лозунгов, типа API — это рабство или open source — это для серьёзных, давайте не будем использовать API, потому что лозунги — это не инженерия.
Speaker A
Если вы сможете таким образом разложить свои требования, то, скорее всего, поймёте, что вам надо использовать.
Speaker A
Вы можете использовать API, либо вы вообще его не можете использовать.
Speaker A
А может быть, вам надо прийти к гибриду.
Speaker A
Если мы с вами прийдём к модели, которую мы хотим сами менеджить, то дальше нам надо будет понять, сколько же это будет стоить на самом деле.
Speaker A
Open source-модели иногда называют бесплатными.
Speaker A
Не платишь провайдерам за токены, кайф, экономия.
Speaker A
Так давайте же разберём, насколько эта экономия настоящая.
Speaker A
Тарифы провайдеров и цены на GPU меняются каждые несколько месяцев.
Topics:агентские системыAPIself-hostopen source моделирегуляция данныхмашинное обучениеэкономика моделейfallbackроутингHugging Face
