鐵人檔案
能啟動模型，不代表能長期營運 AI 平台。本系列從地端生成式 AI 平台的實際維運問題出發，探討 GPU、CPU、記憶體與儲存資源競爭，並延伸至服務監控、效能量測、容量規劃、故障處理、備份與災難復原。透過實際指標、故障情境與復原測試，建立從 PoC 邁向多人穩定服務所需要的 SRE 與平台工程方法。
把模型下載下來、看到 GPU 開始吃 VRAM，再從 Web UI 成功問出第一個問題，通常是架設地端生成式 AI 最有成就感的一刻。 但如果今天不是「我自己的...
昨天我把「模型能回答」和「平台能營運」分開來看，最後留下一個很實際的問題：當使用者只說「AI 今天很慢」，我究竟要從哪裡開始找？ 直覺上會先看 GPU，但當我把...
昨天我把一次 AI 請求經過的 Web/API、Database、Embedding、Vector Store 與 LLM Serving 拆開，也標出共用的...
昨天我把 TTFT、end-to-end latency、queue wait 與 availability 寫成暫定 SLO。寫完後馬上出現一個很實際的問題：...
nvidia-smi 是排查 GPU 問題時最常使用的工具。指令一執行，就能看到 GPU utilization、顯示記憶體用量、溫度、功耗與占用程序。不過，這...
同一組模型權重，放進不同的 serving runtime，可能呈現完全不同的啟動時間、記憶體占用、併發能力與故障模式。模型回答得好不好只是選型的一部分；服務能...
前一篇討論「Ollama 與 vLLM：服務模型相同，營運行為卻不同」，這篇聚焦「併發一上來，瓶頸先出現在哪裡」，並沿用同一組輸入、環境與判讀規則，避免只做名詞...
前一篇處理「併發一上來，瓶頸先出現在哪裡」，這篇進一步討論「VRAM 容量規劃：模型大小不是唯一答案」。共同的量測條件是前後比較的基礎。 今天要回答的問題 拆解...
完成「VRAM 容量規劃：模型大小不是唯一答案」後，下一個問題是「多模型共存：誰把誰擠出 GPU」能否重跑、否定並留下失敗原因。這就是今天的範圍。 今天要回答的...
