隨著近幾年AI的高速發展，湧現出越來越多的AI產品，我們生活中也深切感受到AI給帶來的不一樣的服務和體驗。比如高鐵和機場的刷臉安檢閘機，家裏面的智慧音響和智慧家居，還是兒童教育類的陪伴教育機器人，其背後是人工智慧各種演算法作為支撐。
AI各種演算法在產品化落地時，即要保持演算法的各種效能指標，又要足夠的快（起碼的要求必須能即時處理）。各種演算法根據不同業務場景，部署的位置不太一樣，大多數是部署到雲端伺服器中，還有一部份需要邊緣化部署。前者的主要挑戰是並行服務能力，主要指標是吞吐率和延時；後者主要挑戰是平台多樣化，主要挑戰是即時率和功耗（意味著成本）。
針對上述的問題，給演算法工程化提出了很高的要求，演算法雖然是核心模組，但是占據了大多數的計算資源和時延，所以，工程化做的越好，需要的計算資源越少，要麽可以提高吞吐量（雲端），要麽可以降低功耗（邊緣）；工程化做的越好，時延越小，帶來的好處是，可以加入更復雜的業務邏輯，給產品設計更多自由和選擇。
演算法引擎工程化的主要工作內容包含如下幾點：
1）演算法引擎設計與工程研發
2）版本釋出維護與管理
3）演算法引擎配套的測試框架設計與搭建
4）演算法引擎的效能測試和邊界測試
5）演算法引擎的平台移植與產品化落地
6）上下遊相關聯的演算法引擎的端到端測試和匹配問題
本文無法針對上述所有問題分別進行詳述，後續會分篇慢慢展開。下面以對雲端和邊緣端演算法的工程化思路為例，拋磚引玉，簡單聊聊。
雲端AI演算法工程化思路
雲端執行的演算法有足夠的硬體資源，如果不考慮電費和雲服務租金的話，可以不用太考慮工程化的深度，只要保證執行穩健性即可。即便不考慮成本，也需要考慮吞吐量和時延的問題，對外提供服務，時延是必須要考慮的問題，吞吐量可以拿錢砸（如果不差錢）。如果想把事情做到極致，雲端AI演算法的工程化的要求大概不外乎以下幾點：
雲端的所有程式的最基本要求，要穩健執行，演算法引擎大機率是C\C++語言開發的，眾所周知，C是沒有異常機制的，演算法引擎要是crash，往往崩掉的是整個服務，這個是災難性的。
很多人認為引擎的封裝不就是弄幾個API介面，編譯一個library就OK了嗎？實際上，我們看到的表象是這樣的，但是認知有偏見。雖然是雲端\伺服端上來部署的，但是，介面是不同部門之間的協定，設計不好，會浪費多個部門的資源。這裏有兩方面的要求：
1）介面設計的穩定性，易用性和擴充套件性（引擎基本要求）。
2）介面對業務支持的匹配性，
是設計一個大而全的引擎，還是設計一個和業務精致匹配的引擎，前者容易維護，一把梭，後者需要較深的設計架構能力，也許你擔心可維護性，這個透過架構，完全可以不用擔心。
這個涉及到成本和客戶體驗問題，也是最要緊的問題，加速的前提是不得有不可容忍的效能損失。第一個問題：成本，服務部署好之後，就是電費\租金的問題，加速的越快，吞吐率越高，成本越低；第二個問題：客戶體驗問題，上面也說了，速度越快，時延越低，產品設計的自由度越大，可以增加更復雜的業務邏輯。
邊緣端AI演算法工程化思路
邊緣端共有的特點是受成本影響，一般算力有限，除了AI演算法，還會有諸如視訊編解碼，音訊采樣，和業務邏輯等模組，分給AI演算法的資源是越少越好，這就要求執行在端上的演算法即要夠快，又要占用資源少，工程化的原則和思路如下：
端上的演算法穩定性雖然沒有雲端\伺服端要求那麽高，但是會影響使用者體驗，所以也是必須排在首位，產品體驗不好，產品經理會重點盯著你。
端的平台型別非常之多，主流還是ARM類芯片，即便是ARM類芯片，不同玩家的平台差異還是挺大的，如果每種平台做一個版本，那到計畫多的時候，維護工作就讓你傻眼了。可移植性是工程化的重點工作內容之一。
對於端側的裝置，引擎的加速意味著功耗的降低和體驗性的提高，功耗的降低以為著成本的壓縮，或者增加更多的演算法模組。由於演算法引擎是密集計算模組，可加速的空間比較大，是從事引擎工程化人員必備的核心技能。
以上是對演算法引擎工
