10.8MB 打贏一場仗：Inference Gateway 如何用 Rust 改寫 LLM 部署遊戲規則

LLM 嘅 infra 世界有一個好奇怪嘅現象：大家用緊嘅唔係幾百 MB 嘅 Python 框架，就係要拉成條 Kubernetes 鍊先用到嘅 API gateway。但你有冇諗過，一個得 10.8MB 嘅靜態 binary，其實可以做晒所有嘢，仲要做得更好？

Inference Gateway 就係呢個問題嘅答案。一個開源、cloud-native、用 Rust 由頭寫過嘅 LLM proxy server，binary size 細到可以塞入一隻手指，但功能完整到可以 unified 晒 OpenAI、Anthropic、Google、Groq、Cohere、DeepSeek、Ollama 等十幾個 provider，仲內建 MCP（Model Context Protocol）自動工具整合、streaming response、OpenTelemetry 監控、Kubernetes 原生支援。更重要嘅係，佢顛覆咗我哋對「AI infrastructure 一定要好重」嘅假設。

10.8MB 嘅戰爭機器：點解 size 咁重要？

先搞清楚一個命題：喺 LLM 嘅世界，binary size 關咩事？LLM 本身已經幾百 GB，何必 care 一個 gateway 嘅 size？

答案係：部署邊界嘅自由度。

傳統嘅 LLM gateway 解決方案，例如由 Python 框架改裝嗰啲 proxy，光係 runtime dependencies 已經 200MB 起跳。你仲要裝 Python interpreter、pip packages、做 virtual environment 管理——呢啲嘢喺數據中心做冇問題，但當你要：

• 喺 edge device（Raspberry Pi、Jetson Nano、邊緣伺服器）行 LLM agent
• 喺 CI/CD pipeline 入面做 AI-powered 自動化
• 喺 air-gapped 環境做 private deployment
• 做 sidecar container 塞入已有嘅輕量 service mesh

每次多 200MB overhead，就係一個部署機會嘅消失。

10.8MB 嘅 statically linked binary 意味住乜？意味住你可以 curl -fsSL install.sh | bash 就搞掂，唔使 dependency resolution、唔使 runtime installation、唔使同 Python 版本抗爭。CGO 唔開、pure Go（或者 Rust）嘅 zero-dependency binary，即係連 Alpine Linux 嘅 libc 都唔需要——distroless 或者 scratch container 直接行得。

呢個唔係技術炫耀，而係部署哲學嘅根本轉變：當 infra component 細到可以當做一個普通 Unix 工具咁用，你嘅架構設計空間會幾何級數咁放大。

MCP 自動整合：由「寫 glue code」變「set env var」

講完 binary size，講真正 killer feature：MCP 整合。

傳統嘅 LLM tool-use 經驗係點？client side 要自己管理 function definitions、自己做 tool call execution loop、自己處理同多個工具 server 嘅連接。每一層都係手寫 glue code，每一個 provider 嘅 tool format 都可能有少少唔同。你做一個簡單嘅「search + filesystem」agent，已經要寫幾百行 boilerplate。

Inference Gateway 嘅做法完全唔同：架一個 middleware layer 喺 proxy 同 provider 之間，自動 handle tool injection 同 execution。

實際係點運作？你只需要開 MCP_ENABLE=true，然後指住幾個 MCP server endpoints：

export MCP_ENABLE=true
export MCP_SERVERS="http://filesystem-server:3001/mcp,http://search-server:3002/mcp"

之後任何 request 入到 gateway，MCP middleware 會自動：

1. 向 MCP server discovery 可用 tools
2. 將 tools 以 OpenAI-compatible function calling format 注入 request
3. 當 LLM 決定要 call tool，gateway 幫你 forward 去對應 server
4. 將 tool response 塞返入 conversation loop

Client 完全唔知 MCP 嘅存在。你嘅前端 app、你嘅 CLI tool、甚至只係一個普通 curl，全部都照用標準 chat completions API，唔改任何 code，就會突然有 tool access。

呢個 pattern 嘅革命性在於：佢將「工具整合」嘅責任由應用層搬到基礎設施層。唔使每個 client 都自己實做 tool management，gateway 做一次就搞掂。你加一個新嘅 MCP server（例如 database connector、CRM API adapter），所有經過 gateway 嘅 LLM 會即刻自動用到——zero config 喺 client side。

Edge-first 架構：橫向 scaling 嘅真正自由

Inference Gateway 嘅輕量仲帶嚟第二個重大優勢：真正嘅 horizontal scaling。

傳統嘅 AI proxy 成日綁死喺某個 provider 或某個 protocol，scaling 嘅時候你要考慮嘅唔只係 traffic，仲有 proxy 本身嘅 weight。一個 200MB 嘅 container image，pull time、startup time、memory footprint 全部都係成本。尤其係用 Kubernetes HPA 做 auto-scaling 嗰陣，cold start latency 會直接影響到你嘅 tail latency。

10.8MB 嘅 binary 加上 distroless container，意味住：

• Startup time 係毫秒級——Kubernetes liveness probe 一著就得
• Memory footprint 極低——同一個 node 可以行更多 gateway replicas
• Image pull time 係秒級——rolling update 同 scale-out 唔會 bottleneck
• Network bandwidth 節省——特別係喺 edge location 或者 bandwidth-constrained 環境

仲有就係 provider failover。Inference Gateway 嘅 model routing 係 implicit 嘅——你指定 openai/gpt-4o 或者 groq/llama-3-8b，gateway 會自動 infer provider 同 route。呢個 design 令你可以做到 hybrid deployment：主要用 OpenAI，backup 用 Ollama local model，完全 transparent 俾 client。

對香港開發者嘅啟示

講到呢度你可能會問：關我咩事？我又唔係做 AI infra。

但事實係，呢個架構思路對任何做 software 嘅人都適用：

第一，慎選你的 stack weight。當你決定用一個 framework 或者工具之前，諗清楚佢嘅 deploy-time cost。Python 嘅 richness 係好，但如果你嘅 product 要行 edge、要 embedded、要 cross-platform，pure Rust 或者 Go 嘅 statically linked binary 可能係更好嘅選擇。

第二，MCP 唔只係 protocol，係標準化工具整合嘅第一步。如果你嘅 product 有用 LLM，諗下點樣用 MCP 嚟抽象化 tool integration。唔好再每個 client 獨立寫 function calling 嘅 wrapper，而係用 gateway pattern 集中處理。

第三，Size 係一種架構約束，而約束會逼出好設計。Inference Gateway 得 10.8MB 唔係因為佢偷工減料，而係因為佢哋由第一日就決定要 keep it lean——呢個 constraint 逼佢哋做更好嘅 modular design、更乾淨嘅 dependency management、更有效率嘅 code。

下次你開一個新 project，試下 set 一個 binary size budget。你可能會發現，原來好多嘢你以為需要嘅 dependencies，根本唔需要。而當你冇咗嗰啲包袱，你能夠去到嘅地方，會遠超你想像。