嗨大家，我是 Debuguy。

前面我們完成了從 0 到 1 的產品雛形，也在 Day 1 階段選擇了 GenKit 作為我們的 LLM 抽象層。GenKit 內建的 Developer UI 在開發時確實很讚，可以快速看到 trace、測試 flow、debug 問題。

然後內心就會有個懶惰的小惡魔說著：

「咦？既然 GenKit Developer UI 這麼好用，那直接拿到 Production 用不就好了？」

技術上做得到，但不應該

GenKit 其實可以直接讀取 trace 檔案來顯示 UI。

也就是說，技術上我確實可以：

1. 把 production 的 trace 檔案掛載到某個地方
2. 起一個 GenKit Dev UI 的服務
3. 讓大家連進來看

「看吧，沒那麼難嘛！」

但當我認真想要這樣做時，越想越覺得不對勁...

等等，好像哪裡不對勁

記憶體炸彈

然後我看了一下 GenKit 怎麼儲存 trace 資料：

所有資料都存成檔案。

而且更可怕的是，當你打開 Developer UI 時，它會把所有 trace 檔案都載入記憶體。

在本地開發時這沒什麼問題，trace 數量有限。但如果你把這個部署到 K8s：

Pod Status: OOMKilled
Reason: Container exceeded memory limit
Last State: Terminated
  Exit Code: 137

「％＄＃＠！，Pod 又掛了？」
「查一下...原來是有人開了 GenKit UI 把所有 trace 檔案都讀進記憶體了」
「那開大一點記憶體？」
「開多大？trace 會一直累積，難道要開 32GB？」

這就是為什麼它叫 Developer UI，不是 Production UI。

缺乏 Production 該有的功能

「這個月 LLM 花了多少錢？」
「哪個 prompt 的效果最好？」
「為什麼這個請求特別慢？」
「可以幫我匯出上週的使用報告嗎？」

你會發現 Developer UI：

• ❌ 沒有成本追蹤和統計
• ❌ 沒有效能分析工具
• ❌ 沒有 A/B testing 功能
• ❌ 沒有報表產生功能
• ❌ 沒有告警機制

這些都是 production 環境必須要有的功能。

所以答案是：不行

GenKit Developer UI 就像你在家裡用的小烤箱：

• 做個測試？很方便
• 烤個麵包？沒問題
• 開餐廳？拜託不要

它的設計初衷就是本地開發工具，不是 production monitoring platform。

這不是 GenKit 的問題，而是工具定位的問題。就像你不會拿螺絲起子去敲釘子一樣，工具要用在對的地方。

那 Production 要用什麼？

官方的 observability 教學是使用 Firebase 但這對我來說不是最合適的選項
因此我要另尋他路

好消息是，GenKit 基於 OpenTelemetry 標準。

這意味著什麼？

你可以把 trace 資料送到任何支援 OpenTelemetry 的 observability platform。

這就是為什麼當初選擇 GenKit 的好處之一 — 它沒有把你鎖在自己的生態系裡。OpenTelemetry 就像是工業標準的插頭，換個插座（observability platform）也能用。

想想看如果當初選擇了某個把你鎖死的框架，現在要換 monitoring 工具就得砍掉重練。

那 Production 該用什麼？三個必要條件

在開始找替代方案前，我先列出了三個不可妥協的條件：

條件一：必須是 Open Source

「和 LLM 的對話內容可能包含公司機密、個人隱私...這些東西要傳到第三方服務？」

這不只是技術問題，更是信任問題。

• 使用者和 Bot 的對話可能涉及敏感資訊
• Prompt 可能包含公司的業務邏輯
• 沒辦法確定第三方服務怎麼處理這些資料

Open Source 至少讓我們能：

• 知道資料怎麼被處理
• 遇到問題可以自己 debug
• 需要時可以客製化

條件二：可以 Self-hosting

就算是 Open Source，如果只能用 SaaS 服務也不行。

我們需要能夠：

• 把整套系統架在自己的環境
• 完全掌控資料的存取
• 符合公司的資安政策

條件三：支援 OpenTelemetry

這點是技術層面的考量。

因為 GenKit 基於 OpenTelemetry，如果 observability platform 也支援，整合就會很簡單：

• 不用大改程式碼
• 不會被 vendor lock-in
• 未來要換工具也方便

所以我選擇了 Langfuse

不是因為它有多酷炫的功能，而是因為它符合我們的底線需求。

而且實際用下來，發現它該有的都有：

• ✅ Trace 詳細記錄：每個 LLM call、每個 step 都看得一清二楚
• ✅ 成本追蹤：錢花在哪裡，一目了然（老闆會喜歡）
• ✅ Prompt 管理：可以直接在 Langfuse 上管理和版本控制你的 prompts
• ✅ 評分機制：可以標記好壞，慢慢建立起自己的評估資料集
• ✅ 權限管理：不同團隊可以看到不同的資料
• ✅ 告警功能：出問題時主動通知你

小結

Developer UI 很棒，但它就是 Developer UI。

Production 環境需要的是專業的 observability platform，而不是開發工具。

好在，因為我們一開始就選對了方向（GenKit + OpenTelemetry），現在要接上 Langfuse 也不會太痛苦。

這就是為什麼選擇符合標準的工具這麼重要 — 不會被 vendor lock-in，有更多的彈性。

接下來的幾天，我們就來實際把昨天提到的 LiteLLM & Langfuse 架設起來接上去

LLM 的發展變化很快，目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流，歡迎大家追蹤這個系列。

也歡迎追蹤我的 Threads @debuguy.dev