Хвост инженера

Автор: Артём Вурсалов · Yandex for Frontend

Доклад из серии Yandex for Frontend — короткое введение в алгоритмы и структуры данных для frontend-разработчиков. Это не попытка за час пересказать университетский курс, а разговор о базовом инженерном навыке: уметь оценивать цену решения до того, как оно начнёт тормозить на реальных данных.

Рабочий код ещё не значит хороший код. Два решения могут одинаково проходить тесты, но по-разному расходовать время и память. Вурсалов показывает это на простых примерах: палиндром, массивы, объекты, Set, Map, O-нотация. Смысл не в том, чтобы выучить набор обозначений, а в том, чтобы начать задавать правильный вопрос: что произойдёт с этим кодом, когда входных данных станет в десять, сто или тысячу раз больше?

Кому смотреть: frontend-разработчикам на JavaScript, которые хотят понять что такое O-нотация и как ею пользоваться на практике — без погружения в теорию вычислений.

Из этого можно взять в работу: взять любую функцию из своего кода, которая работает с массивом, и спросить — сколько операций она совершает при массиве размером N? Если ответ «не знаю» — это отправная точка.

Автор: Антон Алексеев · HighLoad++ 2024

Доклад с HighLoad++ 2024 о том, как Selectel собирал инференс-платформу на базе open source-сервера NVIDIA Triton и Kubernetes. Triton решает базовую задачу: позволяет обслуживать ML-модели в продакшне без написания отдельного сервиса для каждой модели с нуля.

Сценарий типичный: модель сначала заворачивают в FastAPI, а затем обвязка постепенно обрастает batching, управлением инстансами, распределением GPU-ресурсов, обновлением версий и маршрутизацией трафика. Triton закрывает существенную часть этой базовой работы: умеет динамический batching, поддерживает модели в форматах PyTorch, TensorFlow, ONNX и TensorRT, а ensemble позволяет собрать цепочку моделей внутри одной ноды с одной GPU.

Но production-инференс начинается там, где заканчивается сам сервер моделей. Канареечное распределение трафика в платформе сделано через Istio, графы моделей на нескольких нодах — через Ray, а автоскейлинг GPU-ресурсов — средствами Kubernetes и дополнительными компонентами. Важная деталь: на момент доклада платформа Selectel ещё находилась в beta, поэтому это не история про «готовое решение из одной коробки», а разбор того, как такую систему собирают на практике.

Кому смотреть: ML-инженерам, MLOps- и DevOps-командам, которые обслуживают несколько моделей на GPU и хотят понять границу между возможностями inference-сервера и задачами всей платформы.

Из этого можно взять в работу: при внедрении Triton заранее разделите требования на две группы — что должен делать сам сервер моделей, а что потребует Kubernetes, service mesh, автоскейлинга, GPU-оператора или отдельного control plane.

Источник: Распределенные системы и system design

Когда одной базы уже недостаточно по объёму, чтению и записи, шардирование выглядит неизбежным решением. Но на этом масштабирование не заканчивается — оно только начинается. Как только сообщения распределяются по шардам, приходится отдельно решать проблему порядка, генерации ID, Kafka, WebSocket-соединений и доставки между регионами.

В авторском ролике разбирается system design мессенджера на миллиард пользователей. Требования намеренно ограничены: создать чат, добавить или удалить участника, отправить текстовое сообщение и доставить его в реальном времени пользователям, которые сейчас онлайн. Статусы прочтения, реакции и медиа автор не рассматривает — они могут быть добавлены поверх предложенной архитектуры.

Кому смотреть: backend-разработчикам и тем, кто готовится к system design-интервью, но хочет увидеть не список модных технологий, а цепочку инженерных компромиссов: какое решение принимается первым и какие новые проблемы оно создаёт дальше.

Из этого можно взять в работу: при шардировании сначала зафиксируйте инварианты. В этом дизайне сообщения одного чата должны оставаться в одном логическом потоке, а их ID — возрастать. Именно эти требования определяют и ключ шардирования базы, и распределение сообщений в Kafka.

Автор: Дмитрий Стогов (Zend Technologies) · PHP Russia 2019

⚠️ Доклад 2019 года — за год до выхода PHP 8.0 (ноябрь 2020). Это анонс и технический разбор того, что готовилось. JIT, Preloading и FFI с тех пор вышли в стабильных версиях; суть механизмов Стогов объясняет точнее, чем большинство статей, написанных постфактум.

Дмитрий Стогов — один из ключевых людей за производительностью PHP. Автор Turck MMCache (eAccelerator), мейнтейнер Zend OPcache, лидер проекта PHPNG, который лёг в основу PHP 7 и дал двукратный прирост производительности без изменения синтаксиса. Теперь — лидер разработки JIT-компилятора для PHP 8. Когда он рассказывает о производительности PHP — это рассказ от человека, который её делал.

Три новых подсистемы PHP 8 — JIT, Preloading и FFI — Стогов рассматривает как взаимосвязанные. Все три направлены на производительность, но также открывают PHP новые области применения: писать системно-зависимые расширения прямо на PHP, подключать сторонние C-библиотеки, быстро прототипировать низкоуровневые вещи.

Кому смотреть: PHP-разработчикам, которые хотят понять JIT, FFI и Preloading не через «что делать в коде», а через «как это устроено и зачем» — от человека, который это написал.

Из этого можно взять в работу: если ваш PHP-сервис тяжело нагружен CPU-вычислениями (а не I/O) — именно для таких сценариев JIT даёт реальный прирост. Для типичного CRUD с базой данных эффект от JIT минимален — и Стогов об этом говорит честно.

Автор: Лёша Королёв · Яндекс для разработчиков

Лёша Королёв — техлид команды observability в Яндекс Go. В этом докладе он показывает, как команда строит единый дашборд для платформы, в которой больше тысячи микросервисов, тысячи подов, базы данных, балансировщики, очереди и сотни изменений в проде каждый день. Когда происходит мажорный инцидент, проблема не в том, что у команды нет метрик. Проблема в том, что среди этого масштаба нужно быстро найти короткий путь к причине.

Дальше он разбирает, как устроен единый дашборд платформы такси и какие требования к нему предъявляет команда. Его задача — не показать всё на одном экране, а помочь ответить на два вопроса: в какой части платформы проблема и как такси чувствует себя прямо сейчас.

Кому смотреть: инженерам и техлидам, которые строят мониторинг для большой распределённой системы и хотят, чтобы дашборд помогал во время инцидента, а не просто содержал много графиков.

Из этого можно взять в работу: начните с бизнес-метрик. Если представить путь заказа как последовательность статусов, то бизнес- и техническая воронки быстро показывают, на каком участке возник сбой. А дальше ссылки должны вести от агрегированной картины к конкретному сервису и его логам.

Автор: Григорий Петров и Никита Соболев · MoscowPython

Python Day Special на Positive Hack Days 2025 — формат живой дискуссии за столом, который Moscow Python проводит как спецвыпуск между конференциями. Ведущие — Григорий Петров (евангелист MoscowPython) и Никита Соболев. Тема — асинхронность в Python: не туториал по asyncio, а честный разговор о том, что эта парадигма даёт и чего стоит.

Разговор идёт по структуре: сначала реальные преимущества (07:43), затем реальные недостатки (19:04), затем то о чём обычно не говорят — сложности асинхронного программирования в целом (22:10). Отдельный блок — несовместимость sync и async миров в библиотеках и фреймворках (28:22, 43:55): когда одна синхронная зависимость блокирует весь event loop.

Кому смотреть: Python-разработчикам, которые используют async на практике или только решают, нужен ли он их проекту — и хотят услышать взвешенную оценку, а не «async — это будущее».

Из этого можно взять в работу: проверить, нет ли в вашем async-коде синхронных вызовов в библиотеках без async-поддержки — это одна из самых частых причин, когда async не даёт ожидаемого прироста.

Автор: Александр Морозов (co-founder & CTO, Datafold) · Python Channel · Moscow Python Conf++ 2021

Datafold — стартап из YCombinator, платформа мониторинга аналитических данных. Прошли акселератор, писали MVP за 1–2 месяца — за основу взяли Redash (MIT-лицензия, аналитические БД, SPA). Redash целиком построен на Flask: sqlalchemy, alembic, REST, auth, rate-limiters, CSRF, CLI. Через какое-то время решили менять стек.

Название доклада начинается с «Не highload» — и это принципиально. Причина переезда не в том, что Flask медленный. Причина в том, что типичный Flask-хэндлер — это огромный boilerplate для простых вещей: получить данные из тела запроса как JSON, провалидировать, сконвертировать. Хочешь нормальные сообщения об ошибках — boilerplate вырастает ещё в несколько раз. FastAPI решает это через type hints и Pydantic: код становится короче, читаемее и самодокументируемым.

Кому смотреть: разработчикам на Flask, которые думают о переходе на FastAPI — или уже переходят. Морозов рассказывает не то, что написано в документации, а конкретные проблемы при реальном переезде и как их обошли.

Из этого можно взять в работу: если у вас Flask и вы тратите значительное время на boilerplate для валидации запросов — это именно тот сигнал. FastAPI с Pydantic закрывает эту боль, а не задачу throughput.

Автор: Екатерина Давыдова · AvitoTech

Екатерина Давыдова — программный менеджер в Авито, ведёт внутреннюю программу, которая объединяет все GenAI-команды компании. Авито — один из крупнейших классифайдов мира, и в этой связи их опыт выстраивания работу с GenAI отличается от опыта стартапов с «чистым листом».

Доклад начинается с конкретной ситуации: к продуктовой команде приходит CEO и говорит «давайте уже что-нибудь запустим на AI, иначе будет поздно» — и команда не понимает ни где брать идеи, ни какие ресурсы нужны, ни как вообще двигаться. Давыдова прошла через это с десятками команд и рассказывает, что работает на каждом из пяти этапов: от генерации идей до масштабирования.

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

Кому смотреть: продуктовым лидерам, которым пришла задача «запустить что-то на GenAI» — и которые хотят понять, с чего начинать и где обычно закапываются.

Из этого можно взять в работу: WizardOfOz-эксперимент. До того как у вас есть рабочая модель, посадите человека имитировать AI в диалоге с пользователями. Вы начнёте собирать паттерны запросов, проверять первые гипотезы и снимать метрики — не написав ни строчки кода для самой модели.

Автор: Валентин Удальцов (Happy Inc. / Typhoon) · PHP Russia 2021

Валентин Удальцов в Happy Inc. прошёл полный путь от ORM до нативного SQL — и рассказывает об этом не как об отказе от абстракций ради принципа, а как об архитектурном решении, которое «во всех смыслах выгодно». Отправная точка: ORM, QueryBuilder и прочие абстракции связывают руки при попытке использовать базу данных на полную.

Конкретный вопрос, который задаёт Удальцов: какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции? Если абстракция закрывает доступ к возможностям СУБД, которую вы выбрали — это уже не абстракция, это ограничение.

Кому смотреть: PHP-разработчикам, которые чувствуют что ORM начинает ограничивать — но не решаются отказаться от него, потому что «так принято».

Из этого можно взять в работу: найти в своём проекте одно место где вы написали сложный raw SQL внутри ORM-контекста (через DB::raw() или аналог). Если такое место есть — это сигнал, где абстракция уже не помогает.

Автор: Алексей Фирсов (мейнтейнер aiopg, SoftPro) · MoscowPython

⚠️ Выпуск записан в 2019 году. Детали реализации aiopg и экосистема async-драйверов для PostgreSQL с тех пор изменились (появились asyncpg, sqlalchemy async, psycopg3). Архитектурные решения и вопросы дизайна — актуальны.

Первый выпуск Moscow Python Podcast (переименован из Python Junior Podcast) открылся «хардкором и сеньорностью». Гость: Алексей Фирсов, старший разработчик SoftPro и мейнтейнер библиотеки aiopg. Разговор ведут сооснователь MoscowPython Валентин Домбровский, тимлид NVIDIA Злата Обуховская и Григорий Петров. 44 минуты про то, как устроен асинхронный доступ к PostgreSQL из Python — и зачем вообще нужна отдельная библиотека для этого.

Центральный вопрос выпуска формулируется прямо: так ли уж нужна целая библиотека для взаимодействия асинхронного кода с PostgreSQL (05:32)? Ответ разворачивается через архитектурные детали: aiopg работает поверх psycopg2, который работает поверх написанной на C библиотеки libpq — и при этом сам написан на Python, а не на C. Почему — отдельный разговор (12:36).

Кому смотреть: Python-разработчикам, которые используют или планируют использовать async с PostgreSQL и хотят понять что происходит «под капотом», а не просто вызывать await conn.execute().

Из этого можно взять в работу: проверить в своём async-коде — есть ли места, где coroutine вызывается без await. Python это разрешает, и это источник трудноуловимых багов. Вопрос поднимается в выпуске явно (35:14) как вопрос дизайна языка.

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

Типичная архитектурная сессия выглядит так: техлид рисует диаграмму, остальные кивают или спорят о деталях реализации. Знание о домене остаётся в головах у бизнес-экспертов и не попадает в код. Event Storming переворачивает процесс: на стену клеятся оранжевые стикеры с доменными событиями («заказ размещён», «платёж подтверждён», «склад уведомлён»), и сразу становится видно, где у команды нет общего языка — кто-то называет одно и то же по-разному, кто-то предполагает событие, которого на самом деле не существует. Пробелы в знании домена вскрываются за часы, а не за месяцы.

Кому смотреть: техлидам и разработчикам, участвующим в проектировании новых фич или рефакторинге сложной предметной области — особенно там, где бизнес-логика плохо формализована.

Из этого можно взять в работу: следующий раз, когда команда пишет задачу на новую фичу, попробуйте перед техническим дизайном провести 30-минутный мини-Event Storming: попросите каждого участника написать 3–5 событий, которые должны произойти в системе. Несоответствия вскроются моментально.

Автор: Кирилл Мокевнин · TechLead Channel

Кирилл Мокевнин — основатель Hexlet, образовательной платформы для разработчиков. Он не просто учит программировать — он годами наблюдает, где люди застревают, и думает о том, чему именно нужно учить. Доклад на TechLead Conf.

Название доклада намеренно отсылает к «Гарри Поттеру и методам рационального мышления» — книге о применении научного мышления к реальным задачам. Мокевнин идёт тем же путём: берёт «Прагматичного программиста» Ханта и Томаса и разбирает, что за этим словом стоит на практике. Вывод неудобный: большинство обучающих материалов учат решать задачи с известным правильным ответом — алгоритмы, паттерны, синтаксис. Реальная работа — это задачи с неизвестным правильным ответом, где нужно выбрать направление при неполных данных, попробовать, получить обратную связь и скорректироваться. Этот навык почти нигде не преподают явно — и именно поэтому технически грамотные разработчики застревают на одном уровне годами.

Ценный угол: Мокевнин смотрит на обучение не теоретически, а через реальные данные — он видит, где именно тысячи студентов Hexlet теряются.

Кому смотреть: разработчикам, которые чувствуют, что технических знаний уже достаточно, но чего-то важного всё равно не хватает — и не могут точно назвать, чего.

Из этого можно взять в работу: найди задачу, которую откладываешь из-за «недостаточно знаю». Запиши письменно, что именно ты не знаешь. Скорее всего обнаружишь, что это не вопрос знаний, а вопрос принятия решения с неполной информацией — а это совсем другая проблема.

Автор: Алексей Мерсон · Код Желтый

Алексей Мерсон работает в Sage — внутренней observability-платформе Т-Банка. Доклад открывает конференцию по надёжности и наблюдаемости, организованную той же командой: это намеренно вводный разговор — синхронизировать понятия, прежде чем идти глубже.

Центральная структура доклада — пирамида качества: в основании надёжность, выше опыт пользователя. Это не абстракция: если система ненадёжна, весь разговор про UX и satisfaction теряет смысл. Надёжность Мерсон определяет через SRE-буки Google — вероятность выполнить требуемые функции без отказов за заданный период. Из этого вырастают SLI (конкретная метрика, связанная с пользовательским опытом), SLO (целевое значение) и бюджет ошибок — то время, которое система может «лечь», не нарушив SLO. Ключевые метрики для оптимизации — MTBF (среднее время между отказами) и MTTR (среднее время восстановления): чем больше первое и меньше второе, тем лучше используется бюджет ошибок. Наблюдаемость нужна именно для того, чтобы обе величины улучшать — без неё, по словам Мерсона, «бежишь через горящий лес с закрытыми глазами».

Кому смотреть: инженерам и тимлидам, которые слышали слова SLO, observability и MTTR в разных контекстах, но хотят разложить их по полочкам и понять, как они связаны между собой — до того как разбираться с конкретными инструментами.

Из этого можно взять в работу: сформулировать для своего сервиса один SLI — одну метрику, напрямую отражающую пользовательский опыт, а не просто аптайм базы данных. Это первый шаг, с которого Мерсон предлагает начинать.

Автор: Папочка Разработки · Папочка Разработки

Канал «Папочка Разработки», 20 минут. CQRS (Command Query Responsibility Segregation) — паттерн с устойчивой репутацией «понятного на собесе, но непонятного в коде». Видео разбирает, почему так происходит.

Распространённое понимание CQRS: разделить код на команды (пишут данные) и запросы (читают данные), сложить по разным папкам, добавить Handler для каждого — и считать, что CQRS внедрён. Это не CQRS, это просто именование. Настоящий паттерн — про разделение моделей: модель записи оптимизирована для инвариантов и бизнес-правил, модель чтения — для отображения данных в том виде, в котором их хочет видеть клиент. Когда модели разделены по-настоящему, появляется возможность масштабировать чтение и запись независимо, использовать разные хранилища, денормализовать read-side для производительности. Без разделения моделей это просто организация кода, а не архитектурный паттерн.

Кому смотреть: разработчикам, которые используют или планируют CQRS и хотят убедиться, что понимают его правильно — и тем, кто готовится к техническому интервью, где этот паттерн регулярно всплывает.

Из этого можно взять в работу: если у вас уже «есть CQRS» — проверьте: используете ли вы разные модели для чтения и записи? Если read side — это та же доменная модель, просто завёрнутая в Query-объект, вы не используете CQRS, вы используете именование.

Автор: Егор Заплатин · Яндекс Вертикали

Егор Заплатин — фронтенд тимлид в Яндекс Вертикалях (Путешествия, Аренда, Авто.ру). Доклад на Vertis JS 2026: полгода работы с AI-агентами в реальных задачах, выводы о том, что нужно сделать, чтобы они работали предсказуемо.

AI-агент не замещает инженера — он меняет то, на что инженер тратит время. Заплатин это понимает, хотя в докладе использует популярную аналогию «прокачать до мидла» — скорее как метафору для аудитории, а не буквальное сравнение. Содержательная часть, если убрать маркетинговую рамку, прикладная и по делу.

Центральная мысль: если ваш агент работает — это ещё ничего не значит. Надёжная работа в production требует инженерии. Заплатин разбирает четыре конкретные практики: правильно выстроенный контекст (что агент видит и в каком виде), feedback loop (как агент получает сигнал об ошибке и исправляет курс до конца задачи), MCP-интеграции (реальные инструменты вместо угадывания по обучающим данным), и скиллы — описания того, как решать конкретные задачи в конкретной кодовой базе. Примеры из продуктовых и технических задач на реальных проектах. Отдельно — задачи за пределами кода и масштабирование на команду.

Кому смотреть: разработчикам и тимлидам, которые уже попробовали агентов и столкнулись с нестабильным результатом — работает в одном случае, ломается в другом.

Из этого можно взять в работу: прежде чем оценивать агента, проверьте, что он видит нужный контекст — правильные файлы, актуальную документацию, внятное описание задачи. Половина проблем с качеством — это проблема контекста, а не модели.

Автор: Денис Буздалов · Heisenbug

Денис Буздалов работает в ИСП РАН с 2010 года: верификация авиационной электроники самолётов, тестирование криптопротоколов по формальным моделям, зависимые типы. Человек, который думает о корректности систем профессионально.

8 апреля 2022 года самолёт TAP Air Portugal в Копенгагене ушёл на второй круг в нестандартной ситуации — и левый двигатель не свернул реверс тяги. ПО было корректно сертифицировано. Баг проявился после 95 миллионов посадок и не воспроизводился ни в одной другой конфигурации. Самолёты так и продолжили летать с этим ПО спустя годы — исправление планировалось к 2025 году. Буздалов задаёт с этого вопрос: что вообще значит «хорошо протестировано», если такое возможно?

Его ответ: хорошее тестирование должно ставить систему в ситуации, о которых автор тестов даже не подумал. Property-based testing это умеет — описываешь свойства, а не примеры, фреймворк ищет опровержение на случайном входе. Но есть класс задач, где случайный вход почти всегда бессмысленен: сгенерировать программу, которая корректно тайпчекается, или граф с нетривиальными инвариантами наугад — значит получить 99% мусора. Буздалов показывает, как зависимые типы закрывают эту дыру: инвариант входных данных кодируется в типе, и генератор выводится автоматически через DepTyCheck.

Кому смотреть: всем, кто строит системы, где ошибки дорого стоят и плохо воспроизводятся вручную — не только авторам компиляторов, но и разработчикам протоколов, финансовых движков, встроенного ПО, любых систем с нетривиальными инвариантами на входе.

Из этого можно взять в работу: сформулировать для своей системы одно свойство вместо набора примеров и запустить на нём property-based тест. Не для сложных структур — просто как первый шаг к тому способу думать о тестировании, который Буздалов описывает.

Автор: Юрий Самсонов · JUG.ru

Юрий Самсонов — разработчик из Яндекса. Доклад на JPoint 2023 — не обзор GraphQL и не агитация за его повсеместное использование, а конкретный опыт внедрения: что сломалось, что не ожидали, как вышли.

REST-эндпоинты имеют предсказуемую проблему роста: по мере того как клиентов становится больше, у каждого появляются свои требования к форме данных. Один клиент хочет вложенный объект, другой — плоский список. Появляются параметры вроде ?include=user,tags,comments, эндпоинты обрастают опциями, и в какой-то момент backend-разработчик обнаруживает, что его работа — это в основном добавление новых вариаций существующих эндпоинтов под нужды клиентов. GraphQL переворачивает эту ответственность: клиент сам описывает, какие данные ему нужны, и получает ровно их — без over-fetching и under-fetching. Самсонов честно рассказывает о том, что эта свобода стоит: N+1 проблемы, сложность с кешированием, отладка запросов, которые клиент сформировал сам.

Кому смотреть: backend-разработчикам, у которых REST API начинает «расти вширь» под давлением разных клиентов, и тем, кто думает о GraphQL, но хочет услышать не маркетинг, а реальный опыт внедрения.

Из этого можно взять в работу: посчитайте, сколько полей в ответе вашего самого нагруженного эндпоинта реально используется мобильным клиентом. Если меньше трети — у вас есть over-fetching, и это стоит трафика, памяти и CPU прямо сейчас.

Автор: Александр Макаров · Организованное программирование | Кирилл Мокевнин

Александр Макаров — Lead of Yii Framework, CTO нескольких компаний — пришёл с провокацией: «трофей» вместо «пирамиды тестирования». Идея в том, что классическая пирамида — карго-культ. Она хорошо работает на первом проекте, а потом перестаёт отражать реальную архитектуру системы и реальные риски.

Разговор — про то, где в живых системах проходит граница между юнит-тестом и интеграционным (она нечёткая, и зависит от того, что ты считаешь «единицей»), и почему формальные определения из книг не помогают принимать решения о тест-стратегии. Это дебаты, не лекция — Мокевнин оппонирует, Макаров защищает позицию.

Кому смотреть: разработчикам, которые уже читали про пирамиду тестирования и задавались вопросом, почему в реальном проекте она так плохо работает. Тем, кто ведёт или планирует вести дискуссию о тест-стратегии в команде.

Из этого можно взять в работу: вместо того чтобы спорить «юниты или интеграционные» — спроси: что ты называешь «единицей» в своей системе? Ответ важнее любой классификации.

Автор: Иван Ямщиков · Podlodka Podcast

Иван Ямщиков работает в Pleias — компании, которая строит открытые языковые модели. Во время записи выпуска Podlodka #468 вышла новость о партнёрстве Pleias с Nvidia в рамках проекта Nemotron. Это не случайный контекст: Ямщиков находится внутри процесса, а не смотрит на него снаружи.

Центральный вопрос выпуска — не технический, а стратегический: что произойдёт, если весь рынок AI окончательно сконцентрируется вокруг нескольких закрытых облачных провайдеров? Ямщиков формулирует это как инженерную проблему: зависимость от GPT-4 API — это зависимость от одного вендора с непрозрачной политикой изменений, ценообразования и доступа к данным. Маленькие открытые модели — это не «дешёвая альтернатива большим», это инструмент сохранения контроля над инфраструктурой. Модель на 7 миллиардов параметров, которая умещается на одной GPU и работает локально, даёт то, что никакое API не даёт: полную воспроизводимость, отсутствие утечки данных и независимость от апстрима.

Кому смотреть: разработчикам и архитекторам, которые принимают решение о том, какой LLM использовать в продукте — и хотят понять, когда открытая маленькая модель является правильным выбором, а не просто компромиссом.

Из этого можно взять в работу: если вы сейчас используете закрытый API для задачи, которая не требует GPT-4-уровня рассуждений (классификация, извлечение структуры, генерация по шаблону) — попробуйте запустить Mistral 7B или Phi-3 локально на той же задаче. Разрыв в качестве окажется меньше, чем вы ожидаете.

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

Кому смотреть: разработчикам и архитекторам, проектирующим API для нескольких типов клиентов — мобильного приложения, веба, внешних партнёров — и чувствующим, что один общий backend начинает проигрывать в гибкости.

Из этого можно взять в работу: посмотрите на ваш API и спросите: сколько данных, которые возвращает один эндпоинт, реально используется мобильным клиентом? Если меньше половины — это сигнал, что клиент переплачивает за лишний трафик и обработку.