2025年AI行業(yè)的“開源與閉源”之爭再次被擺上臺面。Meta創(chuàng)始人馬克·扎克伯格公開批評“封閉AI”競爭對手同時宣布Meta重新回到開放模型路線。這件事在普通用戶眼里只是一條科技新聞但在開發(fā)者的視角里信號遠(yuǎn)比標(biāo)題更有價值。我的判斷是Meta放棄“獨(dú)家閉源優(yōu)勢”本質(zhì)不是格局覺醒而是戰(zhàn)略換軌——它想用開源生態(tài)的普及率換一個更值錢的東西AI應(yīng)用世界的事實(shí)標(biāo)準(zhǔn)。當(dāng)大量開發(fā)者默認(rèn)使用同一套開源模型、同一套工具鏈、同一套推理協(xié)議時控制力就沉淀在生態(tài)層而不是產(chǎn)品層。這篇文章不打算復(fù)述新聞而是從技術(shù)視角拆解幾個真正值得思考的問題開源模型和閉源模型的差異到底在哪Meta開源模型如何在你自己的服務(wù)器上部署運(yùn)行以及在“造模型”和“用模型”之間你究竟該怎么選。讀完你可以自己判斷你的下一個AI項(xiàng)目要不要把寶押在開源大模型上。1. 這篇文章真正要解決的問題很多開發(fā)者看到“Meta開源AI大模型”的新聞后第一反應(yīng)是“關(guān)我什么事”。但真到動手做AI應(yīng)用的時候你會發(fā)現(xiàn)這個問題的分量完全不同你的企業(yè)客戶要求數(shù)據(jù)不出域用不了閉源API怎么辦你的應(yīng)用每天調(diào)用次數(shù)上萬按Token計(jì)費(fèi)的成本開始失控怎么辦你需要針對行業(yè)術(shù)語做微調(diào)但閉源模型不給你權(quán)重怎么辦這三個問題恰好是開源模型最擅長解決的場景。所以不管你是否認(rèn)同扎克伯格的說法Meta重新押注open models這件事會直接影響未來一到兩年內(nèi)AI開發(fā)者的技術(shù)選型。這篇文章會從新聞事件的商業(yè)判斷切入然后落到操作層面。你會看到開源模型與閉源模型的真實(shí)差異熟悉在本地部署Meta開源模型的完整鏈路也搞清楚不同規(guī)模項(xiàng)目的選型思路。最核心的目標(biāo)是幫你建立一套穩(wěn)定的判斷框架遇到具體業(yè)務(wù)需求時知道該往哪個方向走而不是被各家大廠的話術(shù)帶走。2. 事件背景Meta為何押注“開放模型”扎克伯格批評“封閉AI”競爭對手表面上是商業(yè)輿論戰(zhàn)背后其實(shí)是AI產(chǎn)業(yè)路線的一次清晰分化。2.1 Meta的路線選擇從防御到進(jìn)攻回顧Meta在AI領(lǐng)域的動作能看出明顯的節(jié)奏變化。早年Meta在AI研究上有積累但產(chǎn)品化程度不高。當(dāng)生成式AI爆發(fā)后Meta推出了Llama系列大模型并選擇將模型權(quán)重對外開放。這里要注意“開放權(quán)重”和“完全開源”并不完全等同Llama系列使用的是自定義許可證對商用有要求和限制這一點(diǎn)后面會詳細(xì)展開。這次扎克伯格公開攻擊“封閉AI”可以理解為Meta內(nèi)部已經(jīng)確認(rèn)了一條核心路線不再靠出售模型本身賺錢而是讓Meta的模型成為開發(fā)者生態(tài)的基礎(chǔ)設(shè)施。一旦大量開發(fā)者在Meta模型之上構(gòu)建應(yīng)用、積累數(shù)據(jù)和工具鏈Meta就掌握了AI應(yīng)用層的事實(shí)入口。2.2 為什么“開放”反而是一種商業(yè)策略很多人覺得“開源不賺錢”但大模型時代的邏輯不同。閉源模型靠API調(diào)用付費(fèi)開源模型靠生態(tài)滲透獲利。Meta的策略可以拆成三層來看模型層開放權(quán)重降低使用門檻讓開發(fā)者愿意嘗試。工具層圍繞模型提供推理框架、微調(diào)工具、云服務(wù)這些是可以商業(yè)化的。生態(tài)層開發(fā)者遷移到其他模型體系的成本會越來越高最終形成黏性。這種策略在互聯(lián)網(wǎng)歷史上并不罕見。當(dāng)一項(xiàng)技術(shù)已經(jīng)成為基礎(chǔ)設(shè)施時真正賺錢的往往不是賣技術(shù)本身而是技術(shù)的分發(fā)、運(yùn)維和增值服務(wù)。Meta押注的就是這個位置。2.3 對開發(fā)者的含義對開發(fā)者而言這條路線的競爭是好事。至少有三個層面能直接受益選擇權(quán)增加你不再只能依賴兩三家閉源API可以本地部署、私有化定制。價格壓力傳導(dǎo)開源模型的免費(fèi)權(quán)重讓閉源API的定價不敢無限上漲。知識透明化開源模型的權(quán)重、訓(xùn)練細(xì)節(jié)、推理代碼更可追溯學(xué)習(xí)和研究空間更大。但也要注意喊“開放”不等于沒有邊界。Meta依然會在許可證、合規(guī)和云端服務(wù)上做文章。開發(fā)者要做的不是被任何一方的口號影響而是理解背后的技術(shù)約束再做出自己的選擇。3. 開源模型與閉源模型本質(zhì)差異很多剛接觸大模型的開發(fā)者會把“開源模型”簡單理解成“不要錢的模型”把“閉源模型”理解成“要錢的模型”。這個理解不夠準(zhǔn)確可能在實(shí)際項(xiàng)目中造成誤判。3.1 核心概念這里先明確兩個術(shù)語開源大模型指模型的權(quán)重文件、推理代碼、配置信息對外公開開發(fā)者可以在自己的服務(wù)器上下載、運(yùn)行、微調(diào)。典型代表包括Meta的Llama系列、Mistral系列等。要注意開源權(quán)重不等于任何版權(quán)都沒有它只是把使用權(quán)限開放到了許可證規(guī)定的范圍內(nèi)。閉源大模型指模型能力通過服務(wù)方提供的API接口暴露模型權(quán)重不對外公開。用戶通過HTTP請求把文本發(fā)送給服務(wù)方服務(wù)方在云端完成推理后返回結(jié)果。典型代表是GPT系列、Claude系列等。3.2 一個容易理解的類比如果你把大模型比作餐飲閉源模型是去餐廳吃飯。你不用管后廚怎么運(yùn)作點(diǎn)菜、等待、上菜吃完付款。優(yōu)點(diǎn)是方便缺點(diǎn)是價格隨點(diǎn)菜次數(shù)累積而且你永遠(yuǎn)不知道后廚用了什么食材、有沒有按照你的口味調(diào)整。開源模型是“半成品食材自己開火”。你拿到配方和原料在自己的廚房里做菜。剛開始要買鍋、買灶、學(xué)流程成本不低但一旦跑通后續(xù)每道菜的成本都由你控制口味也能按自己的需求調(diào)整。這個類比能幫助理解后續(xù)所有部署和選型的討論。3.3 核心維度對比維度開源模型閉源模型模型權(quán)重可下載、可部署到本地不可下載只能在服務(wù)方環(huán)境運(yùn)行數(shù)據(jù)流向數(shù)據(jù)在自有服務(wù)器處理輸入數(shù)據(jù)需要發(fā)送到服務(wù)方微調(diào)能力可全參數(shù)微調(diào)或輕量微調(diào)主要依賴提示詞工程模型參數(shù)不可變初始成本需要硬件、環(huán)境、運(yùn)維投入按Token計(jì)費(fèi)注冊即可用長期成本硬件折舊人力運(yùn)維相對可控調(diào)用量越大累計(jì)費(fèi)用越高性能天花板受本地硬件限制服務(wù)方有大規(guī)模算力單請求能力通常更強(qiáng)技術(shù)迭代跟隨官方發(fā)布和社區(qū)適配服務(wù)方持續(xù)更新用戶無感升級3.4 不同場景下的選擇邏輯在實(shí)際項(xiàng)目中沒有絕對的“開源更好”或“閉源更好”只有“更適合”。如果業(yè)務(wù)對數(shù)據(jù)隱私要求極高比如醫(yī)療、金融、政務(wù)場景閉源API把用戶數(shù)據(jù)發(fā)給第三方通常是不可接受的這時候開源模型的本地部署幾乎是唯一選擇。如果團(tuán)隊(duì)只是想快速做一個Demo驗(yàn)證產(chǎn)品想法沒有GPU資源也不打算投入模型運(yùn)維人力閉源API明顯更合適。幾十行代碼就能拿到推理結(jié)果不需要關(guān)心模型加載、顯存占用、推理優(yōu)化。如果應(yīng)用需要特定領(lǐng)域的回答質(zhì)量比如法律文書、企業(yè)內(nèi)部知識庫問答開源模型允許你在自有數(shù)據(jù)上做微調(diào)閉源模型很難提供同等程度的定制空間。如果團(tuán)隊(duì)有GPU資源但用戶請求量波動很大開源模型本地部署之后單位請求的增量成本會相對可控長期看更省錢閉源API的賬單則會隨請求量線性增長。4. 開源大模型部署的環(huán)境準(zhǔn)備看懂了差異下一步就是動手。以Meta開源模型為例最常走的兩條路是使用Hugging Face Transformers加載模型或者使用Ollama這類本地推理工具。這條路不像調(diào)用API那么簡單需要準(zhǔn)備環(huán)境。4.1 硬件前置條件大模型推理吃的是顯存不是內(nèi)存。顯存大小決定了你能跑多大參數(shù)的模型、用什么精度跑。如果顯存在8GB左右建議使用7B以下參數(shù)量的模型并開啟4bit量化。如果顯存在16GB到24GB可以比較舒服地運(yùn)行7B到14B的模型配合float16精度或8bit量化。如果顯存在40GB以上可以嘗試70B級別模型的量化版本或者使用多卡并行。沒有NVIDIA GPU的時候純CPU也能推理但速度會很慢只適合做功能驗(yàn)證不適合生產(chǎn)環(huán)境。4.2 軟件環(huán)境與Python依賴操作系統(tǒng)建議使用Linux尤其是Ubuntu系列。Windows也可以跑但驅(qū)動、CUDA、依賴的坑會多一些。Python版本建議3.8以上。這里以Transformers方案為例先創(chuàng)建虛擬環(huán)境并安裝核心依賴。# 創(chuàng)建并激活虛擬環(huán)境 python3 -m venv .venv source .venv/bin/activate # 安裝核心依賴 pip install --upgrade pip pip install --upgrade transformers accelerate bitsandbytes huggingface_hub解釋一下幾個依賴的用途transformersHugging Face的模型加載與推理框架屬于主流方案之一。accelerate負(fù)責(zé)設(shè)備自動分配讓模型可以自動落到GPU或CPU上。bitsandbytes提供4bit/8bit量化支持是顯存不足時的關(guān)鍵工具。huggingface_hub用于從Hugging Face Hub下載模型。需要補(bǔ)充一個關(guān)鍵提醒Meta的Llama系列模型在Hugging Face平臺上屬于受限模型下載前需要在模型頁面接受Meta的許可證協(xié)議并配置Hugging Face訪問令牌。很多新手在這一步卡住報的錯誤是401 Unauthorized。4.3 Ollama方案的環(huán)境準(zhǔn)備如果你不想寫代碼只想過一把本地大模型的癮Ollama是更快捷的路線。它把模型下載、量化、推理封裝成一條命令適合本地實(shí)驗(yàn)。安裝Ollama的方式很簡單到官網(wǎng)下載對應(yīng)操作系統(tǒng)的安裝包或者參考官方文檔執(zhí)行安裝腳本。安裝完成后可以查看版本ollama --version5. 完整示例本地部署Meta開源模型這一節(jié)用一個最小閉環(huán)演示從加載模型到對外提供接口的完整流程。以下代碼面向的是“跑通流程”生產(chǎn)環(huán)境還需要在并發(fā)、安全和可維護(hù)性上做更多工作。5.1 使用Transformers加載模型并生成回復(fù)先把最小推理腳本跑起來。該腳本默認(rèn)使用4bit量化加載模型可以在消費(fèi)級顯卡上運(yùn)行。# 文件路徑load_meta_model.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch # 注意模型名稱以Meta官方在Hugging Face發(fā)布的實(shí)際路徑為準(zhǔn) model_id meta-llama/Llama-3.2-3B-Instruct # Hugging Face訪問令牌需在Hugging Face官網(wǎng)生成 HF_TOKEN 你的Hugging Face訪問令牌 tokenizer AutoTokenizer.from_pretrained( model_id, tokenHF_TOKEN, ) model AutoModelForCausalLM.from_pretrained( model_id, device_mapauto, torch_dtypetorch.float16, load_in_4bitTrue, tokenHF_TOKEN, ) prompt 用一句話解釋什么是開源AI模型 messages [{role: user, content: prompt}] inputs tokenizer.apply_chat_template( messages, return_tensorspt, add_generation_promptTrue, ).to(model.device) outputs model.generate( inputs, max_new_tokens512, temperature0.7, top_p0.9, do_sampleTrue, ) response tokenizer.decode( outputs[0][inputs.shape[1]:], skip_special_tokensTrue, ) print(response)這段代碼有幾個關(guān)鍵點(diǎn)需要說明。device_mapauto會讓Transformers自動把模型層分配到可用的GPU或CPU上不用手動指定設(shè)備。load_in_4bitTrue表示開啟4bit量化這是顯存不足時的重要手段。如果機(jī)器顯存足夠可以去掉這個參數(shù)用float16加載生成質(zhì)量通常更好。apply_chat_template是因?yàn)橹噶钅Ｐ推谕斎氚磳υ捀袷浇M織不能直接把純文本丟給模型。模板會添加模型訓(xùn)練時使用的特殊標(biāo)記這一步容易被忽略。outputs[0][inputs.shape[1]:]表示從生成結(jié)果中截掉輸入部分只保留模型新生成的內(nèi)容。運(yùn)行腳本的命令python load_meta_model.py5.2 使用Ollama快速跑通開源模型如果你只是想本地對話Ollama的方式簡單得多。以下命令以O(shè)llama官方模型庫支持的標(biāo)簽為準(zhǔn)不同版本標(biāo)簽可能不同。# 拉取模型 ollama pull llama3 # 進(jìn)入交互式對話 ollama run llama3拉取完成后終端會進(jìn)入交互模式輸入你的問題模型就會在本地生成回復(fù)。這種方式唯一需要準(zhǔn)備的東西是磁盤空間和內(nèi)存/顯存不需要寫Python代碼。它是快速驗(yàn)證模型能力的有效路徑但想把能力集成到業(yè)務(wù)系統(tǒng)最終還是要走API或代碼調(diào)用。5.3 使用FastAPI封裝模型為Web服務(wù)把模型暴露成Web API是接入業(yè)務(wù)系統(tǒng)的常見方式。這里用FastAPI封裝一個簡單的對話接口。# 文件路徑app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch app FastAPI(titleMeta Open Model Service) MODEL_ID meta-llama/Llama-3.2-3B-Instruct HF_TOKEN 你的Hugging Face訪問令牌 tokenizer AutoTokenizer.from_pretrained(MODEL_ID, tokenHF_TOKEN) model AutoModelForCausalLM.from_pretrained( MODEL_ID, device_mapauto, torch_dtypetorch.float16, load_in_4bitTrue, tokenHF_TOKEN, ) class ChatRequest(BaseModel): message: str max_new_tokens: int 256 class ChatResponse(BaseModel): reply: str app.post(/chat, response_modelChatResponse) def chat(req: ChatRequest): try: messages [{role: user, content: req.message}] inputs tokenizer.apply_chat_template( messages, return_tensorspt, add_generation_promptTrue, ).to(model.device) outputs model.generate( inputs, max_new_tokensreq.max_new_tokens, temperature0.7, top_p0.9, do_sampleTrue, ) reply tokenizer.decode( outputs[0][inputs.shape[1]:], skip_special_tokensTrue, ) return ChatResponse(replyreply) except Exception as exc: raise HTTPException(status_code500, detailstr(exc))啟動服務(wù)uvicorn app:app --host 0.0.0.0 --port 8000用curl做一次接口測試curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {message: 什么是AI Agent}到這一步你已經(jīng)有了一個可以對外提供對話能力的本地模型服務(wù)。業(yè)務(wù)系統(tǒng)只要發(fā)送HTTP請求就能像一個AI接口一樣使用開源模型。6. 運(yùn)行結(jié)果與效果驗(yàn)證6.1 最小腳本的預(yù)期輸出運(yùn)行l(wèi)oad_meta_model.py時如果模型加載成功終端會先顯示一些加載日志之后打印模型的回答。由于生成結(jié)果帶有隨機(jī)性每次可能不完全一樣但語義上應(yīng)該能形成一句關(guān)于“開源AI模型”的合理定義例如“開源AI模型是指公開模型權(quán)重和源代碼的人工智能模型允許用戶自由使用、修改和部署。”這里想強(qiáng)調(diào)一個驗(yàn)證思路不要只看輸出像不像話。真正要驗(yàn)證的有四點(diǎn)模型是否加載在預(yù)期設(shè)備上而不是悄悄跑在CPU上。首次推理耗時可接受不是幾十秒甚至幾分鐘。生成內(nèi)容沒有大量重復(fù)或亂碼。顯存占用在合理范圍不會運(yùn)行一次就OOM。6.2 查看顯存與設(shè)備分配訓(xùn)練和推理過程中最常用的驗(yàn)證命令是nvidia-smi。nvidia-smi這個命令會輸出GPU的利用率、顯存占用、進(jìn)程列表。如果看到你的Python進(jìn)程占用了數(shù)GB到十幾GB的顯存說明模型確實(shí)加載到了GPU。如果GPU利用率顯示為0%但CPU利用率很高就要檢查device_map配置是否正確。6.3 接口服務(wù)驗(yàn)證FastAPI服務(wù)啟動后在瀏覽器訪問http://127.0.0.1:8000/docs可以看到自動生成的API文檔頁面這個頁面可以直接測試/chat接口。如果接口返回結(jié)構(gòu)化JSON說明服務(wù)鏈路已經(jīng)暢通。如果接口返回500查看服務(wù)端日志是第一步。一般錯誤會寫明是模型加載失敗、設(shè)備分配失敗還是生成參數(shù)問題。7. 開源模型使用中的常見問題與排查在本地部署開源模型的過程中開發(fā)者遇到的問題往往集中在環(huán)境、授權(quán)、顯存和生成質(zhì)量這幾個方向。以下是我認(rèn)為最值得記錄的排查清單。問題現(xiàn)象可能原因排查方式解決方案下載模型時返回401Hugging Face令牌無效或未接受模型許可協(xié)議檢查令牌是否有效確認(rèn)已在模型頁面勾選授權(quán)在Hugging Face官網(wǎng)生成新令牌接受Meta許可證條款后重試顯存溢出進(jìn)程被殺模型參數(shù)規(guī)模超過顯存或未啟用量化運(yùn)行nvidia-smi查看當(dāng)前顯存占用改用load_in_4bitTrue或換更小參數(shù)量的模型生成速度極慢模型被分配到CPU或GPU顯存不足導(dǎo)致?lián)Q入換出查看日志確認(rèn)模型設(shè)備觀察GPU利用率調(diào)整device_map關(guān)閉其他GPU進(jìn)程降低模型精度輸出內(nèi)容重復(fù)采樣參數(shù)設(shè)置不當(dāng)檢查temperature和top_p設(shè)置適當(dāng)降低temperature增加no_repeat_ngram_size參數(shù)中文質(zhì)量差基座模型中文語料占比不高用中英文混合測試對比多個模型使用專門的指令版模型或在中文數(shù)據(jù)集上微調(diào)服務(wù)一段時間后內(nèi)存持續(xù)增長未控制并發(fā)或無請求隊(duì)列觀察進(jìn)程內(nèi)存和GPU顯存曲線增加并發(fā)控制、請求隊(duì)列必要時重啟服務(wù)許可證合規(guī)不明確對模型License理解不透徹查閱模型官方頁面License說明商用前請法務(wù)或技術(shù)負(fù)責(zé)人確認(rèn)合規(guī)邊界這里特別展開說明第一個問題。很多開發(fā)者第一次接觸Llama系列模型時下載就卡住了。原因很簡單Hugging Face上的meta模型不是公開直接下載的需要先登錄Hugging Face賬號打開對應(yīng)模型頁面點(diǎn)擊接受許可證協(xié)議再生成訪問令牌。這個令牌要配置到代碼里否則代碼就會報401。生成質(zhì)量的問題也值得多說一句。開源模型的能力上限和硬件配置密切相關(guān)。如果只能用4bit量化在8GB顯存上運(yùn)行一個小參數(shù)模型那么它和云端那種數(shù)百GB顯存集群跑出來的大模型差距是不小的。遇到輸出質(zhì)量不理想時先別急著判斷“模型不行”確認(rèn)一下自己是不是因?yàn)橛布拗瓢涯Ｐ蛪嚎s得太厲害。8. 企業(yè)落地開源模型的最佳實(shí)踐從“能跑通”到“能上線”中間還有一段不短的距離。結(jié)合真實(shí)項(xiàng)目經(jīng)驗(yàn)我認(rèn)為下面幾個方面最容易決定成敗。8.1 模型選型不要只看參數(shù)數(shù)量很多團(tuán)隊(duì)選模型時只看“70B比7B強(qiáng)”但這忽略了兩件事一是參數(shù)越多部署成本和推理延遲越高二是不同模型在不同任務(wù)上的表現(xiàn)差異很大。更務(wù)實(shí)的做法是先把自己業(yè)務(wù)中比較有代表性的問題整理成評測集每個模型都跑一遍看輸出質(zhì)量、延遲、顯存占用是否能接受。評測集里的問題不要只用標(biāo)準(zhǔn)問答要包含你的業(yè)務(wù)中真正會出現(xiàn)的長尾問題。這樣選出來的模型才是適合當(dāng)前場景的模型。8.2 許可證合規(guī)要提前確認(rèn)開源模型的“開源”并不是所有權(quán)的免費(fèi)贈送。Meta Llama系列使用自定義許可證它有明確的商用限制和合規(guī)要求。不同版本之間的條款可能不同因此在商用之前必須做這些事記錄模型的具體版本和下載來源。閱讀該版本對應(yīng)的許可證全文。確認(rèn)所在業(yè)務(wù)場景是否在許可范圍內(nèi)。如果涉及轉(zhuǎn)售或嵌入自身產(chǎn)品更要謹(jǐn)慎。這一條看起來像“法務(wù)問題”但技術(shù)團(tuán)隊(duì)如果完全不管后續(xù)可能導(dǎo)致產(chǎn)品下線或法律糾紛。建議在選型階段就把許可證檢查列入流程。8.3 數(shù)據(jù)安全是本地部署的隱形邊界本地部署不等于絕對安全。模型運(yùn)行在你的服務(wù)器上但訓(xùn)練數(shù)據(jù)本身可能包含敏感信息尤其是當(dāng)你在開源模型之上做微調(diào)時訓(xùn)練數(shù)據(jù)可能被模型記憶并在某個輸入下泄露。實(shí)際項(xiàng)目中的通用做法包括提示詞和輸入數(shù)據(jù)中脫敏不把真實(shí)手機(jī)號、身份證號明文傳給模型。模型服務(wù)接口做鑒權(quán)不暴露在內(nèi)網(wǎng)之外。日志中過濾敏感字段避免日志系統(tǒng)成為泄露渠道。對模型輸出做內(nèi)容安全過濾不能只信任模型本身的安全性。8.4 并發(fā)控制與成本本地部署的誤區(qū)之一是“以為沒有API費(fèi)用所以成本為零”。實(shí)際上GPU服務(wù)器的采購或租用成本、運(yùn)維成本、電費(fèi)都是錢。而且如果模型服務(wù)不做并發(fā)控制請求一多就可能把顯存打爆導(dǎo)致所有請求失敗。生產(chǎn)環(huán)境建議做幾件事在API服務(wù)前加請求隊(duì)列超出的請求排隊(duì)或丟棄。根據(jù)模型推理時延和顯存占用計(jì)算合理的最大并發(fā)數(shù)。對輸入輸出Token數(shù)做上限限制防止異常請求拖垮服務(wù)。記錄推理時延、Token吞吐和錯誤率作為容量規(guī)劃的依據(jù)。8.5 版本管理可復(fù)現(xiàn)開源模型迭代速度很快今天用的模型也許下個月就發(fā)布了新版本。但生產(chǎn)環(huán)境最忌“悄悄變化”。建議把如下內(nèi)容打到發(fā)布記錄里模型名稱和版本。量化精度。推理參數(shù)temperature、top_p等。依賴庫版本transformers、torch等。驗(yàn)證評測集的結(jié)果。這樣就算出問題也能快速回滾到之前可用的配置。9. 趨勢展望與建議Meta重新押注開放模型對整個AI開發(fā)社區(qū)是一個積極的信號。它意味著開源模型和閉源模型的競爭還會持續(xù)而且開源陣營的資源投入會持續(xù)增加。但對開發(fā)者來說最重要的是不要被“開源必勝”或“閉源更好”的簡單敘事誤導(dǎo)。我的建議很直接選型從來不是立場問題而是約束問題。時間、預(yù)算、數(shù)據(jù)安全、團(tuán)隊(duì)能力這些約束條件決定了你更適合開源還是閉源。與其追著新聞跑不如把一套最小流程跑通下載一個開源模型、部署到本地、封裝成API、做一輪業(yè)務(wù)測試。跑完之后你對“開源模型到底行不行”會有自己的結(jié)論這個結(jié)論比任何大V的判斷都可靠。如果你手上正好有空閑GPU可以按本文第5章的示例代碼跑一遍。跑通之后自然會遇到顯存、速度、質(zhì)量之類的問題那些問題本身就是最好的學(xué)習(xí)材料。模型領(lǐng)域的技術(shù)棧還在快速變化但“動手跑通最小閉環(huán)”這條經(jīng)驗(yàn)短期內(nèi)不會過時。