https://yennj12.js.org/yennj12_blog_V4/tags/mlops/Recent content in MLOps on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part4-zh/Tue, 26 May 2026 17:05:09 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part4-zh/前言 生產環境 AI 系統的監控與最佳化是確保企業 AI 應用成功的關鍵。從模型效能追蹤、基礎設施監控到成本控制，AI FDE 需要建立全方位的可觀測性體系。本文將深入探討 LLM-native 指標設計、分散式監控架構、智能故障診斷與企業級成本最佳化策略。 1. LLM-native 指標與評估體系 核心效能指標設計 LLM 特定指標框架： 1from dataclasses import dataclass 2from typing import Dict, List, Optional, Union 3import numpy as np 4from collections import deque 5import time 6import asyncio 7from enum import Enum 8 9class MetricType(Enum): 10 LATENCY = "latency" 11 THROUGHPUT = "throughput" 12 QUALITY = "quality" 13 COST = "cost" 14 RELIABILITY = "reliability" 15 16@dataclass 17class LLMMetrics: 18 timestamp: float 19 request_id: str 20 model_name: str 21 22 # 效能指標 23 time_to_first_token: float # TTFT - 首個 token 延遲 24 time_per_output_token: float # TPOT - 每個輸出 token 時間 25 total_latency: float 26 tokens_per_second: float 27 28 # 品質指標 29 perplexity: Optional[float] = None 30 bleu_score: Optional[float] = None 31 rouge_score: Optional[Dict[str, float]] = None 32 human_feedback_score: Optional[float] = None 33 34 # 成本指標 35 input_tokens: int = 0 36 output_tokens: int = 0 37 compute_cost: float = 0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-16-ttft-throughput-optimization-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-16-ttft-throughput-optimization-zh/核心定義：LLM 推理服務存在兩個永遠相互拉扯的指標——TTFT（首字延遲，決定用戶感知流暢度）與 Throughput（每秒 Token 數，決定 GPU 成本與容量）；所有推理優化技術本質上都是在這兩者之間移動作業點。 一、為什麼面試官問這個 面試官問 TTFT / Throughput 優化，真正測試的是三件事： 你是否理解 LLM 推理的計算瓶頸 — Prefill 受限於 FLOPS（矩陣乘法），Decode 受限於 Memory Bandwidth（KV Cache 讀取）。能分清楚這兩個瓶頸才是起點。 你是否能從業務 SLA 倒推系統設計 — 互動式聊天 TTFT < 500ms 優先；批次摘要任務 Throughput 最大化優先。混淆兩者設計方向是初階錯誤。 你是否知道業界標準工具 — vLLM、TGI、GPTQ、AWQ、Flash Attention 不是加分項，是基本盤。沒提過這些工具，面試官會直接降級評分。 弱答案長什麼樣：「可以用更快的 GPU」、「換成更小的模型」——這種回答顯示你沒有系統化思考，只是在說廢話。 強答案長什麼樣： 先拆解 Prefill vs Decode 的不同瓶頸，再針對每個瓶頸選對應工具，最後說明在給定 SLA 下如何調整 Batch Size 在 TTFT 與 Throughput 間取得平衡，並給出具體數字。 二、核心原理與技術深度 2.1 Prefill vs Decode：兩個截然不同的計算瓶頸 LLM 推理分為兩個階段，具有完全不同的計算特性： ┌──────────────────────────────────────────────────────────────────┐ │ PREFILL 階段（Compute-Bound，計算密集） │ │ │ │ 輸入 Prompt：N 個 Token │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 步驟 1：Q, K, V 投影 │ │ │ │ N × d_model → 三個 N × d_head 矩陣 │ │ │ │ 步驟 2：Attention Score 計算 │ │ │ │ Score = QK^T / sqrt(d_k) ← NxN 矩陣乘法 │ │ │ │ FLOPS = O(N² × d_model) │ │ │ │ 步驟 3：Softmax + 加權 V │ │ │ │ 所有 N 個 Token 並行處理 → GPU 利用率高 │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ │ 瓶頸：FLOPS（輸入越長，計算量平方增長） │ │ 輸出：第一個 Output Token ← 這就是 TTFT 的終點 │ └──────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────┐ │ DECODE 階段（Memory-Bound，記憶體頻寬密集） │ │ │ │ 每一步只生成 1 個新 Token（Auto-regressive） │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 步驟 1：從 KV Cache 讀取所有歷史 K, V │ │ │ │ HBM → SRAM（記憶體頻寬瓶頸在此） │ │ │ │ 步驟 2：計算新 Token 對所有歷史 Token 的 Attention │ │ │ │ FLOPS 極低（只有 1 × N 而非 N × N） │ │ │ │ 步驟 3：寫回新 K, V 到 KV Cache │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ │ 瓶頸：Memory Bandwidth（每步都要讀寫整個 KV Cache） │ │ 公式：Tokens/sec ≈ HBM Bandwidth / KV Cache Size per Token │ └──────────────────────────────────────────────────────────────────┘ 具體數字（LLaMA-2 70B，A100 80GB SXM）：https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-19-llm-judge-bias-mitigation-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-19-llm-judge-bias-mitigation-zh/核心定義：LLM-as-Judge 是用一個強大的語言模型對另一個語言模型的輸出進行自動評分，透過結構化 Prompt、分層抽樣與偏見消除技術，以 1% 的人力成本達到 80% 的人工評估一致性，是大規模 AI 產品品質監控的基礎設施。 一、為什麼面試官問這個 面試官真正在測試的不是「你知道 LLM-as-Judge 這個詞」，而是三件事： 你是否理解評估的統計性質：知道抽樣比例、信賴區間、漂移偵測背後的數學，而不只是說「隨機抽樣評估一下」。能說出「50K 樣本、95% CI、±14% 誤差範圍」的候選人，遠比說「我們抽 5%」的候選人有說服力。 你是否能辨識並主動消除偏見：弱候選人只說「讓 LLM 評分」；強候選人說出自增強偏見、位置偏見、冗長偏見、奉承偏見四類具體問題以及各自的 mitigation 技術，並知道每種技術的代價和侷限。 你是否懂成本工程：能給出具體數字—1M 日查詢、5% 抽樣、每次 $0.002，得出 $100/day vs $2,000/day 的差距，並說明如何用分層設計讓高風險租戶獲得更高覆蓋率。 弱答案：「我們讓 GPT-4 評分，看分數有沒有下降。」這個答案暴露了三個問題：沒有偏見意識、沒有成本意識、沒有統計有效性意識。 強答案：「我們對 5% 的流量做按 intent_class × tenant 的分層抽樣，用與被評估模型不同家族的模型作為裁判，強制 CoT 先推理再評分，pairwise 比較做雙向排列取一致結果，設 7 日滾動均值 ±2σ 漂移告警接 PagerDuty。1M 日查詢成本 $100/日，裁判與人工的 Spearman ρ = 0.84。」 二、核心原理與技術深度 2.1 為什麼人工評估無法規模化 人工評估的隱藏成本遠超表面工資。一個典型的企業 AI 產品日查詢量達 1M： 評估方式 1M 查詢/日 成本 結果延遲 實際覆蓋率 全量人工標注（$0.05/條） ~$50,000/日 24–72 小時 理論 100%，實際 <0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/大多數工程師的直覺：「索引過期了？重新跑一次 Re-indexing 就好。」 資深 FDE 的直覺：「Re-indexing 要數小時，這期間服務怎麼辦？Re-indexing 之後 HNSW 圖會不會因此失衡？」 大多數工程師的直覺：「那就頻繁做增量更新，隨時保持最新。」 資深 FDE 的直覺：「增量更新累積到一定程度，Graph Drift 會讓 RECALL@10 從 95% 跌到 70%，這才是真正的定時炸彈。」 面試情境 面試官：「你們的企業客戶每天會在 GCS 上新增、修改、刪除數千份 PDF 文件。你們的 AI Agent 需要即時查詢這些知識庫，但現在常常給出已被刪除或過期的內容，讓客戶非常不滿。我知道 Vertex AI Vector Search 支援增量更新，但我聽說大規模頻繁更新會造成 HNSW 圖退化，進而影響搜尋精準度。請告訴我，你會如何設計一套既能即時響應文件變更、又能長期維持向量索引健康度的自動化管線？在系統規模達到百萬向量時，你的設計會有哪些具體調整？」 一、核心問題：為什麼向量索引的「即時性」與「精準度」天生對立？ 1.1 RAG 系統的資料新鮮度危機 在企業 RAG（Retrieval-Augmented Generation）場景中，知識庫並非靜態的。法規文件每週更新、產品手冊每月改版、內部 SOP 隨業務調整。當 AI Agent 仰賴向量檢索來回答問題時，索引延遲（Index Lag）直接等同於「AI 在說謊」。 典型的痛點數字： 文件刪除後，向量索引平均滯後 4–8 小時才能同步 在此期間，Agent 回答基於已廢棄文件的機率高達 23% 企業客戶每月因 AI 給出過期資訊而提交的客訴工單：平均 340 件 1.2 三重矛盾的根本原因 矛盾一：即時性 vs. 批次效率 ┌────────────────────────────────────────────┐ │ 即時更新：每次文件變更立即寫入向量索引 │ │ 優點：延遲 < 30 秒 │ │ 缺點：HNSW 圖節點連結逐漸失衡（Graph Drift）│ │ 每 10K 次增量更新後，RECALL@10 下降約 8%│ └────────────────────────────────────────────┘ 矛盾二：完整重建 vs.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/多數工程師的做法：每次模型更新後，手動抽幾十筆對話，憑感覺評估品質有沒有退步。 問題是，樣本量不足無法代表真實用戶分佈，而且人工評估無法在 CI/CD 流程中自動執行。 正確的做法：建立三層自動化評估管線，用統計學方法精準抽樣 5% 送 LLM 裁判， 其餘 95% 走免費傳統指標，並在 Sigma 2 漂移時自動觸發 PagerDuty 警報。 面試情境 你的團隊正在維護一個 B2B SaaS 平台上的 RAG Agent，每天處理約 50 萬筆客戶支援對話。 上週你們將底層模型從 Gemini 1.5 Pro 升級至 Gemini 2.0 Flash，同時調整了 System Prompt。 產品團隊要求你在 48 小時內確認新系統的回答品質沒有惡化，並建立一套長期可用的 自動化觀測機制。你有 Vertex AI 的使用權限，預算受限，你會怎麼設計這套系統？ 一、核心問題：為什麼 GenAI 的品質監控比傳統服務更難？ 傳統後端服務的品質監控相對直觀：HTTP 4xx/5xx 錯誤率、P99 延遲、資料庫查詢失敗數。 這些指標全都是客觀的、可計算的、接近零成本的。 GenAI 系統的品質卻天生是主觀的：一個回答是否「夠好」，取決於事實準確度、 語氣適切性、上下文相關性、甚至法律合規性。這帶來三個根本性挑戰： 挑戰一：評估本身就需要智慧 你無法用 if response == expected_answer 來評分自由文本。傳統 BLEU / ROUGE 指標 只能衡量字面重疊，無法判斷語意正確性。唯一可靠的裁判是另一個 LLM——但這就是 評估成本 ≥ 生產成本的陷阱：https://yennj12.js.org/yennj12_blog_V4/posts/deploying-huggingface-models-aws-cdk-sagemaker/Sun, 30 Nov 2025 12:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/deploying-huggingface-models-aws-cdk-sagemaker/🎯 Introduction Deploying machine learning models to production is a complex challenge that goes far beyond training a model. When working with large models from Hugging Face—whether it’s image generation, text-to-image synthesis, or other AI tasks—you need robust infrastructure that handles: Scalability: Auto-scaling to handle variable loads from 0 to thousands of concurrent requests Cost Efficiency: Paying only for what you use while maintaining performance Reliability: 99.9%+ uptime with proper error handling and monitoring Security: Protecting models, data, and API endpoints Observability: Comprehensive logging, metrics, and tracing This comprehensive guide demonstrates how to deploy a Hugging Face model to AWS using infrastructure as code (CDK with TypeScript), combining SageMaker for model hosting and Lambda for API orchestration.