Nemotron 3 Nano от NVIDIA - на удивление хорошо себя проявляет. С русским работает достаточно хорошо, но не идеально - иногда выдает неправильные слова или путает падеж или род. С Qwen3-30B-A3B подобных проблем не замечал.
Думающая модель, причем думает на английском (что плюс - обучающая выборка больше на английском, что повышает качество ответов) и при этом очень немного токенов тратит на само обдумывание. Что еще понравилось - вывод по вопросу может сделать в начале ответа (таблицей), а потом уже начинает расписывать детали.
Но вот скорость заметно ниже Qwen3-30B-A3B при выводе на CPU. Хотя тут скорее квант виноват - unsloth/Nemotron-3-Nano-30B-A3B-UD-Q2_K_XL.gguf в 1.5-2 крупнее вариантов Qwen3-30B-A3B в UD-Q2_K_XL, не смотря на то, что обе идут с одинаковым (в округлении) числом параметров (30B-A3B).
Лично я продпочитаю в .gitignore добавлять сразу все скрытые файлы, делая исключения для системных. Удобно в любой момент добавить временный скрытый файл/каталог с чем-либо (от todo-листа до бекапа продовой БД).
Не проверять код после LLM - это, конечно, мощно. Никакая документация не спасет от галлюцинаций. Даже если все нюансы описывать. Да и в целом, уровень понимания у LLM на низком уровне (хотя тут грамотный промт вполне помогает).
Да и в целом, именно написание кода - далеко не самая большая проблема в разработке ПО.
P.S. хорошо бы более детальное описание проектов иметь для понимания их сложности. По предоставленным описаниям складывается впечатление, что это достаточно небольшие проекты (и соответственно простые просто в силу размера)...
LLM хорошо справляется с тем, что часто встречалось в обучающей выборке и плохо с тем, что встречалось редко (или вообще не встречалось). Поэтому чем специфичней запрос - тем хуже ответ.
Кроме того, у LLM нет понимания что она делает и почему - так что сколько-нибудь сложные вещи она делает сильно хуже.
Именно поэтому LLM сравнивают со старательным джуном - он очень старается, но ни навыков, ни понимания предметной области нет. Так что решение надо очень тщательно проверять. Причем у LLM подвох может быть в самых тривиальных вещах (где реальный джун справится без проблем).
Как итог - LLM хорошо справляется с написанием черновика - этого не отнять (да и по текущей статье это тоже видно). В работу может и не пойдет, но как отправная точка - вполне себе (после тщательной вычитки).
P.S. архитектуру LLM прорабатывает ничуть не лучше, чем пишет код. Тривиальные вещи - очень даже неплохо (особенно если они в промте прописаны). Но не более.
Хак не странный, а вполне популярный ) Хотя лично для меня, контр-интуитивно, что отдельная сортировка будет быстрее. Хотя замеров на этот счет я не делал, да и не интересовался в целом этим нюансом с TreeMap. Надо будет как-нибудь "поиграться" с TreeMap и HashMap )
Нюансов хватает в алгоритмах. И O(1) не всегда быстрее O(log N) или O(N) - вопрос алгоритма и размеров данных.
Та же сортировка - да, сортировка Хоара (quicksort) быстра (O(N * log N)). Но на небольших массивах тот же "пузырек" быстрее (O(N*N)).
А в некоторых случаях сортировать можно и за O(N) - например, подсчитав количество разных элементов (если память позволяет) - хотя и не факт, что это будет быстрее более традиционных алгоритмов )
Так что выбор TreeMap может быть оправданным. Как минимум - когда важен порядок ключей ) Хотя HashMap - крайне универсальное решение, спору нет.
Если нужно только искать и вставлять бинарные деревья никому не нужны — просто используйте хешмап.
HashMap имеет сложность вставки O(N) в худшем случае (ресайз). Так что бинарные деревья могут быть нужны просто ради более-менее предсказуемой скорости вставки. Хотя, если честно, не сказать что это распространенная проблема - HashMap обычно более чем достаточно )
Qwen3-Coder-30B-A3B-Instruct - просто чтобы знать, сколько можно выжать из модели попроще. Большие модели все-таки достаточно медленными получаются.
P.S. еще можно поиграться с параллельным выполнением запросов (для пакетной обработки может быть интересно) - у меня локально pp/s и tg/s сравнялись в итоге (при 8 запросах на 8 ядер (без учета HT)).
Minimax-m2, gpt-oss 120b и Qwen3-Coder - они все MoE, с активностью только части параметров. Ну и есть смысл использовать квант UD-Q2 от unsloth - достаточно неплохо себя показывают )
ИИ может объяснить, как работать с незнакомыми человеку инструментами, но и это понимание ИИ будет поверхностным, и код на основе этого понимания будет некачественным. Часто полезно просто заглянуть в документацию, а не слушать ИИ.
Да, но бывают ситуации, когда LLM отвечает гораздо подробнее и обстоятельнее официальной документации (сталкивался с таким на директивах nginx).
Я всегда избегал работы с плохим кодом, потому что знаю, какая это сложная, неэффективная и неинтересная работа, а теперь я буду вынужден погружаться с головой в это болото, потому что клиенты этого хотят.
Навык писать код и навык читать код - это, к сожалению, достаточно разные навыки. Само по себе изучение чужого кода, понимание замысла разработчика - это сложно. Для кода "с душком", это еще сложнее - сложно понять, что перед тобой - фича, баг или тех.долг? Но с LLM, когда осознаешь, что он "любит" галлюцинировать, при этом выдавая крайне правдоподобный текст - становится совсем грустно. Скорость LLM сильно превышает мою скорость понимания этого код.
Так что пока, лично для меня, LLМ хороши в качестве "просто спросить, если лень лезть в поисковик" и для подготовки примеров/заготовок нужного мне кода.
С чем-то более сложным LLM не справляется.
Впрочем, есть и успешные отзывы - когда LLM сумел пойти на пользу проекту. Вероятно, польза от LLM сильно от проекта зависит. И чем нестандартнее проект - тем LLM себя хуже чувствует.
Согласен, JSON далеко не идеален, хотя LLM достаточно неплохо с ним дружит. Да и от формата ответа многое зависит - тот же "массив строк кода" останется человеко-читаемым (и экранировать надо будет по минимуму).
Вообще, в llama.cpp можно задать свой формат вывода - но надо определять грамматику в формате GBNF (GGML BNF). Но это не самый общепринятый формат, как я понимаю - у JSON-схемы поддержка гораздо шире.
Это не "спор из прошлого", а "идущий сейчас спор", что несколько больший накал страстей имеет ).
И спор - это просто как пример. Мой посыл в том, что только что добавленный бот не может сделать ничего полезного - и это портит первое впечатление.
Я согласен, не-ахти-какая-проблема, особенно если говорить о бесплатном боте. Но тем не менее, первое впечатление - это важно.
P.S. можно сделать отдельного юзер-бота исключительно для доступа к истории сообщений. А обычный, при добавлении, может присылать в чат что-то вроде "для доступа к истории сообщений добавьте этого юзер-бота, он просканирует историю сообщений и выйдет из чата".
Или может есть возможность самому боту добавлять в чат изер-бота (по отдельной команде, например)...
Nemotron 3 Nano от NVIDIA - на удивление хорошо себя проявляет. С русским работает достаточно хорошо, но не идеально - иногда выдает неправильные слова или путает падеж или род. С Qwen3-30B-A3B подобных проблем не замечал.
Думающая модель, причем думает на английском (что плюс - обучающая выборка больше на английском, что повышает качество ответов) и при этом очень немного токенов тратит на само обдумывание.
Что еще понравилось - вывод по вопросу может сделать в начале ответа (таблицей), а потом уже начинает расписывать детали.
Но вот скорость заметно ниже Qwen3-30B-A3B при выводе на CPU. Хотя тут скорее квант виноват - unsloth/Nemotron-3-Nano-30B-A3B-UD-Q2_K_XL.gguf в 1.5-2 крупнее вариантов Qwen3-30B-A3B в UD-Q2_K_XL, не смотря на то, что обе идут с одинаковым (в округлении) числом параметров (30B-A3B).
Лично я продпочитаю в .gitignore добавлять сразу все скрытые файлы, делая исключения для системных. Удобно в любой момент добавить временный скрытый файл/каталог с чем-либо (от todo-листа до бекапа продовой БД).
Не проверять код после LLM - это, конечно, мощно. Никакая документация не спасет от галлюцинаций. Даже если все нюансы описывать. Да и в целом, уровень понимания у LLM на низком уровне (хотя тут грамотный промт вполне помогает).
Да и в целом, именно написание кода - далеко не самая большая проблема в разработке ПО.
P.S. хорошо бы более детальное описание проектов иметь для понимания их сложности. По предоставленным описаниям складывается впечатление, что это достаточно небольшие проекты (и соответственно простые просто в силу размера)...
LLM хорошо справляется с тем, что часто встречалось в обучающей выборке и плохо с тем, что встречалось редко (или вообще не встречалось). Поэтому чем специфичней запрос - тем хуже ответ.
Кроме того, у LLM нет понимания что она делает и почему - так что сколько-нибудь сложные вещи она делает сильно хуже.
Именно поэтому LLM сравнивают со старательным джуном - он очень старается, но ни навыков, ни понимания предметной области нет. Так что решение надо очень тщательно проверять. Причем у LLM подвох может быть в самых тривиальных вещах (где реальный джун справится без проблем).
Как итог - LLM хорошо справляется с написанием черновика - этого не отнять (да и по текущей статье это тоже видно). В работу может и не пойдет, но как отправная точка - вполне себе (после тщательной вычитки).
P.S. архитектуру LLM прорабатывает ничуть не лучше, чем пишет код. Тривиальные вещи - очень даже неплохо (особенно если они в промте прописаны). Но не более.
Хак не странный, а вполне популярный )
Хотя лично для меня, контр-интуитивно, что отдельная сортировка будет быстрее. Хотя замеров на этот счет я не делал, да и не интересовался в целом этим нюансом с TreeMap. Надо будет как-нибудь "поиграться" с TreeMap и HashMap )
Нюансов хватает в алгоритмах. И O(1) не всегда быстрее O(log N) или O(N) - вопрос алгоритма и размеров данных.
Та же сортировка - да, сортировка Хоара (quicksort) быстра (O(N * log N)). Но на небольших массивах тот же "пузырек" быстрее (O(N*N)).
А в некоторых случаях сортировать можно и за O(N) - например, подсчитав количество разных элементов (если память позволяет) - хотя и не факт, что это будет быстрее более традиционных алгоритмов )
Так что выбор TreeMap может быть оправданным. Как минимум - когда важен порядок ключей )
Хотя HashMap - крайне универсальное решение, спору нет.
HashMap имеет сложность вставки O(N) в худшем случае (ресайз).
Так что бинарные деревья могут быть нужны просто ради более-менее предсказуемой скорости вставки. Хотя, если честно, не сказать что это распространенная проблема - HashMap обычно более чем достаточно )
Предлагаю сравнить 3 варианта (если по памяти влезет):
Qwen3-Coder-480B-A35B-Instruct.
Qwen3-Coder-480B-A35B-Instruct + Qwen3-Coder-30B-A3B-Instruct.
Qwen3-Coder-30B-A3B-Instruct - просто чтобы знать, сколько можно выжать из модели попроще. Большие модели все-таки достаточно медленными получаются.
P.S. еще можно поиграться с параллельным выполнением запросов (для пакетной обработки может быть интересно) - у меня локально pp/s и tg/s сравнялись в итоге (при 8 запросах на 8 ядер (без учета HT)).
А есть замеры скорости в виде таблицы в
pp/sиtg/s(как обычно и принято для замеров LLM)?Все-таки на графиках конкретные результаты не видны...
И можно замерить скорость работы со спекулятивным декодированием (параметр
--model-draft FNAME) - должен заметно ускорять вывод на больших моделей.Minimax-m2, gpt-oss 120b и Qwen3-Coder - они все MoE, с активностью только части параметров.
Ну и есть смысл использовать квант UD-Q2 от unsloth - достаточно неплохо себя показывают )
Да, но бывают ситуации, когда LLM отвечает гораздо подробнее и обстоятельнее официальной документации (сталкивался с таким на директивах nginx).
Навык писать код и навык читать код - это, к сожалению, достаточно разные навыки. Само по себе изучение чужого кода, понимание замысла разработчика - это сложно. Для кода "с душком", это еще сложнее - сложно понять, что перед тобой - фича, баг или тех.долг? Но с LLM, когда осознаешь, что он "любит" галлюцинировать, при этом выдавая крайне правдоподобный текст - становится совсем грустно. Скорость LLM сильно превышает мою скорость понимания этого код.
Так что пока, лично для меня, LLМ хороши в качестве "просто спросить, если лень лезть в поисковик" и для подготовки примеров/заготовок нужного мне кода.
С чем-то более сложным LLM не справляется.
Впрочем, есть и успешные отзывы - когда LLM сумел пойти на пользу проекту. Вероятно, польза от LLM сильно от проекта зависит. И чем нестандартнее проект - тем LLM себя хуже чувствует.
xkcd дает более простой ответ )))
А если распределение не важно - то достаточно
return rand5())))Вопрос финансов - только и всего.
Слабое и дорогое железо, а время инженера дешево - "Оптимизация наше все!".
Быстрое и дешевое железо, а время инженера дорого - "Железо все вытянет!".
Добавить сюда нюансы принятия решений (поиск "серебряной пули", личные интересы и прочее-прочее-прочее) и получим текущую картину.
У ollama под капотом как раз llama.cpp - так что не все так однозначно )
Согласен, JSON далеко не идеален, хотя LLM достаточно неплохо с ним дружит.
Да и от формата ответа многое зависит - тот же "массив строк кода" останется человеко-читаемым (и экранировать надо будет по минимуму).
Вообще, в llama.cpp можно задать свой формат вывода - но надо определять грамматику в формате GBNF (GGML BNF). Но это не самый общепринятый формат, как я понимаю - у JSON-схемы поддержка гораздо шире.
Если задействовать structured output, то вероятно, размер промта можно будет значительно сократить.
Но в чате уже не отправить вопрос (хотя может есть какой софт с поддержкой задания формата ответа). И, вероятно, на формат JSON придется перейти.
Если в системный промт закинуть - то он в кеш попадет один раз и не будет несколько раз обрабатываться (в идеале).
Описание и примеры есть тут: https://ollama.com/blog/structured-outputs
Как понимаю, в поле format задается JSON-схема ответа - и этого достаточно.
Судя по всему, с JSON в основном и работает (есть поддержка у многих провайдеров LLM).
В llama.cpp можно и с другими форматами работать - но надо грамматику для них писать (см https://github.com/ggml-org/llama.cpp/blob/master/grammars/README.md). Но не факт, что ollama передает этот параметр в llama.cpp (я не пробовал с этим играться).
Это не "спор из прошлого", а "идущий сейчас спор", что несколько больший накал страстей имеет ).
И спор - это просто как пример. Мой посыл в том, что только что добавленный бот не может сделать ничего полезного - и это портит первое впечатление.
Я согласен, не-ахти-какая-проблема, особенно если говорить о бесплатном боте. Но тем не менее, первое впечатление - это важно.
P.S. можно сделать отдельного юзер-бота исключительно для доступа к истории сообщений. А обычный, при добавлении, может присылать в чат что-то вроде "для доступа к истории сообщений добавьте этого юзер-бота, он просканирует историю сообщений и выйдет из чата".
Или может есть возможность самому боту добавлять в чат изер-бота (по отдельной команде, например)...