https://yennj12.js.org/yennj12_blog_V4/tags/infrastructure/Recent content in Infrastructure on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Sun, 09 Nov 2025 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Part 2 of the Kubernetes Autoscaling series: Comprehensive guide to cluster-level autoscaling covering Cluster Autoscaler, Karpenter, cloud provider-specific solutions (EKS, GKE, AKS), and emerging technologies for intelligent node provisioning and cost optimization.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part1-serving-zh/Mon, 22 Jun 2026 02:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part1-serving-zh/大多數人：把 torch.load() 包一層 Flask，貼上 /predict 就叫「部署」。 真正的做法：從服務框架選型、GPU 共享策略、冷啟動預熱到多租戶隔離，每一層都有可量測的 SLO。 差距不在演算法，而在系統設計——單機 GPU 使用率 23% vs 叢集使用率 78%，成本相差 3.4 倍。 本文從 POC 到全球部署，逐層拆解 AI 推論服務的工程決策。 面試情境 你的電商平台每天有 500 萬次商品推薦請求，目前用一台 A100 跑 PyTorch 模型，P99 延遲 1.2s，GPU 使用率只有 23%。CTO 說三個月後要支援 10 倍流量，同時把 P99 壓到 200ms 以內，預算只能增加 2 倍。你會如何重新設計推論服務架構？請解釋你在服務框架選型、擴縮容策略、GPU 共享、以及多租戶隔離四個面向的決策依據。 一、核心問題：AI 推論服務與傳統 Web 服務的本質差異 AI 推論服務並不是「把模型包一個 HTTP 端點」這麼簡單。它在資源模型、延遲特性、擴縮容行為上，與傳統 Web 服務有根本性差異。 資源模型的差異 傳統 Web 服務以 CPU 為主，水平擴展幾乎無代價——增加一台虛擬機需要 30 秒，成本線性增加。AI 推論服務以 GPU 為主，GPU 節點冷啟動需要 45–120 秒（含驅動初始化、CUDA context 建立、模型載入），每台 A100 機器成本約 $3–6/hour，是 CPU 機器的 15–30 倍。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/Mon, 22 Jun 2026 03:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/大多數工程師把 LLM 呼叫當成黑箱：記錄 HTTP 狀態碼、回應時間，然後就沒了。 正確的做法是：追蹤每一個 Prompt 版本、每一次工具呼叫、每一個 Token 成本，並量化模型行為漂移。 傳統 APM 只告訴你系統「掛了沒」；AI 可觀測性要告訴你模型「答得好不好」。 沒有這層監控，你永遠不知道提示更新讓答案品質下降了 12%，還是模型供應商悄悄換了版本。 面試情境 面試官問：「你們的 RAG 問答系統上線後，客服主管反應『最近答案怪怪的』，但 p99 延遲和錯誤率都正常。你身為 SRE/AI 工程師，會怎麼設計可觀測性系統來定位這類問題？請說明你的 Traces 設計、漂移偵測機制，以及如何在成本和覆蓋率之間取得平衡。」 一、核心問題：AI 系統的可觀測性為什麼與傳統系統不同 傳統服務的可觀測性三支柱——Metrics、Logs、Traces——在 AI 系統上全都「不夠用」，但原因各不相同。 傳統系統的失敗模式是二元的：請求成功或失敗，HTTP 200 或 500，延遲高或低。失敗有明確的邊界。當資料庫 query 耗時 800ms，你知道哪裡壞了。 AI 系統的失敗模式是漸進的、語意的： 模型回傳 HTTP 200，但答案從準確滑向「有點對但不夠精確」 Prompt 被改了一個詞，召回率悄悄下降 8% 供應商在 2AM 更新基礎模型，語氣風格改變，用戶滿意度在 48 小時後才反映在 CSAT Token 用量因為對話上下文累積，每週成本靜靜地增長 15% 這就是為什麼 AI 可觀測性需要新的維度： 維度 傳統系統 AI 系統 品質訊號 Error rate, p99 latency 語意相似度、答案忠實度、幻覺率 版本追蹤 Code git SHA Prompt version + Model version + RAG index version 成本單元 CPU/Memory/Network Input tokens + Output tokens + Embedding calls 漂移型態 無（確定性系統） 概念漂移、分佈漂移、模型版本漂移 告警閾值 靜態（> 500ms alert） 動態（品質分數 7 日移動平均下降 > 5%） 面試官問的「答案怪怪的」就是典型的語意品質退化。系統層面一切正常，但輸出品質已悄悄崩潰。沒有 AI-native 可觀測性，這種問題的 MTTR 往往超過 3 天。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/Mon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/大多數團隊看到 AI 帳單飆升，第一反應是「換便宜的模型」。 但換模型只是換藥不換病：根本問題是沒有成本工程的思維。 正確答案是把 AI 推論視為可測量、可分解、可優化的工程系統—— 從 Token 單位經濟學到快取命中率，每個數字都是槓桿點。 面試情境 你的 RAG 系統每月 AI API 費用從 $3,000 暴增到 $47,000，只花了 90 天。VP 問你：「不砍功能、不降品質，能把成本壓回 $15,000 以內嗎？」你會從哪裡下手？ 一、核心問題：AI 成本為什麼是工程問題而不是採購問題 1.1 成本爆炸的根因 AI API 成本爆炸通常不是因為「用太多功能」，而是因為工程決策累積的結構性浪費： 重複計算：相同或語義近似的 prompt 反覆打到 API，沒有任何快取層 模型過配（Over-provisioning）：用旗艦大模型處理「幫我把這段文字轉成 JSON」這種任務 無邊界的 Context Window：每次請求塞入整個對話歷史，Context 長度隨時間線性增長 同步阻塞推論：本可批次離線的任務強行走即時路徑，佔用高單價的即時算力 1.2 成本的三個維度 成本 = Token 數量 × 單價 × 請求頻率 ─────── ──── ──────── 工程可控 模型選擇 業務需求 採購談判只能影響「單價」，而且通常邊際效益有限（折扣上限約 20–30%）。 真正的槓桿在「Token 數量」和「請求頻率」——兩者都是純工程問題。 1.3 為什麼 FinOps 思維不夠用 傳統雲端 FinOps 的核心是「Resource Right-sizing」：把過大的 VM 換小。 但 AI 成本的結構完全不同：