香港 AI 團隊的 infra 省錢攻略

香港創業圈有一個公開的秘密：大部分 AI 團隊的 infra 成本，根本撐不過 product-market fit 那天。每個月幾萬到幾十萬的 GPU 帳單，像一把鈍刀慢慢割。但問題不是算力太貴——真正的原因是你用算力的方式太浪費。集中式推理、單機部署、每次對話從頭計算 KV cache，這些習慣才是燒錢的元兇。

集中式推理的隱形成本

大多數團隊的直覺是「租一台 A100 或 H100，把模型放上去，API 一開就收工」。這個做法在 prototyping 階段完全合理，但一到 production 規模，問題逐一浮現。單機推理最大的浪費來自 idle time——用戶請求之間 GPU 閒置，長序列推理時計算資源沒有被充分利用。更致命的是，為了應付 peak load 你必須 over-provision，結果離峰時段七成算力在空轉。

香港團隊面對的處境比矽谷同行更尷尬。不論是 AWS、GCP 還是本地數據中心，GPU 實例的定價都比美國 region 溢價 20-30%。一台 A100 80GB 月租動輒三、四萬港幣，而 startup 通常需要 4-8 台才能跑像樣的服務。一年下來 infra 燒掉一兩百萬——這筆錢本來應該用在產品開發和用戶獲取上。

另一個經常被忽略的成本是 KV cache 的 VRAM 消耗。LLM 推理時，每生成一個 token 都需要讀寫整個 context 的 KV cache。對話歷史愈長，cache 愈大，很快就塞滿 GPU 記憶體。結果你被迫縮短 context window，或頻繁 reload 模型——兩種做法都在犧牲用戶體驗，間接流失用戶。

用網絡換算力：Mesh-LLM 的分散式哲學

Mesh-LLM 的核心思路很反直覺：與其把模型塞進一台昂貴的機器，不如把它拆散到多台便宜機器上，透過網絡協同推理。具體做法是 pipeline parallelism——把 LLM 的不同層分配到不同 GPU 節點，每台機器只需承載模型的一部分權重和對應的 KV cache，VRAM 需求大幅降低。

這意味著你可以用 4 張 RTX 3090（香港二手市場約 $7000-8000 港幣一張）來跑本來需要 A100 才能載入的 70B 模型。對本地團隊來說這是 game changer。RTX 3090 供應充足、價格透明、不受雲端 vendor lock-in 限制。Mesh-LLM 的通訊層對網絡條件做了優化，即使普通 1GbE 也能有不錯的吞吐量。

當然分散式推理有代價。跨節點通訊引入延遲，pipeline bubble 降低 GPU 利用率。但對於 chat 類應用和 batch inference，這 trade-off 完全可接受——犧牲 latency 幾個百分點，換來 infrastructure cost 降低一個數量級。實際測試中，4×RTX 3090 跑 Llama 3.3 70B 的 throughput 約等於 1×A100 的 60-70%，但成本只有後者的十分之一。

Mesh-LLM 的另一個優點是彈性擴展。用戶增長時不需要跳級到更高階的 GPU，只需橫向加入更多 consumer-grade 節點。這讓成本曲線從 exponential 變成 linear——對 seed 階段的團隊來說，這差別足以決定生死。

LMCache：長對話場景的記憶體革命

如果 Mesh-LLM 是從架構層面省錢，LMCache 就是從運算效率層面省錢。LLM 推理有一個很大的浪費：每次用戶發送新訊息時，模型都要重新計算整個對話歷史的 KV cache。即使只多了一條 user message，之前的計算結果也全部丟棄。在長對話場景——客服 bot、程式碼助手、文檔分析——重複計算佔總推理時間的 60% 以上。

LMCache 的做法是把 KV cache 快取到 host memory（系統 RAM）或 SSD，而不是每次都丟掉。當新請求進來時，它比對新 context 和快取之間的重疊部分，只重新計算有變化的區域。這個「差異計算」（delta computation）的思路，把增量推理的計算量從 O(context length) 降到 O(delta length)。

對於香港團隊，這有兩個直接好處。第一，單張 GPU 可以服務更多 concurrent user，因為每次請求的運算量變小了。第二，你可以支援更長的 context window 而不需要升級硬體。以前 128K context 需要 A100 80GB 才跑得順，現在用 LMCache 搭配 RTX 3090，加上 64GB host memory 做 cache，也能達到可接受的推理速度。

LMCache 和 Mesh-LLM 可以疊加使用——這才是真正的殺手組合。Mesh-LLM 處理模型的水平擴展，LMCache 處理每個節點上的運算效率。兩者結合，平民 GPU 集群在吞吐量上可以接近甚至超越單台 A100 的性能。測試數據顯示，在長對話場景（平均 50 輪對話），Mesh-LLM + LMCache 的組合比純 Mesh-LLM 提升約 3.5 倍 throughput，cache hit rate 可達 75-85%。

香港團隊的實戰部署路徑

理論講完，具體點落地。第一步評估你的 workload 特性。如果你的應用是短 query（單輪問答、簡單分類），LMCache 收益有限，但 Mesh-LLM 仍然可以降低成本。如果你是長對話或 RAG 場景，兩個工具一起上。

第二步硬體規劃。以典型客服 chatbot 為例：需要跑 70B 模型、支援 32K context、約 50 concurrent user。傳統方案是 2 台 A100 80GB（月租約 $8000 USD 或 $62000 HKD）。Mesh-LLM + LMCache 方案是 4 張 RTX 3090（一次性投入約 $32000 HKD）加上一台 128GB RAM 的 CPU server（約 $8000 HKD），總投入約 $40000 HKD——兩個月就回本。

第三步部署與調參。用 Mesh-LLM 的 CLI 工具把模型分片，pipeline parallelism 建議 4-8 層 per GPU。LMCache 的 caching policy 在 chatbot 場景建議用 LRU + prefix caching，cache size 設為 host memory 的 50%。負載均衡器把請求分發到推理節點，建議用 round-robin 加 least-loaded 的混合策略。

第四步持續監控。聚焦三個指標：end-to-end latency、cache hit rate、GPU 利用率。Cache hit rate 低於 60% 表示 caching policy 需要調整；GPU 利用率低於 40% 表示可以加更多 concurrent user 或縮小節點規模。

行動點：從今天開始止血

不要等到 infra 成本爆表才想辦法。現在做三件事：

第一，審計你當前的 GPU 使用率。登到雲端 console，看過去一個月的 GPU idle time 和 peak/off-peak ratio。如果 idle 超過 30%，你已經在燒錢。

第二，跑一個 POC。用 Mesh-LLM 的 GitHub repo 範例，在兩台租來的 RTX 3090 上跑一次 distributed inference。對比 latency 和 cost，數據會說話。

第三，重新設計推理 pipeline。把 LMCache 整合進你的服務，特別是長對話場景。OpenAI API 雖然方便，但長期來看 self-host + Mesh-LLM + LMCache 的成本優勢只會愈來愈大。

香港創業生態從來不缺人才和想法，缺的是用有限資源打出超額回報的能力。Infra 省下來的每一分錢，都應該投入到 product 和 user growth 上。Mesh-LLM 和 LMCache 不是萬能藥，但對於資源有限的團隊，它們是目前性價比最高的答案。