朋友最近問我最多的問題基本都繞不開“怎么在免費的云環(huán)境里跑起一個大模型推理服務”。Colab、vLLM、Ngrok這三個詞放在一起剛好能拼出一套完整的方案Colab 給你一張云端的計算卡vLLM 把模型變成標準化的 OpenAI 兼容 APINgrok 再把本地監(jiān)聽端口映射到公網讓你自己的聊天機器人、電報機器人、內部工具都能直接調這個服務。先回答一個很多人糾結的問題Colab 能直接運行 Python 代碼嗎能而且它本質就是一個托管的 Jupyter Notebook 環(huán)境右上角選個 GPU 運行時就能跑絕大部分 Python 項目。真正值錢的不是“能跑代碼”而是它免費額度里附帶的 Tesla T4 15GB 顯存這對 7B、8B 級別的開源模型來說是夠用的。問題在于Colab 的進程默認只對你自己可見其他人訪問不了你啟動的端口所以需要 Ngrok 這類內網穿透工具把端口暴露出去。很多人卡在這一環(huán)要么不會配 token要么隧道起了但服務沒綁定對端口導致模型跑半天卻調不通。這篇內容是我自己反復跑過的完整流程從選哪個 GPU、裝什么版本的 vLLM、加載哪種模型到 Ngrok 怎么配置域名、怎么避免連接老化全程踩坑實錄。適合這幾類人想在 Colab 上臨時部署 DeepSeek、Qwen 這類開源模型給外部調用的開發(fā)者或者在本地跑不動大模型、想白嫖云端 GPU 做試驗的玩家也包括想理解 vLLM 部署原理、Ngrok 隧道機制的同學。不管你是第一次接觸 LLM 部署還是已經用過 Ollama 想換更專業(yè)的推理引擎這篇都能直接抄作業(yè)。1. 整體架構與方案選型邏輯1.1 三件套的分工計算、推理、連接在拆步驟之前先理清這套架構為什么這么組合。Colab 只負責“提供計算資源”它本身不關心你跑的是 vLLM 還是別的什么框架。vLLM 的作用是把模型文件加載進顯存處理并發(fā)請求、KV Cache 管理、連續(xù)批處理這些底層邏輯然后暴露出一個標準的 HTTP 接口通常是http://localhost:8000/v1/chat/completions這個接口協(xié)議和 OpenAI 完全一致。Ngrok 則是在另一個維度工作它建立一個從公網臨時域名到本地端口的隧道外部請求經過 Ngrok 的服務器轉發(fā)到你的 Colab 實例再進入 vLLM 的服務進程。把三者分開看每個都不復雜但組合起來會有很多暗坑。比如 Colab 是一個臨時環(huán)境運行超過 12 小時或者斷線就會銷毀內部文件這意味著你每次都要重裝 vLLM、重新下載模型這點必須提前接受。再比如 vLLM 默認監(jiān)聽0.0.0.0:8000但 Colab 分配給你的 IP 是內網地址外網根本路由不到Ngrok 解決的就是這個“不可達”問題。這里面最容易被忽略的是端口綁定關系。Ngrok 隧道默認把公網流量轉發(fā)到你本地的某一個端口你在 Colab 上啟動 vLLM 時如果指定了--port 8001那 Ngrok 也要對應填8001不是默認的 8000。我見過太多人 Ngrok 顯示 online但訪問時收到 502排查半天發(fā)現端口對不上。這種基礎環(huán)節(jié)出錯最浪費感情一會兒實操部分我會刻意把端口配置寫得非常明確。1.2 為什么推理引擎選 vLLM而不是 Ollama、LM Studio 或 SGLang如果你只是在本地電腦上想快速體驗模型對話能力選 Ollama 或 LM Studio 沒有任何問題它們勝在開箱即用一條命令就能把模型拉下來跑。但 Ollama 在并發(fā)性能和顯存管理上跟專業(yè)推理引擎差距很明顯。vLLM 的核心賣點是 PagedAttention這個機制借鑒了操作系統(tǒng)虛擬內存的分頁思想把 KV Cache 切分成固定大小的塊按需分配避免顯存碎片化。這意味著同樣的顯存vLLM 能承載更大的并發(fā)和更長的上下文這在真實業(yè)務場景里非常關鍵。SGLang 跟 vLLM 是同一梯隊它在自動并行和結構化生成上有自己的優(yōu)勢但社區(qū)生態(tài)和兼容性目前還是 vLLM 更成熟尤其是 OpenAI 兼容接口的完整度vLLM 幾乎做到了標準的程度。至于 LM Studio它更適合 Windows 本機的 GUI 使用場景跑大模型完全靠本機顯卡跟云端方案屬于兩個賽道。所以在 Colab 這個資源受限的環(huán)境里vLLM 的顯存利用率和吞吐性能是能跑通 7B 級別模型的關鍵這也是我選它的核心原因。注意如果你是純新手第一次做這類項目建議先在本地把 vLLM 官方文檔里的 Quickstart 跑通再進入 Colab 環(huán)境。否則你會分不清問題是出在模型參數配置還是云環(huán)境的網絡鏈路。2. Colab 環(huán)境準備與基礎設施配置2.1 選擇 GPU 運行時與硬件確認進入 Colab 之后第一步不是急著寫代碼而是確認自己拿到的是哪個 GPU。點擊右上角的“代碼執(zhí)行程序” - “更改運行時類型”硬件加速器選擇“T4 GPU”。免費用戶大概率分到 Tesla T4顯存 16GB實際可用約 15GB這對 7B 模型在 4bit 量化或者 BF16 精度下是夠的但對 13B 以上的模型就非常吃力了。如果你訂閱了 Colab Pro 而且當天配額允許可能會分到 A100 或 V100這屬于運氣加成不要指望天天都有。拿到 GPU 后跑一行!nvidia-smi重點看兩個信息驅動版本支持的 CUDA 版本以及當前顯存占用。2025 年這個時間點vLLM 新版對 CUDA 12.8 的支持已經相當成熟如果你在 Colab 里看到的是 CUDA 12.8直接裝最新版 vLLM 沒毛病。如果跑出來的結果顯示 CUDA 版本偏老也不用慌pip 安裝 vLLM 時會自動帶編譯好的 CUDA 依賴你的運行環(huán)境只要驅動夠新就行通常 Colab 不會在這塊卡你。有一個細節(jié)值得留意Colab 免費版會不定期回收長時運行的會話尤其是在你離開頁面太長時間后。所以我一般會先在本地把模型 id、端口配置、Ngrok authtoken 這些全部確定好進 Colab 后快速一次性執(zhí)行完避免中途斷線導致前功盡棄。2.2 安裝 vLLM 與版本兼容策略安裝 vLLM 有兩種思路直接用 pip 安裝或者用 Docker 拉取官方鏡像。Colab 里最省事的是 pip因為 Docker 需要嵌套虛擬化而 Colab 本身不具備 Docker daemon雖然可以用一些技巧繞過去但完全沒必要給自己增加復雜度。直接執(zhí)行!pip install -U vllm這里有個版本選擇的教訓。如果你采用的是 Colab 臨時環(huán)境裝最新版通常是正確的因為 vLLM 每個版本都會修復一些顯存分配或 FlashAttention 的兼容問題。但如果你是想在本地 Ubuntu 服務器上部署我反而建議安裝穩(wěn)定的固定版本比如vLLM0.8.x系列不要追新。用官方 Docker 鏡像也是一種可靠方案比如拉取vllm/vllm-openai:v0.27.1然后通過docker run --gpus all -p 8000:8000啟動服務這種方法勝在環(huán)境隔離、依賴干凈適合要在生產機器上長期跑的場景。不過本篇文章聚焦 Colab所以后面都以 pip 安裝舉例。pip 安裝 vLLM 會自動安裝torch和transformers全家桶這個過程會比較漫長通常在 5 到 10 分鐘。Colab 默認的磁盤空間大約有 78GB裝完這些依賴后還剩不少但如果還要下載大模型就得精打細算。比如一個 7B 模型在 BF16 精度下大約 15GB4bit 量化版約 4 到 5GB下載和緩存都需要空間。我的建議是模型文件優(yōu)先放在/content下這是 Colab 實例的主目錄讀取速度最快不要塞到掛載的 Google Drive 里因為 Drive 的 IO 延遲高加載模型的時候會明顯變慢白白增加啟動時間。2.3 除了 Colab 還有什么免費云計算可用如果你覺得 Colab 的 GPU 配額不夠用或者會話被回收得太頻繁還有一些替代方案值得知道。Kaggle 每周會送 30 小時的 GPU 使用時長可以切換到 P100 顯卡體驗比 T4 上了一個臺階Google AI Studio 的 Gemini API 免費額度適合直接調閉源模型不適合跑開源模型容器Modal 提供按秒計費的模式對新用戶有一定免費額度適合跑短時任務Lightning.ai 和 Paperspace 也提供類似的免費 GPU 試用。不過這些平臺的免費額度和權限政策經常變我的核心建議是如果只是做技術驗證Colab 足夠了不要為了那點免費額度在不同平臺間反復橫跳學習成本和遷移成本遠高于 GPU 性能的差異。3 vLLM 推理服務部署實操3.1 用 vllm serve 命令啟動 OpenAI 兼容 API安裝完成后最關鍵的一步就是啟動服務。這里我強烈推薦用vllm serve這個子命令而不是直接寫 Python 腳本調用LLM類跑一次性推理。因為serve會啟動一個完整的異步服務天然支持多用戶并發(fā)請求而且暴露出來的接口就是 OpenAI 的/v1/chat/completions、/v1/models等標準端點后面接什么應用都對得上?；A啟動命令長這樣!nohup python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --dtype bfloat16 \ --port 8000 \ --host 0.0.0.0 vllm.log 21 這里的參數每一個都有說法。--max-model-len是最關鍵的它直接決定 KV Cache 能分配多大。如果你保持默認值比如 Qwen2.5-7B 默認支持的上下文長度可能是 32768 甚至更高在 T4 上絕對爆顯存。把它限制到 8192 意味著模型最多能處理 8K token 的上下文對于大多數演示場景完全夠用同時顯存占用會大幅下降。--gpu-memory-utilization 0.85表示 vLLM 最多使用 85% 的顯存預留一部分給 CUDA context 和臨時變量防止推理過程中因為內存碎片導致 OOM。我推薦從 0.85 起步如果模型很小可以慢慢往上調到 0.92但不要一次拉滿。--dtype bfloat16指的是模型權重用 BF16 精度加載這種精度在大模型推理里幾乎成為標配因為它的指數范圍和訓練時的數值分布更匹配不容易出現數值溢出。啟動之后怎么確認服務跑起來了執(zhí)行!cat vllm.log如果日志末尾出現Application startup complete或類似字樣說明服務已經正常監(jiān)聽。然后用curl做一次最小驗證!curl http://localhost:8000/v1/models返回一個 JSON里面有模型名稱列表就說明 API 通了。提醒nohup和是把進程放到后臺的關鍵。在 Colab 里如果不這樣寫前臺進程會一直占住單元格后面的 Ngrok 就沒辦法啟動。日志重定向到vllm.log還有一個額外好處出錯時不用靠猜直接看日志定位效率高得多。3.2 在 Colab 上部署 DeepSeek 系列模型的參數調整很多人關心 vLLM 部署 DeepSeek 的具體細節(jié)。需要注意一個前提DeepSeek-R1 的 671B 原始版本不可能在 T4 上跑別抱幻想。能跑的是 DeepSeek-R1-Distill-Qwen-7B 或 DeepSeek-R1-Distill-Llama-8B 這類蒸餾版本。部署命令跟上面基本類似但有幾個參數要根據 DeepSeek 模型特性調整!nohup python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --trust-remote-code \ --kv-cache-dtype fp8_e5m2 \ --port 8000 vllm.log 21 --trust-remote-code是很實用的參數因為不少 Hugging Face 模型的代碼文件不是標準實現需要執(zhí)行遠程代碼才能正確加載。出于安全考慮使用這個參數前建議手動確認模型來源可靠。DeepSeek 官方倉庫一般沒問題但最好都加上這個參數否則加載過程中經常報ImportError卡在權重轉換階段。--kv-cache-dtype fp8_e5m2是我實測下來對顯存優(yōu)化比較明顯的參數。它把 KV Cache 的存儲精度降到 FP8雖然會帶來一點點精度損失但在 4K 這種短上下文場景下輸出質量幾乎感覺不到差異顯存卻能省下一大塊。這個技巧在顯存捉襟見肘的 T4 上意義很大能讓你從“裝不下”變成“跑得動”。另外要特別強調DeepSeek 模型的 system prompt 和 OpenAI 的推理模型類似建議把 reasoning 模式相關的提示詞寫清楚否則模型在推理鏈上不會好好利用自己蒸餾得來的先驗能力。這個雖然屬于工程調優(yōu)范疇但在實際調用時感知非常明顯同一句問題加了合適的 system prompt回答質量和格式完全不一樣。3.3 擴展加載 Embedding 模型配合 RAG 使用聊天模型只是 vLLM 能力的一半它還能加載 Embedding 模型用來做向量化這在 RAG 場景里太關鍵了。假設你想部署Qwen/Qwen3-Embedding-0.6B這個模型在 vLLM 0.27.1 版本或更新的版本里只需要加上--task embedding參數!nohup python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-Embedding-0.6B \ --task embedding \ --max-model-len 4096 \ --port 8000 vllm_embedding.log 21 啟動后調用/v1/embeddings端點傳入文本就能拿到向量。這種做法的好處是你不用額外維護一套 FastText 或 sentence-transformers 服務煉丹爐直接一把梭API 風格也跟 OpenAI 的一致下游接入非常順滑。我試過用這個 embedding 服務搭配一個簡單的本地知識庫檢索再用前面 Qwen 聊天模型做生成整個流程在 Colab 上能跑通響應速度還行。不過要注意vLLM 同時只支持加載一個模型聊天模型和 Embedding 模型不能共存在一個服務進程里。如果你兩個都想用就得啟動兩個服務進程占用兩個端口比如 8000 給 chat8001 給 embedding然后分別給它們開兩條 Ngrok 隧道。這樣會消耗更多顯存在 15GB 的 T4 上很勉強。實際項目里我更建議只保留聊天模型Embedding 用別的低成本服務解決比如純 CPU 跑一個 0.6B 的 embedding 模型完全夠用。4 Ngrok 內網穿透實戰(zhàn)4.1 Ngrok 的工作原理與準備事項模型 API 在localhost:8000上跑著外部訪問不到接下來就輪到 Ngrok。這個工具的原理非常直接你在本地安裝一個 Ngrok 客戶端它會主動連上 Ngrok 的云服務器同時分配給你一個臨時公網域名任何對這個域名的 HTTP 請求都會被云服務器轉發(fā)到你的本地端口。整個過程不需要你擁有公網 IP不需要路由器配置端口映射這就是內網穿透的核心價值。Ngrok 上手前需要準備兩樣東西一個是賬號一個是 authtoken。訪問 Ngrok 官網注冊賬號后在 dashboard 里能找到自己的 authtoken一段類似2XXXXX的字符串。這個 token 是用來標識你的身份也決定了你能創(chuàng)建幾條隧道以及自定義域名。免費用戶的域名是隨機生成的每次重啟隧道都會變這一點要提前有心理準備別指望域名能固定下來。在 Colab 里安裝 Ngrok 很簡單用 pip 就能搞定!pip install ngrok新版客戶端支持直接通過 Python 綁定運行配 token 的命令是!ngrok config add-authtoken 你的authtoken這一步沒問題的話后面建隧道就只是一個命令行參數的事。4.2 建隧道的完整步驟與端口綁定細節(jié)現在進入最核心的一步。假設你的 vLLM 已經監(jiān)聽在端口 8000執(zhí)行!nohup ngrok http 8000 --logstdout ngrok.log 21 如果用的是新版 Ngrok這個命令會異步啟動一個隧道并且把日志輸出到ngrok.log。查看日志確認隧道狀態(tài)!tail -20 ngrok.log如果看到類似Session Status: online日志里會出現一個Public URL一般長這樣https://xxxx-free.ngrok-free.app。這就是你的模型 API 公網入口。一個很容易踩的坑是如果 vLLM 指定了--port 8001這里就必須改成ngrok http 8001。邏輯很簡單但人在忙的時候真的會忽略。另一個點Ngrok 免費版在無流量時會休眠隧道如果調用方隔了很久才發(fā)下一次請求第一條響應往往要等 20 到 30 秒的喚醒時間。這不是 vLLM 性能問題不理解這個機制的人很容易誤判為服務卡死。拿到公網 URL 后測試一次完整的 API 請求。用 Python 寫個最小客戶端試試import requests url https://xxxx-free.ngrok-free.app/v1/chat/completions payload { model: Qwen/Qwen2.5-7B-Instruct, messages: [ {role: user, content: 你好簡單介紹一下你自己} ], max_tokens: 512, temperature: 0.7 } resp requests.post(url, jsonpayload, timeout300) print(resp.json()[choices][0][message][content])如果你是在本地電腦跑這個 Python 腳本而 Ngrok 隧道在 Colab 上那么請求會經過本機 - Ngrok 云服務器 - Colab 的 Ngrok 客戶端 - 本地端口 8000 這條完整鏈路。串起來那一刻你會意識到這三個工具確實形成了一條通達公網的推理管線。4.3 鑒權與訪問控制建議Ngrok 把服務暴露到了公網這就意味著任何拿到 URL 的人都能調你的模型。如果你用的模型沒有鑒權機制別人就能白嫖你的算力更糟糕的是如果模型內容不規(guī)范可能被濫用。所以一定要在路由層加上一道訪問限制。有幾條務實的處理方案Ngrok 本身支持 Basic Auth創(chuàng)建隧道時可以用--basic-auth 用戶名:密碼加上一道 HTTP Basic 認證大部分 HTTP 客戶端都支持這種認證方式接入成本很低。vLLM 0.7 及以上版本支持--api-key參數啟用后所有請求必須帶Authorization: Bearer api-key這幾乎是生產環(huán)境的標準做法。在應用層做一個 Gateway只放行特定來源 IP但這在 Colab 這種動態(tài) IP 環(huán)境下不太好維護一般不建議硬做。我自己的習慣是 vLLM 和 Ngrok 兩層認證都開vLLM 層用 API Key 擋住裸調Ngrok 層再套個 Basic Auth雙保險。這樣即使某層配置失誤依然有一層兜底。別看這些配置很簡單真等別人把服務調爆了再補就來不及了。重要任何面向公網的大模型服務一定要想清楚內容合規(guī)和資源濫用的問題別讓一臺免費 GPU 變成公共的免費調用資源。5 常見問題與排查實錄5.1 顯存不足與 OOM 的多種表現在 Colab 上跑 vLLM遇見最多的問題就是顯存不足但它的表現方式不止一種。最典型的是啟動階段直接報CUDA out of memory或torch.OutOfMemoryError這種一般就是--max-model-len設得太長或者模型本身太大。處理辦法很簡單調低上下文長度、切換到量化版模型、或者換更小的蒸餾模型。還有一種隱蔽的 OOM發(fā)生在服務運行一段時間后伴隨長上下文請求或者高并發(fā)訪問。vLLM 的日志會出現Could not find an available block之類的描述這不是模型權重裝不下而是 KV Cache 的可用塊不夠了。遇到這種情況可以用--max-num-seqs 8限制并發(fā)序列數量或者降低--gpu-memory-utilization的上限讓 KV Cache 有更多余量。另外千萬不要同時開多個推理服務進程除非你非常確定顯存夠用。我在 T4 上試過同時跑一個 7B chat 模型和一個 0.6B embedding 模型結果聊天請求稍微密集一點另一個服務的進程就哭了日志全是 GPU 資源沖突。Colab 的 GPU 是一次性分配的資源沒有顯存熱遷移的可能。5.2 vLLM 安裝與模型加載的版本兼容問題很多新手在裝 vLLM 時會踩到一個坑flash_attn編譯失敗。這通常是 CUDA 版本和 PyTorch 版本不匹配造成的。vLLM 從 0.6 系列開始對 FlashAttention 的依賴有所調整較新版本甚至不在啟動時強制要求 flash-attn。遇到編譯報錯可以嘗試先升級 PyTorch 到新版本或者直接重裝當前最新版本的 vLLM。另一個高頻報錯是加載模型時出現tokenizer_config.json not found或trust_remote_codeTrue required。前者一般是模型 id 寫錯去 Hugging Face 倉庫確認一下精確名稱注意大小寫和下劃線后者就老老實實加上--trust-remote-code。這里補一個關于 Windows 環(huán)境的問題經常有人問 vLLM 能不能直接在 Windows 上跑。vLLM 官方對 Windows 的 GPU 支持是有的但歷史版本限制很多只支持 CPU 或者部分算子走純 Python 路徑?，F在社區(qū)版雖然有所改進但建議如果你真的要在 Windows 上做生產部署優(yōu)先用 WSL2 或者 Docker Desktop 跑官方鏡像別直接在批處理環(huán)境里硬剛。在 Colab 上跑這些問題都天然被規(guī)避了因為 Colab 的底層 Linux 環(huán)境跟 vLLM 的編譯匹配度非常高。5.3 Ngrok 隧道連不上、連接老化與性能問題Ngrok 報Failed to connect首先是檢查本地 vLLM 進程是否還活著。跑!ps aux | grep vllm確認一下。如果 Colab 會話因為長時間斷線被回收Ngrok 自然也沒法連到任何端口。這類問題在免費版 Colab 上非常常見我建議每 30 分鐘對前端頁面做一次心跳操作或者用腳本保持會話活躍但這只是緩解改變不了根本的會話生命周期。連接老化也很典型。Ngrok 免費版的隧道如果長時間沒有任何請求會自動進入休眠狀態(tài)等到下一個請求到來時重新建立連接時間差通常在 10 到 30 秒。如果你在自動化場景里調用第一次請求超時幾乎是可以預見的。解決思路有兩個一是寫一個健康檢查腳本每 5 分鐘訪問一次隧道的/v1/models端點保持隧道活躍二是接受這個現象在客戶端設置足夠大的超時時間并自動重試一次。相比 Ngrok還有一個思路是部署cloudflared隧道它免費且不限制流量但配置方式跟 Ngrok 略有不同。不是非要用 Ngrok我這里選它是因為接入簡單、文檔多、出問題容易查到答案。本質上它們解決的是同一類問題你完全可以根據自己的偏好選擇。5.4 性能調優(yōu)如何讓響應更快、并發(fā)更高Colab 上跑 vLLM 沒法跟真機 GPU 比但通過參數調優(yōu)仍然能擠出不少性能空間。最有效的方法是開啟--enable-prefix-caching這個參數可以緩存公共前綴的 KV對多輪對話和同主題批量請求的收益非常明顯。另外把--max-model-len壓縮到業(yè)務實際需要的值能減少 KV Cache 的預留量為并發(fā)請求騰出顯存。如果你需要在并發(fā)場景下使用--max-num-seqs和--max-num-batched-tokens這兩個參數值得仔細調。前者控制一次最多處理多少序列后者控制一個 batch 里最多包含多少 token。在 T4 上我習慣把max-num-seqs設為 16max-num-batched-tokens設為 4096 左右再往上就會經常出現Pool of blocks不足的告警。記住一個原則在沒有監(jiān)控數據的情況下寧可保守不要激進服務穩(wěn)定比瞬時吞吐重要得多。6 經驗總結這套方案還能怎么玩如果你完整跑通了上面的流程恭喜你已經在 Colab 上擁有了一套屬于自己的大模型推理服務。我自己在實測這個方案時最大的體會是真正耗時間的不是模型部署而是理解參數背后的顯存空間邏輯以及踩完那些端口綁定、會話存活和鑒權控制的坑。這套方案完全可以擴展成你的個人 API 網關上午部署一個 Qwen 聊天模型下午換成 DeepSeek 蒸餾模型晚上再加載一個 embedding 模型做知識庫檢索只要顯存和會話還在它就是你的移動推理工作站。最后分享一個我常用的組合套路Colab 跑 vLLM 開兩個賬戶一個始終掛著 Ngrok 隧道作為對外服務另一個用來做開發(fā)調試和跑測試腳本。這樣即使其中一個會話被回收也不會打斷你做試驗的節(jié)奏。模型的下載地址、Hugging Face 的 token、Ngrok 的 authtoken我把它們全都寫在 Colab 的 secret 管理器里每次新建會話后一鍵執(zhí)行一段初始化腳本五分鐘內就能把一個帶公網 API 的推理服務重新拉起來。這已經是我目前測試新模型、接機器人、做 demo 的最快路徑了。