lemonflow 把 Gemma 4 搬上 TPU：充電客服約350毫秒回應，架構改了什麼？
lemonflow分享以Gemma 4與歐洲TPU支援充電客服，P50延遲約350毫秒、P90約600毫秒。本文解析語音優先排程、三十種後台整合、操作控制、備援與AgentCoach測試，並釐清99.9%對話輪次的口徑。
電動車停在充電站，插好線卻無法開始充電時，駕駛最需要的是能接續處理的回覆。語音客服若停頓太久，使用者就可能重說問題或打斷回答，讓同一個故障更難釐清。
lemonflow 在 Google Cloud 標示 2026 年 11 月 12 日的案例中，說明如何把 Gemma 4 部署在歐洲 TPU，公布 P50 延遲約350毫秒、P90約600毫秒。
P50 是中位數，P90 是九成測量值不超過的時間。文末另把典型回應開始描述為約350毫秒，兩者都不代表每次固定耗時，或整段客服工作已完成。這是公司分享，尚未由本站獨立重現。
案例更值得看的地方，是團隊如何把即時語音、聊天與背景任務分開排程，同時整理不同充電系統的資料。模型回得快，才有機會讓後面的操作自然接上。
但客服不只要說話，還可能需要重啟充電樁、解鎖線材或通知維修人員。這些行動有實體後果，執行前的檢查與服務備援，不能只靠語言模型處理。
因此，這個案例適合拿來理解高即時性垂直客服的取捨。已經遇到延遲與容量問題的團隊，可評估自管推論的必要性。流量與工具流程還不明確時，先把端到端時間拆開更有幫助。
lemonflow 為何先處理語音等待？
語音對話的等待會直接改變使用者行為。lemonflow 分享的測試中，延遲超過約800毫秒，就更容易出現使用者搶話與打斷，進而破壞客服需要的對話節奏。
公司原本透過模型服務介面，也就是 API，取得外部模型回應，典型等待約1.0至1.2秒，尖峰可能超過1.7秒，並遇到429限流回應。限流表示服務暫時不接受更多請求，對正在求助的駕駛而言，問題會表現成等待或回覆中斷。
這些是公司自身系統經驗，不能代表所有 API 都會出現相同延遲。不過，當需求是連續語音，尖峰時能否保持回應，確實比平時只測一次的速度更接近使用情境。
例如駕駛已說明線材卡住，若客服很久沒有接話，對方可能重新描述，甚至加入另一個問題。系統接著需要判斷這是補充、改口或中斷，原本單純的處理就變得複雜。
因此，團隊的目標是讓模型輸出能穩定接進對話。要達成這件事，先改變的是推論服務如何部署與分配資源。
自管 Gemma 4 與 TPU，改變了哪個控制範圍？
lemonflow 把 Gemma 4 放在歐洲的 TPU v6e 環境，將推論容量與排程納入自己的控制範圍。TPU 是 Google 為機器學習工作設計的運算硬體，這裡用來執行模型推論。
自管推論讓團隊能調整模型服務方式，而不只是在外部 API 設定請求參數。但這也增加維運責任，包含模型載入、資源分配與異常時切換，不能只把它理解成換一種硬體就自動變快。
公司使用的服務設計包含 vLLM 的記憶體分層安排，讓不同工作使用資源時有更明確的優先順序。模型權重就是保存學習結果的參數。它和上下文、執行狀態都會占用資源，因此尖峰時如何安排，會影響新請求能否順利開始。
官方結果段列出 P50 延遲約350毫秒、P90約600毫秒，另描述典型回應在約350毫秒開始。這些是該架構的結果，不能推論不同地區或工作負載使用相同模型就有同樣時間。
資料位置也是設計條件。案例強調歐洲部署與備援路徑，顯示團隊同時考慮即時性與資料處理位置。這不等於本文已驗證全部法遵要求。
硬體提供執行能力，但當多種任務一起進來，仍需要明確決定誰先用。
語音、聊天與背景模擬，為何不能排在一起？
即時語音先取得資源，聊天其次，背景模擬則排在較低流量時段。這是 lemonflow 案例中很實際的取捨，因為不同工作對等待的容忍度不同。
駕駛正在說話時，系統必須盡快接續。文字聊天即使稍慢，使用者仍能看到對話內容。背景模擬則可延後執行，不需要和當下求助的人爭同一段容量。
如果把這些工作放在相同優先順序，一次大量背景測試就可能拖慢即時客服。模型即使單獨測試很快，實際服務仍會在資源競爭時出現停頓，這也是單次速度數字無法完整呈現的部分。
把工作分開之後，團隊也比較容易追查延遲來源。究竟是語音辨識、模型等待、工具查詢還是語音輸出變慢，需要分段觀察，才能決定要調整哪一層。
這種排程不是所有服務都需要同樣複雜。若需求只有少量文字詢問，自管即時推論可能還不是主要瓶頸。充電客服之所以投入，是因為它要在現場連續接住問題。
容量安排好之後，客服還需要理解不同充電後台提供的資料。
約三十種後台，如何交給同一套代理理解？
lemonflow 先把不同充電管理系統的資料整理成較一致的形式，再讓代理判斷。案例提到約三十種 CPMS，這類系統負責管理充電樁與充電服務的後台資訊。
如果每個後台都使用不同欄位與狀態名稱，模型就得在每次對話重新辨認。先做資料正規化，也就是轉成一致的表達方式，能讓代理較專注於目前是哪個充電點、發生什麼狀況。
公司同時使用即時 OCPP 紀錄。OCPP 是充電設備與管理系統交換訊息的協定，相關紀錄可提供設備端的事件線索，而不只依賴駕駛用口語描述。
這樣的結合可以區分使用者說「不能充電」背後不同狀況。可能需要補問現場資訊，也可能已有後台事件可查。資料是否完整，會影響接下來適合採取哪個動作。
但資料整理不表示故障會自動消失。若工具查不到該站狀態，或後台資訊與現場不一致，系統仍需要把不確定處交代清楚，並保留轉交人員的路徑。
代理理解狀態之後，下一個責任便是哪些操作可以執行。
重啟、解鎖與派修，執行前怎麼把關？
充電客服的工具會影響真實設備，因此控制必須放在模型執行行動之前。案例列出的操作包含重啟、解鎖、停止充電、傳送簡訊與通知技術人員。
這些操作的後果並不相同。傳送一段說明，和停止一個正在使用的充電工作階段，需要的資訊與確認程度不同，不能只因它們都以工具形式提供，就交給相同規則處理。
lemonflow 描述的是在語言模型之前先套用控制。對導入者而言，這提醒工具服務本身就要判斷請求是否符合條件，而非只期待模型每次都選對。
例如應用需要知道目標是哪個充電點，以及該動作是否適用目前狀態。這是從案例延伸出的設計要點，本文沒有取得其所有內部規則，不能宣稱已確認每種操作的授權細節。
備援也在行動流程裡扮演角色。案例安排 GPU 與 Gemini Enterprise 作為後備路徑，並維持在歐洲。當主要推論不可用時，服務需要有接續處理方式。
這些安排可以改善可用性，卻不構成「所有操作都安全」的保證。要知道系統是否持續符合需求，仍須把真實問題帶回評估流程。
AgentCoach 如何把真實求助變成長期測試？
lemonflow 用 AgentCoach 把對話與背景脈絡整理成可重複測試的案例。重點是讓曾經遇過的問題，之後每次調整都還能被檢查，而不只在當天修好一次。
客服問題通常不會只以一句標準問法出現。有人先描述卡住的線材，有人先問帳單，有人說到一半才發現充電已停止。如果測試只有理想對話，就容易漏掉這些交錯情境。
案例描述團隊把真實通話加入永久測試集合，並在夜間跑固定情境。這讓系統更新之後，可以回頭看它是否仍會選對工具，以及能否在相似問題下接續處理。
評估的價值也在比較變更。若換模型後回應更快，但更常漏問必要資訊，就需要把兩個結果一起看。速度與任務品質不是同一個量，單看其中一項會錯估實際效益。
這個做法讓模型、工具與資料變更有共同的檢查基礎。
固定情境也能幫助分辨模型更新與後台變動。假設相同對話過去會得到一個設備狀態，現在卻查不到，測試就需要保留工具回應，才能知道是模型選錯查詢，還是後台資料已改。
對充電客服，工具結果和對話不能各自評分就結束。代理可能說得很自然，但沒有完成必要查詢。也可能工具已完成操作，語音卻沒有把結果說清楚。兩種情況都影響駕駛下一步。
因此，永久案例的內容應保留任務條件與預期結果，而不只保存一句標準問法。這是依案例方法延伸的導入判斷，並非本文取得了lemonflow全部內部評估資料。
夜間執行固定測試，也呼應前面讓即時語音優先的資源安排。背景工作需要跑，但不必搶在駕駛正在求助時進行。同一套硬體的效益，來自模型服務與工作排程共同配合。
架構與測試能說明如何維持服務，規模與比例則要再看各自衡量什麼。
99.9% 與350毫秒，分別代表什麼？
公司說 Gemma 處理了99.9%的即時對話輪次，這是模型承接輪次的比例。它不是充電故障解決率，也不能直接寫成99.9%的駕駛都成功完成充電。
延遲的 P50 約350毫秒，表示一半測量值落在這個時間左右或以下，P90則約600毫秒。文末的典型回應起始，同樣不能當成整句語音結束，或從撥入到設備修復的總時間。
案例另列出四十多個網路、十七個國家、二十五萬個以上充電點與九十多種語言。這些規模數字由公司提供，能交代服務範圍，不能替代每個地區與語言的品質評估。
未來硬體方向也應分開。團隊提到當歐洲可用時評估 Ironwood，這是後續計畫。目前案例的部署仍是 TPU v6e，不宜把兩代硬體混成現有架構。
把分母與時間點說清楚之後，這個案例才更適合拿來和自己的客服需求比較。
哪些團隊值得評估這條路？
已有連續語音流量、遇到尖峰延遲，並且有能力管理模型服務的團隊，可以進一步評估自管推論。因為它提供的是資源控制與垂直流程整合，並不只是一個較快的聊天入口。
評估前可先拆出語音辨識、模型、工具與朗讀的等待時間。如果主要時間花在查後台，先換推論硬體未必會帶來相同程度的改善。反之，若模型排隊才是瓶頸，容量管理就更值得研究。
台灣充電業者也需要保留自己的用語、設備與後台情境。歐洲服務的多語規模，不能直接證明本地口音、站名與維修流程已處理妥當，應用自己的案例驗收。
lemonflow 常見問題
使用 Gemma 4 就一定能350毫秒回應嗎？
不能。公司公布的 P50 延遲約350毫秒、P90約600毫秒，並描述典型回應在約350毫秒開始。這些是特定部署結果，未被本文獨立重現，也不是每次固定值。
99.9% 是客服成功率嗎？
它指 Gemma 承接的即時對話輪次比例。故障是否解決、使用者是否完成充電，需要另外的任務結果資料，不能由這個數字推算。
自管模型適合剛開始做客服的團隊嗎？
先確認流量、延遲來源與工具責任會更實際。這個案例需要推論維運、後台資料整合與回歸測試能力，團隊應把相關投入一起評估。
如果你正規畫語音客服，可以先把一次真實求助的等待分段記錄，再對照這份案例，找出最值得先改善的環節。
延伸閱讀：ElevenLabs 語音客服研究，469 個代理如何比較語音與文字，長對話為何不同？
延伸閱讀：Claude Message Threads 公開測試，長對話代理如何縮短首字等待？
