Уточню, num_gpu в ollama это не количество gpu, а число слоёв модели которые пробуются для offload на gpu. В статье это действительно можно было подписать явнее.
При этом мой запуск был не на дискретной видеокарте с отдельной vram, а на Radeon 780M в составе r7 260 то есть на igpu со shared memory. Поэтому сценарий не совсем такой же как “модель целиком должна влезть в dedicated vram” часть нагрузки уходила в cpu/ram, часть в gpu/shared memory и это как раз видно по приведённой загрузке системы.
Скорость в среднем 13 т/с получил не как теоретическую оценку, а из локального запуска на этой конфигурации. Согласен что для чистого бенчмарка лучше отдельно показать eval_count / eval_duration из ответа ollama и вывод ollama ps, чтобы было видно фактическое распределение. Добавлю это уточнение чтобы не было впечатления что num_gpu: 20 означает “20 видеокарт” или гарантированный full gpu offload.
Да, на этом этапе RAG чаще всего и начинает “ехать”. В моём случае по скорости слабым местом была generation: retrieval занимал около 2 секунд, а локальная llm могла отвечать десятки секунд.
По качеству слабое место оказалось на границе retrieval/filtering: semantic search что то находит почти всегда, но похожий chunk не всегда даёт достаточный контекст для ответа. Поэтому добавил strong/borderline пороги, negative tests и exact-term guard для технических токенов, то есть backend должен не просто собрать prompt, а сначала решить есть ли вообще смысл вызывать llm.
Это как раз про переход от “embeddings + prompt” к back системе. Scores сами по себе не универсальны, они зависят от модели, чанкинга и корпуса. Поэтому на проде важнее смотреть top-k sources, что ушло в prompt, latency retrieval/generation, долю запросов без контекста, ошибки/timeouts и случаи, где модель ответила не по sources.
Контрольные вопросы это regression tests для RAG: positive, negative, exact token и stale index сценарии, после смены модели, prompt, chunking или thresholds они показывают не сломалось ли поведение.
В таком случае смотрел не на язык а на весь RAG pipeline. Если система на половину запросов отвечает none а на вторую половину отвечает не то, значит нужно разбирать не только llm, а retrieval: какие документы попали в индекс, как они нарезаны на chunks, какие sources поднимаются, какие scores, что уходит в prompt и когда backend вообще должен отказаться от генерации.
Для production RAG на мой взгляд обязательны request_id, sources, debug endpoint, negative tests, метрики retrieval/generation и набор контрольных вопросов. Без этого получается не система а “надеемся что vector search и prompt как нибудь справятся”.
Сейчас заканчиваю статью про этот переход. Там хочу показать это на локальном примере.
Про recision/recall скорее имел в виду как offline проверку на заранее подготовленном наборе вопросов, а не как то что можно просто посчитать в production. В проде конечно нужны уже proxy метрики: score у top-k, доля no context ответов, сколько запросов дошло до generation, latency по этапам, частые провальные вопросы и т.п.
И да тут как раз видно, что RAG это не только ml часть и не только backend. Если смотреть только из ноутбука или только со стороны API, легко не увидеть где именно всё ломается.
Бэкендеру не обязательно становиться ml инженером, но базу по retrieval и метрикам качества понимать надо, иначе получается классика: api есть, модель отвечает, ui есть а бизнесу прилетает либо none либо ответ вообще не про то.
RAG всё равно нужно отдельно проверять: тестовые вопросы, качество найденного контекста, precision/recall хотя бы на базовом уровне.
Тут появляется отдельный инженерный слой между “работает в Jupyter” и “работает в проде”.
Кто это делает ml engineer, backend разработчик с ml контекстом или команда зависит от проекта, но задачи уже не только в модели, нужно ещё вынести код в сервис, добавить обработку ошибок, логи, метрики, трассировку, тестовые вопросы и контроль того, какие документы/чанки реально попали в prompt.
Без такой диагностики llm/rag быстро становится чёрным ящиком, вроде что то отвечает но непонятно почему именно так.
Согласен. Я скорее не про то, что внутренности инструмента не важны, а про то что глубина понимания зависит от задачи.
Где то хватает прикладного уровня, а когда появляются ограничения по производительности, конкурентности или сопровождению уже приходится глубже разбираться, как инструмент устроен.
Думаю если человек в основном занимается обучением моделей в PyTorch, то asyncio ему может быть вообще не нужен.
Но вокруг нейросетей часто есть не только само обучение модели, есть ещё инференс сервисы, api, очереди, стриминг ответов, параллельные запросы к внешним сервисам, обвязка вокруг llm и т.д. И вот там уже понимание async/await и asyncio может оказаться вполне полезным.
То есть я бы не сказал, что “всем кто пишет на PyTorch обязательно знать asyncio”. Предполагаю это пример того, что python используется в очень разных контекстах и глубина знания языка сильно зависит от задач.
На системе с отдельной vram картина ожидаемо будет другой.
В моём случае тест был именно про ноутбук без дискретной видеокарты: Radeon 780m использует shared memory, поэтому ram одновременно нужна и системе и модели и графике. Плюс запуск был через lm studio на windows 11, без ручной настройки llama.cpp и без агрессивного квантования kv cache.
Поэтому я бы не сравнивал напрямую “19 gb vram + 8 gb ram на ubuntu” и мой сценарий с 30 gb ram на ноутбуке, это разные режимы использования памяти. В статье как раз пытался показать пользовательский сценарий “запустил в lm studio на ноутбуке без dgpu и посмотрел, насколько это комфортно”.
Про qwen интересно. Для задач по коду вполне возможно что qwen coder/qwen 3.x на C++ даст более сильный результат чем tested openai/gpt-oss-20b. Эту статью специально не делал сравнением моделей, но как направление для следующего теста звучит разумно.
В llama.cpp есть отдельные benchmark инструменты и для чистого сравнения производительности они подходят лучше. В статье больше смотрел на пользовательский сценарий через lm studio: запустилось ли, сколько ест RAM, какая скорость в реальных prompt задачах и насколько этим можно пользоваться.
Сравнение CPU vs iGPU идея интересная, возможно стоит сделать как отдельный мини тест.
То что llama.cpp более гибкий инструмент, не спорю.
Статья была не про максимальную ручную оптимизацию, а про другой практический сценарий: запуск модели через LM Studio как через готовый UI инструмент. Для части пользователей это не "трата времени", а нормальный способ быстро проверить модель без ухода в параметры llama.cpp.
Запас RAM это важная метрика: ноутбук используется не в вакууме, параллельно обычно открыты браузер, IDE, мессенджеры и фоновые процессы. Если после запуска модели остаётся 1-2 GB свободной памяти, это уже влияет на комфорт и стабильность.
Наверное почти в каждом стеке есть такие темы, в java можно спросить про устройство JVM и GC, в c# про CLR и async/await под капотом. Пользоваться инструментом и глубоко понимать его внутренности всё таки разные уровни.
Мне кажется это вообще относится не только к python. Среди разработчиков на java, c# или js тоже далеко не все глубоко понимают устройство JVM, CLR или движка V8.
Для большинства задач важнее уметь эффективно решать проблему с помощью инструмента, чем знать все внутренние детали его реализации.
У меня python просто появился через интерес к llm, а дальше уже постепенно появился интерес и к самому языку, и к его экосистеме.
Согласен, python это не только переходник к llm, на нём вполне пишут нормальные back сервисы.
В статье фокус был на взгляд c#/java back разработчика, у которого python появился именно через llm/rag задачи. Поэтому я больше писал про прототипы, embeddings, rag и ai инструменты, а не про python как основной back стек.
Про полноценный back на python это, скорее отдельная большая тема.
Если по содержанию есть конкретные замечания по rag, python, back интеграции, безопасности или enterprise контексту с интересом обсудим. Гадание по модели вряд ли что то добавит к теме статьи.
Про linux согласен python там давно стандартный инструмент для скриптов, автоматизации и glue кода. В статье фокус был уже не python как linux инструмент, а python как быстрый вход в llm/rag задачи для back разработчика из java/c# мира.
А back в схеме не отдельный стек, тут формулировка могла быть точнее. Имелись в виду back практики доступы, безопасность, логи, сопровождение и production качество, которые нужны независимо от языка.
С точки зрения контейнеров, otel, пайплайнов и деплоя .net и java действительно во многом равноправны. Здесь как раз нет принципиальной проблемы, современный .net нормально живёт в linux/контейнерах.
Но я и не писал что новые сервисы технически нельзя стартовать на .net. Вопрос в другом "какие стеки уже согласованы внутри организации, какие есть команды, шаблоны проектов, библиотеки, требования иб, экспертиза и кто потом будет это сопровождать".
То есть выбор стека в enterprise обычно шире чем "runtime + devops обвязка", devops может видеть образ, но организация всё равно видит людей, процессы, стандарты и стоимость поддержки.
Уточню, num_gpu в ollama это не количество gpu, а число слоёв модели которые пробуются для offload на gpu. В статье это действительно можно было подписать явнее.
При этом мой запуск был не на дискретной видеокарте с отдельной vram, а на Radeon 780M в составе r7 260 то есть на igpu со shared memory. Поэтому сценарий не совсем такой же как “модель целиком должна влезть в dedicated vram” часть нагрузки уходила в cpu/ram, часть в gpu/shared memory и это как раз видно по приведённой загрузке системы.
Скорость в среднем 13 т/с получил не как теоретическую оценку, а из локального запуска на этой конфигурации. Согласен что для чистого бенчмарка лучше отдельно показать eval_count / eval_duration из ответа ollama и вывод ollama ps, чтобы было видно фактическое распределение. Добавлю это уточнение чтобы не было впечатления что num_gpu: 20 означает “20 видеокарт” или гарантированный full gpu offload.
Да, всё верно.
Да, на этом этапе RAG чаще всего и начинает “ехать”. В моём случае по скорости слабым местом была generation: retrieval занимал около 2 секунд, а локальная llm могла отвечать десятки секунд.
По качеству слабое место оказалось на границе retrieval/filtering: semantic search что то находит почти всегда, но похожий chunk не всегда даёт достаточный контекст для ответа. Поэтому добавил strong/borderline пороги, negative tests и exact-term guard для технических токенов, то есть backend должен не просто собрать prompt, а сначала решить есть ли вообще смысл вызывать llm.
Это как раз про переход от “embeddings + prompt” к back системе. Scores сами по себе не универсальны, они зависят от модели, чанкинга и корпуса. Поэтому на проде важнее смотреть top-k sources, что ушло в prompt, latency retrieval/generation, долю запросов без контекста, ошибки/timeouts и случаи, где модель ответила не по sources.
Контрольные вопросы это regression tests для RAG: positive, negative, exact token и stale index сценарии, после смены модели, prompt, chunking или thresholds они показывают не сломалось ли поведение.
Сегодня опубликовал статью с локальным примером: https://habr.com/ru/articles/1048252/
В таком случае смотрел не на язык а на весь RAG pipeline. Если система на половину запросов отвечает none а на вторую половину отвечает не то, значит нужно разбирать не только llm, а retrieval: какие документы попали в индекс, как они нарезаны на chunks, какие sources поднимаются, какие scores, что уходит в prompt и когда backend вообще должен отказаться от генерации.
Для production RAG на мой взгляд обязательны request_id, sources, debug endpoint, negative tests, метрики retrieval/generation и набор контрольных вопросов. Без этого получается не система а “надеемся что vector search и prompt как нибудь справятся”.
Сейчас заканчиваю статью про этот переход. Там хочу показать это на локальном примере.
Про recision/recall скорее имел в виду как offline проверку на заранее подготовленном наборе вопросов, а не как то что можно просто посчитать в production. В проде конечно нужны уже proxy метрики: score у top-k, доля no context ответов, сколько запросов дошло до generation, latency по этапам, частые провальные вопросы и т.п.
И да тут как раз видно, что RAG это не только ml часть и не только backend. Если смотреть только из ноутбука или только со стороны API, легко не увидеть где именно всё ломается.
Бэкендеру не обязательно становиться ml инженером, но базу по retrieval и метрикам качества понимать надо, иначе получается классика: api есть, модель отвечает, ui есть а бизнесу прилетает либо none либо ответ вообще не про то.
RAG всё равно нужно отдельно проверять: тестовые вопросы, качество найденного контекста, precision/recall хотя бы на базовом уровне.
Тут появляется отдельный инженерный слой между “работает в Jupyter” и “работает в проде”.
Кто это делает ml engineer, backend разработчик с ml контекстом или команда зависит от проекта, но задачи уже не только в модели, нужно ещё вынести код в сервис, добавить обработку ошибок, логи, метрики, трассировку, тестовые вопросы и контроль того, какие документы/чанки реально попали в prompt.
Без такой диагностики llm/rag быстро становится чёрным ящиком, вроде что то отвечает но непонятно почему именно так.
Согласен. Я скорее не про то, что внутренности инструмента не важны, а про то что глубина понимания зависит от задачи.
Где то хватает прикладного уровня, а когда появляются ограничения по производительности, конкурентности или сопровождению уже приходится глубже разбираться, как инструмент устроен.
Думаю если человек в основном занимается обучением моделей в PyTorch, то asyncio ему может быть вообще не нужен.
Но вокруг нейросетей часто есть не только само обучение модели, есть ещё инференс сервисы, api, очереди, стриминг ответов, параллельные запросы к внешним сервисам, обвязка вокруг llm и т.д. И вот там уже понимание async/await и asyncio может оказаться вполне полезным.
То есть я бы не сказал, что “всем кто пишет на PyTorch обязательно знать asyncio”. Предполагаю это пример того, что python используется в очень разных контекстах и глубина знания языка сильно зависит от задач.
Согласен lm studio больше показывает общую картину, но задержку до первого токена там легко не заметить.
Для честного сравнения надо отдельно мерить time to first token, скорость генерации и общую latency, llama.cpp здесь benchmark будет показательнее.
Про NPU интересный вариант для embeddings/векторизации данных он может быть полезнее, чем грузить cpu/igpu. Надо будет отдельно попробовать.
На системе с отдельной vram картина ожидаемо будет другой.
В моём случае тест был именно про ноутбук без дискретной видеокарты: Radeon 780m использует shared memory, поэтому ram одновременно нужна и системе и модели и графике. Плюс запуск был через lm studio на windows 11, без ручной настройки llama.cpp и без агрессивного квантования kv cache.
Поэтому я бы не сравнивал напрямую “19 gb vram + 8 gb ram на ubuntu” и мой сценарий с 30 gb ram на ноутбуке, это разные режимы использования памяти. В статье как раз пытался показать пользовательский сценарий “запустил в lm studio на ноутбуке без dgpu и посмотрел, насколько это комфортно”.
Про qwen интересно. Для задач по коду вполне возможно что qwen coder/qwen 3.x на C++ даст более сильный результат чем tested openai/gpt-oss-20b. Эту статью специально не делал сравнением моделей, но как направление для следующего теста звучит разумно.
В llama.cpp есть отдельные benchmark инструменты и для чистого сравнения производительности они подходят лучше. В статье больше смотрел на пользовательский сценарий через lm studio: запустилось ли, сколько ест RAM, какая скорость в реальных prompt задачах и насколько этим можно пользоваться.
Сравнение CPU vs iGPU идея интересная, возможно стоит сделать как отдельный мини тест.
То что llama.cpp более гибкий инструмент, не спорю.
Статья была не про максимальную ручную оптимизацию, а про другой практический сценарий: запуск модели через LM Studio как через готовый UI инструмент. Для части пользователей это не "трата времени", а нормальный способ быстро проверить модель без ухода в параметры llama.cpp.
Запас RAM это важная метрика: ноутбук используется не в вакууме, параллельно обычно открыты браузер, IDE, мессенджеры и фоновые процессы. Если после запуска модели остаётся 1-2 GB свободной памяти, это уже влияет на комфорт и стабильность.
Не удивлён)
Наверное почти в каждом стеке есть такие темы, в java можно спросить про устройство JVM и GC, в c# про CLR и async/await под капотом. Пользоваться инструментом и глубоко понимать его внутренности всё таки разные уровни.
Мне кажется это вообще относится не только к python. Среди разработчиков на java, c# или js тоже далеко не все глубоко понимают устройство JVM, CLR или движка V8.
Для большинства задач важнее уметь эффективно решать проблему с помощью инструмента, чем знать все внутренние детали его реализации.
У меня python просто появился через интерес к llm, а дальше уже постепенно появился интерес и к самому языку, и к его экосистеме.
Согласен, python это не только переходник к llm, на нём вполне пишут нормальные back сервисы.
В статье фокус был на взгляд c#/java back разработчика, у которого python появился именно через llm/rag задачи. Поэтому я больше писал про прототипы, embeddings, rag и ai инструменты, а не про python как основной back стек.
Про полноценный back на python это, скорее отдельная большая тема.
Нет, не угадали)
Если по содержанию есть конкретные замечания по rag, python, back интеграции, безопасности или enterprise контексту с интересом обсудим. Гадание по модели вряд ли что то добавит к теме статьи.
Про linux согласен python там давно стандартный инструмент для скриптов, автоматизации и glue кода. В статье фокус был уже не python как linux инструмент, а python как быстрый вход в llm/rag задачи для back разработчика из java/c# мира.
А back в схеме не отдельный стек, тут формулировка могла быть точнее. Имелись в виду back практики доступы, безопасность, логи, сопровождение и production качество, которые нужны независимо от языка.
С точки зрения контейнеров, otel, пайплайнов и деплоя .net и java действительно во многом равноправны. Здесь как раз нет принципиальной проблемы, современный .net нормально живёт в linux/контейнерах.
Но я и не писал что новые сервисы технически нельзя стартовать на .net. Вопрос в другом "какие стеки уже согласованы внутри организации, какие есть команды, шаблоны проектов, библиотеки, требования иб, экспертиза и кто потом будет это сопровождать".
То есть выбор стека в enterprise обычно шире чем "runtime + devops обвязка", devops может видеть образ, но организация всё равно видит людей, процессы, стандарты и стоимость поддержки.