gpt4 book ai didi

Tensorflow 服务性能与直接推理相比非常慢

转载 作者:行者123 更新时间:2023-12-03 14:53:54 24 4
gpt4 key购买 nike

我在以下场景中运行:

  • 单节点 Kubernetes 集群(1x i7-8700K、1x RTX 2070、32GB RAM)
  • 1 个 Tensorflow 服务 pods
  • 4 个推理客户端 Pod

  • 推理客户端所做的是他们从 4 个独立的摄像头(每个 1 个)获取图像并将其传递给 TF-Serving 进行推理,以便了解视频源中看到的内容。

    我之前一直通过直接调用 TensorFlow 在推理客户端 Pod 中单独进行推理,但这在显卡的 RAM 上并不好。最近引入了 Tensorflow Serving 以优化 RAM,因为我们不会将重复的模型加载到显卡中。

    并且性能看起来不太好,对于 1080p 图像,它看起来像这样:

    Direct TF:20ms 用于输入张量创建,70ms 用于推理。
    TF-Serving:80ms 用于 GRPC 序列化,700-800ms 用于推理。

    TF-Serving pod 是唯一可以访问 GPU 的,并且是独占绑定(bind)的。其他一切都在 CPU 上运行。

    我可以做任何性能调整吗?

    我正在运行的模型是来自 TF Model Zoo 的 Faster R-CNN Inception V2。

    提前谢谢了!

    最佳答案

    This is from TF Serving documentation :

    Please note, while the average latency of performing inference with TensorFlow Serving is usually not lower than using TensorFlow directly, where TensorFlow Serving shines is keeping the tail latency down for many clients querying many different models, all while efficiently utilizing the underlying hardware to maximize throughput.


    根据我自己的经验,我发现 TF Serving 在提供一致的模型服务抽象方面很有用,并且 不需要实现自定义服务功能 .开箱即用的模型版本控制和多模型可为您节省大量时间,并且是很好的补充。
    此外,我还推荐 batching your requests如果你还没有。我还建议使用 TENSORFLOW_INTER_OP_PARALLELISM , TENSORFLOW_INTRA_OP_PARALLELISM , OMP_NUM_THREADS TF Serving 的参数。 Here is an explanation of what they are

    关于Tensorflow 服务性能与直接推理相比非常慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60997316/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com