Комментарии 41
Интересно было примерить этот dot-to-ascii для наших схем, спасибо!
https://habr.com/ru/companies/yoomoney/articles/830538/
Исходный текст llama.cpp - 25 мб.
И похоже Releases обновляется несколько раз каждый день уже года 2.
За 11 минут компилируются в llama-server.exe+dll - 76 мб.
Для python torch и пр. нужно около 5 гб. т.е. в 50 раз больше!
При этом llama.cpp содержит web интерфейс и ещё кучу полезных программ.
Почему такая разница?
Для себя сделал интерфейс на Delphi к llama-server и whisper.cpp.
При этом контроль намного больше, чем у прочих оболочек
и можно сделать всё как мне нужно.
А gguf - уже стал стандартом для локальных LLM и любая программа, которая его загружает, использует llama.cpp.
"Интерфейс на Delphi к llama-server и whisper.cpp." - можете рассказать поподробнее с какими целями и что получается?
Для контроля вывода - IdHTTP с IdHTTP1ChunkReceived и "stream":true позволяет
получать ответ по токенам и останавливать при повторах, числу предложений,
максимальному размеру списка и т.п и говорить голосом по предложениям.
Для автоматизации запросов: можно получить несколько ответов и выбрать лучший
или автоматически формировать новые запросы из ответов или просто
запрашивать "Продолжай мыслить и саморазвиваться." и сделать
мышление LLM бесконечным.
Для оценки моделей: выдать несколько запросов из списка и оценить ответы
по наличию полезных для меня слов.
Для контроля запроса: системный промпт + указанное число вопрос-ответ диалога + промпт + теги
по шаблону. Причем диалог можно редактировать, отменять, повторять, запоминать, т.к. он в RichEdit и его можно подчищать, форматировать, раскрашивать.
whisper.cpp реализовал, работает, но не использую - надо микрофон, наушники, клавишами удобнее.
И ещё много идей пробовал и буду пробовать.
Со своей программой этому ничто не мешает.
В опенсорс не выкладывали свой интерфейс?
В опенсорс не выкладывал.
Когда-нибудь выложу, но для этого нужно подчищать, писать справку.
Там многие настройки прямо в программе - мне просто, а люди не поймут
и много остатков реализаций моих идей, что усложнит понимание.
Может просто как пример работы с llama-server из Delphi.
Есть уже мини-GUI на Delphi к LLM:
Почему такая разница?
Потому что сначала трансформеры нужно было открыть, т.е. обнаружить эту успешно работающую на практике модель с помощью многих итераций проб и ошибок. И только потом стало возможным написать эффективную реализацию на C/C++, зная что нужно написать и имея готовые веса для проверки.
Python'овский ML-стек подходит для исследователей, так как даёт высокую скорость итераций и лёгкость экспериментирования. C/C++ же даёт скорость выполнения за счёт эффективной реализации конкретной модели.
В этом нет ничего удивительного. Людям нужен продукт.
Что мешает автору llama.cpp упаковать свою библиотеку в красивую коробку, которая легко устанавливается и имеет удобный UI?
Вопрос риторический, но ответ скорее всего: он этого сделать не может. Потому что не имеет продуктового мышления.
А продуктовом мышление, способность не только прекратить свои идеи в рабочий код, а ещё и сделать так, чтобы код решал нужную людям проблему - искусство.
Людям не нужна библиотека для инференса на ЦПУ или ГПУ, людям нужна программа чтобы запускать локально ЛЛМки. Ollama и LM toolbox решают эту проблему. llama.cpp - нет
Похоже что автор статьи "слышал звон". llama.cpp это давно уже не просто библиотека, а целая система с кучей плагинов и собственным Web сервером с поддерждкой различных API. Установка llama.cpp выглядить до боли тривиальна: cmake . && make install. Установка моделей полность автоматизирована, просто указываете название модели и он выкачивает её с Huggingface и запускает. Какое еще нужно продуктовое мышление ?
$ git clone https://github.com/ggml-org/llama.cpp.git
$ cmake .
$ make && make install
# далее
$ llama-cli --help
# Web сервер с чатом можно запустить вот так:
$ llama-server -m $MODEL --host 1.2.3.4 --port 8080
# далее подключаетесь Web браузером на 1.2.3.4:8080 и получаете
# полноценный интерфейс к ИИ чат-ботуИ да, llama.cpp поддерживает FIM API позволяя подключать vim, vscode и прочие IDE.
Мы держим свой локальный сервер на базе llama.cpp с моделями DeepSeek для чата и для FIM. Спасибо Георгию за то, что сделал инферренс моделей простым и доступным для старпёров умеющих в make.
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
Установка llama.cpp выглядить до боли тривиальна:
cmake . && make install
Ага, тривиальна, если не лезть в CMakeLists и не смотреть какие опции там используются, что включено по умолчанию и какие там зависимости, какие оптимизации и т. д. Пакетные менеджеры существуют уже несколько десятков лет, а кто-то до сих пор считает, что cmake . && make install - это нормальный способ установки пользовательского ПО в операционной системе. Может хватит уже? Шутка надоела.
А с pre-built у них так себе, не каждый захочет пользоваться nix.
, если не лезть в CMakeLists и не смотреть какие опции там используются
А зачем?
Или вы когда условный npm i запускаете - тоже все дерево зависимостей отсматриваете?
Ну хотя бы затем, чтобы понимать, что там вообще происходит, потому что в cmake конфиг можно напихать всё что угодно и install-цели можно тоже определить как угодно.
npm не запускаю, но дерево зависимостей пакетов смотрю. Хорошая привычка, я считаю. Это вообще давно проблема - распухающие зависимости.
А зачем?Или вы когда условный npm i запускаете - тоже все дерево зависимостей отсматриваете?
npm (без опции -g) ставит все пакеты в локальную папку, а make install без должного контроля легко устраивает срач в системе, который потом еще и не вычистить так просто.
это нормальный способ установки пользовательского ПО в операционной системе
В случае комплексного, не всем нужного ПО, которое нередко требуется собрать под свои личные нужды - да, cmake + make + закатать в свой собственный пакет - это абсолютно нормальный способ.
`make install` ненормальный способ, потому что пока ты не залезешь в конфигурацию cmake или в сгенерированный makefile и не посмотришь как прописаны install-цели, ты вообще не знаешь, что он сделает и куда распихает весь хлам.
Сборка под свои личные нужды - это вообще отдельный случай, и там как раз придется лезть в cmake конфиг и разбираться с опциями сборки. Это вообще не способ установки ПО в систему.
закатать в свой собственный пакет
так выше речь идет как раз не про закатывание в пакет, а про тупо install скриптом глобально в систему.
Ага, тривиальна, если не лезть в CMakeLists и не смотреть какие опции там используются,
Во-первых, в CMakeLists смотреть не надо, надо читать README.md, это если Вас интересуют какие-то специализированные опции. Во-вторых, там подефолту всё нормально отстроено, никаких опций крутить не требуется. Инструкция, которую я привел выше, рабочая! cmake автоматом подхватывает CUDA если он у Вас есть и собирает всё что требуется. Я вот буквально вчера запустил llama.cpp на RTX 4060, никаких опций не накручивал.
При запуске llama-server пришлось, правда, ограничить число слоёв для оффлоада на GPU (-ngl 20) из-за малого обьема VRAM памяти на карточке.
Go-шники.
Ну нормальная тулза - запустить ллм, если ты не хочешь вообще ничем заморачиваться. Как продукт они, конечно, обычному пользователю тоже не упали.
За свой небольшой опыт с линуксом, если я вижу make, я до победного ищу готовые бинарники. Потому что обязательно что-то разломается и сиди несколько часов кури гугл.
Ollama в ридми даёт ссылки на готовые dmg/exe файлы, чтобы даблклик и все готово
За свой небольшой опыт с линуксом, если я вижу make , я до победного ищу готовые бинарники.
Какой-то у Вас неправильный опыт. Если я вижу Makefile, то беру и собираю из исходников. Я вообще стараюсь держать всё в исходниках, кроме компилятора. Как раз потому, что когда-то их обязательно сломают и я смогу откатиться на требуемую мне версию (может быть даже исправить проблему самостоятельно), а не судорожно искать и качать новые бинарники ко всему стеку используемого софта со всеми его зависимостями.
Если я вижу Makefile, то беру и собираю из исходников
и обычно это приводит к парочасовому пердолингу, потому что выясняется, что нужна такие или другие библиотеки определенных версий, которых нет у тебя в системе и в твоем дистрибутиве, которые в свою очередь требуют еще других библиотек которых нет, или что код древний и не собирается современными компиляторами, или наоборот слишком свежий и не поддерживается компилятором в твоем дистре, и так далее
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
По большей частью хорошие питонисты - хорошие сишники.
Никогда не пользовался Ollama. Это такой же полуфабрикат как и llama.cpp, только еще и скачает непонятно что непонятно откуда за тебя.
Долгое время хватало llama.cpp-python и своих надстроек для RAG и других вещей. Потом стало интересно экспериментировать с activation steering, выбором из словаря, и прочим, что не было на тот момент реализовано в llama.cpp. В итоге перекатился на hugging face transformers, хоть она и не позволяет разбивать веса между GPU и СPU (по крайней мере я не знаю как).
Я думал, что Георгий Герганов наш соотечественник, оказывается - потомственный болгагин. :-)
библиотеки llama.cpp на С
Чувствую нестыковку я.
>в llama.cpp поддерживаются несколько платформ, включая x86, ARM, CUDA, Metal, Vulkan (версии 1.2 или выше) и SYCL
Даже какие-то ограниченные вендором metal и cuda есть, а единственно верного Dx нет что-ли?
iSWA (Integrated Service Workload Analyzer), который представляет аналитику о рабочей нагрузке
Нет, это Interleaved Sliding Window Attention, он уменьшает размер kv-кэшей для длинных контекстов
Попробовал этот "звуковой кейлоггер" — полная буйня на постном масле. Не говоря уж о том, что прямо в документации сказано, что рассчитан только на английский язык — так ещё и, судя по всему, на тех, кто сидит в звукоизолированной комнате, никогда при печати не затыкается и не делает опечаток.
Стоить добавить, что llama.cpp это только половина, вторая половина это всем привычные кванты Q4_K_M или Q5_K_M, без которых сложно представить локальное использование моделей.
И вот автор всех K-квантов и i-квантов - это ikawrakow, который недавно создал форк ik_llama.cpp.
В этом форке он сосредоточен на улучшения скорости работы текущих k- и i- квантов и создании новых SOTA (передовых) квантов. Среди уже созданных новых квантов это серия IQK, которые работают быстрее и выдают лучшее качество при меньшем размере, они походят и для CPU и для GPU, кванты Trellis quants KT - эти кванты очень хороши для выполнения на CUDA, при этом имеют высокое качество, но не особо подходят для CPU, кванты с R4 - заточены на работу только на CPU.
Можно посмотреть его выступление про историю квантования: https://fosdem.org/2025/schedule/event/fosdem-2025-5991-history-and-advances-of-quantization-in-llama-cpp/
Я попробовал подобрать 2 квантованные версии, которые по качеству равны для вчера вышедшей Qwen3-235B-A22B-Instruct-2507:
Qwen3-235B-A22B-Instruct-2507-UD-Q4_K_XL для классического llama.cpp.
Qwen3-235B-A22B-Instruct-pure-IQ4_KS работающие только на ik_llama, вся модель квантована как IQ4_KS.
Модель весит ~120гб, и это намного больше размера видеопамяти GPU, поэтому ускорение достигается через -ot, а основные веса крутятся на i7-14700 + DDR5 со скоростью памяти 70 гб/с. Для ускорения скорости обработки контекста PP использую -ub 4096 -b 4096.
Показатель PPL у обоих квантов примерно равен, но новые кванты весят меньше (117гб против 125гб), а скорость генерации выше на той же конфигурации ПК. В зависимости от модели, квантования и оборудования разница может достигать до 2.5 раз.
Кроме прямых замеров ещё важна стабильность скорости. Например, обновленный qwen3-235B теперь поддерживает размер контекста 256к и скорость PP важна, так как PP ощутимо падает на длинном контексте, и на ik_llama падение скорости происходит медленнее, чем просто на llama.cpp.
Георгий Герганов, автор llama.cpp и звукового кейлогера