Так в этом и их сила, что они позволяют решать задачи, где входные данные недетерминированы. В остальных вопросах классические алгоритмические системы будут лучше, быстрее и точнее. Принудительное следование грамматике лишь позволяет более корректно преобразовать входные данные в что-то более определенное для последующей формальной обработки. При данном преобразовании всегда будет какой-то процент ошибок, т.к. ни обучающие, ни входные данные на 100% не будут корректны. Во многих задачах решение “на глаз” вполне ок, с чем LLM идеально справляются. Просто потому что нельзя добиться детерминизма там, где его просто нет. А построение формальной логики в данной среде создаст иллюзию. Максимум можно построить огород из конкретных условий, где на этой модели уже можно решить задачу уже формально, но не всегда это будет работать в реальном мире, где условия будут меняться на ходу.
В llama.cpp есть возможность заставить следовать модель заданной грамматике на этапе сэмплирования. Только это не гарантирует, что результат будет осмысленный, если в промте не рассказать нейронке про правила языка. Если все сделать правильно, то можно даже слабые модели, которые плохо следуют инструкциям по формату ответа, заставить давать осмысленный результат.
Теперь, по словам Уирика, компания отслеживает «количество взаимодействий» инженеров с агентами по написанию кода в день.
Предполагается, что чем выше этот показатель, тем продуктивнее работает команда. Кроме того, компания отслеживает эффективность этих взаимодействий.
Звучит аналогично утверждению как "давайте считать сколько строк разработчик пишет в день" :)
У меня лично вообще обратное предположение, что чем меньше с агентами взаимодействуешь, и при этом выше общее качество, то вот это есть признак эффективности, а не то, сколько раз пришлось его уговаривать сделать что-то адекватное.
Для обоих вариантов флаги --ctx-size 32000 --fit-ctx 32000, только вот в случае с rocm вполне успешно 200к контекст грузит, а на вулкане при загрузке модели падает из-за нехватки памяти.
upd: перепроверил еще раз: для vk не было включено квантование кеша и модель все-таки смогла загрузиться, в остальном все осталось так же.
Провел сравнение вулкана и rocm на своей 7900xtx. Запускал модель Qwen3-Coder-30B-A3B-Instruct-Q4_K_M, получилось на вулкане 200 t/s, а на rocm 100 t/s. Но есть жирное НО: на вулкане контекст пришлось со 100к до 32к урезать чтобы влезло в память, настройки были абсолютно те же: квантование кеша до 8 бит, flash attention. Скорее всего что-то для вулкана не работает, но в логах не увидел предупреждений. Запускал через llama.cpp (b8123)
У Qwen3-Coder-Next-UD-Q6_K_XL вулкан выдал 21 t/s, на rocm 18 t/s, но пришлось сжать контекст с 200к до 32к чтобы на вулкане запустилось.
Да, заработает. Веса модели занимают 14гб. Если включить квантование контекста хотя бы до 8 бит, то в оставшиеся 2гб можно побольше уже контекст запихнуть. Если через llama.cpp с флагом -cmoe, то скорее всего даже весь контекст можно будет использовать, доступный для модели, но возрастет потребление обычной памяти и часть нагрузки уйдет на CPU с просадкой по скорости.
Если обычной ОЗУ много, то получится gpt-oss-120b, qwen3-next, qwen3-coder-next запустить на этой карте. Вот в соседней статье на 6 гиговой карте запускали. Так как часть нагрузки пойдет на проц, то он тоже должен быть достаточно мощный, и шину PCI-E 4-5 версии желательно с ddr5 ОЗУ :)
Возможно, unsloth что-то испортили с динамическим квантованием. Перепроверю на обычной версии тогда. Вот Qwen3-Next как раз обычная была и ответ был верный.
upd: похоже на рандом, потому что на новый прогон получил уже корректный ответ за то же время и расход токенов:
Ответ, конечно, неправильный, но для статистики выложу: Qwen3-Coder-Next на 78Гб DDR4 RAM 3200 частота, amd 7900xtx на 24Гб VRAM по PCI-E 3.0, ryzen 5700x3d:
Я думаю, правильный ответ:
✅ Плотник ест пиццу. ✅ Плотник держит крокодила.
Поскольку в таблице, где 1: плотник, 1: пицца, и единственное животное, которое не использовано в других >позициях — крокодил.
Мне модель в агентном режиме очень сильно зашла, гоняю через Claude code cli (другие сильно хуже). Простенькие кодерские задачки решает на ура. Даже есть мысли на сервере поднять как "умный" линтер для пулл реквестов на проекте и как анализатор почему тесты падают (по коду ориентируется неплохо). Это вообще у меня первая локальная модель, которая нормально смогла в агентный режим :)
Если вообще никакого опыта нет, то можно посмотреть на lmstudio. А для более продвинутых можно уже и на llama.cpp, llama-swap, Ollama.
Устанавливается все просто по доке, если железо поддерживается. В случае rdna2 амд карт для запуска на ROCm может потребоваться компиляция с определенными параметрами, на vulkan без бубна даже на древних картах а-ля amd rx 550 запускается (лично проверял).
Но это все только для инференса, с обучением там все гораздо сложнее. Есть вариант файнтюна для бедных - LoRa, а для еще более бедных QLoRa.
Для Nekobox уже предложили трюк для блокировки запросов по socks5, надо добавить кастомное правило в Маршруты:
Самое главное это микросервисы не делать “микро”.
Это как? Модель не знает все ответы, ей приходится их интерполировать на основе знаний, которые в неё заложены (в которых точно есть ошибки).
По-моему это тоже самое, как по двум точкам попытаться найти всю функцию (в простейшем случае будет работать :)).
Чтобы их фиксировать нужно знать правильны ответ, а мы же его как раз на практике и не знаем.
Возможно, вы просто смогли подогнать результаты под конкретные бенчмарки.
Так в этом и их сила, что они позволяют решать задачи, где входные данные недетерминированы. В остальных вопросах классические алгоритмические системы будут лучше, быстрее и точнее. Принудительное следование грамматике лишь позволяет более корректно преобразовать входные данные в что-то более определенное для последующей формальной обработки. При данном преобразовании всегда будет какой-то процент ошибок, т.к. ни обучающие, ни входные данные на 100% не будут корректны. Во многих задачах решение “на глаз” вполне ок, с чем LLM идеально справляются. Просто потому что нельзя добиться детерминизма там, где его просто нет. А построение формальной логики в данной среде создаст иллюзию. Максимум можно построить огород из конкретных условий, где на этой модели уже можно решить задачу уже формально, но не всегда это будет работать в реальном мире, где условия будут меняться на ходу.
В llama.cpp есть возможность заставить следовать модель заданной грамматике на этапе сэмплирования. Только это не гарантирует, что результат будет осмысленный, если в промте не рассказать нейронке про правила языка. Если все сделать правильно, то можно даже слабые модели, которые плохо следуют инструкциям по формату ответа, заставить давать осмысленный результат.
Звучит аналогично утверждению как "давайте считать сколько строк разработчик пишет в день" :)
У меня лично вообще обратное предположение, что чем меньше с агентами взаимодействуешь, и при этом выше общее качество, то вот это есть признак эффективности, а не то, сколько раз пришлось его уговаривать сделать что-то адекватное.
Для обоих вариантов флаги
--ctx-size 32000 --fit-ctx 32000, только вот в случае с rocm вполне успешно 200к контекст грузит,а на вулкане при загрузке модели падает из-за нехватки памяти.upd: перепроверил еще раз: для vk не было включено квантование кеша и модель все-таки смогла загрузиться, в остальном все осталось так же.
Провел сравнение вулкана и rocm на своей 7900xtx. Запускал модель Qwen3-Coder-30B-A3B-Instruct-Q4_K_M, получилось на вулкане 200 t/s, а на rocm 100 t/s. Но есть жирное НО: на вулкане контекст пришлось со 100к до 32к урезать чтобы влезло в память, настройки были абсолютно те же: квантование кеша до 8 бит, flash attention. Скорее всего что-то для вулкана не работает, но в логах не увидел предупреждений. Запускал через llama.cpp (b8123)
У Qwen3-Coder-Next-UD-Q6_K_XL вулкан выдал 21 t/s, на rocm 18 t/s, но пришлось сжать контекст с 200к до 32к чтобы на вулкане запустилось.
Да, заработает. Веса модели занимают 14гб. Если включить квантование контекста хотя бы до 8 бит, то в оставшиеся 2гб можно побольше уже контекст запихнуть. Если через llama.cpp с флагом -cmoe, то скорее всего даже весь контекст можно будет использовать, доступный для модели, но возрастет потребление обычной памяти и часть нагрузки уйдет на CPU с просадкой по скорости.
Если обычной ОЗУ много, то получится gpt-oss-120b, qwen3-next, qwen3-coder-next запустить на этой карте. Вот в соседней статье на 6 гиговой карте запускали. Так как часть нагрузки пойдет на проц, то он тоже должен быть достаточно мощный, и шину PCI-E 4-5 версии желательно с ddr5 ОЗУ :)
Возможно, unsloth что-то испортили с динамическим квантованием. Перепроверю на обычной версии тогда. Вот Qwen3-Next как раз обычная была и ответ был верный.
upd: похоже на рандом, потому что на новый прогон получил уже корректный ответ за то же время и расход токенов:
А вот ответ от обычной (не кодерской) версии модели:
Конфиг:
Ответ, конечно, неправильный, но для статистики выложу:
Qwen3-Coder-Next на 78Гб DDR4 RAM 3200 частота, amd 7900xtx на 24Гб VRAM по PCI-E 3.0, ryzen 5700x3d:
По софту: llama-swap + llama.cpp (версия b8100).
Просто на CPU выдавливает 5 t/s.
Мой конфиг для llama-swap:
Мне модель в агентном режиме очень сильно зашла, гоняю через Claude code cli (другие сильно хуже). Простенькие кодерские задачки решает на ура. Даже есть мысли на сервере поднять как "умный" линтер для пулл реквестов на проекте и как анализатор почему тесты падают (по коду ориентируется неплохо). Это вообще у меня первая локальная модель, которая нормально смогла в агентный режим :)
По-моему база всегда раскрывалась в Go Tour и тему со слайсами там как раз в сендвич-меню можно найти.
Как раз смысл LSP интерфейса в том, чтобы сервер был реализован третьей стороной (довольно часто разработчиками языка), а не разработчиком IDE.
Костыли вида ls+grep работают еще и из-за того, что модели сами стремятся их использовать, даже если рядом есть более релевантные инструменты...
Использую klogg - десятки гб на стром ноуте в легкую переваривает, включая поиск.
Если вообще никакого опыта нет, то можно посмотреть на lmstudio.
А для более продвинутых можно уже и на llama.cpp, llama-swap, Ollama.
Устанавливается все просто по доке, если железо поддерживается. В случае rdna2 амд карт для запуска на ROCm может потребоваться компиляция с определенными параметрами, на vulkan без бубна даже на древних картах а-ля amd rx 550 запускается (лично проверял).
Но это все только для инференса, с обучением там все гораздо сложнее. Есть вариант файнтюна для бедных - LoRa, а для еще более бедных QLoRa.
Статья - нейросетевой булшит. С помощью Ollama нельзя файнтюнить модели, она только для инференса. Нет там такого флага:
--train.Есть неплохая локальная альтернатива - searxng (API)
Еще есть https://github.com/ory/dockertest для тех же целей.
Не самый лучший пример использования интерфейсов в Go. Делайте интерфейсы максимально узкими по назначению.
Как это используется в реальной жизни