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