Настроил напоминалки с кнопками "Сделал" / "Отложить на 30 минут". Но главное — добавил логику: если отложил два раза подряд, бот пишет: "Слушай, давай честно — перенесём на завтра? Или ты реально через полчаса сделаешь?"
Это уже не тупой будильник. Это accountability partner, который не даёт соврать самому себе.
Ради этого арендовать VPS и ставить OpenClaw? :) Задачи такого рода (и даже больше) элементарно реализовать локально через скрипты в несколько строк.
Отсюда вопрос - вы не смотрели что под капотом? Собственно, в чем именно соль проекта? В соло-установке из sh-файла? И что там ставится кроме необходимого именно вам?
Как мне видится, большую часть этой "магии" можно реализовать самостоятельно, и все будет компактнее, понятнее, безопаснее и тд.
Потом, насчет этого:
OpenClaw по умолчанию настроен на максимальную автономность. Там, где Claude Code остановится и спросит "Делаем А или Б?", OpenClaw просто сделает
Наверное не составит труда залезть в исходники и добавить везде, где нужно запросы указанные вами (Делаем А или Б?).
Здесь можно возразить, что смысл проекта "поставить из коробки и пользоваться", но, слушайте, если вы готовы дать слабо-изученной утилите, доступы, например, к почте и право делать с ней (почтой) что угодно, тогда нужно как минимум понимать, что там происходит внутри, иначе это просто моветон. И нужен ли этот посредник в принципе? Не проще ли (и безопаснее!) написать все что реально нужно самому? Или хотя бы взять нужные части/блоки, адаптировать под свои нужды. Ведь там нет никакой магии, вся "магия" в LLM, все остальное обертка для работы с LLM.
В общем, интересно было бы заглянуть под капот этого комбайна. Идея вам к следующему посту :) (у самого пока нет времени)
Понимаю, что это перевод, но позволю себе заметить:
Инференс на GPU не стоит того при объеме VRAM менее 8 ГБ. Если GPU у вас маловато, делайте инференс на CPU
Если мало VRAM, тогда можно разместить на GPU только часть слоев (это может быть большая часть), а остальные слои будут работать на CPU. И такой вариант работает существенно быстрее, чем когда все слои на CPU. Странно, что автор не указал это.
Делается это добавлением параметра:
-ngl, --gpu-layers, --n-gpu-layers N (три варианта написания)
Если модель поддерживает большой контекст, у вас может закончиться память. В таком случае установите меньший размер контекста
Еще можно квантовать KV-кеш на инференсе, что также существенно экономит память, часто без заметной потери качества. По умолчанию KV-кеш в float16 (f16), его можно поменять на:
Bы уверены, что хоть в одном из ныне расплодившихся ИИ есть хоть какая-то связь между словами "вектор" и "A245B511D1451F576C847B9589D980F060A060D7"
Такой связи не будет, потому что "A245B511D1451F576C847B9589D980F060A060D7" это абракадабра, она будет рядом с другими мусорными векторами вроде этого же.
А слово "вектор" будет в пространстве ближе к таким концепциям, как: математика, направление, векторная графика и тд.
Примеры с носом, ключом и глаголом "идти" ну это же совсем банальная вещь, обычный механизм Attention с пол оборота разделит концепции "нос корабля" и "нос, как орган", например, это будут совсем разные векторы. С этим справится даже любой простейший n-граммный механизм
Добрый день! Не вполне понятно о чем именно речь, из абстракта к статье - еще более не понятно. Отдал материал ChatGPT (нет времени читать полностью), позадавал ему вопросы.
Правильно ли я понял суть исследования:
есть датасет LORuGEC с примерами ошибка-исправление ("он сам пошла туда" - "он сам пошел туда")
есть текст который нужно исправить на грамматические ошибки с помощью LLM без существенного изменения текста (чтобы только ошибки исправлял, не перефразируя)
предварительно, c помощью малой модели GECTOR, анализируется текст на ошибки, находятся похожие в представленном датасете LORuGEC
в итоге LLM на вход подаются: примеры найденных ошибок и их исправление (few-shot) + текст который нужно исправить. LLM исправляет текст без существенного его изменения
Параллельно еще проверили разные модели на то, какие ошибки они не понимают.
Не рекомендовал бы использовать совсем модели ниже 12b в фактологии, арифметике и других точных задачах. Сам когда-то тестировал несколько 8b моделей, они все ошибались в банальных вопросах даже про самых известных людей или других моментах, кстати приведенная здесь Мистраль 8b в их числе. Вероятно модели с параметрами выше 20b в этом плане сколько-то лучше, но лично я их бы не использовал для точных вопросов тоже.
А вообще небольшие современные модельки на 4-8-12b очень даже хороши для некоторых задач. Я например использую их для не сложных Function Calling (часто через промпты), для переводов простых текстов (например новостей), для суммаризации, оценки материалов на разные вещи (например сложность чтения), для практики английского (об этом хочу написать статью) и тд тд, много применений можно найти.
Из последних нравятся модельки gemma3-12b, gemma3-4b, qwen3-8b и много других, даже относительно старые gemma2-9b и qwen2-7b тоже хороши и влезают в GPU 12Gb (кванты 6/8).
Когда давно еще тестировал (из малых) например wizardlm2-7b и openchat3.6-8b, поболтать на русском было очень неплохо (тогда еще было не много моделей умеющих нормально в русский), правда модельки уже старые, ну и не для фактологии 100%.
Использую для некоторых локальных задач квантованные НЕ function calling модели, например Gemma2 7b, функции описываю своими словами в промпте, ответ прошу предоставить в формате json-like. Все работает очень хорошо, если не работает сразу, правим промпт. Для разных групп запросов/задач разные промпты. Ваша реализация показалась странной, зачем-то какой фреймворк, который даже между 3мя простейшими функциями не смог выбрать нужную, ну это совсем не серьезно. Простые функции в состоянии определить модель уровня Gemma2 2b (2 млрд параметров), даже прилично квантованная.
Позже хочу написать статью, как я реализовал свой function calling на локальных моделях, можете подписаться на меня здесь.
Может будет интересно, писал здесь небольшой пост по теме: Сколько стоит «Спасибо» для Сэма Альтмана. Там про то, сколько могут стоить простые, фактически бессмысленные, финальные сообщения от пользователя вроде "спасибо", "ок", "пока" и тп (вероятно дорого)
Для расчета глубины используется DepthAnythingV2 (можно и другие аналогичные применять). Для параллакса NumPy и OpenCV, в скриптах же все очевидно вроде
Наверное это будет очень долго. В текущей реализации на нескольких потоках один фильм обрабатывается в районе суток на модели Large. То что вы описали это добавочно еще один ресурсозатратный стек обработки. Да и ни к чему это, по большому счету.
переделал на чтение видео по кадрам из python, инференс, покадровая запись. Никаких 500 гб не понадобилось
Разобрался что вы имели в виду, вероятно речь про промежуточный сервер на VapourSynth. Возможно позже я включу такую опцию, но придется много чего переделать. Да и настораживает, что в процессе где-то что-то зависнет (да хоть свет выключат), а время на обработку фильма от 8 часов и выше, вплоть до 2х суток (в зависимости от продолжительности фильма), и тогда все по новой запускать. Ну и вопрос с потоками, я еще не сравнивал, может покадрово в потоках быстрее будет, но это не точно. Зато место на диске не требует, это да, большой плюс. Аудио-дорожки можно после подключить.
До слез :'))
В тексте есть мета-смыслы :)
Совсем не единственный, причем уже несколько лет как
Улыбнуло :) Еще чтобы дубли новостей убирало, а то часто одна и та же новость сообщается дважды-трижды, причем иногда совсем рядом
Ради этого арендовать VPS и ставить OpenClaw? :) Задачи такого рода (и даже больше) элементарно реализовать локально через скрипты в несколько строк.
Отсюда вопрос - вы не смотрели что под капотом? Собственно, в чем именно соль проекта? В соло-установке из sh-файла? И что там ставится кроме необходимого именно вам?
Как мне видится, большую часть этой "магии" можно реализовать самостоятельно, и все будет компактнее, понятнее, безопаснее и тд.
Потом, насчет этого:
Наверное не составит труда залезть в исходники и добавить везде, где нужно запросы указанные вами (Делаем А или Б?).
Здесь можно возразить, что смысл проекта "поставить из коробки и пользоваться", но, слушайте, если вы готовы дать слабо-изученной утилите, доступы, например, к почте и право делать с ней (почтой) что угодно, тогда нужно как минимум понимать, что там происходит внутри, иначе это просто моветон. И нужен ли этот посредник в принципе? Не проще ли (и безопаснее!) написать все что реально нужно самому? Или хотя бы взять нужные части/блоки, адаптировать под свои нужды. Ведь там нет никакой магии, вся "магия" в LLM, все остальное обертка для работы с LLM.
В общем, интересно было бы заглянуть под капот этого комбайна. Идея вам к следующему посту :) (у самого пока нет времени)
Понимаю, что это перевод, но позволю себе заметить:
Если мало VRAM, тогда можно разместить на GPU только часть слоев (это может быть большая часть), а остальные слои будут работать на CPU. И такой вариант работает существенно быстрее, чем когда все слои на CPU. Странно, что автор не указал это.
Делается это добавлением параметра:
-ngl, --gpu-layers, --n-gpu-layers N (три варианта написания)
Еще можно квантовать KV-кеш на инференсе, что также существенно экономит память, часто без заметной потери качества. По умолчанию KV-кеш в float16 (f16), его можно поменять на:
"f32", "f16", "bf16", "q8_0", "q4_0", "q4_1", "iq4_nl", "q5_0", "q5_1", через параметры:
-ctk, --cache-type-k (два варианта написания) и -ctv, --cache-type-v (два варианта написания), например:
--cache-type-k q8_0 cache-type-v q8_0
Странный логический вывод, но да ладно :)
Такой связи не будет, потому что "A245B511D1451F576C847B9589D980F060A060D7" это абракадабра, она будет рядом с другими мусорными векторами вроде этого же.
А слово "вектор" будет в пространстве ближе к таким концепциям, как: математика, направление, векторная графика и тд.
Примеры с носом, ключом и глаголом "идти" ну это же совсем банальная вещь, обычный механизм Attention с пол оборота разделит концепции "нос корабля" и "нос, как орган", например, это будут совсем разные векторы. С этим справится даже любой простейший n-граммный механизм
Спасибо за модель, ребят! Потестировал на своих локальных задачах (в том числе c использованием function calling), очень понравилась
Добрый день! Не вполне понятно о чем именно речь, из абстракта к статье - еще более не понятно. Отдал материал ChatGPT (нет времени читать полностью), позадавал ему вопросы.
Правильно ли я понял суть исследования:
есть датасет LORuGEC с примерами ошибка-исправление ("он сам пошла туда" - "он сам пошел туда")
есть текст который нужно исправить на грамматические ошибки с помощью LLM без существенного изменения текста (чтобы только ошибки исправлял, не перефразируя)
предварительно, c помощью малой модели GECTOR, анализируется текст на ошибки, находятся похожие в представленном датасете LORuGEC
в итоге LLM на вход подаются: примеры найденных ошибок и их исправление (few-shot) + текст который нужно исправить. LLM исправляет текст без существенного его изменения
Параллельно еще проверили разные модели на то, какие ошибки они не понимают.
Все верно?
Сколько ж оно денег скушает за один консилиум?
Не рекомендовал бы использовать совсем модели ниже 12b в фактологии, арифметике и других точных задачах. Сам когда-то тестировал несколько 8b моделей, они все ошибались в банальных вопросах даже про самых известных людей или других моментах, кстати приведенная здесь Мистраль 8b в их числе. Вероятно модели с параметрами выше 20b в этом плане сколько-то лучше, но лично я их бы не использовал для точных вопросов тоже.
А вообще небольшие современные модельки на 4-8-12b очень даже хороши для некоторых задач. Я например использую их для не сложных Function Calling (часто через промпты), для переводов простых текстов (например новостей), для суммаризации, оценки материалов на разные вещи (например сложность чтения), для практики английского (об этом хочу написать статью) и тд тд, много применений можно найти.
Из последних нравятся модельки gemma3-12b, gemma3-4b, qwen3-8b и много других, даже относительно старые gemma2-9b и qwen2-7b тоже хороши и влезают в GPU 12Gb (кванты 6/8).
Когда давно еще тестировал (из малых) например wizardlm2-7b и openchat3.6-8b, поболтать на русском было очень неплохо (тогда еще было не много моделей умеющих нормально в русский), правда модельки уже старые, ну и не для фактологии 100%.
Спасибо за статью, сэкономили часть времени.
Писал статью по этой теме, внизу там есть ссылки на оригинал и апскейлнутое видео:
https://habr.com/ru/articles/904784/
Спасибо большое! Удивительно, что до сих пор применяются такие относительно старые модели как Tacotron и Tortoise.
Если получится уточнить:
Как происходит тюн через sft, это специально записанные отрывки текстов с нужной интонацией?
Цитата:
модель отлично читала вслух научпоп, а художественная литература давалась ей с трудом. Но в итоге мы научили её читать одинаково хорошо.Тот же вопрос.
И есть ли где посмотреть больше технических деталей?
Использую для некоторых локальных задач квантованные НЕ function calling модели, например Gemma2 7b, функции описываю своими словами в промпте, ответ прошу предоставить в формате json-like. Все работает очень хорошо, если не работает сразу, правим промпт. Для разных групп запросов/задач разные промпты. Ваша реализация показалась странной, зачем-то какой фреймворк, который даже между 3мя простейшими функциями не смог выбрать нужную, ну это совсем не серьезно. Простые функции в состоянии определить модель уровня Gemma2 2b (2 млрд параметров), даже прилично квантованная.
Позже хочу написать статью, как я реализовал свой function calling на локальных моделях, можете подписаться на меня здесь.
Может будет интересно, писал здесь небольшой пост по теме: Сколько стоит «Спасибо» для Сэма Альтмана. Там про то, сколько могут стоить простые, фактически бессмысленные, финальные сообщения от пользователя вроде "спасибо", "ок", "пока" и тп (вероятно дорого)
Библиотека чего? Не вполне понятен вопрос.
Для расчета глубины используется DepthAnythingV2 (можно и другие аналогичные применять). Для параллакса NumPy и OpenCV, в скриптах же все очевидно вроде
Наверное это будет очень долго. В текущей реализации на нескольких потоках один фильм обрабатывается в районе суток на модели Large. То что вы описали это добавочно еще один ресурсозатратный стек обработки. Да и ни к чему это, по большому счету.
В статье же написано про VapourSynth, как один из вариантов для связки с Python.
Разобрался что вы имели в виду, вероятно речь про промежуточный сервер на VapourSynth. Возможно позже я включу такую опцию, но придется много чего переделать. Да и настораживает, что в процессе где-то что-то зависнет (да хоть свет выключат), а время на обработку фильма от 8 часов и выше, вплоть до 2х суток (в зависимости от продолжительности фильма), и тогда все по новой запускать. Ну и вопрос с потоками, я еще не сравнивал, может покадрово в потоках быстрее будет, но это не точно. Зато место на диске не требует, это да, большой плюс. Аудио-дорожки можно после подключить.
Все таки наверное могут, раз каждый квартал выходят бенчи, где LLM решают задачи лучше стольки-то процентов людей, задачи, которые раньше не видели.