У меня сервер на linux и я устанавливал llama.cpp через brew - это неправильный способ? о_О
Покопался в логах. Действительно дело в GPU. Буду копать в эту сторону. Спасибо!
~$ llama-server -hf lmstudio-community/gpt-oss-120b-GGUF --host 0.0.0.0 --port 8080 -c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 25 warning: no usable GPU found, --gpu-layers option will be ignored warning: one possible reason is that llama.cpp was compiled without GPU support warning: consult docs/build.md for compilation instructions
Что без флагов 11t/s что с -c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 2511t/s, что с -c 32000 -ngl 99 -ub 4092 -b 4092 -cmoe11t/s. вообще никакого влияния на производительность 🤷
Недавно проскакивала статья, в которой как раз освещался успешный пример механизма снабжения органоидов питательными веществами. Вместо кровеносных сосудов использовалась матрица желобков на поверхности, на которой выращен органоид. Благодаря этому их получалось в большие (относительно) горизонтальные кластеры выращивать.
В cline и десятках его форков и аналогов есть такое понятие как чекпоинты - возможность откатываться по истории коммуникации. При этом там на выбор: откатить только историю, только состояние файлов, и то и другое.
Как раз, когда к диалогу нужно кроме пары фраз добавлять ещё и файлы - чаты тупо требуют больше телодвижений по сравнению со всеми остальными альтернативами. Чаты просто не особо для этого предназначены. Чаты больше подходят для переписки. А для редактирования кода, как не удивительно, редакторы кода (:
В IDE вы можете передать LLM сразу несколько файлов, так же просто, как заменьшонить коллегу в корпоративном чате - через @. Через него же можно сразу целую директорию добавить в контекст. Можно выделить часть лога и в один хоткей добавить именно эту часть, а не весь файл. Более того, можно сказать ему самостоятельно запустить код и получить из stdio или из файла логи и их обработать. То есть ещё до появления самих логов, сказать ему как их обработать.
P.S. я не считаю проект плохим или что-то в этом роде. Задача которую вы решаете актуальна и решается каждым из упомянутых мною инструментов индивидуально. Более того, существуют отдельные LLM которые натренированы выполнять лишь одну задачу - применять изменения в формате, аналогичном вашему. Я лишь удивлён что вы решаете её в отрыве от инструментов, которые решают её сейчас в рамках своей работы.
Контекстное окно от инструмента очень даже зависит, в colipot например я не могу использовать Gemini 2.5 Pro с её 2 млн токенов
А Cline, RooCode, KiloCode и десятки их аналогов? Зачем останавливаться на единственном инструменте в котором нельзя?
бесплатно я его как cli не могу использовать вовсе
Почему? Во первых у Gemini есть свой cli, а во вторых есть aider и десятки других клонов claudecode.
решение сложных задач вроде исправления багов в запутанных legacy исходниках или разработку с нуля любых штук хотя бы немного сложнее тривиальных приходится рубить на несколько чатов
Конечно! И это относится к любому инструменту. Что Cursor, что Cline, что Claude Code. Ну как ваш формат помогает эту проблему решать? Благодаря нему можно ввести один диалог на 50 млн токенов с хорошим результатом? А если нет то чем плохо патч которым пользуются IDE? Только его не приходится копировать и вставлять, это происходит нативно
Во первых: если критично "прятать" от LLM часть кода - есть cline в котором нет "индексации" кода и можно как раз точечно передавать только нужные файлы.
Во вторых: контекстное окно модели одинаковое и в IDE и в чате. От инструмента оно не зависит. Если вы жалуетесь на размер контекстного окна, то эти претензии актуальны и для чата. Разве что у чата интерфейс не удобный и приходится городить костыли вроде того, что в статье описан.
В третьих: что у вас за задачи такие, которым 1-2 млн контекстного окна мало? Это огромный массив текста, который человек будет читать десятки часов. Пару лет назад, когда окна были по паре десятков тысяч токенов, претензии были уместны. Но не в 2025 году. Но даже если это реально проблема - замена IDE на чат её никак не решает
Практически все.. Некоторые ещё студенты
Не способность закончить проект "универ" - ред флаг для работы.
У меня сервер на linux и я устанавливал llama.cpp через brew - это неправильный способ? о_О
Покопался в логах. Действительно дело в GPU. Буду копать в эту сторону. Спасибо!
~$ llama-server -hf lmstudio-community/gpt-oss-120b-GGUF --host 0.0.0.0 --port 8080 -c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 25warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
warning: consult docs/
build.mdfor compilation instructionsчуда не произошло ):
3.6 t/s при любых раскладах
GPU 1x RTX 3060
CPU 26 Cores
Memory 51.2 GB
Можете дать ссылку на cuda версию? не понимаю как отличить её от cpu на huggingface
Запускал как рекомендует сам huggingface
🤦 сорян, не ту модель скопировал в сообщение. Вот:
unsloth/gpt-oss-120b-GGUF- её использовал. Gemma 3 12b показывает гораздо выше t/s на такой карте.Сейчас проверяю ту же OSS-120B на 3060. Надеюсь будет заметна разница в скорости. через полчаса-час скину результаты
Попробовал
unsloth/gemma-3-12b-it-GGUFна:GPU: 1x RTX 5090
CPU: 48 Cores
Memory: 128 GB
Disk: 200 GB
Что без флагов 11t/s что с
-c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 2511t/s, что с-c 32000 -ngl 99 -ub 4092 -b 4092 -cmoe11t/s. вообще никакого влияния на производительность 🤷А можно такое повернуть с ollama?
Думаю стоит сразу два домена регистрировать - с обычной у и нескладовай
Недавно проскакивала статья, в которой как раз освещался успешный пример механизма снабжения органоидов питательными веществами. Вместо кровеносных сосудов использовалась матрица желобков на поверхности, на которой выращен органоид. Благодаря этому их получалось в большие (относительно) горизонтальные кластеры выращивать.
Спасибо за упоминание ImageSorcery 😊
Молодец! Больше агентов богу агентов.
Но не очень понятно как можно было не найти Cline или KiloCode там 🤷
Как я понял, все самые популярные ИИ-агенты из вскода есть и в кодсервере...
Благодарю инфослужбу хабра, за рассказ о том, как инфослужба хабра, меняла инструмент инфослужбы хабра, для управления задачами инфослужбы хабра!
Я удивлён что после выхода shotgun code он этого ещё не сделал.
В cline и десятках его форков и аналогов есть такое понятие как чекпоинты - возможность откатываться по истории коммуникации. При этом там на выбор: откатить только историю, только состояние файлов, и то и другое.
Как раз, когда к диалогу нужно кроме пары фраз добавлять ещё и файлы - чаты тупо требуют больше телодвижений по сравнению со всеми остальными альтернативами. Чаты просто не особо для этого предназначены. Чаты больше подходят для переписки. А для редактирования кода, как не удивительно, редакторы кода (:
В IDE вы можете передать LLM сразу несколько файлов, так же просто, как заменьшонить коллегу в корпоративном чате - через @. Через него же можно сразу целую директорию добавить в контекст.
Можно выделить часть лога и в один хоткей добавить именно эту часть, а не весь файл.
Более того, можно сказать ему самостоятельно запустить код и получить из stdio или из файла логи и их обработать. То есть ещё до появления самих логов, сказать ему как их обработать.
P.S. я не считаю проект плохим или что-то в этом роде. Задача которую вы решаете актуальна и решается каждым из упомянутых мною инструментов индивидуально. Более того, существуют отдельные LLM которые натренированы выполнять лишь одну задачу - применять изменения в формате, аналогичном вашему.
Я лишь удивлён что вы решаете её в отрыве от инструментов, которые решают её сейчас в рамках своей работы.
А Cline, RooCode, KiloCode и десятки их аналогов? Зачем останавливаться на единственном инструменте в котором нельзя?
Почему? Во первых у Gemini есть свой cli, а во вторых есть aider и десятки других клонов claudecode.
Конечно! И это относится к любому инструменту. Что Cursor, что Cline, что Claude Code. Ну как ваш формат помогает эту проблему решать? Благодаря нему можно ввести один диалог на 50 млн токенов с хорошим результатом? А если нет то чем плохо патч которым пользуются IDE? Только его не приходится копировать и вставлять, это происходит нативно
Спасибо, можем продолжить в той ветке
Во первых: если критично "прятать" от LLM часть кода - есть cline в котором нет "индексации" кода и можно как раз точечно передавать только нужные файлы.
Во вторых: контекстное окно модели одинаковое и в IDE и в чате. От инструмента оно не зависит. Если вы жалуетесь на размер контекстного окна, то эти претензии актуальны и для чата. Разве что у чата интерфейс не удобный и приходится городить костыли вроде того, что в статье описан.
В третьих: что у вас за задачи такие, которым 1-2 млн контекстного окна мало? Это огромный массив текста, который человек будет читать десятки часов. Пару лет назад, когда окна были по паре десятков тысяч токенов, претензии были уместны. Но не в 2025 году. Но даже если это реально проблема - замена IDE на чат её никак не решает
Кто в 2025 ещё использует чат для кодинга? Абсолютно все современные IDЕ имеют ИИ инструментарий. А кроме этого существует ещё и консольные агенты.
Выглядит так, что сам придумал себе проблему - сам героически её решил.
Intel уже как-то поставила во главе инженера, а не менеджера. чуть не потонула...
Где вы увидели его в openrouter? Нет его там. Во всяком случае сегодня