靈伴科技（Rokid）藉助 Knative 實現 AI 應用雲原生 Serverless 化

作者：朱煒棟、元毅、子白

公司介紹

Rokid 創立於 2014 年，是一家專注於人機交互技術的產品平臺公司，2018 年即被評爲國家高新技術企業。Rokid 作爲行業的探索者、領跑者，目前致力於 AR 眼鏡等軟硬件產品的研發及以 YodaOS 操作系統爲載體的生態構建。公司通過語音識別、自然語言處理、計算機視覺、光學顯示、芯片平臺、硬件設計等多領域研究，將前沿的 Al 和 AR 技術與行業應用相結合，爲不同垂直領域的客戶提供全棧式解決方案，有效提升用戶體驗、助力企業增效、賦能公共安全，其 Al、AR 產品已在全球八十餘個國家和地區投入使用。

業務場景

Rokid 在數字文化領域，圍繞展陳導覽解決方案，主要形成了三維建圖，場景創作，場景體驗三個業務模塊，每個模塊都有不同的後臺平臺支撐。

三維建圖： 製作展陳導覽的第一步是取景，通過設備獲取場地的真實佈景，然後通過算法處理，進行三維建模，之後可以經過創作器進行下一步的內容創作。

場景創作： 在三維建模生成的視頻流上創作，通過 Web3D 渲染引擎，將創作內容與場景緊密結合，結合硬件設備，在 AR 設備使用時，形成一體化的體驗效果。

場景體驗： AR 設備在使用時，根據定位服務，錨定在場景中的位置，根據位置的不同會顯示不同的空間內容，達到擴展現實場景的效果。

未雨綢繆，磨刀不誤砍柴工

在 AR 大潮的湧動中，Rokid 緊隨時代脈搏，持續精進業務迭代與技術更新。我們深刻理解到，在構建穩定可靠、高效卓越且經得起市場嚴峻考驗的 AR 部署解決方案時，必須秉持未雨綢繆的策略和工匠精神。

面對瞬息萬變的場景體驗領域，我們尤爲關注 GPU 資源的依賴性，因其直接決定了用戶通過掃描或小程序步入 AR 世界的實時服務品質。定位的即時性和準確性成爲了衡量服務質量的關鍵指標。從具體的商業邏輯、研發挑戰到技術選型層面，我們面臨的核心問題聚焦於以下兩點：

初期的策略構想中，我們曾探討過購置專用 GPU 機型以及採用 Kubernetes 社區原生的 Horizontal Pod Autoscaler 方案。然而，實踐是檢驗真理的唯一標準，基於業務實際運行效果的反饋，我們意識到單一方案並不能滿足所有需求。深信“工欲善其事，必先利其器”的理念，在歷經數次實戰探索及聯合調試的過程中，Rokid 攜手阿里雲共同砥礪前行，最終在阿里雲強大基礎設施的支持下，打磨出一套更爲高效、成熟且適應市場需求的實施方案。

基於 GPU 按需使用如何做

我們知道 GPU 資源很貴，按需使用尤爲重要。K8s 社區提供的原生 HPA 方案基於 CPU、內存等靜態閾值實現，如果要基於 GPU 使用率指標則需要通過自定義指標方式實現，配置繁瑣，此外 GPU 使用率指標並不能最直接反饋業務請求負載情況，對於在線應用來說，通過請求流量的併發數、qps、rt 等指標，可以很好的衡量當前的服務質量，能否基於這些指標做到按需彈性。

如何快速發佈迭代應用

在 K8s 中如果要做基於流量的藍綠髮布，首先需要創建對應的 K8s Service 與 Deployment，如果需要彈性，則還需要配置 HPA，然後在流量灰度發佈時，要創建新的版本，最後通過 Ingress 設置對應的流量比例，最終實現流量灰度發佈的功能。顯然，在 K8s 要做基於流量的藍綠髮布，需要管理多種資源，並且隨着版本的迭代，管理起來會更加複雜。

彈性滯後

我們知道應用往往很難做到秒級啓動，也使得基於 HPA 擴容存在較大的滯後性，帶來真實業務的穩定性風險。如何減少彈性滯後帶來的業務影響，是需要我們要解決的問題。

GPU 資源不足的問題

雲上 GPU 資源有限，如何保證常態下 GPU 資源供給，以及在突發業務場景下，及時擴容出 GPU 資源。

標準化

當前 Serverless 產品豐富多樣，各個雲廠商和開源社區都有。我們在技術選型時需要考慮儘可能通過標準化的方式使用 Serverless 能力，以滿足多雲、混合雲等場景。

解決方案

從資源按需使用、GPU 供給、穩定性以及標準化等方面的考慮，我們選擇了阿里雲 ACK + Knative 的解決方案，保證彈性供給兼顧成本最優，整體方案如下：

雲原生 Serverless 框架 Knative

Knative 是一款基於 Kubernetes 的開源 Serverless 應用編排框架，其目標是制定雲原生、跨平臺的 Serverless 應用編排標準。其提供了基於請求數、併發等指標的自動彈性能力，並且通過多版本管理機制，可以方便的做到基於流量的灰度發佈、快速回滾的功能。

ACK 智能彈性（AHPA）

針對傳統彈性能力所存在的問題，我們採用了 ACK 容器服務推出的 AHPA（Advanced Horizontal Pod Autoscaler）彈性預測 [ 1] ，可以根據歷史 Pod 的 Ready Time 以及歷史 Metrics 自動學習規律，在業務量上漲之前的一個 Ready Time 開始擴容，在業務量上漲時 Pod 已提前準備，可以及時供給資源，解決彈性滯後的問題。

AHPA 彈性預測根據歷史數據自動規劃未來 24 小時每一分鐘的應用實例數，相當於進行 1440 個點（一天爲 1440 分鐘）的 CronHPA 定時配置。

ECS、ECI混部

彈性容器實例 ECI（Elastic Container Instance）是阿里雲一款敏捷安全 Serverless 容器運行服務，用戶無需管理底層服務器資源，同樣也不需要關心運行過程中的容量規劃，非常適合應對這種流量突發下業務場景。

但從彈性供給來看，ECI 並不能完全保證資源的供給，結合我們常態下業務使用情況，當前採取混合部署模式，兼顧成本及穩定性兩方面的業務目標。如圖所示，常態業務下我們使用 ECS 資源，在突發業務流量下，通過 ECI 提供按需使用資源。

自定義彈性資源優先級調度

由於採用了 ECS 及 ECI 兩種部署模式，在資源的調度策略上，我們期望應用擴容和縮容行爲都是確定性的。那麼，部署的服務優先調度順序理論上依次爲：ECS、彈性實例 ECI。同時在服務縮容時優先刪除 ECI 上的 Pod，釋放 ECI 的節點資源，然後刪除 ECS 上的 Pod。這裏我們採用了自定義彈性資源優先級調度策略：ResourcePolicy。

對於不同類型的節點需通過打上不同節點標籤實現，然後創建 ResourcePolicy 自定義節點池調度順序。參考文檔：自定義彈性資源優先級調度 [ 2] ；那麼結合 Knative 使用的話只需要在 selector 指定相應的 Knative Service 名稱即可。ResourcePolicy 配置示例如下：

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: prod
spec:
  selector:
    serving.knative.dev/service: worker-go ## 此處指定Knative Service 名稱即可
  strategy: prefer
  units:
  - resource: ecs
    max: 2
    nodeSelector:
      key: value
  - resource: eci

業務價值

在當前的實施中，我們已成功運用 ACK（阿里雲容器服務）與 Knative 這一先進組合構建並部署了在線服務系統，籍由 Knative 出色的多版本管理特性，提升了我們的應用迭代效率。 同時，得益於其基於請求動態調節的自動擴縮容能力，能夠實時響應突發業務需求，精準按需調配 GPU 資源，實現成本和性能之間的平衡。

本次合作實踐，猶如 Rokid 與阿里雲攜手共舞，在賦能業務創新的同時，也有力推動了阿里雲產品的深度優化。展望未來，身處 AR 技術引領的宏大計算新時代，Rokid 深信，以阿里雲 Knative 結合 ECI 爲代表的技術解決方案將在持續演進與迭代的過程中，不僅將爲衆多雲計算使用者帶來實質性收益，更將以卓越的架構設計和體驗革新，逐漸滲透到更多前沿產品之中，構築起強大而靈動的雲上基礎設施，進而惠及廣大用戶羣體，共同見證並塑造雲計算髮展的新篇章。