Компании по разработке систем с низкой задержкой: какая вам нужна и как проверить её на вашей собственной системе

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

Что значит «низкая задержка» для нашей системы?

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

• Торговое железо — десятки или сотни наносекунд. STAC-T0, бенчмарк, разработанный по согласованию с торговыми компаниями из STAC Benchmark Council, замеряет, как быстро сетевое железо и софт системы превращают смоделированные рыночные данные в смоделированную заявку, без какой-либо торговой логики между ними. В обзоре STAC от 5 ноября 2020 года сказано, что бенчмарк рассматривает систему как чёрный ящик, «взаимодействуя с ней исключительно через сетевые пакеты, которым он аппаратно ставит отметки времени», и что программные отметки времени на уровне десятков или сотен наносекунд могут давать значительную погрешность. Тестируемым стеком (stack under test), как STAC называет измеряемую систему, может быть FPGA-карта — плата с микросхемой, схемы которой запрограммированы под одну задачу
• Торговые площадки — от микросекунд примерно до миллисекунды. Правило ЕС о том, насколько точными должны быть часы торговой площадки, привязывает эту точность к тому, сколько времени торговая система площадки тратит на обработку заявки и отправку подтверждения. С 2 марта 2026 года это правило — Делегированный регламент Комиссии (ЕС) 2025/1155, который заменил прежнее правило, известное как RTS 25, и называет это время задержкой gateway-to-gateway: «время, измеряемое с момента, когда сообщение получено внешним шлюзом системы торговой площадки, передано по протоколу подачи заявок, обработано матчинг-движком и отправлено обратно, до момента, когда шлюз отправляет подтверждение». Если на это уходит 1 миллисекунда или меньше, часы площадки могут отклоняться от всемирного координированного времени (UTC) не более чем на 100 микросекунд, а гранулярность отметок времени должна составлять 0,1 микросекунды или меньше
• AdTech — от десятков миллисекунд до секунды. OpenRTB 2.6, стандарт IAB Tech Lab для real-time bidding, позволяет бирже задавать дедлайн в каждом запросе на ставку, и время на прохождение через интернет входит в этот дедлайн. Документация Google Authorized Buyers для разработчиков, последний раз обновлённая 17 сентября 2026 года, говорит, что дедлайн ответа «составляет от 80 до 1000 мс в зависимости от формата и типа аукциона»
• Приложения и веб-страницы, которыми пользуются люди, — около десятой доли секунды. Jakob Nielsen писал в 1993 году, что «0,1 секунды — это примерно предел, при котором у пользователя возникает ощущение, что система реагирует мгновенно». Для веб-страниц руководство Google web.dev, последний раз обновлённое в сентябре 2025 года, считает отзывчивость хорошей, когда Interaction to Next Paint (INP) составляет 200 миллисекунд или меньше. INP измеряет, сколько времени страница тратит на реакцию на клики, касания и нажатия клавиш

У одного продукта могут быть части в разных диапазонах. Трейдер читает цены на экране, а заявке, которую он отправляет, по пути на площадку может понадобиться уложиться в гораздо более жёсткий дедлайн. Запишите каждый дедлайн вместе с двумя точками, между которыми он измеряется. Диапазон, в который попадает каждый из них, подскажет, в какую компанию обращаться.

С какими компаниями по разработке систем с низкой задержкой нам стоит поговорить?

Эта статья не составляет рейтинг компаний. Подходящий вид компании зависит от вашего диапазона и от работы, которую нужно сделать:

• Специалисты по железу и сетям — для дедлайнов, которые измеряются наносекундами или несколькими микросекундами. Они работают с FPGA-картами, сетевыми картами, коммутаторами и каналами связи до биржи. Спросите, какие из их цифр получены по отметкам времени, которые аппаратно снимаются на сетевом кабеле, и на чьём оборудовании шли тесты
• Инженерные компании в области торговых технологий — для дедлайнов в микросекундах или миллисекундах, когда время теряется внутри вашего собственного софта или на пути к брокеру или площадке. Они пишут софт, который отправляет заявки, обрабатывает рыночные данные, проверяет риск каждой заявки до её отправки, а на площадке — сводит заявки на покупку и продажу. Спросите, какие из построенных ими систем работают в проде сегодня и какие подключения к брокерам или площадкам они писали
• Инженерные компании в AdTech — когда биржа задаёт вам дедлайн отдельно в каждом запросе, а счёт за серверы растёт вместе с трафиком. Они строят биддеры и рекламные биржи. Спросите, какой из построенных ими биддеров или бирж до сих пор работает и получены ли его цифры таймаутов по подсчёту биржи или по их собственному
• Независимые инженеры по производительности — когда вы ещё не знаете причину или когда изменения будут вносить ваши собственные инженеры. Обычно они работают в одиночку или небольшой группой, измеряют работающую систему и сообщают, куда уходит время. Попросите показать прежний отчёт, из которого убраны название и данные клиента, и ждите диагноза, а не перестройки
• Вендоры компонентов — когда нужная вам часть у всех работает одинаково, а ваше преимущество лежит в другом. Они продают готовую часть, например матчинг-движок или подключение к бирже, которую вы запускаете вместо того, чтобы заказывать собственную. Спросите, от какой и до какой точки измерялись их цифры задержки и что вам разрешено менять в коде, который вы лицензируете
• Универсальные аутсорсинговые компании с конкретной командой по системам с низкой задержкой — когда вам нужно много инженеров, а путь, критичный к задержке, — лишь малая часть работы. Попросите назвать людей из этой команды и рассказать, что каждый из них построил в вашем диапазоне, и закрепите письменно, что именно они будут работать над вашим проектом
• Собственный наём — если вы конкурируете именно скоростью и так будет и дальше, а нанять и удержать инженеров, которые уже выпускали такие системы, вам по силам. Исследовательская компания Acuiti спросила 50 систематических хедж-фондов — фондов, которые торгуют по компьютерным моделям, — как они строят свои торговые технологии. В январе 2023 года она сообщила, что задержка «является ключевым фактором, определяющим отношение к аутсорсингу технологий фронт-офиса: компании, для которых задержка критична, чаще разрабатывают их своими силами»

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

Как проверить, что компания уже строила быстрые системы?

Статья о выделенных командах, ссылка на которую есть выше, перечисляет, что должно сопровождать каждую цифру производительности, и даёт чек-лист, который можно вставить в запрос предложений (RFP). Вопросы ниже помогают выяснить, как получены собственные цифры компании.

Спросите, где запускается отсчёт и где он останавливается. OPRA, которая публикует сводные данные о сделках и котировках американских опционных бирж, запускает отсчёт, когда входящее сообщение «поступает на вход приложения в среде OPRA», и останавливает его, когда исходящее сообщение «достигает выхода приложения из среды OPRA». Определение ЕС, процитированное выше, так же точно задаёт обе точки. Цифру без названных начальной и конечной точек невозможно сравнить с вашей.

Смотрите не только на типичный ответ, но и на самые медленные. В опубликованных метриках OPRA медианная задержка, то есть серединное значение, составляла 19,5 микросекунды в январе 2024 года и 20,5 в феврале. За те же два месяца 99-й перцентиль — время, которое превышал лишь самый медленный 1 процент сообщений, — снизился с 543,5 микросекунды до 57,5. Отчёт с одной лишь медианой не показал бы почти никаких изменений.

Средние значения тоже прячут медленные ответы. Книга Google Site Reliability Engineering, выпущенная O'Reilly в 2016 году, описывает веб-сервис со средней задержкой 100 миллисекунд при 1000 запросов в секунду, в котором «1% запросов вполне может занимать 5 секунд». Просите 99-й перцентиль по каждому пути и, если ваша система обрабатывает достаточно запросов, чтобы его измерить, 99,9-й, который превышает лишь 1 ответ из 1000.

Проверьте нагрузку, стоящую за каждой цифрой. Согласно обзору STAC 2020 года, STAC-T0 подаёт тестовый трафик с тремя частотами. Самая низкая «предназначена для того, чтобы увидеть, как ведут себя системы, когда они в основном простаивают», а самая высокая, обычно близкая к максимуму, который выдерживает тестируемая система, нужна, «чтобы увидеть, как ведут себя системы, когда они очень загружены». Просите цифры за вашу собственную самую загруженную минуту или из теста, который её воспроизводит.

Спросите, как проводился нагрузочный тест. Многие инструменты нагрузочного тестирования отправляют запрос, ждут ответа и только потом отправляют следующий. Когда система подвисает, такой инструмент перестаёт отправлять запросы, поэтому запросы, которые пришли бы во время подвисания, так и не попадают в замер.

Gil Tene, автор инструмента нагрузочного тестирования wrk2, называет этот эффект coordinated omission. В документации инструмента, последний раз изменённой в сентябре 2019 года, он пишет, что «ответы с высокой задержкой приводят к тому, что генератор нагрузки согласуется с сервером и избегает замеров в периоды высокой задержки». Его инструмент отправляет запросы с фиксированной частотой и замеряет каждый ответ «с того момента, когда должна была произойти отправка». Спросите, работает ли так инструмент компании или как были скорректированы его результаты.

Спросите, где ставилась каждая отметка времени. Для задержек в микросекундах обзор STAC называет бенчмарк с программными отметками времени «лучшим вариантом». Но он же предупреждает, что небольшие неравномерные задержки в программных отметках времени «могут давать значительную погрешность при измерении задержек в десятки или сотни наносекунд», и STAC-T0 вместо этого ставит отметки времени аппаратно. Компания, которая называет цифры в наносекундах, должна суметь показать, где снимались её аппаратные отметки времени.

Какой тест провести, прежде чем кого-то нанимать?

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

Отчёт должен показывать:

• Куда уходит время в вашу самую загруженную минуту — шаг за шагом вдоль пути, который вы записали
• Для каждого пути — время ответа на 99-м и 99,9-м перцентилях
• Исправления, упорядоченные по тому, сколько стоит каждое и что оно убирает, — время на пути или серверы, которые добавили, чтобы скрыть медленный путь
• Что компания оставила бы как есть и почему

Для торговых систем статья о медленном исполнении заявок, ссылка на которую есть выше, перечисляет четыре отметки времени, которые нужно записывать на каждой заявке. В AdTech статьи о всплесках трафика и о таймаутах DSP разбирают, что измерять на пике и по каждому подключению к бирже.

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

Какие тревожные сигналы стоит замечать при выборе компании для работы с низкой задержкой?

• Скорость описана словами — без цифры и без начальной и конечной точек
• Только средние значения — и ничего о самых медленных ответах
• Бенчмарк из собственной лаборатории компании, проведённый на её железе с трафиком, который она сама сгенерировала, — как доказательство применительно к вашей системе
• Переписывание или переход на новый язык программирования предлагают раньше, чем кто-то измерил вашу систему
• Цифру задержки обещают уже на первом созвоне
• Одна и та же презентация и для трейдинговой работы, где счёт идёт на микросекунды, и для рекламного биддера с дедлайном 100 миллисекунд

Если компания предлагает новый язык, статья по ссылке ниже показывает, как инженеры проверяют, в языке ли причина.

Где здесь место amBrain?

amBrain диагностирует медленные системы в трейдинге и AdTech: работающую платформу замеряют от начала до конца, и в отчёте названо, куда уходит время. Работа amBrain в трейдинге включает разработку торговых терминалов, систем управления заявками и биржевую интеграцию по протоколу FIX.

В AdTech amBrain занимается разработкой DSP, платформ real-time bidding и рекламных бирж.

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

amBrain делает софт с 2019 года.

Эта статья — не кейс и не описывает никакой работы для клиентов. Она не приводит ни цифр задержки для систем, которые построил amBrain, ни цен, ни сроков.

Спросите amBrain или любую другую компанию из вашего списка, что она измерила бы первым на вашей системе, и проведите каждую компанию через одни и те же проверки.

Частые вопросы

• Может, лучше собрать собственную команду? В исследовании Acuiti 2023 года, охватившем 50 систематических хедж-фондов, фонды, для которых задержка критична, чаще разрабатывали торговые технологии собственными силами. В любом случае сначала измерьте: отчёт подскажет, каких инженеров нанимать или что поручить компании
• Может ли одна компания закрыть и трейдинг, и AdTech? Может, если у неё есть системы в проде в вашем диапазоне в обеих областях. Попросите показать по одной работающей системе в каждой области и проверьте их цифры вопросами выше