低延迟软件开发公司：你需要哪一类，以及如何在自己的系统上检验一家

没有哪份低延迟软件开发公司名单能适合每一位买家，因为这个说法涵盖的时限，彼此可以相差一百万倍。在交易硬件里，它可能指几十或几百纳秒。在应用或网页里，大约十分之一秒以内的回答，对使用者来说就已经是即时的了。所以第一个问题是：你自己的时限落在哪里。

对我们的系统来说，“低延迟”意味着什么？

对你的系统来说，低延迟就是一个时限，在两个你能说出名字的点之间测量。时限大致分为四个区间：

• 交易硬件，以几十或几百纳秒计。STAC-T0 是一项与 STAC Benchmark Council 中的交易公司协商制定的基准测试，它测量一个系统的网络硬件和软件把模拟行情数据转换成模拟订单有多快，中间不含任何交易逻辑。STAC 在 2020 年 11 月 5 日发布的概述中说，该基准把系统当作一个黑盒，“只通过网络数据包与之交互，并在硬件中为这些数据包打时间戳”；还说在几十或几百纳秒的量级上，软件时间戳可能带来相当大的误差。被测系统（STAC 称之为 stack under test，即被测栈）可以是一块 FPGA 卡，卡上的芯片其电路是为单一任务编程的
• 交易场所，从微秒级到大约一毫秒。欧盟关于交易场所时钟必须有多精确的规定，把这一精度与交易场所的交易系统处理一笔订单并发回确认所需的时间挂钩。自 2026 年 3 月 2 日起，这条规定是 Commission Delegated Regulation (EU) 2025/1155，它取代了此前被称为 RTS 25 的规定，并把这段时间称为网关到网关延迟（gateway-to-gateway latency），即“从交易场所系统的某个外部网关接收到一条消息的时刻起，该消息经订单提交协议发送、经撮合引擎处理、再发回，直至网关发出确认为止所测得的时间”。如果这段时间不超过 1 毫秒，交易场所的时钟与协调世界时（UTC）的偏差不得超过 100 微秒，时间戳的粒度必须达到 0.1 微秒或更细
• 广告技术，从几十毫秒到一秒。OpenRTB 2.6 是 IAB Tech Lab 的实时竞价标准，它允许广告交易平台在每个竞价请求里设定时限，而穿越互联网所花的时间也算在这个时限之内。Google Authorized Buyers 的开发者文档（最近一次更新于 2026 年 9 月 17 日）说，响应时限“在 80 到 1000 ms 之间，取决于广告格式和竞价类型”
• 人们日常使用的应用和网页，大约十分之一秒。Jakob Nielsen 在 1993 年写道，“0.1 秒大约是让用户感觉系统在即时响应的极限”。对网页而言，Google 的 web.dev 指南（最近一次更新于 2025 年 9 月）规定，当 Interaction to Next Paint（INP）不超过 200 毫秒时，响应性评为良好。INP 衡量的是页面对点击、轻触和按键作出响应需要多长时间

同一个产品的不同部分，可能落在不同的区间。交易员在屏幕上看价格，而他发出的订单在去往交易场所的路上，可能要满足严格得多的时限。把每个时限连同测量它的起止两个点一起写下来。每个时限落在哪个区间，就告诉你该找哪一类公司。

我们应该找哪些低延迟软件开发公司谈？

本文不给公司排名。哪一类公司合适，取决于你的区间以及你需要完成的工作：

• 硬件和网络专家，适合以纳秒或几微秒计的时限。他们做的是 FPGA 卡、网卡、交换机以及通往交易所的线路。要问清楚：他们的数字里，哪些来自硬件在网线上打的时间戳，以及测试是在谁的设备上跑的
• 交易技术工程公司，适合以微秒或毫秒计的时限，且时间损失在你自己的软件内部，或在通往经纪商或交易场所的途中。他们编写的软件负责发送订单、处理行情数据、在每笔订单发出之前检查其风险，在交易场所一侧还负责撮合买卖订单。要问清楚：他们做的哪些系统今天仍在生产环境中运行，以及他们写过哪些经纪商或交易场所的接入
• 广告技术工程公司，适合广告交易平台逐个请求为你设定时限、服务器账单随流量增长的情况。他们构建出价方和广告交易平台。要问清楚：他们做的哪个出价方或广告交易平台至今仍在线运行，以及它的超时数字是按广告交易平台的口径统计的，还是按他们自己的
• 独立性能工程师，适合你还不知道原因、或者改动将由你自己的工程师来做的情况。他们通常单独或以小团队工作，测量运行中的系统，并报告时间耗在了哪里。请他们出示一份以往的报告，删去客户名称和数据，并且要预期拿到的是一份诊断，而不是一次重建
• 组件厂商，适合你需要的那个部件对谁都一样、而你的优势在别处的情况。他们出售现成的部件，比如撮合引擎或交易所接入，你直接运行它，而不必委托别人专门开发。要问清楚：他们的延迟数字是从哪里测到哪里的，以及在你获得许可的代码里，你可以修改什么
• 设有专门低延迟团队的综合外包公司，适合你需要大量工程师、而快速路径只占工作一小部分的情况。要他们说出那个团队里每个人的名字，以及每个人在你的区间里做过什么，并以书面形式写明这些人会参与你的项目
• 自己招人，适合速度就是你的竞争手段、而且会一直如此的情况，前提是你能招到并留住已经交付过这类系统的工程师。研究机构 Acuiti 询问了 50 家系统化对冲基金（即依靠计算机模型交易的基金），了解它们如何构建自己的交易技术。它在 2023 年 1 月报告称，延迟“是决定对前台技术外包态度的关键因素，延迟至关重要的公司更有可能自行开发”

很多公司不止属于一类，所以要问清楚，派给你的工程师做过的是哪一类工作。

我们怎么核实一家公司以前确实做过快速系统？

上面链接的那篇关于专属团队的文章，列出了每一个性能数字都应当附带什么，并给出了一份可以直接粘贴进需求建议书（RFP）的清单。下面这些问题，用来弄清一家公司自己的数字是怎么得出来的。

问清楚计时从哪里开始、到哪里结束。OPRA 负责发布美国各期权交易所的综合成交与报价数据，它在传入消息“到达 OPRA 环境的应用程序入口”时开始计时，在传出消息“到达 OPRA 环境的应用程序出口”时停止计时。上文引用的欧盟定义，对这两个点同样界定得很精确。一个没有点明起止点的数字，无法和你的数字相比较。

既要看典型的回答，也要看最慢的那些。在 OPRA 公布的指标中，延迟中位数（也就是居中的那个值）2024 年 1 月为 19.5 微秒，2 月为 20.5 微秒。同样这两个月里，第 99 分位（只有最慢的 1% 的消息才会超过的那个时间）从 543.5 微秒降到了 57.5 微秒。一份只给中位数的报告，几乎看不出任何变化。

平均值同样会掩盖慢的回答。Google 的《Site Reliability Engineering》一书由 O'Reilly 于 2016 年出版，书中描述了一个每秒处理 1,000 个请求、平均延迟为 100 毫秒的 Web 服务，其中“1% 的请求很可能要花 5 秒”。要对方给出每条路径的第 99 分位；如果你的系统处理的请求量足以测出第 99.9 分位，也要这个数，每 1,000 个回答中只有 1 个会超过它。

核查每个数字背后的负载。在 STAC 2020 年的概述中，STAC-T0 以三种速率发送测试流量。最低的一档“旨在观察系统在大部分时间空闲时的表现”，最高的一档通常接近被测系统所能承受的上限，用来“观察系统在非常繁忙时的表现”。要对方拿出你自己最忙那一分钟的数字，或者来自重现那一分钟的测试的数字。

问清楚压测是怎么做的。很多压测工具发出一个请求，等到回答之后，才发下一个。系统一卡住，这样的工具就停止发送，于是本该在卡顿期间到达的那些请求，从来没有被计时。

压测工具 wrk2 的作者 Gil Tene 把这种效应称为 coordinated omission。在该工具最近一次修改于 2019 年 9 月的文档中，他写道：“高延迟的响应会导致压测生成器与服务器协同，从而避开在高延迟期间进行测量”。他的工具以固定速率发送请求，并“从本应发送请求的时刻起”为每个回答计时。要问清楚这家公司的工具是不是这样工作的，或者它的结果是怎么修正的。

问清楚每个时间戳是在哪里打的。对于微秒级的延迟，STAC 的概述把使用软件时间戳的基准测试称为“最佳选择”。它同时警告说，软件时间戳中那些微小而不均匀的延迟，“在测量几十或几百纳秒的延迟时，可能构成相当大的误差”，STAC-T0 则改为在硬件中打时间戳。一家报出纳秒数字的公司，应当能说明它的硬件时间戳是在哪里打的。

在雇任何人之前，我们该做什么测试？

如果你还不知道问题出在哪里，只知道系统似乎比应有的更慢、或者花费比应有的更多，就从这里开始。付费请你看好的那家公司，对你的线上系统做一次范围固定的测量，并附一份报告；无论你下一步怎么决定，报告都归你所有。以书面形式约定：为了做测量，这家公司可以安装或改动什么，以及事后如何移除它的工具。

报告应当给出：

• 在你最忙的那一分钟里，时间沿着你写下的那条路径，一步一步都耗在了哪里
• 每条路径的第 99 和第 99.9 分位响应时间
• 各项修复方案，按每一项的成本和它能消除的东西排序，无论消除的是路径上的时间，还是为掩盖一条慢路径而加上的服务器
• 这家公司会保持不动的部分，以及原因

对于交易系统，上面链接的那篇关于订单执行慢的文章，列出了每笔订单都要记录的四个时间戳。在广告技术领域，关于流量峰值和关于 DSP 超时的两篇文章，讲了高峰时以及每条广告交易平台连接上要测量什么。

用报告来评判这家公司。如果你自己的工程师不靠这家公司也能照着报告行动，你就可以依据真实的数字，选择接下来由谁来做这项工作，无论是这家公司还是别家。

选择低延迟公司时，有哪些危险信号？

• 只用文字描述速度，没有数字，也没有起止点
• 只有平均值，对最慢的回答只字不提
• 拿该公司自家实验室的基准测试——在它自己的硬件上、用它自己生成的流量跑出来的——当作关于你系统的证据
• 还没有人测量过你的系统，就提议重写，或者改用一种新的编程语言
• 第一次通话就许诺了一个延迟数字
• 对以微秒计的交易工作，和对时限为 100 毫秒的广告出价方，用的是同一套推销说辞

如果一家公司提议换一种新语言，下面链接的文章讲了工程师如何核查问题是不是出在语言上。

amBrain 在其中处于什么位置？

amBrain 诊断交易和广告技术领域的慢系统：对运行中的平台做端到端测量，报告会指明时间耗在了哪里。其交易方向的工作包括交易终端开发、订单管理系统和 FIX 协议交易所对接。

在 AdTech 领域，amBrain 从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作。

amBrain 有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。客户拥有产品与代码的全部所有权，amBrain 的可复用组件除外。

amBrain 自 2019 年起开发软件。

本文不是案例研究，也不描述任何客户项目。本文没有引用 amBrain 所建任何系统的延迟数字，也不给出任何价格或工期。

问问 amBrain，或者你名单上的任何其他公司，它会先在你的系统上测量什么，并让每一家公司都经受同样的核查。

常见问题

• 我们是不是应该自建团队？在 Acuiti 2023 年对 50 家系统化对冲基金的研究中，延迟至关重要的那些基金更有可能自行开发交易技术。无论走哪条路，都要先测量，因为报告会告诉你该招哪一类工程师，或者该请外部公司做什么
• 一家公司能同时覆盖交易和广告技术吗？能，前提是它在这两个领域都有处在你那个区间的生产系统。请它在每个领域各拿出一套在线运行的系统，并用上面那些问题核查其数字