Я тоже пробовал таким заниматься и пришел к выводу, что это не работает. Ллм хорошо себя показывает в столкновении с детерминизмом т.е. с некоторой формой реальности. Столкновение же с другой ллм ухудшает ситуацию т.к. снижает уровень детерминизма и увеличивает возможность для фантазий. Я видел как ллм пытаются прийти к консенсусу и выйти на хороший результат. Но по факту это дает результат хуже чем если ллм пытается прийти к консенсусу с реальной внешней утилитой.
Ну вообще в посте написано буквально, что мы говорим спасибо тем, кто писал софт символ-за-символом. Это намек на то, что сейчас можно писать с помощью ии. Ничего криминального нет вообще.
Mistral взяли свою собственную модель и сделали ее файн тюнинг используя lean. Затем они сравнили свой файнтюн и ванильные модели других вендоров в других задачах lean. А почему не сделали такие же файнтюны моделей других вендоров и не сравнили их?
Я бы охарактеризовал это как синдром Кандинского-Клерамбо: одной рукой разработчики Mistral делают файн тюн, а другой рукой маркетологи втюхивают это как прорыв по сравнению с другими вендорами. Псевдоавтоматизмы - это верный признак шизофрении в компании. Я бы в такую компанию не инвестировал.
Автор, если ты этой темой интересуешься, то я тебе могу дать интересную наводку на еще одну штуку: локальное кеширование в слотах. Я просто сам изучаю и возможно тебе будет это интересно взять.
В llama.cpp (и не только) ты можешь кешировать несколько контекстов параллельно. Например если у тебя lang chain, то ты можешь очень эффективно обрабатывать несколько чейнов параллельно на нескольких машинах одной и той же моделью. Твоя задача - обеспечить любой вид синхронизации между ЖД на разных локальных машинах по сети. Размер kv кеша разнится от модели к модели, но обычно не более 8 гб.
Самое интересное, что можно дать фидбек из самого приложения и удалить kv кеш файл тогда, когда ты полностью обработал lang chain.
Получается очень круто: одна машина начинает обрабатывать один чеин, а вторая - другой. После обработки машины буквально за пару секунд обмениваются кешами и теперь каждая из них может обрабатывать любой чеин дальше.
Еще в данной парадигме интересно как будет работать мультиагентность с разными моделями. Т.е. на каждой из 10 машин у нас хранится много моделей и мы решаем сколько инстансов на данную модель поднять. Например мы решили по каким-то соображениям (из фидбэка самого приложения) поднять 3 машины с одинаковым агентами и моделями. После этого эти машины начинают шарить между собой общий кеш и очень эффективно в группе обрабатывать запросы. Т.е. получается алгоритм буста в мультиагентных системах с шарингом кеша.
Заходь на hugginface и смотри внимательно: для видеокарт на 8gb сейчас специально выпускают неплотные мое модели. Такие модели имеют в имени "a3b", что значит 3 миллиарда активных параметров. В реальности на карте для размещения всех слоев модели (а это как правило роутер + аутпут) нужно всего 4 гб видеопамяти. Получается, что остальные 4 гб видеопамяти можно заюзать на kv кеш для контекста (<= 96к) и обеспечить хорошую производительность. Если отключить ризонинг (или взять инстракт модель), то это дает возможность интегрировать абсолютно ненужную и завалящую видеокарту на 8 гб (типа 2060 super или 3050) на дев или даже стейджинг (на прод конечно не стоит).
Есть еще новая и очень интересная тема: MUSA (Moore Threads). В llama.cpp уже есть поддержка, в devops лежит готовый докер файл. По отзывам он хорошо работает с qwen (что лично для меня уже достаточно).
Карта Moore Threads S80 на 256 бит и 16 гб стоит на jd.com 1к юаней т.е. копейки в сравнении с даже 2-мя картами нвидиа или амд. Энергопотребление на базовых частотах в районе 150 ватт. Тензорные ядра для ускорения матричного умножения низкобитных чисел есть. Проблема только в непроверенной на практике архитектуре и драйверах.
Но вообще было бы разумно попробовать 2 такие карты, чтобы крутить плотную модель типа qwen 3.5 27b Q6: 26 гб на слои + 5 гб kv кеш на контекст 128к = 31 гб. Не факт, что на практике все сложится сразу в высокую производительность, но пробовать можно.
Я бы посоветовал выставлять базовые частоты, а не фиксировать tdp, но не суть важно.
Положим 650 ватт на машину ~ 475 квтч в месяц. Это 2900 рублей по ценам Питера каждый месяц.
Если у тебя 42 тс аутпут то инпут где-то 150 тс. Если предположить среднее использование с соотношение инпут:аутпут 2:1 то получится средняя скорость 80 тс. В месяц это выходит 200 млн токенов.
На опенроутере $0.05/M input tokens $0.20/M output tokens. При потреблении 2:1 средняя цена $0.1. В пересчете на 200 млн токенов получается $20 т.е. 1600 рублей.
При этом ты понес капитальные расходы на покупку карт. Копейки, но все равно. Ты уверен, что оно имеет смысл или просто балуешься?
Автор, тебе будет лучше купить любую карту с тензорными ядрами типа 2060 супер на те же 8 гб vram. Затем взять moe модель типа qwen 3.5 a3b и запустить ее в кванте на 3-4 бита. Тензорные ядра (пусть даже первой версии у 2060) дают возможность ускорять умножение для тех самых квантованных чисел в 3-4 бита. Сам роутер модели займет 4 гб vram плюс output слой плюс kv кеш на 48к контекста и суммарно выйдет 7 гб vram. В итоге ты получишь адекватные 30 тс инпут и 5 тс аутпут. Никаких других более бюджетных решений не существует. Я пробовал даже майнинговые карты и там все плохо.
На этой карте, как и например на картах нвидия 1000 серии нет тензорных ядер, что делает невозможным ускорение квантованных моделей. Запустить можно, но производительность будет боль и печаль. Запускать же крошечные модели в q8 на 8гб нет особого смысла тк они глуповатые.
Качество кода не имеет значения. Он генерирует код который только он сам и понимает в текущем контексте. Контекст ушел - образовался техдолг который никто не понимает
В коде луп и промпт в чистом виде, каждая инструкция промпта в отдельности не провалидирована, не проверена совместимость между инструкциями, отсутвуют мутации промпта и инструкций впринципе. Обычная наколеночная поделка.
Еще было бы интересно посмотреть те же модели но с учетом агентной обертки. Например у меня квен кодер с фидбеком и мутацией промпта минимаксом/немотроном решает вообще все задачи которые я ему даю.
Я тоже пробовал таким заниматься и пришел к выводу, что это не работает. Ллм хорошо себя показывает в столкновении с детерминизмом т.е. с некоторой формой реальности. Столкновение же с другой ллм ухудшает ситуацию т.к. снижает уровень детерминизма и увеличивает возможность для фантазий. Я видел как ллм пытаются прийти к консенсусу и выйти на хороший результат. Но по факту это дает результат хуже чем если ллм пытается прийти к консенсусу с реальной внешней утилитой.
Ну вообще в посте написано буквально, что мы говорим спасибо тем, кто писал софт символ-за-символом. Это намек на то, что сейчас можно писать с помощью ии. Ничего криминального нет вообще.
Mistral взяли свою собственную модель и сделали ее файн тюнинг используя lean. Затем они сравнили свой файнтюн и ванильные модели других вендоров в других задачах lean. А почему не сделали такие же файнтюны моделей других вендоров и не сравнили их?
Я бы охарактеризовал это как синдром Кандинского-Клерамбо: одной рукой разработчики Mistral делают файн тюн, а другой рукой маркетологи втюхивают это как прорыв по сравнению с другими вендорами. Псевдоавтоматизмы - это верный признак шизофрении в компании. Я бы в такую компанию не инвестировал.
Автор, если ты этой темой интересуешься, то я тебе могу дать интересную наводку на еще одну штуку: локальное кеширование в слотах. Я просто сам изучаю и возможно тебе будет это интересно взять.
В llama.cpp (и не только) ты можешь кешировать несколько контекстов параллельно. Например если у тебя lang chain, то ты можешь очень эффективно обрабатывать несколько чейнов параллельно на нескольких машинах одной и той же моделью. Твоя задача - обеспечить любой вид синхронизации между ЖД на разных локальных машинах по сети. Размер kv кеша разнится от модели к модели, но обычно не более 8 гб.
Самое интересное, что можно дать фидбек из самого приложения и удалить kv кеш файл тогда, когда ты полностью обработал lang chain.
Получается очень круто: одна машина начинает обрабатывать один чеин, а вторая - другой. После обработки машины буквально за пару секунд обмениваются кешами и теперь каждая из них может обрабатывать любой чеин дальше.
Еще в данной парадигме интересно как будет работать мультиагентность с разными моделями. Т.е. на каждой из 10 машин у нас хранится много моделей и мы решаем сколько инстансов на данную модель поднять. Например мы решили по каким-то соображениям (из фидбэка самого приложения) поднять 3 машины с одинаковым агентами и моделями. После этого эти машины начинают шарить между собой общий кеш и очень эффективно в группе обрабатывать запросы. Т.е. получается алгоритм буста в мультиагентных системах с шарингом кеша.
Здравствуйте. Chat GPT инстант, подписка за 8 баксов. Отлично консультирует и вообще для всего.
Заходь на hugginface и смотри внимательно: для видеокарт на 8gb сейчас специально выпускают неплотные мое модели. Такие модели имеют в имени "a3b", что значит 3 миллиарда активных параметров. В реальности на карте для размещения всех слоев модели (а это как правило роутер + аутпут) нужно всего 4 гб видеопамяти. Получается, что остальные 4 гб видеопамяти можно заюзать на kv кеш для контекста (<= 96к) и обеспечить хорошую производительность. Если отключить ризонинг (или взять инстракт модель), то это дает возможность интегрировать абсолютно ненужную и завалящую видеокарту на 8 гб (типа 2060 super или 3050) на дев или даже стейджинг (на прод конечно не стоит).
Есть еще новая и очень интересная тема: MUSA (Moore Threads). В llama.cpp уже есть поддержка, в devops лежит готовый докер файл. По отзывам он хорошо работает с qwen (что лично для меня уже достаточно).
Карта Moore Threads S80 на 256 бит и 16 гб стоит на jd.com 1к юаней т.е. копейки в сравнении с даже 2-мя картами нвидиа или амд. Энергопотребление на базовых частотах в районе 150 ватт. Тензорные ядра для ускорения матричного умножения низкобитных чисел есть. Проблема только в непроверенной на практике архитектуре и драйверах.
Но вообще было бы разумно попробовать 2 такие карты, чтобы крутить плотную модель типа qwen 3.5 27b Q6: 26 гб на слои + 5 гб kv кеш на контекст 128к = 31 гб. Не факт, что на практике все сложится сразу в высокую производительность, но пробовать можно.
Я бы посоветовал выставлять базовые частоты, а не фиксировать tdp, но не суть важно.
Положим 650 ватт на машину ~ 475 квтч в месяц. Это 2900 рублей по ценам Питера каждый месяц.
Если у тебя 42 тс аутпут то инпут где-то 150 тс. Если предположить среднее использование с соотношение инпут:аутпут 2:1 то получится средняя скорость 80 тс. В месяц это выходит 200 млн токенов.
На опенроутере $0.05/M input tokens $0.20/M output tokens. При потреблении 2:1 средняя цена $0.1. В пересчете на 200 млн токенов получается $20 т.е. 1600 рублей.
При этом ты понес капитальные расходы на покупку карт. Копейки, но все равно. Ты уверен, что оно имеет смысл или просто балуешься?
У вас электричество государственное?
Или h200?
При сборке докер образа llama.cpp указывать билд арг ROCM_DOCKER_ARCH=gfx... и получается рабочий образ. Все.
Лучше для инференса ллм, то о чем ты и пишешь в статье.
Лучше сжигать элекроэнергию на рх? Это ведь вообще глупо. Разумнее уже заплатить за апи или купить подписку на микро модель.
Автор, тебе будет лучше купить любую карту с тензорными ядрами типа 2060 супер на те же 8 гб vram. Затем взять moe модель типа qwen 3.5 a3b и запустить ее в кванте на 3-4 бита. Тензорные ядра (пусть даже первой версии у 2060) дают возможность ускорять умножение для тех самых квантованных чисел в 3-4 бита. Сам роутер модели займет 4 гб vram плюс output слой плюс kv кеш на 48к контекста и суммарно выйдет 7 гб vram. В итоге ты получишь адекватные 30 тс инпут и 5 тс аутпут. Никаких других более бюджетных решений не существует. Я пробовал даже майнинговые карты и там все плохо.
На этой карте, как и например на картах нвидия 1000 серии нет тензорных ядер, что делает невозможным ускорение квантованных моделей. Запустить можно, но производительность будет боль и печаль. Запускать же крошечные модели в q8 на 8гб нет особого смысла тк они глуповатые.
Гугл экспериментирует с командами разработки 3-4 человека для MVP, но не для продукта
Качество кода не имеет значения. Он генерирует код который только он сам и понимает в текущем контексте. Контекст ушел - образовался техдолг который никто не понимает
И этот центр компетенций будет расположен в... Бангладеш т.к. в Индии слишком дорого такой создавать. Но тогда заголовок врет как дышит.
В коде луп и промпт в чистом виде, каждая инструкция промпта в отдельности не провалидирована, не проверена совместимость между инструкциями, отсутвуют мутации промпта и инструкций впринципе. Обычная наколеночная поделка.
Еще было бы интересно посмотреть те же модели но с учетом агентной обертки. Например у меня квен кодер с фидбеком и мутацией промпта минимаксом/немотроном решает вообще все задачи которые я ему даю.