Openwebui + litellm, внешний провайдер + vllm с oss-120b в контуре (для внутренних данных)
Модели дороже 50$ за миллион исходящих отключены, как и генерация картинок
Пока самая большая проблема - длинные чаты, несмотря на объяснения почему большая накопленная история - плохо и как перенести контекст в новый чат - регулярно вижу в litellm запросы по 80-120к токенов, без прилепленных файлов
Я бы начал с проверки теоретической возможности переноса и демонстрации на левом проекте и внешнем провайдере нормальных токенов а потом уже попробовал бы выбить под задачу бюджет на связку из пары серьезных но всё ещё бытовых gpu.
Ps То что ваши коллеги получили bad experience на кванте изначально слабой модели - логично
У сообщества в запросах разве нет готового образа чтоб без заморочек api дергать?
Это было бы удобно для
Если вы уже пользуетесь Whisper или другими моделями, то попробуйте подменить их на GigaAM-v3 в своём пайплайне и посмотрите, как изменятся метрики и субъективное восприятие.
Сейчас подумал и пришел к выводу что действительно, prefill этап быстрый и читая только один поток генерации черновика мастер будет большую часть времени простаивать занимая ценную vram, а при необходимости перехватить генерацию для 2+ потоках черновика шанс того что в памяти окажутся необходимые эксперты - небольшой, в итоге случится затык
В чате вполне могут использоваться и методы сжатия контекста (поиск/переупаковка участков) и кэш, но вот по api только кэш, оптимизация контекста - забота разработчика
Именно квадратичной сложности от размера контекста не осталось после flash attention. Взялась она из матрицы попарного внимания между токенами, с нюансами вроде: внимание считается для всего что левее конкретного токена
Один из шаблонов dify про дип рисерч, редактируется под свои хотелки за пару часов. В моем случае использует mcp по яндекс трекеру и конфлюенсу
Как будто репостам не хватает нормировки по просмотрам, это важно
Litellm oss много дашбордов не отдает, за декабрь четверть запросов была у sonnet 4.5, ~85% всех расходов через openwebui
Данных пока мало, с ноября собираем
Openwebui + litellm, внешний провайдер + vllm с oss-120b в контуре (для внутренних данных)
Модели дороже 50$ за миллион исходящих отключены, как и генерация картинок
Пока самая большая проблема - длинные чаты, несмотря на объяснения почему большая накопленная история - плохо и как перенести контекст в новый чат - регулярно вижу в litellm запросы по 80-120к токенов, без прилепленных файлов
Отрицание не равно опровержению, сколько можно уже..
Последняя миля относительно просто и дёшево решается с помощью радиомоста
Перплексия это не про качество абсолютно, это про "уверенность" при выборе следующего токена.
Прунинг делается под конкретную задачу, с контрольным датасетом и нормальными метриками
Если вы удаляли первый слой то просто обязаны были попробовать удалить и последний )) Но ни слова об этом вроде не сказано
Я бы начал с проверки теоретической возможности переноса и демонстрации на левом проекте и внешнем провайдере нормальных токенов а потом уже попробовал бы выбить под задачу бюджет на связку из пары серьезных но всё ещё бытовых gpu.
Ps То что ваши коллеги получили bad experience на кванте изначально слабой модели - логично
Sglang хорош на time to first token а вот при высокой конкурентности vllm в топе
Можно подробнее почему n8n орекстратор над flowise? Пока не щупал ни тот ни другой но планирую, рассматривал их в режиме vs а не coop
Нельзя было этот маркер "экспертизы" в самом начале проговорить? Столько времени можно было бы сэкономить..
У сообщества в запросах разве нет готового образа чтоб без заморочек api дергать?
Это было бы удобно для
Спасибо за проверку.
Сейчас подумал и пришел к выводу что действительно, prefill этап быстрый и читая только один поток генерации черновика мастер будет большую часть времени простаивать занимая ценную vram, а при необходимости перехватить генерацию для 2+ потоках черновика шанс того что в памяти окажутся необходимые эксперты - небольшой, в итоге случится затык
Классный материал, спасибо!
Вы не запускали (ну вдруг) в спекулятивном режиме oss-20b (драфт) + 120b + выгрузка экспертов для мастера?
Ps тот случай когда ссылка на ТГ канал нужна но её нет )
Зачем на олламе скорость замерять?
vllm и 50 параллельных запросов, тем более если есть h100
На ollama даже 4060 не раскроется, чего уж говорить о картах мощнее
В чате вполне могут использоваться и методы сжатия контекста (поиск/переупаковка участков) и кэш, но вот по api только кэш, оптимизация контекста - забота разработчика
Именно квадратичной сложности от размера контекста не осталось после flash attention. Взялась она из матрицы попарного внимания между токенами, с нюансами вроде: внимание считается для всего что левее конкретного токена
Да, надо было писать на visual basic и делать xbox эксклюзивом
Добрый день. Ограничение max len в 8к, это для а100 подобрано?
Есть в планах тюн для qwen2.5 b14?
Сравнивали свой тюн с RuadaptQwen1.5b ?
Тут суверенными будут даже попугаи, удобно