让每块GPU产出更多可销售的Token
AI原生推理公司的收入取决于每GPU小时的令牌产出量，而请求路由决定了每个GPU能生成多少令牌
每一次请求都决定着您的利润空间
推理服务公司以固定成本购买GPU算力，再以不断下降的价格销售token。两者的差额就是利润，而利润在很大程度上取决于请求处理路径：由哪个GPU处理请求、其缓存是否已预热，以及请求是否需要排队等待。轮询机制对所有请求一视同仁。F5则在F5 Application Delivery and Security Platform上，根据实时推理服务信号路由每个请求。
使用相同的GPU生成更多token
经The Tolly Group验证的测试显示，在DPU模式下，词元吞吐量可提升至多40%。
更快生成首个词元
经The Tolly Group验证的测试表明，首个词元生成时间缩短幅度高达61%。
沿用现有服务栈
根据NVIDIA Dynamo和NVIDIA NIM的信号进行路由，无需替换技术栈中的任何组件。
治理并保护每一位客户
跟踪并限制每位客户的Token用量，保护用于提供模型访问的API。
F5助力推理服务公司保持利润率
推理感知路由
首个词元生成时间
按客户进行令牌治理
保护模型API和智能体
资源
常见问题
推理感知路由利用服务层的实时信号（如队列深度、KV缓存利用率和GPU负载），将每个AI请求发送到适合处理该请求的模型服务器。通用负载均衡会均匀分配请求，但推理请求的资源开销差异很大，因此均匀分配请求反而会导致工作负载不均。Kubernetes Gateway API Inference Extension将这一模式标准化。
要缩短首个token的返回时间，应先优化排队环节，因为在繁忙的GPU上，如果请求需要等待前面的长文本生成任务完成，那么无论模型速度多快，首个token的返回都会延迟。将请求路由到队列较短且缓存已预热的端点，将提示词前缀保留在已缓存这些前缀的服务器上，并将超长请求与简短的交互式请求分开处理。调整批处理设置、量化等模型侧技术有助于进一步缩短首个token的返回时间。
每个token的成本大致等于GPU每小时的成本除以该小时内生成的有效token数量。硬件购买或租赁后，成本端基本固定，因此关键在于提高产出，具体涉及利用率、缓存命中率、批处理效率，以及请求在各GPU之间的分配是否均衡。在token价格下降时，每GPU小时的token产出即使小幅提升，也会直接影响利润率。
不会，推理感知路由不会取代NVIDIA Dynamo或vLLM。模型服务框架决定模型如何在GPU上运行，包括批处理、缓存和调度。推理感知路由则决定请求到达哪台服务器，以及依据何种策略进行路由。BIG-IP Next for Kubernetes根据这些系统提供的信号进行路由，因此现有的模型服务技术栈保持不变。
公布的结果是在DPU模式下使用NVIDIA BlueField-3 DPU测得的，不会自动适用于主机部署。BIG-IP Next for Kubernetes可在标准主机CPU上运行，采用相同的路由逻辑；对于大多数使用租赁算力的推理服务公司，这将是起步时采用的部署方式。请根据主机部署自身的测试结果确定其资源配置。