Magnitude обгоняет llama.cpp до двух раз за счёт компиляции ядер на вашем устройстве
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
Magnitude — открытый inference-движок для агентов, который компилирует и настраивает ядра прямо на вашем железе, поэтому открытые модели работают до 2 раз быстрее llama.cpp: декодирование на Metal ускоряется на 92%, на CUDA — на 19%. Работает на Apple Silicon, NVIDIA, AMD и даже на одном CPU. Поддерживает Pi, OpenCode, Hermes, Codex и другие агенты через OpenAI-совместимый API, экономит 27% памяти на агента и не отправляет данные в сеть.
Magnitude компилирует и настраивает свои ядра на вашем реальном устройстве до запуска модели, поэтому они точно подходят под ваш чип.
- kmike84
Насколько точны оценки скорости в UI? Спрашиваю, потому что для Qwen 3.8 (Q8) числа скорости, указанные в UI, выглядят довольно скромно:
Оценочная скорость на вашей машине
Контекстные токены Токенов/сек
25 000 17
50 000 16
75 000 16
262 144 12
Число для 262K нормальное, но для меньших размеров контекста (<128K) оно примерно в 2 раза медленнее, чем числа, которые я получаю в реальных сессиях mtplx для qwen3.8 q8 (mac m5 max).
Это недостаток оптимизаций, неверные числа или артефакт бенчмарка (например, что-то, что сложнее для spec decoding, чем обычные агентные сессии)?
- happybox2016
«В 2 раза быстрее llama.cpp» — на чём, на M3 Max? Metal-ядра llama.cpp уже насыщают пропускную способность памяти. Настоящее узкое место агента — не tok/s одного потока, а KV-кэш для 5+ одновременных контекстов по 128k на 24 ГБ VRAM. Кто вообще запускает мультиагентные системы локально? A) Только одна сессия B) 2–3 агента C) 5+ агентов D) Сдался,
- lxe
На своей локальной машине для инференса у меня постоянно открыт тред codex в моём чекауте llama.cpp, которому я периодически поручаю просмотреть текущие открытые PR-ы llama.cpp, провести исследование по последним MTP, Dflash и другим оптимизациям предсказания или внимания, изучить последние кванты и файнтюны моделей, просмотреть треды на Reddit в localLlama и просто сделать по сути обзор переднего края.
Затем он пересобирает последнюю версию llama.cpp, забирает PR-ы, которые считает релевантными для тестирования, а затем выполняет бенчмарк, завершает обновление и проверяет, какую модель, вариант или даже отдельный файнтюн нам следует запускать.
Иногда он выполняет собственные оптимизации и коммитит их, которые затем вытесняются пул-реквестами и слитым кодом, что по сути подтверждает направление оптимизации самой модели.
- kmike84
Это кажется хорошей идеей. Однако обогнать llama.cpp по скорости — низкая планка :)
Я считаю его хорошей базовой точкой отсчёта, но по крайней мере на Mac всегда находилось что-то значительно быстрее и/или с лучшими требованиями к памяти — как вы и сказали, ds4, omlx, mtplx и т.д. Похоже, если вы реально используете локальные LLM, почти нет причин не использовать один из более оптимизированных движков.
3 основных режима отказа, которые я наблюдал в движках:
* Не используется лучшее доступное spec decoding
* Слишком много VRAM уходит на KV-кэш (например, KV-кэш раньше почти ничего не занимал в ds4, но огромный объём VRAM в unsloth/llama.cpp для моделей deepseek)
* Деградация производительности на больших контекстах — бенчмарки на 4K или 32K великолепны, но на реалистичных 100–200K это медленнее, чем какой-нибудь тупой базовый вариант
- singh_abinashi
Интересно, как оценки для этого работают на реальных агентных нагрузках по сравнению с синтетическими бенчмарками. По моему опыту, профили стоимости и задержки агента сильно меняются, когда появляется цикл использования инструментов, потому что распределение токенов становится гораздо более «всплесковым», чем при одиночном промпте. Вы оценивали на многошаговых трассировках вызова инструментов или в основном на одноходовых?