💡 快速答案:怎麼把自己的 AI 模型架成推論 API 服務?
POC 用 Ollama,生產用 vLLM 或 SGLang,提供 OpenAI 相容 API,前端改 base_url 就能接。7B 權重約 14-16GB 顯存,每路 4K 對話的 KV cache 抓 0.5-2GB,10-20 路併發用一張 24GB 卡起步,台灣機房月租 NT$15,000-25,000。
模型選好了、也驗證過效果,接下來的問題才是工程的開始:怎麼讓全公司、甚至你的客戶,穩定地用到這個模型?答案就是把它包成推論 API。這一步的難度常被低估——單人測試跑得飛快的模型,一上線就延遲爆炸;或者為了扛併發把規格拉滿,月底看帳單才發現 GPU 大半時間在發呆。自建推論 API 本質上是在延遲、併發、成本三個角之間找平衡,這篇教學把三角關係拆開講,給你可以直接套用的估算方法與架構建議。
為什麼要自建:三個過不去的檻
用現成的雲端模型 API 沒什麼不對,直到你撞上三件事之一。資料敏感:客戶對話、病歷、財務數據不能送出境,個資法與行業主管機關的要求擺在那裡;成本失控:按 token 計費的帳單跟著用量線性長,月百萬次呼叫的產品,API 費用常常超過自建月租的兩三倍;客製需求:你微調過的模型、特殊的取樣參數、需要保證的回應時間,公有 API 都給不了。成本這條再講個常見劇本:產品加了「AI 摘要」按鈕,上線時每天 2,000 次呼叫,三個月後功能被預設開啟、變成每天 5 萬次,API 帳單從五位數跳到六位數,而訂閱定價早就鎖死——毛利被吃掉的速度比任何人的反應都快,自建的固定月租在這種「功能普及化」劇本裡就是定價保險。三者中一項成立,自建就值得認真評估;兩項成立,基本上是遲早的事。
反過來也要誠實:三種情況不建議自建。用量太小——每天幾百次呼叫,API 月費幾百塊,自建怎麼算都不划算;完全沒有維運人力——連 Linux 都沒人碰的團隊,先用 API 把產品驗證起來;以及任務非旗艦閉源模型不可——開源模型盲測過確實不夠力的少數場景。自建是工程決策不是信仰,拿你的用量、資料屬性與人力對照上面六條,答案通常很清楚。
三角習題:延遲、併發、成本怎麼互相拉扯
看懂三角關係,要先認識兩個延遲指標。TTFT(Time to First Token)是使用者按下送出到看到第一個字的時間,決定「有沒有在動」的體感,健康值在 0.5-2 秒;生成速度(token/s)決定字流出來的速度,單人閱讀場景 20 token/s 以上就順。併發是同時處理的請求路數,成本則是你為此付出的 GPU 月租。
三者的拉扯關係很具體:併發拉高,同一張卡上的請求互搶算力,TTFT 與生成速度都會掉;要守住延遲就得加卡,成本上升;要省成本就得接受排隊,延遲變長。工程上沒有三全其美,只有「依產品需求選兩個保、放掉一個」:內部工具保成本與併發、犧牲一點延遲;對客戶的付費服務保延遲、用超額配置換體驗。規格單一直搖擺的團隊,多半不是不會算,是還沒想清楚產品定位,先回去把定位吵完再來選卡。先寫下你的目標值(例如 p95 TTFT 低於 1.5 秒、尖峰 30 併發、月預算 NT$60,000),再開始選規格,順序不要反過來。
給一組實測的感覺:一張 4090 跑 7B FP16 配 vLLM,單人使用 TTFT 約 0.3 秒、生成 70-100 token/s;把併發灌到 10 路,TTFT 升到 0.8-1.2 秒、每路生成掉到 30-50 token/s;灌到 25 路,TTFT 破 2 秒、開始排隊。同一張卡,體驗從「飛快」到「將就」到「不可用」,差的只是併發數——這就是為什麼規格討論一定要從「尖峰有幾路」開始,而不是從「模型幾 B」開始。
TTFT 的組成也值得拆開看:排隊等資源、prefill(把整段輸入一次算完)、然後才開始逐字生成。長輸入的 prefill 很重——丟一份 8K token 的文件進去,光 prefill 就可能占掉一兩秒,這是文件型應用的 TTFT 永遠比聊天型難看的原因。對策有三:前綴快取讓相同的系統提示詞不重算、超長輸入先截斷或摘要、把文件批次任務改走非同步路徑,別讓它跟即時對話搶同一條佇列。
推論引擎選型:效率差距可以到十倍
| 引擎 | 定位 | 關鍵能力 | 適用階段 |
|---|---|---|---|
| Ollama | 極簡部署 | 一行指令起服務、自動量化 | POC、個人與小團隊 |
| vLLM | 生產標準 | PagedAttention、continuous batching,吞吐高 5-10 倍 | 正式環境首選 |
| SGLang | 高階生產 | RadixAttention 前綴快取,重複前綴場景更快 | Agent、大量共用 prompt |
| TensorRT-LLM | 極致效能 | NVIDIA 深度優化、需編譯 | 極端吞吐需求、固定模型 |
選擇邏輯很簡單:POC 用 Ollama 十分鐘上線;要對多人服務,直接上 vLLM——它的 continuous batching 會把不同請求的生成步驟交錯排進 GPU,同一張卡的有效吞吐是逐條處理的 5-10 倍,這一項就決定你要租一張卡還是五張卡。四個引擎都支援 OpenAI 相容 API,應用端程式碼可以完全不動,把 base_url 從商用服務換成自家端點即可,這也讓「先用商用 API 驗證產品、再切自建」的路徑幾乎零改寫成本。
引擎與量化的搭配有慣例可循:vLLM 生產部署搭 AWQ 或 GPTQ 的 4-bit 權重最順,顯存省一半以上、吞吐幾乎不折損;Ollama 用 GGUF 格式,拉檔即用。要留意的是不同引擎的預設參數差很多——最大併發數、KV cache 上限、context 長度都要按你的硬體明確設定,用預設值上線然後 OOM,是新手工程師的固定戲碼。
顯存預算:權重之外,KV cache 才是變數
推論顯存等於「模型權重加 KV cache 加少量開銷」。權重好算:7B FP16 約 14-16GB、32B INT4 約 18-20GB;KV cache 是每一路進行中的對話都要占用的快取,依模型架構,每路 4K token 大約 0.5-2GB,而且跟併發數與 context 長度成正比。這就是為什麼「單人測試沒問題,上線就 OOM」的劇本不斷重演:20 路併發、每路 8K context,KV cache 可能吃掉 20-40GB,比模型本體還大。
實用的估算流程:先定尖峰併發與平均 context,算 KV cache 總量,加上權重,再留 15-20% 餘裕。舉例:32B INT4(20GB)服務 15 路併發、平均 4K context(約 15-20GB KV cache),總需求 40-48GB,一張 L40S 48GB 剛好,或雙 4090 用張量平行分攤。若跑的是 DeepSeek R1 這類思考鏈很長的推理模型,context 消耗更兇,預留空間要再放大,各版本的具體數字見 DeepSeek R1 GPU 需求對照。
好消息是新一代架構與引擎都在幫你省這筆錢:採用 GQA 的模型(Llama 3、Qwen2.5 世代)KV cache 比舊架構省 4-8 倍;vLLM 的 PagedAttention 把 cache 切成小分頁按需配置,傳統部署裡三到五成的顯存碎片浪費幾乎歸零。同樣一張 24GB 卡,2023 年的部署方式撐 4-5 路併發,2026 年的組合拳可以撐 15-20 路——選對引擎本身就是最大的一次降本。
台灣案例:SaaS 團隊把月帳單砍掉六成
一家台中的 HR SaaS 公司,產品內建履歷解析與面談摘要功能,原本走海外商用 API。用戶成長後兩個問題同時爆:月 API 帳單衝到 NT$90,000 出頭並持續上升;金融與醫療類客戶在資安問卷上直接問「求職者個資是否出境」,答不好就丟單。他們花了六週切換到自建:模型選 Qwen2.5-14B 微調版,INT4 量化後 9-11GB,跑在台灣機房一台雙 4090 主機上(月租約 NT$35,000),vLLM 做服務層,尖峰實測 22 路併發。
六週的切換時程值得拆開參考:第 1-2 週租單卡主機做離線評測,拿 500 筆歷史請求對比自建模型與原 API 的輸出品質,確認可接受;第 3 週建雙卡生產環境與監控;第 4 週用 5% 真實流量做灰度,發現兩個格式邊界問題,修 prompt 解決;第 5 週流量放到 50%,壓測驗證尖峰;第 6 週全量切換,原 API 降為備援。全程使用者無感,這是照劇本走的結果,不是運氣。
切換後的數字:月固定成本 NT$35,000,比原帳單省六成,而且不再隨用量成長;p95 TTFT 從 2.8 秒(含跨海往返)降到 1.1 秒,台灣機房到台灣用戶的網路往返只有 5ms 上下;資安問卷的資料出境欄位從此填「否」,當季就簽下兩家原本卡關的金融客戶。他們保留了原本的商用 API 作為 fallback:自建端點健康檢查失敗時自動切換,雙保險的月成本不到 NT$1,000,因為 99% 的流量都走自建。
壓測方法他們也走了標準流程:用開源壓測工具重放歷史流量的放大版(平常尖峰的 1.5 倍),連續打 30 分鐘,盯 p95 延遲與錯誤率;再單獨測「長文件」路徑——履歷有一頁的也有八頁的,長輸入是延遲長尾的主要來源,單獨設超時與截斷規則後,p99 才穩下來。切換這種事,九成的信心來自壓測,一成才來自祈禱。
上線後才是重點:監控、SLA 與擴容節奏
推論服務的維運圍繞四個數字:p50/p95 TTFT、生成速度、佇列深度、GPU 使用率。前三個顧體驗,最後一個顧錢包——GPU 使用率長期低於 30%,表示規格買太大或該把批次任務排進離峰;佇列深度常態大於零,表示該擴容了。告警設在使用者抱怨之前:p95 TTFT 超標 20% 就通知,而不是等客服工單進來。儀表板不用花俏,四個數字加一條佇列趨勢線,值班的人一眼能看懂,就是好儀表板。
成本也要有月報:每月統計 token 總量、GPU 平均與尖峰使用率、換算的單位成本(每百萬 token 幾塊錢),跟商用 API 的牌價對照一次。這張報表有兩個用途——向管理層證明自建的價值持續成立,以及在用量成長到需要擴容時,用數據而不是感覺去申請預算。自建服務最怕的不是壞掉,是沒人說得清它到底省了多少錢。
資安層的最低標配:API key 按應用發放、每季輪替;閘道做速率限制擋暴衝與濫用;請求日誌全留但個資欄位遮罩;管理介面只開內網。這四件事一天可以做完,卻是資安問卷與稽核的必考題,別等被問到才補。
擴容的節奏建議「垂直先、水平後」:先把量化等級、批次參數、context 上限調到位,再考慮換大卡,最後才是多卡多副本加負載均衡。另外,推論主機與訓練主機的規格邏輯完全不同,別拿訓練的配置思維來配推論——這個常見誤區在 訓練與推理的 GPU 配置邏輯 有完整拆解。把這些機制建立起來,自建 API 的穩定度可以做到跟商用服務同級,成本卻是自己可控的。
人力配置的真實答案:一套自建推論 API 的日常維運,由一位後端工程師兼任就夠,前提是監控與告警已經自動化;需要專注投入的是前兩個月的建置與調校期。很多團隊卡在「我們沒有 AI 工程師」的心理門檻,實際上推論服務的維運技能跟一般後端服務八成重疊,缺的那兩成——顯存邏輯與引擎參數——一週可以補起來,或者選一家願意陪你調參數的主機商,把學習曲線再砍一半。
找台灣在地的 GPU 主機夥伴
推論 API 的規格會隨產品成長而演進:從單卡 POC、雙卡生產,到多副本高可用。戰國策 GPU 主機提供 NVIDIA H100 與 RTX 系列多種配置,台灣機房、使用者資料不出境,月租 NT$15,000 起,7×24 中文技術支援,擴容時可平滑升級不中斷服務。方案細節見 戰國策 GPU 主機,或加 LINE @119m、撥免費專線 0800-003-191,顧問可依你的併發與延遲目標試算最省的配置。
常見問題 FAQ
自建推論 API 和呼叫商用 API,成本怎麼比?
商用 API 按 token 計費,量小便宜;月呼叫量到百萬次後,帳單常達 NT$80,000-200,000。自建是固定月租:雙 4090 主機約 NT$35,000、H100 約 NT$60,000-80,000,用量再大也不變。月 API 費穩定超過自建月租 1.5 倍,就該評估切換。
TTFT 和 token/s 是什麼?目標值該設多少?
TTFT 是送出請求到第一個字出現的時間,對話產品建議 p95 壓在 1.5-2 秒內;token/s 是後續生成速度,單人閱讀 20 token/s 以上就流暢,程式生成建議 40 以上。兩者都要在「尖峰併發」下量測才有意義,單人測試的數字不能當 SLA。
一張 RTX 4090 能撐多少併發?
以 7B FP16 加 vLLM 估:權重 14-16GB,剩 8-10GB 給 KV cache,每路 4K context 約 0.5-1GB,尖峰 10-20 路併發可維持每路 20 token/s。32B INT4 權重占 18-20GB,單卡空間有限,併發壓在 5-8 路或改雙卡。
vLLM 為什麼比一般部署快這麼多?
兩個機制:PagedAttention 把 KV cache 分頁管理,顯存利用率從常見的 20-40% 拉到 90% 以上;continuous batching 讓不同請求的生成步驟交錯執行,GPU 不再等最慢的請求。合計效果是同卡吞吐提升 5-10 倍,等於直接省下 5-10 倍的硬體租金。
KV cache 到底要預留多少顯存?
粗略公式:每路併發、每 4K token 的 context,依模型抓 0.5-2GB(GQA 架構的新模型較省)。例如 15 路併發、平均 4K context,預留 8-30GB。實務建議:總顯存 = 權重 + KV cache 估算 + 15-20% 餘裕,上線後再用實測數據修正。
自建 API 的延遲可以比商用 API 低嗎?
可以,而且低很多。台灣用戶呼叫海外 API,光網路往返就 60-150ms,加上排隊常見 p95 兩三秒;自建在台灣機房,網路往返 5ms 上下,搭配合理併發配置,p95 TTFT 壓在 1 秒上下是常態。對即時互動型產品,這是體感等級的差距。
怎麼做到服務不中斷的模型更新?
標準做法是藍綠部署:新模型先在第二個服務副本載入並通過煙霧測試,負載均衡器再把流量切過去,舊副本觀察 24-48 小時後下線。單卡預算做不了雙副本時,選離峰時段換模型,vLLM 重載一個 14B 模型約 3-8 分鐘,公告維護窗口即可。
需要準備 fallback 機制嗎?怎麼設計?
建議要。常見設計:自建端點健康檢查連續失敗 3 次,閘道自動把流量切到商用 API 或備用副本,並發告警。fallback 的月成本通常不到 NT$1,000(因為 99% 流量走自建),卻能把服務可用率從單機的 99% 拉到 99.9% 以上,對外服務尤其必要。
推論 API 的資安要注意什麼?
最少四件:API key 發放與輪替、請求與回應日誌(留存供稽核,注意個資遮罩)、輸入輸出的敏感內容過濾、以及網路層的 IP 白名單或 VPN。自建的意義是資料不出境,但機房內的存取控制與日誌若沒做,稽核一樣過不了,第一天就要納入架構。
從零開始自建,合理的時程是多久?
有經驗的團隊:第 1 週選型與 POC(Ollama 加內部測試),第 2-3 週建生產環境(vLLM、監控、日誌、fallback),第 4-6 週試營運與壓測,共 4-6 週。沒有 GPU 維運經驗的話,選有 7×24 中文支援的台灣主機商可以把前期環境問題的處理時間砍掉一半以上。