噴一噴

我看到市面上大多是Yolo實現的點選服務，什麼各種DLL庫滿天飛，被易語言中間商賤賣到幾百一套，筆者白嫖了幾個這樣的本地識別庫，果然效能是不行的，併發幾個就掛了，即使用上GPU也才達到我這個伺服器CPU的效能水準，有多慢用過的應該知道，或許有的人做的還達不到我CPU的水準。但是有一個很奇怪的現象：很多人就是點名只要易語言的DLL庫，理由居然是DLL快一點，但是快不快取決於目標檢測和影象分類模型的預測速度，使用Web服務實現或者DLL呼叫庫實現對效能的影響幾乎可以忽略不計。不排除用易語言的也有業內大佬，但是吧，就深度學習而言，企業還是秒殺這些半路出家野路子的，正規軍還是隨便吊打只會套框架的易選手的本文目的只是為了給無腦要本地庫不懂開發的開發打個臉。因為不少人一直覺得目標檢測CPU這麼快是不可能的，總覺得我在吹牛，時代變了，大人，給出介面自行驗證。

測試介面

測評機器

請求介面：

具體引數： | 引數名 | 必選 | 型別 | 說明 | | ------------ | ---- | ------ | ------------------------------------------- | | 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毫秒之間

附上部分測試原圖 作者QQ：27009583

順便提一句，以上內容都可以在 lengyue.video 學習到