沙崙綠能園區，5 台機器人、5 層樓、逾 100 個巡檢點，連續巡邏已經跑了逾 100 天——這段期間 AI 判讀燒掉的總成本，連台幣一百塊都不到。
我們想要分享的就是：帳單為什麼可以這麼小。答案不是「找到便宜的模型」，而是架構。
為什麼巡檢比遞送難
服務型機器人最主流的兩個應用，是遞送跟巡邏。這兩個任務的共通點是：本質上都不要求機器人跟物理世界互動（開門、拿東西那類），只要能自己走到目標點就好。
但「走到定點」對這兩者的意義完全不同。
遞送走到定點，任務基本上就結束了——東西送到，價值一翻兩瞪眼，最容易評估。
巡檢剛好相反。機器人走到定點，真正的任務才開始：這個畫面正不正常？而這個問題，會被丟給影像判讀。
三種影像判讀技術的取捨
影像判讀不是新題目，它存在超過 40 年了。從農場裡的蘋果到你手上的蘋果手機，工廠裡早就有非常成熟的方案。
但工廠方案有個前提：相同的待測物、相同的光源、相同的背景，在這種受控條件下追求極高的正確率。把它丟進一個隨機變化的真實環境……嗯，good luck。
後來有了 YOLO 這類神經網路演算法，能在變動環境中快速、穩定地偵測物件。這給了所有想做影像巡檢的人一線希望——看起來 AI 終於能幫上巡邏了。
於是這套架構被大量導入各種 AI 偵測方案：人員危險偵測、天網系統、工地安全帽稽核、車牌辨識、車流與人流計數、零售貨架盤點⋯⋯全都是它。但它有個硬傷：YOLO 只能告訴你「這個畫面上有什麼」。畫面裡有杯子椅子電腦背包，但它沒有辦法告訴你「看起來有人剛剛在這裡工作」。
照片取自網路
那現實中那些危險判讀是怎麼做出來的？答案意外地土炮——全是工人智慧，一條一條疊在偵測結果上。這套做法能保住辨識的精度，但規則的擴充性極差：每多一種新狀況，就要再投一批人力去開發跟維護。這個架構穩定成熟高效，唯一的缺點是建置時的人工時很高，因此適合做大規模同條件的判讀。對於在設施內的異常巡邏就有點吃力。
然後，VLM 來了。
VLM（視覺語言模型）是更大的模型，它能理解影像，並根據你的需求對畫面問答。
雲端模型（例如 Google Gemini 家族）能精準判讀表頭與各種環境資訊，而且你可以下各種千奇百怪的需求，例如「這個插座只能插左邊的洞」。基本上你完全用打字的，就能讓 AI 判斷這張照片正不正常。
那這三種技術到底怎麼選？你可以看下表：
| 面向 | 傳統 CV | NN 物件偵測（YOLO 等） | VLM（視覺語言模型） |
|---|---|---|---|
| 技術核心 | 手工特徵＋影像處理演算法（閾值、邊緣、樣板比對、形態學），規則由工程師針對特定待測物寫死 | 卷積神經網路，資料驅動訓練，輸出物件的類別與位置(bounding box)——只回答「畫面上有什麼、在哪」 | 視覺編碼器＋大型語言模型，理解影像語意，能用自然語言下任意問題並推理判斷，直接給出 OK／NG 與理由 |
| 硬體需求 | 極低，一般 CPU 甚至嵌入式裝置就夠 | 中低，輕量模型可在 Raspberry Pi／邊緣裝置即時執行（如人偵測），較重模型才需 GPU | 地端需 GPU；雲端閉源走 API，本地端零硬體 |
| 精確度／可重複性 | 超高——同一張圖跑幾次都一模一樣，受控量測精度高到誇張 | 也很高；受控任務漏檢壓得很低，但一般偵測 mAP 大多落在 90–97% | 三者墊底：會取樣、會幻覺，同一張照片問兩次可能給你兩個答案 |
| 環境變化耐受度 | 低——光源、角度、背景一變就失效 | 中高——訓練資料涵蓋範圍內能容忍變動 | 高——對沒見過的場景、光線、擺設有泛化能力 |
| 規則變化耐受度 | 極低——換規則＝重寫演算法 | 低——新類別要重新標註訓練，且「危不危險」仍得人工手寫邏輯疊在偵測結果上 | 極高——改需求只要改一句 prompt（「這個插座只能插左邊的洞」），免重新訓練 |
一句話總結這張表：CV 精度高但一離開機台就崩潰、YOLO 看得到東西卻讀不懂語意、VLM 懂語意又能改一句 prompt 就換規則。我們要在一般設施內巡邏，所以主角很明確，是 VLM。
我們挑了 Google 的方案，原生多模態，照片影片都可以分析。不僅可以自由判斷這個地方是否可以擺雜物或是滅火器，連地上有沒有積水都有不錯的效果。
重點是便宜：一張照片輸入加輸出大概 2K token，就算用最貴的 Gemini 3 Pro 判，一張攤下來差不多台幣一塊；而且因為多數 token 是輸入而非輸出，實際落在 0.1 塊上下。經我們實測，Flash 的效能跟 Pro 基本沒差，價格還能再降一位到 0.01 塊。
模型的幻覺更可以靠結構化輸出來抑制，而且結構化輸出的 token 更少——品質更穩、價格更低。
VLM 這麼強，為何不整碗上雲？
既然 VLM 這麼萬能，那全部丟雲端不就好了？源源不絕把照片、影片全丟給 Google 算吧？你算一下就笑不出來了——
假設串流以 2 fps 上傳，如果拿來處理要 24 小時盯著的火災、動物闖入等狀況，一個月要花 2 × 60 × 60 × 24 × 30 × 0.01 > 50K。嗯⋯⋯等到缺工更嚴重，這當然也是一個作法，但顯然不是最好的，現階段很多設施都還是會覺得請個保全加個煙霧警報器就好。於是我們開始想：那在地端跑開源模型不就好了？每天看著一堆開源模型發出「自己在某某評測與大模型不相上下、即將彎道超車」的新聞，我們手癢，也決定玩了一下。
大模型跟小模型的差距，到底差在哪
先講結論：地端小模型在巡檢場景很快就暴露了劣勢，而且暴露的位置很精準——不是「看」，是「想」。
我們測試過 Gemma、Qwen、Llama 等常見的 10B 以下多模態地端模型，無一例外：大家描述畫面的能力都很強，你問「這張圖裡有什麼」，它可以流暢地告訴你有兩個人、一盞燈、地上有個箱子，細節豐富到你會誤以為它跟 Gemini 是同一個等級。但只要把任務從「描述」換成「判斷」，例如給它這種 prompt——
這個畫面上不可以有人在打架，也不可以有人跌倒，燈光必須保持打開。
它多半會給你一串胡言亂語。
為什麼？因為「描述」跟「判斷」根本是兩個不同難度的任務。描述是純感知：把視覺編碼器看到的東西轉成文字，這件事 3B 的模型就做得有模有樣。但判斷是感知之上再疊三層推理：理解規則、逐條核對、輸出裁決。上面那句 prompt 拆開來，是三個條件、兩個否定、一個狀態檢查——小模型面對它的典型死法有三種：
- 漏條件。三條規則只核對到一條，通常是最後一條，前面的直接當作沒看到。
- 否定看反。「不可以有人打架」這種否定句，小模型很容易把「畫面裡沒有人打架」判成 NG——因為它在字面上同時看到了「打架」跟畫面，就把兩者湊在一起了。否定理解(negation)一直是小模型的重災區。
- 裁決漂移。同一張照片問兩次，一次 OK 一次 NG，理由還都寫得頭頭是道。
而這三種死法，雲端大模型幾乎不犯。差距的根源不難理解：VLM 是「視覺編碼器＋語言模型」的組合，10B 以下的開源模型跟雲端旗艦比，視覺那一半的差距其實沒那麼大——大家看到的東西差不多；真正拉開差距的是語言模型那一半。規則理解、多條件核對、否定邏輯、裁決一致性，全都是 LLM backbone 的工作，而這些能力跟參數量是硬掛鉤的。小模型不是眼睛不好，是腦子不夠用。
這也解釋了那些「彎道超車」新聞為什麼跟我們的實測體感差這麼多。主流多模態評測（MMMU、MMBench 這類）考的大多是描述、辨識、選擇題——剛好全是小模型擅長的科目；而真實巡檢考的是「開放環境＋自訂規則＋否定條件＋強制結構化輸出」，這科評測根本沒考。小模型在考卷上追平大模型，跟它能不能在你的機房裡值班，是兩回事。
再補兩刀：
- 結構化輸出的遵循度也有落差。叫雲端模型回
{is_NG, Description}，配合 API 的 schema 約束，它就是乖乖回這個 JSON。叫地端小模型回，你會收到用 markdown 包起來的 JSON、JSON 前面多一段熱情的說明文、或是欄位名自己改成它喜歡的樣子——解析層又得多寫一堆防禦性程式碼。 - 地端還要再被量化削一層。Jetson 上跑的模型多半是 4-bit 量化版（我們用的是 AWQ），本來就吃緊的推理能力再被砍一刀，描述能力掉得不明顯，判斷能力掉得很明顯——偏偏我們要的就是判斷。
所以走到這裡的暫時結論很尷尬：小模型要能用，就得把「判斷」從它身上拿走，退回 YOLO 疊工人智慧的老路⋯⋯如果我要手刻規則，那我用 YOLO 就好了，還省一個 GPU。
雲端地端混合架構
好家在，NVIDIA 推了一個有趣的架構：VILA 搭配 JPS (Jetson Platform Services)。這套組合等於是承認了上面那個尷尬的結論，然後換一個方式解題——既然通用小模型判斷不行，那就把模型特化、把任務收窄。它對「即時警報」有兩層優勢：
模型層：VILA 讀得懂時序。通用 VLM 拿來單張逐格判斷時，每一格都是獨立看、獨立下結論——「把打架看成打球」就是這樣來的，因為「打架」是跨影格才成立的事件，單看任何一格都只是兩個人肢體靠很近。VILA 專為多影格／影片理解而生，能把前後文一起吃進去，判斷「這段時間到底發生了什麼」，而不只是「這一格有什麼」；它又針對每張影像的 token 數做過優化，才跑得動 Jetson 上的即時串流。這是小模型的另一種活法：不跟大模型比通用判斷力，而是在「時序事件偵測」這個窄任務上做深。
系統層：JPS 把整條告警管線變成服務。JPS 直接吃 RTSP 串流（IP 攝影機、VST 等來源都行），讓你用自然語言下告警規則（「畫面裡有沒有火？」「有沒有人持刀？」），持續評估串流後，直接吐出 True/False 的告警狀態往外推。注意這裡的規則形態——「有沒有火」是單一條件的封閉式問題，正好落在小模型還撐得住的判斷範圍內；它不會要求小模型去核對三條規則加兩個否定。反過來，如果你手上只有一顆裸的 Gemma，那就真的只有「模型」——串流接入、抽幀、連續推論、告警觸發與狀態管理、去重、推播，全部得自己從頭刻。VILA＋JPS 是為 Jetson 邊緣優化、開箱即用的微服務，這些雜活它都幫你包好了。
於是分工就清楚了：複雜、多條件、常變動的規則判斷，交給雲端大模型；持續、窄問題、要求即時的事件偵測，交給地端特化小模型。這不是「大模型比較好所以放雲端」的成本妥協，而是兩種模型各自站在自己能力曲線的甜蜜點上。
分層原則只有一句話：持續性的影像留在地端，雲端只判讀有意義的畫面。落地成三條管線：
| 管線 | 輸入 | 處理位置 | 延遲 |
|---|---|---|---|
| 定點巡檢 | 單張 JPEG | 雲端 VLM | 約 3-5 秒 |
| 影片分析 | MP4 | 雲端 VLM | 約 5-30 分鐘 |
| 即時警報 | RTSP 串流 2 fps | 地端 VLM（Jetson 本地推論） | 約 1-2 秒 |
即時警報這條最能說明分工：煙霧、火災、持刀、動物闖入四類事件，由 Jetson 上的地端 VLM 持續盯著 2 fps 串流，detection-to-alert 小於 2 秒，直接推播 LINE/Telegram，整條管線不上雲。雲端從頭到尾沒看過這些串流，自然不產生費用。
為什麼帳單這麼小
把上面的架構換算回帳單，雲端在一次例行巡檢裡實際做的事，少得驚人：
- 輸入只有定點單張照片。機器人停穩才拍，一個巡檢點一張 JPEG——不是影片、不是連拍。逾 100 個點就是逾 100 次單張影像判讀，加上最後一次報告摘要生成。
- 輸出被結構化壓到最小。判讀強制回傳
{is_NG, Description}的結構化 JSON，模型不寫散文，輸出 token 自然少，也省掉脆弱的文字解析。 - 問題窄，模型就能輕。「這張照片裡有沒有滅火器」是封閉式問題，輕量級雲端 VLM（Gemini Flash-Lite 級）就夠，不必動用旗艦模型。前面說小模型判斷不行，指的是多條件開放判斷；問題一旦收窄，連雲端都可以往下用最便宜的那檔。
- 連續監看的雲端成本歸零。最花錢的「一直看」整個搬到地端，雲端只處理巡檢當下的離散快照。
一個巡檢點換算下來約一千多個 token。把逾 100 個點、逾 100 天累加起來，雲端帳單連台幣一百塊都不到——成本不是省出來的，是架構決定的。
巡檢的最後一哩路
把巡檢每張照片都精確的判讀了，帳單也沒有爆掉。可喜可賀，感覺可以收工了！ 那就搞錯了巡檢的最重要產出：巡檢的目的不是在做影像判讀，而是要產出報告。
你看了一堆滅火器，是要知道有沒有符合消防安全。看了一堆插座，是要知道有沒有符合用電規範。 這是傳統巡檢最惱人的地方，不管影像判斷有多彈性，報告最終的 schema 還是要手刻。
但 AI 不一樣，它最會寫報告了。
於是我們可以讓它自動寫出這個報告
而要新增或是減少任何一個項目，只要打字就好
做機器人應用這麼久，從來沒有覺得幫客戶改報告格式是如此輕鬆寫意的事情。
幾個務實的提醒
- 上述成本只涵蓋 AI 判讀；機器人本體、訂閱與佈建另計。
- 地端推論不是免費的——你付的是一台 Jetson 的固定成本，換來即時性，以及串流不出場域的隱私。
- 開源小模型的迭代很快，今天「10B 以下判斷不行」的結論有賞味期限；但「描述能力先到、判斷能力後到」這個規律，短期內大概不會變。挑地端模型時，別看它描述得多流暢，直接拿你最刁鑽的那條規則去考它。