Спасибо за подробный разбор. Название статьи действительно могло создать ожидание низкоуровневого материала про C++ и оптимизацию внутренних механизмов llama.cpp. При этом сама статья посвящена практическому запуску, конфигурации, API и первичному бенчмаркингу.
С частью замечаний не согласимся. Ollama не тождественна llama.cpp: она использует llama.cpp как один из ключевых компонентов, но добавляет собственный слой управления моделями, API и конфигурацией. /v1/chat/completions и /completion корректно называть эндпоинтами. Утверждение, что Flash Attention ничего не ускоряет, также слишком категорично: снижение обмена с памятью и потребления памяти в ряде сценариев даёт прирост производительности.
Тезис о том, что в 2026 году локальные LLM запускали уже все, тоже вряд ли универсален. Материал рассчитан на инженеров, которым нужен воспроизводимый путь от сборки до рабочего API. Для такой аудитории подобный разбор сохраняет практическую ценность.
Согласны, что диаграмму можно сделать понятнее за счёт более явного именования событий и шлюзов, а также более прозрачного отображения обмена сообщениями. Мы рады, что в комментариях предлагают конкретные шаги по улучшению материала.
Надеемся, что читатели, которые захотят пройти тренажёр с самого начала, воспользуются и вашими рекомендациями. Спасибо также за ссылку на дополнительный тренажёр - посмотрим.
Вы правы: в статье мы делали акцент прежде всего на постепенном усложнении процесса и разборе логики BPMN-элементов, но действительно недостаточно внимательно отнеслись к правилам хорошего визуального стиля. Для обучающего материала это важно и здесь замечание справедливое.
Синтаксис BPMN и хороший стиль моделирования - не одно и то же, и в следующих материалах мы постараемся это лучше развести: отдельно логику процесса, отдельно требования к читаемости схемы.
Спасибо и за ссылки: добавим их в статью. Отдельно отмечу, что именно ради таких комментариев и стоит публиковать материалы: полезная обратная связь помогает читателю точнее понимать, как правильно применять инструменты на практике.
Спасибо за развернутый комментарий. Вы поднимаете действительно фундаментальный момент: классический REST по Филдингу и то, что в индустрии обычно называют REST API - две разные вселенные.
В строгом REST HATEOAS является ключевым ограничением архитектуры и большинство современных API под это определение действительно не подпадают. По сути, то, что мы используем в микросервисах - это HTTP RPC c REST-like конвенциями уровня ресурсов, методов и кодов ответа.
Именно к этой практической модели и относится статья: она описывает типичные ошибки аналитиков и разработчиков в прикладных корпоративных API, в которых:
HATEOAS практически никогда не применяется;
кеширование чаще контролируется на уровне клиентской логики, а не прокси;
URL используется как удобный идентификатор ресурса, а не как часть гипермедийного контракта.
Именно в таких условиях (корпоративные системы, интеграции между сервисами, работа аналитиков с backend-разработчиками) и возникают описанные в статье ошибки - от неправильного выбора HTTP-метода до отсутствия версионирвования.
Вы абсолютно правы в теории - и это важное уточнение, - но фокус статьи был именно на индустриальном, упрощённом REST, который используется при интеграции сервисов между собой.
Спасибо, что подсветили разницу. Возможно стоит вынести это в отдельный раздел, чтобы разделять уровни абстракции и не смешивать архитектурную идею с индустриальной реальностью.
Спасибо за замечание — абсолютно справедливо. В статье мы ошибочно не сфокусировались на более широких CRUD-случаях. Добавили пометочку со звёздочкой. Вам респект за бдительность :)
Лучше использовать POST с передачей фильтров в body. GET с телом формально не запрещён стандартом разработки, но в реальности большинство прокси, кешей и даже часть HTTP-клиентов игнорируют или отбрасывают body, поэтому поведение получается нестабильным. Для REST-совместимого решения обычно применяют POST, когда объём фильтров превышает безопасную длину URI.
Спасибо, что поделились - крутой, жизненный рассказ. Прямо видно, как по ходу колесо сансары проверок превращается в проверку не алгоритмов, а нервной системы ))
System Design - отдельная боль. Прекрасно вас понимаем.
Кстати, если Яндекс не выберет - не расстраивайтесь. Выбирайте MaDeLa :) У нас тоже бывают интересные задачки, но больше с доверием к опыту. Мы ценим тех, кто умеет кодить, применяя здравый смысл.
Думается, что алгоритмические задачки не вымрут. Этот скилл требовали на собеседованиях 10 лет назад, и, скорее всего, будут требовать ещё долго - даже в эпоху развитого AI. А значит и тренажёры по зубрёжке будут жить. Кстати, как относитесь к тому, что на собесах дают алготимические задачки решать? Считаете полезной практикой или устаревшей традицией?
Да, для паттернов это частая история. Взять в том числе гоф-паттерны: когда ты впервые с ними сталкиваешься, то не осознаёшь когда их нужно применять и стремишься их использовать даже там, где не надо. Вероятнее всего по мере решения задач, придёт понимание относительно того, где какой паттерн применить. Они сами всплывут в памяти и вам останется лишь взглянуть в статью, чтобы использовать её как шпаргалку
Подтверждаем: отличная книга, хороший совет. Но одно другому не мешает. Мы в MaDeLa считаем, что чем шире арсенал подходов к решению задач, тем лучше. И классические книги, и практические паттерны вроде тех, что в статье, отлично дополняют друг друга.
Во фронт-бэк можно использовать gRPC-Web - это адаптация gRPC под браузеры. Он поддерживает унарные запросы и частично серверный стриминг, но С СЕРЬЁЗНЫМИ ОГРАНИЧЕНИЯМИ.
gRPC-Web требует прокси (к примеру, Envoy), не даёт привычной отладки через DevTools или Postman, не работает с JSON (только protobuf - если хочется послать json, нужно ставить gRPC-gateway или городить прослойки) и в целом требует более сложной инфраструктуры.
Вывод: фронт-бэк технически возможен, но на практике REST или GraphQL для фронта проще, лучше и надёжней. gRPC лучше оставить для связи между микросервисами, бэк-бэк.
Да, согласны - gRPC с рефлексией и grpcurl - мощная штука. Тут речь больше о том, что REST с OpenAPI проще для публичных API: документация сразу видна в браузере и не требует каких-то спец-инструментов.
Бесспорно. Фронт может случайно нагрузить бэк: спровоцировать тяжёлый запрос или N+1. GraphQL требует дисциплины. На практике также встречается гибридный подход: REST - для типовых операций (создание, получение, обновление, удаление), где состав данных стабилен, GraphQL - для гибкой агрегации из микросервисов.
gRPC изначально построен на HTTP/2, который обеспечивает мультиплексирование, бинарную передачу и эффективное использование соединения. gRPC официально НЕ поддерживает HTTP/3 в стабильных продакшн-версиях на большинстве платформ (по крайней мере по состоянию на 2025 год) Есть экспериментальная поддержка (в некоторых клиентах на C++, Go, Java), но она ограничена и пока не готова к продакшн-нагрузке. Основная причина: HTTP/3 построен на QUIC, а это непростой стек (включает UDP, TLS 1.3 и т.д.), требующий существенной переработки как клиентов, так и серверов. gRPC использует фичи HTTP/2, которые не напрямую совместимы с HTTP/3. Как только появятся стабильные библиотеки, обратная совместимость и поддержка в инфраструктуре, вероятно, увидим переход.
Спасибо за подробный разбор. Название статьи действительно могло создать ожидание низкоуровневого материала про C++ и оптимизацию внутренних механизмов llama.cpp. При этом сама статья посвящена практическому запуску, конфигурации, API и первичному бенчмаркингу.
С частью замечаний не согласимся. Ollama не тождественна llama.cpp: она использует llama.cpp как один из ключевых компонентов, но добавляет собственный слой управления моделями, API и конфигурацией. /v1/chat/completions и /completion корректно называть эндпоинтами. Утверждение, что Flash Attention ничего не ускоряет, также слишком категорично: снижение обмена с памятью и потребления памяти в ряде сценариев даёт прирост производительности.
Тезис о том, что в 2026 году локальные LLM запускали уже все, тоже вряд ли универсален. Материал рассчитан на инженеров, которым нужен воспроизводимый путь от сборки до рабочего API. Для такой аудитории подобный разбор сохраняет практическую ценность.
Очень хорошая рекомендация. Обязательно добавим эту книгу в статью как материал для дальнейшего изучения. Спасибо!
Хороший и конструктивный комментарий, спасибо.
Согласны, что диаграмму можно сделать понятнее за счёт более явного именования событий и шлюзов, а также более прозрачного отображения обмена сообщениями. Мы рады, что в комментариях предлагают конкретные шаги по улучшению материала.
Надеемся, что читатели, которые захотят пройти тренажёр с самого начала, воспользуются и вашими рекомендациями. Спасибо также за ссылку на дополнительный тренажёр - посмотрим.
Спасибо за развёрнутый комментарий.
Вы правы: в статье мы делали акцент прежде всего на постепенном усложнении процесса и разборе логики BPMN-элементов, но действительно недостаточно внимательно отнеслись к правилам хорошего визуального стиля. Для обучающего материала это важно и здесь замечание справедливое.
Синтаксис BPMN и хороший стиль моделирования - не одно и то же, и в следующих материалах мы постараемся это лучше развести: отдельно логику процесса, отдельно требования к читаемости схемы.
Спасибо и за ссылки: добавим их в статью. Отдельно отмечу, что именно ради таких комментариев и стоит публиковать материалы: полезная обратная связь помогает читателю точнее понимать, как правильно применять инструменты на практике.
Спасибо за развернутый комментарий. Вы поднимаете действительно фундаментальный момент: классический REST по Филдингу и то, что в индустрии обычно называют REST API - две разные вселенные.
В строгом REST HATEOAS является ключевым ограничением архитектуры и большинство современных API под это определение действительно не подпадают. По сути, то, что мы используем в микросервисах - это HTTP RPC c REST-like конвенциями уровня ресурсов, методов и кодов ответа.
Именно к этой практической модели и относится статья: она описывает типичные ошибки аналитиков и разработчиков в прикладных корпоративных API, в которых:
HATEOAS практически никогда не применяется;
кеширование чаще контролируется на уровне клиентской логики, а не прокси;
URL используется как удобный идентификатор ресурса, а не как часть гипермедийного контракта.
Именно в таких условиях (корпоративные системы, интеграции между сервисами, работа аналитиков с backend-разработчиками) и возникают описанные в статье ошибки - от неправильного выбора HTTP-метода до отсутствия версионирвования.
Вы абсолютно правы в теории - и это важное уточнение, - но фокус статьи был именно на индустриальном, упрощённом REST, который используется при интеграции сервисов между собой.
Спасибо, что подсветили разницу. Возможно стоит вынести это в отдельный раздел, чтобы разделять уровни абстракции и не смешивать архитектурную идею с индустриальной реальностью.
Спасибо за замечание — абсолютно справедливо.
В статье мы ошибочно не сфокусировались на более широких CRUD-случаях. Добавили пометочку со звёздочкой. Вам респект за бдительность :)
Лучше использовать POST с передачей фильтров в body.
GET с телом формально не запрещён стандартом разработки, но в реальности большинство прокси, кешей и даже часть HTTP-клиентов игнорируют или отбрасывают body, поэтому поведение получается нестабильным.
Для REST-совместимого решения обычно применяют POST, когда объём фильтров превышает безопасную длину URI.
Спасибо, что поделились - крутой, жизненный рассказ. Прямо видно, как по ходу колесо сансары проверок превращается в проверку не алгоритмов, а нервной системы ))
System Design - отдельная боль. Прекрасно вас понимаем.
Кстати, если Яндекс не выберет - не расстраивайтесь. Выбирайте MaDeLa :) У нас тоже бывают интересные задачки, но больше с доверием к опыту. Мы ценим тех, кто умеет кодить, применяя здравый смысл.
Удачи на финале - даже если просто для галочки
Думается, что алгоритмические задачки не вымрут. Этот скилл требовали на собеседованиях 10 лет назад, и, скорее всего, будут требовать ещё долго - даже в эпоху развитого AI. А значит и тренажёры по зубрёжке будут жить. Кстати, как относитесь к тому, что на собесах дают алготимические задачки решать? Считаете полезной практикой или устаревшей традицией?
Да, для паттернов это частая история. Взять в том числе гоф-паттерны: когда ты впервые с ними сталкиваешься, то не осознаёшь когда их нужно применять и стремишься их использовать даже там, где не надо. Вероятнее всего по мере решения задач, придёт понимание относительно того, где какой паттерн применить. Они сами всплывут в памяти и вам останется лишь взглянуть в статью, чтобы использовать её как шпаргалку
Подтверждаем: отличная книга, хороший совет. Но одно другому не мешает. Мы в MaDeLa считаем, что чем шире арсенал подходов к решению задач, тем лучше. И классические книги, и практические паттерны вроде тех, что в статье, отлично дополняют друг друга.
Во фронт-бэк можно использовать gRPC-Web - это адаптация gRPC под браузеры.
Он поддерживает унарные запросы и частично серверный стриминг, но С СЕРЬЁЗНЫМИ ОГРАНИЧЕНИЯМИ.
gRPC-Web требует прокси (к примеру, Envoy), не даёт привычной отладки через DevTools или Postman, не работает с JSON (только protobuf - если хочется послать json, нужно ставить gRPC-gateway или городить прослойки) и в целом требует более сложной инфраструктуры.
Вывод: фронт-бэк технически возможен, но на практике REST или GraphQL для фронта проще, лучше и надёжней.
gRPC лучше оставить для связи между микросервисами, бэк-бэк.
Да, согласны - gRPC с рефлексией и grpcurl - мощная штука. Тут речь больше о том, что REST с OpenAPI проще для публичных API: документация сразу видна в браузере и не требует каких-то спец-инструментов.
Бесспорно. Фронт может случайно нагрузить бэк: спровоцировать тяжёлый запрос или N+1.
GraphQL требует дисциплины.
На практике также встречается гибридный подход: REST - для типовых операций (создание, получение, обновление, удаление), где состав данных стабилен, GraphQL - для гибкой агрегации из микросервисов.
Хороший вопрос, спасибо.
gRPC изначально построен на HTTP/2, который обеспечивает мультиплексирование, бинарную передачу и эффективное использование соединения.
gRPC официально НЕ поддерживает HTTP/3 в стабильных продакшн-версиях на большинстве платформ (по крайней мере по состоянию на 2025 год)
Есть экспериментальная поддержка (в некоторых клиентах на C++, Go, Java), но она ограничена и пока не готова к продакшн-нагрузке.
Основная причина: HTTP/3 построен на QUIC, а это непростой стек (включает UDP, TLS 1.3 и т.д.), требующий существенной переработки как клиентов, так и серверов. gRPC использует фичи HTTP/2, которые не напрямую совместимы с HTTP/3.
Как только появятся стабильные библиотеки, обратная совместимость и поддержка в инфраструктуре, вероятно, увидим переход.
Спасибо за ссылку на статью, очень интересно