https://yennj12.js.org/yennj12_blog_V4/tags/serving/Recent content in Serving on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 02:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/Sun, 21 Jun 2026 19:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/大多數人把 LLM 推論想成「載入模型，呼叫 generate()，等結果」。 實際上，每個 token 都在搶 GPU HBM 頻寬，記憶體碎片化讓吞吐量砍半， 一個設計不良的 batch 策略讓 A100 的使用率停在 12%。 真正的推論工程是記憶體管理、排程策略、精度取捨三件事同時做對。 面試情境：「你的團隊剛把一個 70B 參數的對話模型從研究環境搬到生產，目前 p99 延遲 18 秒、GPU 使用率 15%、每千 token 成本 $0.04。CTO 要求三個月內把成本降到 $0.008、p99 降到 4 秒。你的架構計畫是什麼？」 一、核心問題：LLM 推論為什麼貴又慢 LLM 推論和傳統深度學習推論有本質上的差異。ResNet 做影像分類，輸入固定大小，一次 forward pass，批次容易排。LLM 是自回歸生成（autoregressive generation）：每個 token 依賴前面所有 token，必須一步一步產生。 三個根本瓶頸： 瓶頸一：記憶體頻寬牆（Memory Bandwidth Wall） 70B 模型 FP16 佔 140 GB。A100-80GB 只能塞下半個模型，必須 tensor parallel。每生成一個 token，模型的所有 140 GB 權重都要從 HBM 讀一次。A100 HBM 頻寬 2 TB/s，讀 140 GB 需要 70 ms——這就是單 token 延遲的硬下限，和計算無關。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 倍。