rPman

Это фича модели, сами разработчики об этом заявляют, что более менее адекватно она будет работать только с английским и китайским.

Используй другие модели до и после, для перевода вопроса с русского на английский и обратно.

И еще момент, 8b модель это дистиляция, у них конечно получилось нечто шикарное именно дистиляцией (особенно qwen модели) но все же 8b очень слабая модель, толку от нее будет мало.

https://huggingface.co/collections/deepseek-ai/dee...

Если тебя устраивала llama3.1 8b, то попробуй ее тюн на основе deepseek r1, говорят дистилированные модели стали неожиданно лучше чем то на чем они основаны, забрав у deepseek умение рассуждать по типу o1

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

Ну и чем больше весов будет у модели тем лучше, говорят deepseek-r1-llama70b очень очень хороша, и требования у нее такие что взять на vast.ai машину за дешево можно ею пользоваться на 'всю катушку'

Ну и расуждающие модели очень по разному будут работать от разных промптов, а уж если будешь вмешиваться в рссуждения (условно останавливаешь периодически, и просишь эту или другую модель проверить рассуждения, подправить, вернуть первоначальный запрос и продолжить рассуждения)

Могу только догадываться (странно что это появилось после установки ssd), но выглядит все следующим образом.

Для выключения питания, операционная система сначала завершает все процессы и службы, затем переводит файловые системы в readonly (со сбросом кеша) и посылает с помощью acpi сигнал на выключение... но из-за плохой реализации поддержки в некоторых брендовых решениях (собственно пилится это реверсинженерингом, а компании производители железа не шевелятся публиковать нормальные спецификации или скорее намеренное вредительство, если текущая ОС не windows, то поддержка acpi ломается) это не работает.

Правильно - починить поддержку acpi (может погуглить название своей материнки/чипсета добавив acpi linux или еще как).

попробуйте прописать в grub в опциях ядра acpi_osi="Windows 2009"

Очевидно для того что бы бесплатно это делать, вам нужно где то добыть данные, и уже работать с ними самостоятельно.

Сам не пробовал, но гугл выдает кучу примеров работы с яндекс картами в браузере с помощью selenium, т.е. представляйтесь обычным пользователем и кликайте по карте... со всеми вытекающими от этого проблемами.

Я думаю лучше заплатить

Если это python приложение, то благодаря venv можно запускать где угодно (с оговорками поддержки чего то типа nvidia gpu)

Если это бинарник - то зависит, под какую версию системных библиотек (например glibc) это ПО было собрано. Обычно пишут, под какую версию debian/ubuntu оно собрано и предлагают несколько вариантов. Бывает ещё есть зависимости других библиотек, но с ними можно вручную разобраться.

И конечно, спасибо docker, можно почти все запускать в любом окружении. А ещё есть flatpak, snap, lxc и виртуальном

eclipse (Адон для c# acute), такой мощный комбайн еще поискать, был за долго до появления phpstorm или vs code

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

Но, скорее всего просто будет для ручного переключения делать несколько шевелений на роутере и может быть на машинах... в очень похожей ситуации я подсмотрел, какие http запросы делает роутер, когда меняешь настройки, и повторил их в curl (скопировав его из консоли разработчика браузера), и настроив пару простеньких скриптов, которые переключал настройки роутера по моему выбору на основной и резервный (параллельно запускал команду повторного получения настроек dhcp на машине, так как на роутере нельзя было изменить его автообновления на меньше часа).

Так как роутеры у тебя получается в одной локальной сети, то по уму можно было бы настроить что бы основной интернет выводил машины в сети по одному ip адресу (настройка у клиентов - шлюз по умолчанию), а резервный по второму, соответственно на машинах достаточно было бы сменить шлюз по умолчанию, что бы они выходили по нужному (сейчас у меня так в локальной сети vpn настроен)

Попробуй добавить disable_content_type_detection =True в context.bot.send_document

Существуют сетевые протоколы, которые с некоторой долей везения будут работать даже если ОБЕ стороны за NAT (т.е. и сервер и пользователь), основаны на UDP и для их работы обычно требуется третий сервер с ip адресом, но не для передачи данных, а только для соединения.

Наилучшим приложением, которое позволило бы работать с данными в нескольких местах с их синхронизацией по сети, даже при отсутствии выделенного ip адреса - это syncthing (opensource, работает везде, по до все платформы, от PC до android и iphone).

Под вашу задачу может и не подойдет, так как это инструмент синхронизации данных, которые все должны храниться на обоих сторонах... зато работает без каких либо телодвижений и настройки (ну может в северной кореи и будущей России потребует настройку своего STUN сервера, у syncthing он тоже opensource) и естественно не требует хранение этих данных где то в облаке.

Добавляешь в базу данных триггеры на delete, update и insert, для каждой таблицы (код создания можно сгенерировать по списку таблиц простым скриптом), которые будут заполнять дополнительно созданные тобой таблицы (дублирующую оригинальную структуру или только там что тебе нужно переносить), в которых будут обновленные данные и поля со временем события и его типом. Время тут будет идентификатором (можешь сделать с миллисекундами, параноики могут использовать автоинкрементируемое поле, только сделать его общим на все таблицы, что не выгодно) и единственным индексируемым полем

p.s. для delete можно отдельную таблицу пилить, что бы не тягать лишние колонки пустые (на сколько я помню во многих базах null может занимать заметно места на диске сравнимо с данными)

Затем пишешь простенькое приложение, которое будет считывать эти таблицы (фильтруя на время запуска этого скрипта или по текущему максимальному значению autoincrement, что бы не затрагивать те данные что появились в процессе передачи), отсылать один в один запросы на целевую базу (в т.ч. в том же порядке!) и чистить из этих лог таблиц записи, которые успешно были переданы (ошибки аккуратно отслеживать, например в удаленную базу записали а из локальной не удалили).

Этот скрипт может крутиться в бесконечном цикле, мониторя наличие изменений в базе (например постим инвент из тригера, а на том же php мониторим этот ивент с помощью ibase_wait_event, само собой это можно делать из других языков программирования).

В похожей ситуации весь код был где то строк 100, еще столько же код генерации sql для создания триггеров (ну может больше, если информация о структуре будет не вручную задана).

Задержка переноса данных в этом случае будет равна времени их передачи.. без изменения кода самого приложения, это не изменить

Для начала у antropic есть рабочее пространство https://console.anthropic.com/ где можно работать через их api

Еще можно воспользоваться сторонними провайдерами, я например использую openrouter.ai (не без глюков но доступна даже оплата в криптовалюте, но к сожалению нужен vpn/прокси), они предоставляют доступ к куче моделей, включая труднодоступные o1, а так же разных провайдеров, и все в одном месте, плюс свой api (кажется дублирует openai)

Практически во все популярные IDE среды для разработки есть плагины для использования ИИ по разработке... достаточно указать api key (и иногда указать url, так как можно использовать локальные) и получить результат сразу в редакторе.

p.s. Первым делом топ ии модели, особенно openai и anthropic claude sonnet их разработчики обучают на программирование, и в т.ч. на работу с их api (openai даже переобучивает, что проблемы создает), ты можешь спокойно попросить их написать необходимые скрипты по твоей логике и будет у тебя свой чат или что тебе нужно.

Например, мне нужно было что бы мои вопросы проходили через чат с моделью, где я задаю типичные шаблонные вопросы, получаю ответ и продолжаю чат дальше,.. игнорируя промежуточные ответы, выводить только последний (это я пилил до появления рассуждающих o1), это приложение gpt4o написал за пару промптов и несколько минимальных исправлений.

Я знаю, очень часто у компании нет нескольких миллионов рублей, что бы заплатить сторонней компании на атусорсе, что бы реализовать свои хотелки, к тому же, выбрав компанию разработчика, вы подсядете на его вендорлок (искусственно созданные усложнения, затрудняющие поддержку другими разработчиками) и сменить уже почти не получится, а зная это, компания будет требовать даже за простую работу высокую стоимость и дальше.

Правильный подход, любой компании, где работает от порядка 100 человек, выращивать внутри свой отдел по разработке и поддержке своего внутреннего ПО. К сожалению очень сложно убедить руководство компании нанимать для этого готовых специалистов, которые, временами (по нескольку месяцев), не будут иметь работы в принципе и в лучшем случае будет нанят один или несколько человек, совмещающие должности, да еще и без значительного опыта. Именно поэтому я сказал выращивать - выбирать желающих среди своих сотрудников с малым опытом но не совсем новичков конечно, пусть совмещают.

Готовое решение никогда не будет полностью готовым! Всегда в нем будет требоваться что то доработать под нужды организации. Именно на этом (и не только) зарабатывают 1С разработчики, коробочная версия продукта, с хорошей поддержкой законодательства и возможностью доработки... только уж дорого получается.

p.s. задачу нужно начинать с проведения анализа, составления ТЗ (даже если кажется что это простенькая задача),.. и где то в самом низу можно подумать о выборе технологих и фреймворков, уже после того как уже есть люди, которые будут готовы это решать и в них разбираются

Если все же хотите ответ на вопрос - выбирайте веб технологии. Работа на клиентских устройствах в браузере решит проблемы совместимости с железом. Если выберите устаревшую но не потерявшую актуальность технологию генерации html на бакэнде, то требования к клиентскому железу будут еще и самые низкие (на самом деле можно писать на javascript интерфейсы для браузера правильно, эффективно и не сильно сложно, но выросло огромное количество специалистов, замусоривших рынок катастрофическим оверинженерингом, и мне кажется уже и не помнят что можно просто делать все).

Задача в вашей постановке не выглядит сложной, если убрать дизайн и рюшечки, решается опытным разработчиком за пару-тройку вечеров.. но наверняка есть невысказанного много

Информация обо всех событиях складывать в машиночитаемом виде, не важно каком, выбор зависит от задачи, от нагрузки, от наличия денег и т.п.

Машиночитаемом, это значит информация, разделенная на элементы (поля, структуры или что у тебя еще имеет значение) должна храниться в таком виде, что бы эти элементы можно было извлечь без дополнительной работы, а при наличии больших объемов и требованиях аналитики. еще и с возможностью индексации на их основе.

Самое простое - это текстовый лог в формате jsonl, это сериализованный в json по строчно на каждое событие (а атрибуты события - атрибуты объекта json). В некоторых случая json не поддерживается, например какой-нибудь fail2ban его не умеет, но умеет с помощью регулярных выражений извлекать данные из текста, тогда данные можно собирать и разделять в виде, удобным для последующей обработке регулярными выражениями.

Как только объемы событий выходят на гигабайты, текстовые логи становятся неудобными (а может и раньше) и данные лучше складывать в какую-либо базу данных... кому то нравится nosql (неудобна для анализа), кто то сразу в sql базы складывает (они удобны тем что могут хорошо масштабироваться на несколько устройств или машин). Те, кому нужно совсем много данных, могу задуматься о предварительном анализе данных через промежуточный сервис (т.е. для того что бы оставить сообщение, приложение по сети отправляет лог-серверу запрос), который делает минимальный анализ, выделяет что сохранить и как, проводит базовую аналитику и сохраняет в базы данных (лог база данных может быть сложнее чем пара табличек).

Помимо проблем с перегревом, есть ещё не менее неуловимые ошибки, из-за нехватки или нестабильности электропитания под нагрузкой.

Для начала нужно удостовериться, что проблема не в программе, проведя синтетические тесты нагрузки, по отдельности на диск, на память, на процессор (это заодно позволит выявить проблемные комплектующие)...

Есть еще instr это однозначно быстрее like

Ну и fulltext индексы конечно, искать с некоторым языком запросов

p.s. если искать в строках базы приходится ограниченное количество слов (т.е. грубо говоря список слов определяется проектом, а не свободным вводом от пользователя) то можно заранее (при добавлении строк) построить свой собственный индекс, размещая факт наличия подстроки в строке boolean полем true/false или создав соответствующие таблицы (если наличие слов сильно разряжено - это эффективнее), где наличие записи - факт наличия слова.

Например у тебя искать нужно три слова: man, woman, child, соответственно создаешь три boolean колонки has_man, has_woman, has_child в той же таблице где анализируемая строка и заполняешь их триггером.

Или если тот же пример но через таблицы, то в искомой таблице у тебя должно быть primary key поле, и ты создаешь на каждое слово по таблице has_man, has_woman, has_child, с единственным полем id, в эти таблицы помещаешь запись с id из искомой таблицы, если в ее строке есть это слово.. это так же можно делать триггером.

Низкое качество каждого кадра видео по отдельности, но человеческий мозг вытягивает из нескольких соседних кадров информацию и распознает

У тебя условно два пути:
1. попытаться из видео какими-то методами, не обязательно нейронной сетью, вытянуть повышение качества изображения, и уже на нем проводить распознавание
2. собрать 3d обучающую выборку, где одним примером является серия соседних кадров одного и того же участка (можно кстати комбинировать методы из 1 пути, для центрирования искомой части изображения, что бы можно было распознавать в движении)

Второй метод универсальнее, и в каком то смысле проще, если ты сможешь собрать большую обучающую выборку.. но первый даст прогнозируемое качество.

Для первого, пример использования - stacking, используемый в астрофотографии