В продолжение вайб кодинга на уровне квестов и курсора

Взялся протестировать один наш сервис для gptdaisy.com начинаем тонуть в запросах на генерацию изображений там связка async image generation сервис состоит из Comfy(кастомное апи написанное нами + flux + rabbit)

И так получил файлы от лида и взял наш новенький сервер с двумя 4090 и раскатил все что надо, скачал модели докер куда фигуда в общем сказка все на моих любимых скриптах

Цель была стабилизировать сервис и проверить на масштабирование как будет вести себя при n воркерах там еще и удаленные есть и сколько у нас будет IPM(image per minute) сейчас кстати почти честные 15 штук

В общем сервис не взлетел апи принимало запросы картинки не отдавлись

В общем я же вайб кодер взял подключил курсор к core + worker он проиндексировал папки ну и выдал пачки кода которые я принял

Получил я в итоге рабочий сервис все завелось, довольный я, лег спать

На утро пустил на сервер бекенд лида и получил порцию консервированных оценок кода от ллм в общем и целом результат на лицо(на скрине)

Курсор (клод 3.7) переписал все обратно на синхронные функции и зачем-то решил каждый раз открывать закрывать содениение по ws чтож тут должен быть мем но придумайте сами =)

Результаты Enterprise RAG challenge (https://abdullin.com/erc/)
На сайте клацаем кнопку Show Local Models Only

На сегодня я завершаю свои исследования по локальным RAG подходам по документам и расскажу как мы заняли 4 место с разницей в 8 баллов от 70+b моделек (Локальных) и 1 первое место среди 32b моделей и Full Dense retrieval and cross-encoder reranker подходом (никаких кстати langchain и другого готового рагоделья только вайб кодинг в курсор и requests + vLLM)

Предыдущие посты на эту тему:
1) Анализ разных векторных моделек
2) Сравнение локальных моделей векторизации с 1 местом
3) Первые эксперименты

В итоге навайбкодил около 11к строк кода которые позволили показать такие результаты
Важное отступление что более 7 дней у меня в итоге заняло эксперименты по экстракту данных из PDF (карл)

И так для начала какое решение я принял сразу что-то ошибочно:

1) Никакой подготовки стендов заранее, все материалы команда и я в частности приступили изучать в день старта соревнований (взял из команды 2 человек ребята помогли вчитаться в условия и понять данные) (Вот тут рефлексия что нужно выделять как минимум неделю заранее свою что бы войти в курс дела)

2) Заранее пополнили все нужные нам сервисы для аренды локальных мощностей

3) Выкинул наш пайплайн RAG и я его стал строить с 0

4) Были заранее развернуты и заготовлены cross encoder bge-rerank + bge-m3 embedding model Арендована машина с А100 для (qwen 2.5 32b (16FP) instruct)


Первый этап парсинг данных из PDF
тут не обошлось без приключений так как внутри компании мы сконцентрировались на интеграциях к конфлюенс и системам для забора данных на документах мы давно не делали акцент по этому пошли гуглить и перебирать что же сможет нам достоверно достать данные из PDF

Перебрав около 3-5 библиотек финальный результат был сделан на библиотеке Marker

Далее чанкование и векторизация
Ничего нового каждая страница была разбита на чанки по 400 токенов с перекрытием в 80 токенов и дальше векторизирована батчами в сервис vLLM где развернута модель bge-m3

Далее под каждый док была созданная коллекция и настроены модели данных (что бы при запросе на KNN возвращать чанки номер страницы с которой он был взят и путь до файла где есть фулл контент страницы как потом я выяснил данный подход называется Parent Document Extraction)

Роутинг был заранее понятен из названия компаний и документов к ним в сабсет там были названя компаний их легко было смэтчить с документами(это я ксатит понял только почти в самом конце и выкинул роутинг совсем)
И так из приятного в сабсете(датасет) изначально указаны типы по этому были составлены через клод промпты под каждый тип запроса

Ну и пошли прогоны (прогонял я систему наверное раз 40 не менее)
Каждый раз вчитываясь что же она отвечает

Ищем чанки внутри дока через KNN
Ранжируем через bge-reranker (cross-encoder)
Передаем в ллм с CoT+SO для ответа

Были проблемы и с множественными вопросами но как показала моя практика курсор (в 20 итераций) смог учесть эти особенности и неплохо обработал этот формат

Как итог часть этих наработок уже ушла в наш прод продукт Smart Platform которая нацелена решать проблему создания RAG агентов для крупных компаний на локальных мощностях

Stay Tuned!
Скоро будет большой анонс нашей платформы будем с нашим CPO рассказывать что же мы там ваяли за год

P.S мы уже провели внутренние демо нашего продукта получили очень позитивный фидбек! Значит движемся куда нужно!

Кстати схема работы моего решения) Если смотреть между строк почти ничем не отличается от других топ решений

1/2 Когда выгодно переходить с облачных API на собственные LLM-модели: сравнение OpenAI API, облачных и локальных open-source решений


Пришел тут ко мне интересный вопрос, допустим у нас планируется 100 000 только текстовых диалогов в сутки размером не более 3 сообщений от пользователя
Текущий стек gpt-4o-mini CoT + SO

И так, допустим, у нас есть 100 000 диалогов примерно по 100-300 токенов от пользователя и еще по 3 сообщения от ллм в сумме на инпут у нас 900 аутпут примем что чуть больше 1200

получаем вот такую картину пока исключил кеширование:
gpt-4o-mini

Входящие токены (900 × 100K): $11.48 (некеш) + $1.01 (кеш) = $12.49/день
Исходящие токены (1,200 × 100K): $72/день
Всего: ~$84.49/день или ~$2,535/месяц


Расчет RPS (запросов в секунду) возьмем очень идеальное условия:

100,000 диалогов в день = 100,000 ÷ 86,400 секунд ≈ 1.16 RPS
В пиковые часы (если 70% трафика приходится на 6 часов): ~5.63 RPS

Теперь представим, что мы хотим не повторить, но хотя бы быть на уровне результатов gpt-4o-mini
В моем честном бенчмарке это что-то около модели qwen2.5-32b-instruct
А теперь цифры, что вышли у меня
Одна А100 стоит на runpod $1.89 и такая штука будет иметь пропускную способность 2-3 запроса в секунду со стримингом

Необходимое количество серверов: 6 (для обеспечения пиковой нагрузки с запасом)

Расчет стоимости на RunPod:

Стоимость одной A100: $1.89/час
Стоимость 6 серверов A100: 6 × $1.89 = $11.34/час
Месячная стоимость (24/7): $11.34 × 24 × 30 = $8,164.80/месяц

Итого при текущих параметрах

gpt-4o-mini: ~$2,535/месяц
Локальное решение (qwen2.5-32b-instruct на 6 A100): ~$8,165/месяц

Локальное решение может становится выгодным?
Да когда мы четко выявляем для себя вот такие пункты:

1.Когда важна защита данных - нет отправки конфиденциальной информации в облако
2. Когда необходимо соответствие регуляторным требованиям - GDPR, 152-Ф3, запрет на трансграничную передачу (и то Amazon вроде GDPR соответствует если мы говорим про не РФ)
3. Стабильная работа без лимитов - нет ограничений API, кредитной системы или очередей
4. Независимость от вендора - нет риска, что АРІ поднимет цены или изменит условия

Когда еще выгодно? Update расчет для покупки железа https://t.iss.one/neuraldeepchat/4288

Когда у нас не растет RPS но растет кол-во обрабатываемых токенов за одну сессию допустим мы начинаем сторить не 3 сообщения от пользователя а 10-20 и тогда нам начинает быть более интересно переходить на покупку/аренду железа

Забирайте как шпаргалку когда вам в голову приходит идея аренды железа под ллм

в комментариях еще кинул (написаный курсором калькулятор) есть вопросы к качеству но представление он показывает

2/2 Когда выгодно переходить с облачных API на собственные LLM-модели: сравнение OpenAI API, облачных и локальных open-source решений

Решил для себя закрепить пройденный материал

Давайте за термины проговорим:
API облачных LLM сервисы, предоставляющие доступ к языковым моделям через API (OpenAI, Anthropic, Google и др.) где оплата происходит за каждый обработанный токен

Open-source модели открытые модели (Qwen, Llama, Mistral и др.), которые можно скачать c huggingface и использовать на собственной инфраструктуре

On-premise размещение моделей на собственном локальном оборудовании компании

Cloud аренда вычислительных ресурсов в облаке (RunPod, AWS, GCP(google platform)) для запуска моделей (возможны разные вариации защиты данных от confidential compute до Федеративного шифрования с DP)

Confidential Computing для компаний с критическими требованиями к безопасности, где затраты вторичны по отношению к защите данных

Сценарий_simple_text_chat_system: 100к текстовых диалогов в сутки
Исходные данные
100 000 диалогов ежедневно
3 сообщения от пользователя в каждом диалоге
900 токенов на вход, 1200 токенов на выход
Средняя нагрузка: 1.16 RPS
Пиковая нагрузка: 5.63 RPS (70% трафика в течение 6 часов)

Стоимость Cloud API (GPT-4o-mini)

----------------------------------
Парам | Расчет         | Сумма   |
------|----------------|----------
Вход  | 900×100K×$0.15 | $12.5/д |
Выход | 1.2M×100K×$0.6 | $72/д   |
------|----------------|----------
Итого |                | $2535/м |
----------------------------------
Итого |                | $2535/м |

Аренда RunPod

--------------------------------
Парам | Расчет       | Сумма   |
------|--------------|----------
A100  | $1.9×6×24×30 | $8165/м |
--------------------------------

Стоимость своего оборудования

------------------
Парам  | Сумма   |
-------|----------
Железо | $106K   |
Колок  | $240/м  |
Энерг  | $400/м  |
Аморт  | $2945/м |
DevOps | $3000/м |
-------|----------
Итого  | $6585/м |
------------------

Сравнение решений

|Решение | $/мес.| Преимущ.|Недос.|
|--------|-------|---------|------|
|CloudAPI| $2,5к | Low ent |APIdpn|
|RunPod  | $8,1к | flexi   |High $|
|Lcl     | $6,5к | fullctrl|High $|

Когда переходить на собственные модели?

1. Экономические факторы
- Высокий объем запросов- локальное решение становится выгоднее GPT-4o-mini при более 140,000 диалогов/день
- Длинные контексты- при обработке больших объемов данных (>100K токенов) на запрос
- Долгосрочные проекты - окупаемость собственного оборудования относительно RunPod: ~24 месяцев

2. Неэкономические факторы
- Конфиденциальность данных - отсутствие передачи информации внешним сервисам
- Соответствие регуляторным требованиям - GDPR, 152-ФЗ, ограничения трансграничной передачи
- Стабильность работы - отсутствие очередей, ограничений скорости, кредитных лимитов, прекращение поддерживание старых версий моделей

Альтернативные сценарии_agentic_system(реальный кейс)
Пример: SAST агент патчер на базе qwen32b-coder

Экономическое обоснование:
- 50 репозиториев с ежедневными сканированиями (это минимум что апдейтит средний tir1-2 корп в сутки)
- 20 уязвимостей/день требуют исправления (анализа и быстрой реакции на них)
- 160K токенов на вход, 25K на выход 1000 запусков в день

Просто сравним сколько бы в месяц даже на старте мы тратили бы на gpt-4o-mini
И так как это MAS мы насчитали около 40+ промптов для каждого агента (представьте после PoC переезжать на qwen и все переписывать
Но для чистоты сравню стоимость

|   Решение   | Стоимость/месяц |
|-------------|-----------------|
| GPT-4o-mini |      $990       |
| Local(A100) |      $868       |

Для стартапов и проектов с небольшим объемом запросов(и низкими требованиям к безопасности после PoC) оптимальным выбором остаются облачные API из-за низкого порога входа и отсутствия капитальных затрат

Гибридный подход может быть оптимальным: использование облачных API(на старте) для обычных задач и локальных моделей для конфиденциальных данных или при высоких объемах запросов.

Мы в red_mad_robot реализовали интересный кейс с применением workflow агентов на базе RAG(SO CoT)
Переходите читать на Хабр

Раскрыли некоторые технические детали

https://habr.com/ru/companies/redmadrobot/articles/892882/

SO CoT - самый полезный паттерн при создании продуктов с LLM под капотом

Так выходит, если судить по комментариям в моем прошлом опросе.

Я обещал расписать самый полезный паттерн постом в канале. Поскольку сам ответ не влазит в масштаб и формат поста, вот вам две статьи с более подробным описанием и примерами:

- Structured Output (SO): https://abdullin.com/structured-output/
- Custom Chain of Thought (SO CoT): https://abdullin.com/custom-chain-of-thought/

Ваш, @llm_under_hood 🤗

Вышла Llama 4!

И снова огромный вклад в open-source

Читать и любоваться обсуждением Тут

Выделяю отдельно вот такие характеристики:

это самый большой официально выпущенный контекст пока что (были отдельные работы по файнтюнингу до 50 млн под конкретные задачи. Все это делается с помощью частичного отказа от позиционных эмбеддингов в некоторых слоях, Rotary embeddings в большинстве слоев и подбору коэффициентов софтмакса в attention, лучше соответствующих длине контекста.

Needle in the Haystack: 100% на 10 млн контексте (бенчмарк мы автоматически расширили синтетически до 10 млн, оригинально там 1 млн)

Блогпост тут
Поглядеть на веса тут
Попробовать тут (Web)
По попробовать тут (API openrouter)

Для меня самое интересное это 10M контекста будем смотреть что нужно по hardware

Update нужно 512 штук H100 на 10М контекста RAG не call продолжаем

** Single GPU inference using an INT4-quantized version of Llama 4 Scout on 1xH100 GPU
*** Context lengths are evaluated across 512 GPUs using 5D parallelism.

Structured Output = Stream?

Все знаю что если использовать API к LLM например openai библиотеку
При разработке LLM приложений можно использовать SSE стриминг выставим флаг stream=True и ловить ответ по чанкам тогда можно передавать ответ пользователю в реальном времени как печатная машинка

Но если мы используем SO (structured output) то возможность получить в реальном времени чанки для отображения пропадает


Есть решение использовать extra body и передать туда схему в метод client.chat.completions.create на vLLM можно наблюдать стриминг схемы в реальном времени

    # Extra body parameters with schema
    extra_body = {
        "repetition_penalty": 1,
        "guided_json": json.dumps(DOCUMENT_SCHEMA),
        "guided_decoding_backend": "xgrammar"
    }

На мой взгляд для UI опыта можно сделать что-то интересное на базе CoT+SO (доставать рассуждения сразу и показывать пользователю например)
Как пример выводить у не рассуждающей модели поле reasoning демонстрируя рассуждения по заданному шаблону