Гугл накидывает разных вариантов по запросу best ollama model for claude code. Думаю, они будут быстро летать даже на 16 гб видеокарте. У меня медленными были только те модели, что в оперативку не влезали. Так что, потенциал вроде как есть.
вроде новую гугловскую бесплатную модель хвалят
но тут зависит от целей, может быть модель поменьше, но оптимизированная для определённых задач.
Во первых тем, что времени на его изучение и настройку уходит больше чем создать свой плагин который работает как мне надо. Во вторых даже после изучения и настройки он не работает как мне надо, не обновляет файлы в реальном времени и не сохраняет всё в бд.
В общем, несколько часов возни с популярными программами для синхронизации закончились намного более интересным и эффективным процессом создания собственного инструмента.
Не обязательно сравнивать с локалкой, можно взять онлайн самую крутую модель из тех что потенциально можно установить на домашний комп и поработать с ней. Она будет на уровне топовых моделей середины прошлого года, что неплохо с точки зрения прогресса, но совсем не хочется тратить несколько часов на то что современные топовые модели делают за час.
Какие плюсы от использования локальной модели? Приватность и "бесплатность". Имеет смысл для создания чего то запрещённого без цензуры, для обычной работы очень сомнительная затея.
ну плюсы можно найти, например когда простаивает мощный компьютер, а у платной модели закончились токены... а также интернет отрубили \ заблокировали
а так, потихоньку, локальная модель будет шуршить кулерами и чего то генерить 
@alexvg, работает конечно, я же не спорю с этим. Мой просто лучше работает, сохраняет зашифрованную копию в бд в облаке в реальном времени. Написал слово - оно уже в бд и на всех устройствах. Syncthing намного более сложная и универсальная программа, но для синхронизации записок не настолько хороша.
Последнее редактирование:
пока попробовал google/gemma-4-e4b
на 6 гигов - подсказать что-то по кодингу может, но 4 стандартных файла для juce подготовить ей слабо. Качаю на 19 гигов, посмотрим. Оказывается мой мини ПК с Radeon 780M вполне себе переваривает с LM Studio. Ничего настраивать не пришлось.
Кстати, немного сегодня обновил свою папочку. )
на 6 гигов - подсказать что-то по кодингу может, но 4 стандартных файла для juce подготовить ей слабо. Качаю на 19 гигов, посмотрим. Оказывается мой мини ПК с Radeon 780M вполне себе переваривает с LM Studio. Ничего настраивать не пришлось.
Кстати, немного сегодня обновил свою папочку. )
Вложения
Последнее редактирование:
У меня затык: инсайдер просит порядка 25 ГБ, полный с известного места порядка 65. Места столько прям сейчас нет. Что делать? Может есть какие-то менее емкие варианты или надо ставить такое большое?
VS Code, Juce, Github оказывается уже стоят порядка 3 лет, просто забыл про них.
полный Visual Studio не нужен, при установке можно выбрать только нужные компоненты для нужных платформ,
или минимальный вариант, только build tools (примерно 7 ГБ) https://aka.ms/vs/stable/vs_BuildTools.exe
но компилировать нужно будет из коммандной строки с CMake\MSBuild command line
Последнее редактирование:
sorry а можно более детально описать процесс вайбкодинга. я как то давно писал плюгины на джусе. насколько помню там весь плаг был в четырех файлах. PluginEditor.h, PluginEditor.cpp, PluginProcessor.h, PluginProcessor.h был редактор GUI, в котором можно было разместить все крутилки/переключалки и он сам писал начальный код эдитора. но нужно было самому было прописать отработку запросов хоста GetParameter и SetPatameter, GetParameterName, getStateInformation и setStateInformatiom. ну и собственно написать processBlock, где ты получаешь один или два семпла и отдаешь столько же обработанных.
и как происходит вайбкодинг? пишешь ему - напиши для juce код 4-х полосного EQ и он сам пишет код для editor-а и где то тырит код фильтра и вставляет его. или как это происходит?
@Andrew_S., примерно так и происходит, есть 4 стандартных файла, можно подключить в проект любые другие. Редактором GUI я пока не пользовался, интерфейс делаю тоже путём взаимодействия с нейросетью, какие-то мелочи вручную правлю. Выше в теме есть ссылка на кучу кнобов и индикаторов кастомных, они без проблем экспортируются и скармливаются ИИ агенту, чтобы встроить в интерфейс.
Программирование алгоритма происходит поэтапно методом написания нужных промтов, ИИ агенту надо просто написать что именно нужно, как должно работать, какие органы управления должны быть. Можно спросить совета по усовершенствованию, какие алгоритмы можно использовать для достижения лучшего результата, можно привести в пример для создания кода, какой-то известный прибор/плагин, нейросети известны их принципы работы, далее можно попросить создать 4 стандартных файла для juce 8, проверить их на ошибки. А дальше тестирование, допиливание, модификация. Это всё немного сложнее работает, чем просто "где-то стырил код плагина", нейросеть не копирует, она компилирует из всей базы данных, которая в ней хранится, а направляется эта компиляция промтами, чем они более осмысленные и детальные, тем и результат ближе к желаемому.
Тут можно в пример картинки и видео привести, какие мы видим, получаются с помощью нейросети. Их в реальности никогда не существовало, они не скопированы. Точно так же и с кодом получается.
p.s. локально 16 Гб модель gemini на Radeom 780m и 64 Гб оперативки - невозможно работать. Невероятно медленно работает. К тому же у этих gemini локальных слишком малая длина диалога, он просто обрывается когда настаёт лимит, только что-то простое можно делать.
Программирование алгоритма происходит поэтапно методом написания нужных промтов, ИИ агенту надо просто написать что именно нужно, как должно работать, какие органы управления должны быть. Можно спросить совета по усовершенствованию, какие алгоритмы можно использовать для достижения лучшего результата, можно привести в пример для создания кода, какой-то известный прибор/плагин, нейросети известны их принципы работы, далее можно попросить создать 4 стандартных файла для juce 8, проверить их на ошибки. А дальше тестирование, допиливание, модификация. Это всё немного сложнее работает, чем просто "где-то стырил код плагина", нейросеть не копирует, она компилирует из всей базы данных, которая в ней хранится, а направляется эта компиляция промтами, чем они более осмысленные и детальные, тем и результат ближе к желаемому.
Тут можно в пример картинки и видео привести, какие мы видим, получаются с помощью нейросети. Их в реальности никогда не существовало, они не скопированы. Точно так же и с кодом получается.
p.s. локально 16 Гб модель gemini на Radeom 780m и 64 Гб оперативки - невозможно работать. Невероятно медленно работает. К тому же у этих gemini локальных слишком малая длина диалога, он просто обрывается когда настаёт лимит, только что-то простое можно делать.
Последнее редактирование:
то есть вы вообще в код не лезете? и ничего в ручную там не меняете? и даже cpp не знаете?
по сути - не лезу, cpp - знаю.
если бы я cpp не знал на каком-то уровне, то не смог бы стартануть и создать свой первый плагин, а дальше дело пошло! )
ведь можно сконцентрироваться не на написании кода ручками, а на управлении его архитектурой, в этом вся суть.
Последнее редактирование:
это можно в настройках модели увеличить, но будет больше ресурсов жрать,
а то что медленно, увы, у меня с видеокартой 16GB памяти, большие модели медленно работают.
поигрался ещё чуть с LM Studio, прикрутил по MCP доступ моделям к интернету и локальной папке.
насчёт gemma-4 - у неё данные до 2024 года, то есть о более новых версиях программ \ плагинов и т.д информации у неё нет.
(прикол, вчера пришлось доказывать что на дворе 2026, а не 2024, не верила, говорит или пользователь галлюцинирует
, или показывает фэйковые сайты )
Хорошо что не завиноватила. Чем-то мою бывшую напоминает.пользователь галлюцинирует
до чего дошел прогресс!
sorry за прямоту, но вы просто не в зуб ногой в теме, поэтому у вас и возникает ощущение, что там все сложнее чем "просто стырил".
я разными алгоритмами dsp давно занимаюсь и многие из них писал сам с нуля. не так давно мучил гпт по поводу написания нескольких алгоритмов. и к сожалению максимум что он может - это стырить. иногда тырит с ошибками. если просить его модифицировать алгоритм - происходит полная шляпа. это как просить бабушку сидящую у подъезда слетать побыстрому на Луну.
примерно так - есть спецы по dsp, которые могут написать библиотеку с нуля. их примерно 0.1%. и есть 99.9% просто приграммистов, которые максимум что могут - взять готовую библу и подключить ее в свой проект. именно это и делает ии. в лучшем случае. наверное круто навайбкодить эдитор. в ручную его писать долгое и нудное дело. но насчет алгоритмов - ии вообще ничего не знает о том как работает LA2A. маскимум - она найдет опенсорсный проект в котором кто то как то пытался иммитировать работу LA2A, сопрет оттуда код алгоритма и адаптирует его под текущий плаг. а не найдет LA2A, то возьмет алгоритм первого попавшегося компрессора и ничего тебе об этом не скажет.
я это к тому, что какой смысл делать такие плаги? чем это отличается от приграммирования в синтэдиторе? там ты хотя бы честно сам собираешь цепочку из стандартных эффектов. а тут что и где нашла ии вообще непонятно. такого Г на просторах и-нета валяется великое множество.
вы тут не первый хейтер, тоже извините за прямоту, просто не интересно вашими страхами и переживаниями на тему профессии заниматься и вести диалог на эти темы )
Сам столкнулся с подобным, когда копилотом пытался найти алгоритм ЛА-2А. Он мне собрал примитивный VCA.
Предположим собрал. А доработать? А поменять алгоритмы? Попробовать разные?
Слишком быстро нейросетки развиваются. Ну вот навскидку, экспресс:
Для точного VST3 копирования LA-2A на JUCE есть несколько подходов:
- Opto-эмуляция через моделирование CdS фоторезистора — самый важный компонент. Его сопротивление меняется нелинейно и с гистерезисом. Моделируют через RC-цепочку с переменным сопротивлением (LDR — Light Dependent Resistor). Ключевые параметры: время включения/выключения ~10-15ms / 60-150ms (зависит от глубины компрессии), память эффекта (hysteresis).
- Моделирование в стиле Wave Digital Filters (WDF) — ламповые каскады (12AX7, 12BH7) как нелинейные элементы, решаемые через итерации Ньютона-Рафсона. Самый точный, но тяжёлый.
- State Variable / ODE solver подход — моделирование всей схемы как системы дифференциальных уравнений (например, модифицированный nodal analysis), численное решение.
- Аппроксимация «на слух» — эмуляция передаточной характеристики opto-пары через кусочно-линейные кривые + таблицы предрасчитанных времён атаки/релиза, наложенный сатурационный clipper на выходе (имитация трансформатора и ламп).
ну уровне промптов можно детальнейшим образом вмешиваться в куски кода и их модифицировать на своё усмотрение, при этом никакого геморроя.
а если какой-то алгоритм не до конца понятен, то можно попросить ИИ агента внести в файлы подробные комментарии на русском. он каждую строчку кода распишет... и так уже вручную будет легче внести какие-то правки.
Последнее редактирование:
я так понял года на 3. и это прямо пропасть ) поэтому можно смело браться за старое и снова попробовать, если есть интерес.
вот сходу рекомендую модель Big Picle в Open Code попробовать, это бесплатно и места не занимает. (как я понял погуглив, это свежее, оно на тестировании и через какое-то время перейдёт в платное)
Последнее редактирование:
если просто с наскока спросить чат-бот (тем более если бесплатный), то скорее всего результат будет как спросить бабушку, или продавщицу кваса,
а для более специфических, серьёзных задач, нужно подход более серьёзный,
выбрать подходящую платную модель (желательно последих версий), создать проект, с нужной информацией (можно схемы, можно документацию, можно книжки по созданию DSP алгоритмов которые ИИ проработает), тогда можно ожидать более правильных ответов, как то так
Зависимость от онлайн моделей — не Айс! В любой момент либо вырубят, либо что то поменяется.
Локальные модели требуют больших ресурсов, видеокарты, оперативки и.т.д... Спорный вопрос что быстрее, навайбкодить какую нибудь программку за 2-3 часа на мега-навороченном компе, либо написать её ручками за те же 2-3 часа (а то и быстрее) на калькуляторе.
Не совсем верный стереотип, что динозавры набирают 100500 строк кода ручками. Они же тоже не первый день замужем, там уже все настроено и воркфлоу и куча шаблонов, библиотек, своих наработок и.т.д... CTRL+С и CTRL+V кусками по 1000 строк, несколько правок и все готово.
Локальные модели требуют больших ресурсов, видеокарты, оперативки и.т.д... Спорный вопрос что быстрее, навайбкодить какую нибудь программку за 2-3 часа на мега-навороченном компе, либо написать её ручками за те же 2-3 часа (а то и быстрее) на калькуляторе.
Не совсем верный стереотип, что динозавры набирают 100500 строк кода ручками. Они же тоже не первый день замужем, там уже все настроено и воркфлоу и куча шаблонов, библиотек, своих наработок и.т.д... CTRL+С и CTRL+V кусками по 1000 строк, несколько правок и все готово.
тут есть еще проблема, вслучае какихто форсмажоров большая часть проектов на вайбкоде встанут, если "вайб кодеры" потеряют доступ к ИИшкам.
чтоб запустить и крутить локальную модель нужны большие ресурсы
чтоб запустить и крутить локальную модель нужны большие ресурсы
при таком сценарии, можно и ручками,
а вот если ручками день, а на следующий ещё продолжать, а с ИИ 2-3 часа ?
ИИ это инструмент. можно пользоваться, для экономии времени, можно не пользоваться.
можно вручную винтики закручивать, даже при наличии электроотвертки.
это не так работае, как разтаки вы и не втеме. модель ничего не тырит впрямом смысле. она/оно на этом обучается и не хранит в базе
Почитайте хотя бы базово про next-token prediction и SGD, прежде чем кидаться словом «тырит».
и что. допустим мы снимем вольтамперную ха-ку оптрона. что она нам даст без моделирования всей остальной схемы? + моделирование оптрона через RC цепочку - это очень оригинально но не работает. + ии правильно упомянул про гистерезис! то есть у вас вольтамперная ха-ка будет меняться в зависимости от конкретного напряжения. пытаться описать это формулой сложно. теоретически можно попробовать описать через здоровенную многомерную таблицу, но сперва надо разработать корректную методику сьема и сделать лабораторную работу по заполнению этой таблицы. развлекухи - не на один день.
ии и добралась до остальных компонентов cхемы. да на триоды можно сделать мат модель (только не итеррациями), но проблема в том что она очень ресурсожручая и не оптимизируется. на 3 каскада примерно 800 умножений на семпл.
5000 умножений на семпл.
ии вспомнила про динамическую конволюцию. в свое время focusrite делала такую. называлась она liquid channel кто помнит. как раз для описания поведений приборов динамической обработки. но проблема была в том что все это было очень ресурсоемко и даже при это весьма посредственно иммитировала звучания реальных компрессоров. поэтому была благополучно забыта.
ИТОГО: в отличие от эвалайзеров, которые могут быть достаточно неплохо смоделированы при помощи статической конволюции + перегиба переходной ха-ки (что позволяет сделать плагин который требует 10-15 умножений на семпл). более менее точное физмоделирование или просто моделирование динамической обработки требует построения очень ресурсоемких моделей, которые требуют тысячи MUL/FMA операций на семпл. то есть практически это не реализуемо. это знают все разработчики, которые реально пробовали это сделать.
ИТОГО: ии что то написал, а вы не поняли что. в результате полная идиллия.