我看到市面上大多是Yolo实现的点选服务,什么各种DLL库满天飞,被易语言中间商贱卖到几百一套,笔者白嫖了几个这样的本地识别库,果然性能是不行的,并发几个就挂了,即使用上GPU也才达到我这个服务器CPU的性能水准,有多慢用过的应该知道,或许有的人做的还达不到我CPU的水准。但是有一个很奇怪的现象:很多人就是点名只要易语言的DLL库,理由居然是DLL快一点,但是快不快取决于目标检测和图像分类模型的预测速度,使用Web服务实现或者DLL调用库实现对性能的影响几乎可以忽略不计。不排除用易语言的也有业内大佬,但是吧,就深度学习而言,企业还是秒杀这些半路出家野路子的,正规军还是随便吊打只会套框架的易选手的本文目的只是为了给无脑要本地库不懂开发的开发打个脸。因为不少人一直觉得目标检测CPU这么快是不可能的,总觉得我在吹牛,时代变了,大人,给出接口自行验证。
测评机器
请求接口:
请求地址 | Content-Type | 参数形式 | 请求方法 |
---|---|---|---|
http://152.136.181.66:19196/predict | application/json | JSON | POST |
具体参数:
参数名 | 必选 | 类型 | 说明 |
---|---|---|---|
image | Yes | String | Base64 编码 |
title_coord | No | String | 值固定为:[0, 344, 120, 384] |
Python请求示例:
import base64
import requests
with open(r"1.jpg", "rb") as f:
img_bytes = f.read()
r = requests.post("http://152.136.181.66:19196/predict", json={
"image": base64.b64encode(img_bytes).decode(),
"title_coord": [0, 344, 120, 384]
}
返回样例:
{
"msg":{
"title":"水晶南瓜",
"items":[
{
"content":"水",
"coord":[277, 215],
"crop":[247, 182, 307, 249]
},
{
"content":"晶",
"coord":[171, 171],
"crop":[144, 140, 199, 202]
},
{
"content":"南",
"coord":[85, 258],
"crop":[56, 225, 115, 291]
},
{
"content":"瓜",
"coord":[246, 66],
"crop":[214, 30, 278, 102]
}
],
"coord_list":[
"247,182,307,249",
"144,140,199,202",
"56,225,115,291",
"214,30,278,102"
]
},
"success":true
}
服务识别的 总耗时 在70-80毫秒左右,目标检测 仅耗时20-40毫秒
算上本地网络延迟,请求耗时300ms左右
本地机器测评:
本地的数据好看多了,总体耗时在30-40毫秒之间
业务优先联系原创作者!!!
业务优先联系原创作者!!!
业务优先联系原创作者!!!