В своих прошлых материалах я уже рассказывал о запуске крупных MoE-моделей на ограниченном железе через llama-server и о сравнительных экспериментах с 35B, 120B и 176B-классами моделей. Практика показала, что llama.cpp давно перестал быть п...
В своих прошлых материалах я уже рассказывал о запуске крупных MoE-моделей на ограниченном железе через llama-server и о сравнительных экспериментах с 35B, 120B и 176B-классами моделей. Практика показала, что llama.cpp давно перестал быть просто «запускатором GGUF»: сегодня это полноценный рантайм с OpenAI-совместимым API, поддержкой инструментов, Jinja-шаблонов, спекулятивного декодирования и гибкого CPU/GPU-offload. Единственное, чего ему не хватало для повседневной работы, — удобной обвязки, которая избавила бы от ручного набора десятка флагов при каждом старте.
Именно поэтому у меня появился небольшой лаунчер на Go: llama-runner, который брал на себя типовые сценарии: сам раскрывал ~ в абсолютные пути, проверял наличие бинарника и модели, собирал аргументы llama-server, пробрасывал логи и корректно гасил дочерние процессы по Ctrl+C. Программа успешно решала свою задачу, пока я не наткнулся на статью «70 токенов в секунду в Qwen3.8-27B на RTX 3090», где помимо тонкой настройки llama-server подробно разбиралась связка локального сервера с агентной оболочкой Claude Code. Идея показалась мне логичным развитием собственного инструмента: зачем запускать сервер и клиент двумя командами в разных терминалах, если это можно сделать одним вызовом?
Так родилась вторая версия llama-runner, о которой и пойдёт речь.