地端還是雲端？企業整合 AI 語音總機的兩種部署架構，怎麼選、怎麼接

企業要導入 AI 語音總機，IT 與資安最先問的，往往不是「它準不準」，而是兩個更現實的問題：「客戶資料和通話錄音，會不會離開我的機房？」以及「它要怎麼接進我們用了多年的電話系統？」

Qubby 的答案是：用同一套容器化服務，提供兩種部署方式——地端部署到客戶自有機房，或 Qubby 雲端託管。兩者的 AI 語音推論都跑在雲端的 Qubby 語音多模態模型上；真正的差別只在於媒體／錄音／客戶資料落在哪裡，以及誰負責維運。

架構一：地端部署（On-Premise）— 資料不出機房

把整套服務以 Docker 部署在客戶自有的 IDC 機房。電信中繼線（SIP Trunk）直接進到機房，AI 以「分機」向客戶既有 PBX 的內網註冊——因為同機房內網對接，語音延遲最低。

關鍵在於資料流向：通話錄音、通話記錄、客戶個資全部留在機房內網，對外只有「AI 推論」這一條流量，經防火牆／Proxy 以 TLS 加密出網。其餘語音媒體完全不出機房。

適合對個資落地、資安合規要求高的金融、醫療、政府或大型企業——資料主權掌握在自己手上。

架構二：Qubby 雲端託管（Managed Cloud）— 免機房維運

整套服務部署在 Qubby 託管的 AWS 雲上，多區域（台灣，可加日本等）。前端有 Global Accelerator 就近導流、ALB + 憑證做 HTTPS 加密分流。我方雲端的電話交換模組以 IP Phone（分機）跨網、經 VPN 向客戶 PBX 註冊——因為跨網，延遲略高於地端。

資料（角色／設定／通話記錄）存於雲端 Firestore，錄音存 S3，設定走 Redis 快取；監控、更新、擴充全部由 Qubby 託管。

適合想快速上線、彈性擴充、不想自建與維運機房的企業——開帳號、對接 SIP Trunk 即可上線。

整合重點：AI 是「掛上」你的 PBX，不是取代它

兩種架構的服務模組完全相同：電話交換模組（asterisk）、通話控制模組（sidecar）、AI 語音對話核心（backend）、營運管理後台（admin-console）、AI 流程生成引擎（ivr-builder-api）、網頁語音客服（share-web，選用）。

整合的核心是同一個動作：AI 以一支「分機」向你既有的 PBX 註冊，不更動你的總機、號碼與既有分機。差別只在這支分機怎麼接——地端是 SIP Trunk 進機房、分機走內網；雲端是分機 over VPN 跨網註冊。

一張表，選對你的架構

面向	地端 IDC 部署	Qubby 雲端託管
資料落地	錄音／通話記錄／個資留在自有機房，僅 AI 推論出網	資料存於雲端 Firestore／S3（由 Qubby 管理）
語音延遲	最低：AI 分機與 PBX 同機房內網註冊	略高：AI 分機跨網向 PBX 註冊（VPN）
資安／合規	最符合自有機房／個資落地要求	依雲端供應商合規（需資料跨境評估）
維運責任	客戶提供機房／硬體／網路，Qubby 提供容器與更新	Qubby 全託管（監控／更新／擴充）
擴充彈性	受實體機房限制，擴充需採購硬體	彈性快速（多區域／水平擴充）
導入時程	較長：機房進駐／網路開通／防火牆白名單	最快：開帳號 + SIP Trunk 對接即上線
成本模型	機房／硬體 CAPEX + 授權；長期自有	訂閱／用量 OPEX；零硬體投入

兩案皆連雲端的 Qubby 語音多模態模型做 AI 推論；地端版只讓「這一條」AI 流量加密出網，其餘留內網。

可以先雲端 PoC，再平滑移轉到地端

因為兩種架構的服務模組組成完全相同，你可以先用雲端託管快速做 PoC 驗證效果，再平滑移轉到地端正式部署，無需重做。若你的合規要求連 AI 推論都不得出網，還可評估「地端 LLM／私有語音模型」選項（需另行算力規劃）。

不論資料主權優先、還是上線速度優先，整合的本質都一樣：讓 AI 以一支分機掛上你既有的電話系統，剩下的交給 Qubby。 想評估哪種架構適合你的機房與合規條件，歡迎與我們的顧問聊聊。