自托管AI這幾年從一個(gè)極客圈子的玩具慢慢變成了很多團(tuán)隊(duì)和個(gè)人認(rèn)真考慮的方向。說(shuō)白了就是把自己用的模型、推理服務(wù)、數(shù)據(jù)管道全部部署在自己的服務(wù)器或者本地電腦上而不是去調(diào)云端API。前陣子我把團(tuán)隊(duì)內(nèi)部的知識(shí)庫(kù)問(wèn)答、日常代碼輔助、還有一些自動(dòng)化腳本里的文本處理全部遷到了自托管方案上跑整體體驗(yàn)下來(lái)我覺得這件事值得更多人嘗試。這篇文章不會(huì)勸你馬上拋棄所有云端服務(wù)而是想跟你聊聊自托管AI到底解決了什么問(wèn)題、需要什么硬件和軟件、怎么一步步搭起來(lái)以及我踩過(guò)的一些坑。適合想徹底掌控?cái)?shù)據(jù)、長(zhǎng)期算賬發(fā)現(xiàn)API太貴、或者單純想深入理解大模型工作原理的朋友。如果你只是偶爾想聊天玩一下那可能確實(shí)沒必要折騰但只要你跟模型打交道夠頻繁自托管的性價(jià)比和自由度就會(huì)開始碾壓云端API。1. 自托管AI到底解決了什么問(wèn)題1.1 云端API模式的隱性成本很多人一開始用大模型都是走云端API注冊(cè)個(gè)key、充值、調(diào)用確實(shí)五分鐘就上手了。但用久了你會(huì)發(fā)現(xiàn)成本根本不是賬面上那個(gè)“每百萬(wàn)token多少錢”那么簡(jiǎn)單。首先是費(fèi)用隨著調(diào)用量線性膨脹內(nèi)部測(cè)試還好一上生產(chǎn)每天幾萬(wàn)次調(diào)用月底賬單能嚇你一跳。其次是數(shù)據(jù)安全凡是敏感數(shù)據(jù)過(guò)API不管對(duì)方怎么承諾不留存心理上那道坎過(guò)不去很多商業(yè)項(xiàng)目合規(guī)上也不允許。還有一個(gè)很多人忽略的問(wèn)題云端API的模型更新是不受你控制的。今天用的模型版本明天可能就下線了或者廠商悄悄換了一個(gè)行為不一樣的替代版本你都不知道。這對(duì)做自動(dòng)化、做穩(wěn)定業(yè)務(wù)的人來(lái)說(shuō)非常致命因?yàn)槟愕膒ipeline可能依賴某個(gè)模型特定的輸出格式或行為傾向。換版本之后輸出變了下游任務(wù)結(jié)果跟著崩排查起來(lái)極其痛苦。1.2 自托管的真正價(jià)值成本拐點(diǎn)、數(shù)據(jù)主權(quán)與模型自由度自托管AI最大的價(jià)值我歸納成三點(diǎn)。第一是成本拐點(diǎn)。如果你的調(diào)用量穩(wěn)定且長(zhǎng)期自托管幾乎是必然選擇。本地跑一個(gè)7B模型一臺(tái)消費(fèi)級(jí)顯卡的機(jī)器就夠了電力成本遠(yuǎn)低于同樣調(diào)用量的API費(fèi)用。即使算上機(jī)器折舊、運(yùn)維時(shí)間只要跑夠一個(gè)月以上往往就比API劃算。我之前粗略算過(guò)一個(gè)每天處理幾十萬(wàn)token的任務(wù)用云端API一個(gè)月可能要幾千塊自托管用一張二手3090跑量化模型電費(fèi)加折舊一個(gè)月可能就幾百塊。第二是數(shù)據(jù)主權(quán)。模型、數(shù)據(jù)、推理過(guò)程都在自己機(jī)器上出門斷網(wǎng)也能跑。不用考慮供應(yīng)商審查、數(shù)據(jù)留存策略、接口限流這些事突然變得完全由你自己決定。這種掌控感做技術(shù)的人應(yīng)該都能理解。第三是模型自由度。你可以隨便換模型從Llama到Qwen到Mistral再到各種微調(diào)版本想換就換想跑幾個(gè)跑幾個(gè)。云端API只能選廠商提供的模型而且很多開源模型在云端根本沒有托管。更關(guān)鍵的是自托管之后你可以加載自己的微調(diào)模型、接自己的嵌入模型、按自己的需求定制推理參數(shù)這是API模式完全做不到的。1.3 適合與不適合的場(chǎng)景自托管不是銀彈我還得把邊界說(shuō)清楚。適合的場(chǎng)景首先是隱私敏感或合規(guī)要求高的業(yè)務(wù)比如醫(yī)療、金融、企業(yè)內(nèi)部文檔處理。其次是高頻調(diào)用、批量任務(wù)多的場(chǎng)景自托管邊際成本低跑批處理甚至可以不限速地并發(fā)跑。再次是學(xué)習(xí)與研究場(chǎng)景你想看模型權(quán)重、想看推理中間過(guò)程、想fine-tune只有自托管才能操作。不適合的場(chǎng)景包括一次性小型項(xiàng)目、極低調(diào)用量的個(gè)人嘗鮮、或者對(duì)多模態(tài)能力要求極高而你自己又沒有強(qiáng)力硬件的情況。舉個(gè)例子如果你只是偶爾翻譯幾段文字那自托管反而讓你維護(hù)一套環(huán)境純屬浪費(fèi)。另外本地如果沒有可靠的GPU硬件卻想跑超大模型體驗(yàn)會(huì)很痛苦這種情況用云端API或者云端租GPU實(shí)例反而更合適。2. 搭一套自托管AI需要做哪些準(zhǔn)備2.1 硬件選型與顯存估算方法好多朋友上來(lái)就問(wèn)“需要什么配置”但其實(shí)這個(gè)問(wèn)題要倒過(guò)來(lái)算先想清楚你要跑什么規(guī)模的模型再反推硬件。大模型運(yùn)行時(shí)的顯存占用可以用一個(gè)很粗略但實(shí)用的公式估算模型參數(shù)顯存約等于參數(shù)量乘以每個(gè)參數(shù)占用的字節(jié)數(shù)。以FP16精度為例1B參數(shù)大約占2GB顯存7B參數(shù)就是約14GB13B大約26GB70B則需要140GB。但如果用4bit量化比如GPTQ或AWQ每個(gè)參數(shù)大約只需要0.5-0.6字節(jié)7B模型量化后只需要4-5GB一下子門檻就低了很多。除了模型權(quán)重本身推理時(shí)KV cache也要占顯存它和上下文長(zhǎng)度、并發(fā)數(shù)相關(guān)。長(zhǎng)度4096的上下文、7B模型KV cache一般也就幾個(gè)GB但如果你要跑32K上下文還并發(fā)幾十路請(qǐng)求KV cache會(huì)變成大頭。所以選硬件時(shí)要多留30%的余量不能卡著模型權(quán)重大小去配。基于這些估算我給你的建議是只跑7B-14B量化模型一張24GB顯存的顯卡比如RTX 3090/4090就很舒服。要跑34B量化或者多路并發(fā)7B一張48GB的卡比如A6000、L40S或者兩張24GB卡組并行。想跑70B甚至更大預(yù)算充足就上兩張A100/H100預(yù)算有限則考慮CPU內(nèi)存推理方案但性能我勸你別期待太高。沒有GPU的朋友也能用純CPU跑小模型比如7B量化模型在好的CPU上大概每秒能出幾個(gè)token用于異步任務(wù)勉強(qiáng)可以但交互式聊天會(huì)很折磨人。2.2 軟件棧選擇從Ollama到vLLM硬件只是第一步軟件棧決定了你用得痛不痛快。如果你想最快速度跑起來(lái)推薦Ollama。它幾乎把一切封裝好了安裝之后幾條命令就能拉模型、跑交互、暴露API。適合個(gè)人嘗鮮、局域網(wǎng)內(nèi)小范圍使用也適合快速驗(yàn)證一個(gè)模型的效果。它的缺點(diǎn)也很明顯并發(fā)吞吐不如專業(yè)推理服務(wù)對(duì)生產(chǎn)級(jí)高并發(fā)場(chǎng)景支持較弱。如果你的目標(biāo)是長(zhǎng)期服務(wù)化讓多個(gè)應(yīng)用共享模型能力那vLLM是更正確的選擇。vLLM使用PagedAttention顯存利用率高自帶Continuous Batching能極大提升并發(fā)吞吐。部署好后它提供一個(gè)OpenAI兼容的API接口你現(xiàn)有的代碼從調(diào)用OpenAI換成調(diào)用本地地址基本只需要改base_url遷移成本極低。還有一個(gè)選擇是LocalAI或者llama.cpp的server模式適合對(duì)依賴包敏感、想盡量輕量化的場(chǎng)景。另外如果你是做完整應(yīng)用平臺(tái)可以選Dify、FastGPT這類工具它們內(nèi)置了模型接入層、RAG、Agent工作流編排自托管模型可以直接對(duì)接省去很多膠水代碼。2.3 模型獲取與目錄管理模型權(quán)重文件需要通過(guò)模型倉(cāng)庫(kù)下載。Hugging Face是最全的但國(guó)內(nèi)訪問(wèn)不穩(wěn)定這時(shí)候可以用ModelScope或者HF鏡像站。下載模型時(shí)建議用命令行工具Hugging Face的huggingface-cli download或者M(jìn)odelScope的modelscope download都能斷點(diǎn)續(xù)傳。模型文件非常大7B模型動(dòng)輒十幾GB70B更是上百GB。我的習(xí)慣是單獨(dú)準(zhǔn)備一塊數(shù)據(jù)盤專門放模型而且保持目錄結(jié)構(gòu)清晰比如/models/transformers存原始權(quán)重、/models/gguf存GGUF量化版、/models/sentence-transformers存嵌入模型。這樣當(dāng)你要做模型替換、清理磁盤空間時(shí)心里有數(shù)。另外強(qiáng)烈建議下載時(shí)記錄模型的sha256校驗(yàn)值因?yàn)榇笪募螺d偶爾會(huì)損壞跑起來(lái)出現(xiàn)詭異報(bào)錯(cuò)時(shí)先排查是不是文件損壞。3. 從零開始的自托管AI實(shí)操記錄3.1 第一步快速跑通Ollama并部署第一個(gè)模型我先說(shuō)一條最快能感受到“自托管AI”的路徑。以Ubuntu服務(wù)器為例安裝Ollama只需要一行命令curl -fsSL https://ollama.com/install.sh | sh然后拉一個(gè)中文能力不錯(cuò)的模型Qwen2.5系列是我目前最推薦的7B這個(gè)尺寸均衡性很好ollama pull qwen2.5:7b ollama run qwen2.5:7b第一條命令是下載模型下載完以后第二條命令會(huì)進(jìn)入交互式對(duì)話界面你可以直接在終端里跟模型聊天。這時(shí)候你的模型已經(jīng)完全跑在自己的機(jī)器上了沒有任何外部依賴。Ollama同時(shí)也暴露了一個(gè)本地HTTP接口默認(rèn)監(jiān)聽127.0.0.1:11434。你可以用curl驗(yàn)證一下curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句話解釋什么是自托管AI, stream: false }返回JSON里就有模型生成的文本。這里有個(gè)關(guān)鍵點(diǎn)Ollama默認(rèn)只綁定本地回環(huán)地址如果你想在局域網(wǎng)內(nèi)其他設(shè)備使用要修改服務(wù)配置加上OLLAMA_HOST0.0.0.0同時(shí)注意網(wǎng)絡(luò)安全這點(diǎn)我在后面排查章節(jié)會(huì)專門講。3.2 第二步用vLLM啟動(dòng)一個(gè)高并發(fā)推理服務(wù)如果Ollama只是熱身那vLLM才是真正把自托管AI變成基礎(chǔ)設(shè)施的組件。我建議先用conda或venv建一個(gè)干凈的環(huán)境Python版本3.10以上然后安裝pip install vllm啟動(dòng)Qwen2.5-7B模型的推理服務(wù)python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000這里幾個(gè)參數(shù)值得解釋一下。--gpu-memory-utilization 0.9表示允許vLLM使用90%的顯存剩下的留給計(jì)算圖和其他開銷。--max-model-len 8192限制了最大上下文長(zhǎng)度這個(gè)值設(shè)得越大KV cache占用越高能同時(shí)處理的并發(fā)數(shù)就越小需要根據(jù)你的顯存來(lái)權(quán)衡。啟動(dòng)成功后vLLM會(huì)打印類似“Uvicorn running on http://0.0.0.0:8000”的日志服務(wù)就起來(lái)了。驗(yàn)證方式也很簡(jiǎn)單用OpenAI SDK的姿勢(shì)調(diào)用from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好介紹一下你自己}] ) print(response.choices[0].message.content)代碼里唯一的區(qū)別就是base_url換成了本地地址api_key隨便填。這意味著你之前用openai庫(kù)寫的所有調(diào)用代碼幾乎不用改造就能切到自托管服務(wù)這個(gè)兼容性設(shè)計(jì)是我最滿意的點(diǎn)之一。3.3 第三步接入業(yè)務(wù)應(yīng)用并配置Agent協(xié)作跑通了基礎(chǔ)服務(wù)接下來(lái)就是把它用起來(lái)。我有三個(gè)比較推薦的落地方向。第一個(gè)是接入對(duì)話應(yīng)用或者內(nèi)部工具。比如你有一個(gè)團(tuán)隊(duì)內(nèi)部的問(wèn)答機(jī)器人原來(lái)是調(diào)云端API現(xiàn)在只要把接口地址換成本地vLLM地址即可。團(tuán)隊(duì)幾十個(gè)人一起用完全不擔(dān)心限流費(fèi)用幾乎固定為電費(fèi)。第二個(gè)是配合Agent框架做自動(dòng)化。自托管模型因?yàn)椴皇軓S商策略限制特別適合做AI Agent的任務(wù)規(guī)劃、工具調(diào)度。我現(xiàn)在的做法是用n8n或者自寫Python腳本把多個(gè)模型串聯(lián)起來(lái)一個(gè)小模型做意圖識(shí)別一個(gè)大模型做內(nèi)容生成一個(gè)專用模型做實(shí)體抽取。這種“多AI協(xié)作”的模式在云端API下會(huì)很貴但在自托管下可以隨意調(diào)用。第三個(gè)是把自托管模型作為RAG系統(tǒng)的基礎(chǔ)。知識(shí)庫(kù)文檔切片、向量化、召回、重排最后把結(jié)果加上用戶問(wèn)題一起交給本地大模型生成答案。整套鏈路都在內(nèi)網(wǎng)數(shù)據(jù)從來(lái)不出服務(wù)器。對(duì)于文檔敏感的企業(yè)知識(shí)庫(kù)這個(gè)架構(gòu)幾乎是唯一解。這里我特別想說(shuō)一下自托管之后你可以更大膽地試驗(yàn)“多模型多角色”的架構(gòu)。比如某個(gè)流程里讓Qwen負(fù)責(zé)中文理解、讓Llama負(fù)責(zé)英文生成、讓一個(gè)小參數(shù)embedding模型專門做檢索。在API模式下這種做法幾乎不可行因?yàn)閠oken成本疊加太迅速但在本地這些模型共享一臺(tái)GPU調(diào)度起來(lái)毫無(wú)壓力。3.4 性能調(diào)優(yōu)從一秒出幾個(gè)字到穩(wěn)定并發(fā)真正用起來(lái)之后性能調(diào)優(yōu)是繞不開的。我總結(jié)過(guò)幾個(gè)立竿見影的手段。第一是啟用連續(xù)批處理。vLLM默認(rèn)就是Continuous Batching它會(huì)動(dòng)態(tài)地把并發(fā)請(qǐng)求拼批次處理大幅提高GPU利用率。實(shí)測(cè)同一個(gè)7B模型沒有批處理時(shí)單路請(qǐng)求每秒大概20 token并發(fā)10路之后單路會(huì)降到每秒8 token左右但整體吞吐可能是原來(lái)的4-5倍。如果你的應(yīng)用場(chǎng)景是“很多用戶同時(shí)用但每個(gè)請(qǐng)求不急著秒回”這個(gè)特性是神級(jí)優(yōu)化。第二是選擇更高效的量化格式。同一個(gè)模型FP16、GPTQ-4bit、AWQ-4bit、GGUF-Q4_K_M幾者的推理速度差別很大顯存占用也不同。我的建議是追求上限用AWQ追求兼容性用GGUF。但要記住量化會(huì)帶來(lái)一定精度損失如果你做的是代碼生成、數(shù)學(xué)推理這類對(duì)精度敏感的任務(wù)最好保留FP16模型做對(duì)比測(cè)試。第三是調(diào)整并發(fā)和隊(duì)列參數(shù)。vLLM啟動(dòng)時(shí)可以通過(guò)--max-num-seqs限制最大并發(fā)序列數(shù)避免請(qǐng)求過(guò)多時(shí)顯存溢出--max-parallel-loading-workers控制加載速度。這些參數(shù)要根據(jù)顯存和上下文長(zhǎng)度來(lái)做實(shí)驗(yàn)沒有固定的最優(yōu)值。我的經(jīng)驗(yàn)是先設(shè)一個(gè)保守值跑一輪壓力測(cè)試觀察顯存占用率再逐步調(diào)高。還有一個(gè)小技巧如果你的GPU顯存不夠但CPU內(nèi)存很大可以考慮vLLM的--cpu-offload-gb參數(shù)把一部分KV cache卸載到內(nèi)存。速度會(huì)下降但至少任務(wù)能跑起來(lái)適合應(yīng)急場(chǎng)景。4. 常見問(wèn)題與排查技巧實(shí)錄4.1 顯存不足與顯存碎片化最常見的報(bào)錯(cuò)就是“CUDA out of memory”。這里有個(gè)容易忽視的點(diǎn)除了模型權(quán)重PyTorch緩存機(jī)制也會(huì)占用顯存即使你感覺模型不大也可能在第一次請(qǐng)求時(shí)OOM。解決方法是啟動(dòng)前給vLLM設(shè)置--gpu-memory-utilization不要超過(guò)0.85留足緩沖。另外Ollama也支持在服務(wù)環(huán)境變量里設(shè)置OLLAMA_MAX_LOADED_MODELS不要同時(shí)加載太多模型。如果是多卡機(jī)器還要注意任務(wù)是否真的用上了多張卡。跑vLLM時(shí)可以用CUDA_VISIBLE_DEVICES0,1來(lái)指定卡大模型會(huì)用tensor parallel自動(dòng)拆分到多卡。用Ollama則要確認(rèn)它默認(rèn)只用了單卡。4.2 推理速度慢瓶頸可能不在GPU很多人發(fā)現(xiàn)GPU利用率到不了100%先懷疑顯卡不行但實(shí)際上瓶頸往往在別處。第一是CPU解碼輸入token太慢如果prompt很長(zhǎng)prefill階段瓶頸就在CPU的tokenizer處理上建議開啟--tokenizer-processes或者在請(qǐng)求時(shí)做好prompt緩存。第二是磁盤IO太慢模型首次從磁盤加載到顯存如果非常慢后續(xù)請(qǐng)求卻沒問(wèn)題那就是讀取盤的問(wèn)題把模型放到SSD或者內(nèi)存盤上可以明顯改善啟動(dòng)時(shí)間。第三是系統(tǒng)顯存帶寬不匹配量化模型看起來(lái)占用小但可能反而因?yàn)榉戳炕?jì)算導(dǎo)致更慢需要實(shí)際對(duì)比FP16和量化版本的速度再做取舍。4.3 模型下載中斷與損壞下載幾十GB的模型時(shí)網(wǎng)絡(luò)波動(dòng)甚至斷網(wǎng)都可能導(dǎo)致下載失敗。Hugging Face CLI和ModelScope CLI都支持?jǐn)帱c(diǎn)續(xù)傳但前提是你用官方工具而不是瀏覽器直接下載。如果下載之后加載模型報(bào)一些莫名的tensor大小對(duì)不上多半是文件損壞重新下載對(duì)應(yīng)分片就行。我的習(xí)慣是寫一個(gè)簡(jiǎn)單的下載腳本循環(huán)檢查本地文件是否完整、缺失則重試下載這樣跑一晚上不管它都沒問(wèn)題。4.4 磁盤空間與多模型管理自托管模型越多磁盤空間越緊張。7B模型平均14GB13B大概26GB放三五個(gè)模型就上百GB了。我自己會(huì)在項(xiàng)目目錄里寫一個(gè)MODELS.md記錄每個(gè)模型的用途、原始下載地址、量化版本、實(shí)測(cè)顯存占用和速度。這樣半年后再回來(lái)找模型一眼就知道該刪哪個(gè)、該用哪個(gè)。另外不同框架產(chǎn)出的模型目錄結(jié)構(gòu)差異很大transformers格式、GGUF格式、safetensors格式混在一起容易搞混。建議分目錄存儲(chǔ)不要把所有模型放在同一個(gè)目錄里。4.5 服務(wù)暴露與安全加固自托管AI服務(wù)一旦監(jiān)聽在0.0.0.0意味著局域網(wǎng)內(nèi)任何人都能訪問(wèn)你的模型接口。如果機(jī)器有公網(wǎng)IP風(fēng)險(xiǎn)更大。我見過(guò)有人把Ollama暴露到公網(wǎng)結(jié)果被人掃描到以后拿去做免費(fèi)算力挖礦的甚至還有因?yàn)殚_放API被刷爆流量的。我的安全基線是默認(rèn)只綁定127.0.0.1需要局域網(wǎng)訪問(wèn)再改綁定地址。如果必須公網(wǎng)訪問(wèn)放在Nginx或Caddy后面加Basic Auth或者API Key校驗(yàn)并強(qiáng)制啟用HTTPS。vLLM的OpenAI兼容接口沒有內(nèi)置認(rèn)證生產(chǎn)環(huán)境一定要前置一層認(rèn)證網(wǎng)關(guān)。定期檢查日志看是否有陌生IP訪問(wèn)。畢竟自托管意味著責(zé)任也歸你安全防護(hù)不能偷懶。5. 從自托管到更廣闊的AI工程實(shí)踐自托管AI只是第一步一旦你把這套基礎(chǔ)設(shè)施搭建起來(lái)后續(xù)可做的事就多了。比如可以開始做模型微調(diào)。在本地用LoRA微調(diào)一個(gè)小模型讓它學(xué)習(xí)你團(tuán)隊(duì)的術(shù)語(yǔ)、你的寫作風(fēng)格、你的代碼習(xí)慣。微調(diào)完導(dǎo)出的權(quán)重文件就放在自己的服務(wù)器上隨時(shí)可以加載回vLLM里提供服務(wù)。這個(gè)過(guò)程在API模式下根本沒辦法實(shí)現(xiàn)因?yàn)槲⒄{(diào)接口不會(huì)給你開源模型即便給你也不能部署在本地。又比如可以構(gòu)建更完整的AI Agent系統(tǒng)。自托管模型配合函數(shù)調(diào)用、工具調(diào)用、多Agent協(xié)作可以讓一個(gè)Agent負(fù)責(zé)規(guī)劃任務(wù)、另一個(gè)Agent負(fù)責(zé)調(diào)用外部搜索、再一個(gè)Agent負(fù)責(zé)總結(jié)輸出。本地模型的成本優(yōu)勢(shì)讓這種重試次數(shù)多、token消耗大的Agent方案變得可以接受。我在公司內(nèi)部做了一個(gè)自動(dòng)化文檔助手由多個(gè)模型分工協(xié)作每次跑完一個(gè)任務(wù)成本幾乎為零這在以前用API時(shí)想都不敢想。還可以把自托管模型接入到更多的端側(cè)設(shè)備。比如在局域網(wǎng)內(nèi)做一個(gè)語(yǔ)音助手語(yǔ)音識(shí)別用本地Whisper理解用本地7B模型語(yǔ)音合成用本地TTS。整套系統(tǒng)離線可用延時(shí)還可以接受。這種“全棧本地AI”的體驗(yàn)用云端API拼接是做不到的因?yàn)槟悴荒馨炎约杭业恼Z(yǔ)音數(shù)據(jù)天天傳到云端再傳回來(lái)。最后聊一下我對(duì)自托管AI趨勢(shì)的判斷。模型的權(quán)重會(huì)越來(lái)越大但量化技術(shù)和推理框架的優(yōu)化也在突飛猛進(jìn)消費(fèi)級(jí)硬件能跑的模型上限一直在提高。兩年前大家覺得70B模型必須有A100現(xiàn)在通過(guò)量化加CPU offload在48GB的卡上也能跑起來(lái)。硬件的演進(jìn)加上開源生態(tài)的繁榮讓自托管不再只是大公司的專利普通人用一臺(tái)工作站甚至一臺(tái)高端游戲本就能擁有自己的私有AI能力。這件事對(duì)我來(lái)說(shuō)最大的吸引力不是省了多少錢而是那種“這個(gè)東西完全屬于我”的自由感。模型是我的數(shù)據(jù)是我的推理過(guò)程是我的我可以任意改造它、實(shí)驗(yàn)它而不需要征求任何人的允許。如果你也有類似的追求我建議你從Ollama拉一個(gè)小模型開始親手體驗(yàn)一次自托管AI帶來(lái)的掌控力。