這次我們來(lái)看一個(gè)評(píng)測(cè)類項(xiàng)目karminski 發(fā)布的小模型競(jìng)技場(chǎng)橫評(píng)。項(xiàng)目核心是把 8 款小尺寸模型放到同一套評(píng)測(cè)體系里做橫向?qū)Ρ雀采w生成質(zhì)量、指令遵循、推理速度、顯存占用、多輪穩(wěn)定性等關(guān)鍵維度最終輸出一份可以直接指導(dǎo)選型的對(duì)比結(jié)論。對(duì)本地部署玩家來(lái)說這類項(xiàng)目比官方 benchmark 更有參考價(jià)值因?yàn)樵u(píng)測(cè)環(huán)境更接近真實(shí)使用場(chǎng)景普通顯卡、本地推理框架、默認(rèn)參數(shù)下的實(shí)際表現(xiàn)。小模型在本地部署里越來(lái)越受關(guān)注原因很直接不需要頂配顯卡8G 到 12G 顯存就能跑數(shù)據(jù)不用離開本機(jī)還能通過量化進(jìn)一步壓縮資源需求。但小模型的問題也很明顯——版本多、量化格式多、評(píng)測(cè)數(shù)據(jù)分散用戶很難判斷哪個(gè)模型真正適合自己。這個(gè)競(jìng)技場(chǎng)評(píng)測(cè)項(xiàng)目解決的就是8 款模型到底怎么選這件事。它把零散的評(píng)測(cè)結(jié)果整合成統(tǒng)一對(duì)比讓選型成本大幅降低。從項(xiàng)目標(biāo)題來(lái)看這個(gè)橫評(píng)有幾個(gè)值得關(guān)注的點(diǎn)第一評(píng)測(cè)對(duì)象是 8 款小模型而不是動(dòng)輒幾十 B 的大模型普通消費(fèi)級(jí)顯卡就能復(fù)現(xiàn)第二評(píng)測(cè)方式是競(jìng)技場(chǎng)模式即統(tǒng)一環(huán)境、統(tǒng)一測(cè)試集、統(tǒng)一采樣參數(shù)降低變量干擾第三輸出形式是橫向?qū)Ρ葓?bào)告而不是單個(gè)模型的獨(dú)立跑分方便直接做選型決策。本文會(huì)圍繞這個(gè)項(xiàng)目拆解三塊內(nèi)容一是小模型評(píng)測(cè)的維度設(shè)計(jì)和指標(biāo)含義二是如何在本地復(fù)現(xiàn)一套類似的評(píng)測(cè)流程三是如何解讀橫評(píng)結(jié)果、把分?jǐn)?shù)轉(zhuǎn)化成部署選型依據(jù)。如果你正在糾結(jié)該選哪個(gè)小模型或者想搭一套自己的模型對(duì)比測(cè)試流程這篇文章可以直接收藏。1. 小模型競(jìng)技場(chǎng)橫評(píng)項(xiàng)目概覽先明確這個(gè)項(xiàng)目的定位。從標(biāo)題看這是由 karminski 發(fā)布的一個(gè)小模型競(jìng)技場(chǎng)評(píng)測(cè)項(xiàng)目。所謂競(jìng)技場(chǎng)借鑒的是大模型對(duì)戰(zhàn)評(píng)測(cè)的思路把多個(gè)模型放到同一套條件下用統(tǒng)一任務(wù)、統(tǒng)一打分規(guī)則做對(duì)比最終輸出排名和結(jié)論。和普通榜單最大的區(qū)別在于競(jìng)技場(chǎng)模式更強(qiáng)調(diào)可控對(duì)比而不是簡(jiǎn)單羅列各自的基準(zhǔn)測(cè)試分?jǐn)?shù)。這類評(píng)測(cè)項(xiàng)目對(duì)本地部署用戶的價(jià)值體現(xiàn)在三個(gè)層面。第一解決信息不對(duì)稱問題。開源小模型生態(tài)非常碎片化同一個(gè)模型可能有 base、chat、instruct 等多個(gè)版本還有 GGUF、GPTQ、AWQ 等不同量化格式普通用戶很難快速搞清楚差異。第二評(píng)測(cè)環(huán)境更貼近實(shí)際。官方 benchmark 通常在特定評(píng)測(cè)集上跑分換到真實(shí)業(yè)務(wù)場(chǎng)景往往失效而競(jìng)技場(chǎng)模式會(huì)統(tǒng)一采樣參數(shù)、統(tǒng)一推理框架更能反映真實(shí)部署表現(xiàn)。第三結(jié)果可復(fù)現(xiàn)。橫評(píng)如果附帶了測(cè)試集、配置參數(shù)和運(yùn)行腳本讀者就能在自己機(jī)器上重新驗(yàn)證。1.1 核心能力速覽能力項(xiàng)說明項(xiàng)目類型小尺寸模型橫向評(píng)測(cè)競(jìng)技場(chǎng)模式評(píng)測(cè)對(duì)象8 款小參數(shù)模型評(píng)測(cè)范圍通用對(duì)話、指令遵循、推理能力、運(yùn)行性能、資源占用環(huán)境要求以項(xiàng)目倉(cāng)庫(kù) README 為準(zhǔn)常規(guī) N 卡環(huán)境即可啟動(dòng)方式腳本或評(píng)測(cè)框架具體以倉(cāng)庫(kù)說明為準(zhǔn)輸出形式指標(biāo)對(duì)比表、排名、選型建議是否支持批量評(píng)測(cè)本身即批量任務(wù)需要腳本批量推理適合場(chǎng)景本地選型、量化對(duì)比、推理框架對(duì)比上表中標(biāo)注以倉(cāng)庫(kù)為準(zhǔn)的部分是因?yàn)槟壳肮_信息有限。真實(shí)的硬件要求、模型名單、啟動(dòng)腳本要以項(xiàng)目倉(cāng)庫(kù)里給出的 README 和配置文件為準(zhǔn)。2. 為什么小模型評(píng)測(cè)值得關(guān)注小模型通常指參數(shù)規(guī)模在 1B 到 8B 之間的模型。這個(gè)量級(jí)的模型在普通消費(fèi)級(jí)顯卡上就能運(yùn)行配置到位后還能通過量化進(jìn)一步降低顯存需求。但小模型的選擇難度其實(shí)比大模型更高。首先是生態(tài)碎片化問題。同一款開源模型往往有多個(gè)版本分支不同量化方式又會(huì)產(chǎn)生不同精度的權(quán)重文件用戶很難直接比較。比如一個(gè) 7B 模型F16 精度、8bit 量化、4bit 量化的顯存占用和生成質(zhì)量差異很大不看實(shí)測(cè)數(shù)據(jù)根本沒法判斷。其次是評(píng)測(cè)結(jié)果不一致。不同評(píng)測(cè)集、不同推理框架、不同采樣參數(shù)都會(huì)影響最終分?jǐn)?shù)兩份榜單放到一起經(jīng)常出現(xiàn)矛盾結(jié)論。最后是性能與質(zhì)量的取舍不直觀。有的模型跑得快但回答質(zhì)量差有的模型質(zhì)量好但顯存占用高沒有綜合對(duì)比就只能靠挨個(gè)試錯(cuò)。karminski 這個(gè)橫評(píng)項(xiàng)目解決的并不是AI 模型原理問題而是我該選哪個(gè)模型、怎么跑、跑起來(lái)怎么樣的工程選型問題。對(duì)本地部署用戶而言這比單純刷高分更重要。更關(guān)鍵的是這類評(píng)測(cè)方法本身是可以復(fù)用的。你用同一套測(cè)試腳本換一批模型、換一個(gè)推理框架就能得到自己業(yè)務(wù)場(chǎng)景下的對(duì)比結(jié)論。3. 評(píng)測(cè)維度與指標(biāo)體系小模型橫評(píng)最核心的是評(píng)測(cè)維度。維度設(shè)置不合理跑分再高也沒有參考價(jià)值。綜合常見的小模型評(píng)測(cè)實(shí)踐建議從通用能力和工程性能兩個(gè)方向切入。3.1 通用能力維度維度說明觀察方式指令遵循模型能否按要求的格式、長(zhǎng)度、結(jié)構(gòu)輸出固定提示詞檢查輸出格式是否符合知識(shí)問答事實(shí)性問題的準(zhǔn)確率使用帶標(biāo)準(zhǔn)答案的測(cè)試集邏輯推理數(shù)學(xué)題、邏輯題的分析能力使用 GSM8K、MMLU 子集或自建題庫(kù)代碼生成能否生成可運(yùn)行的代碼用代碼生成測(cè)試集并實(shí)際執(zhí)行檢查多輪對(duì)話上下文記憶和指令追蹤連續(xù)多輪對(duì)話測(cè)試長(zhǎng)文本處理超過模型默認(rèn)上下文后的表現(xiàn)分段輸入長(zhǎng)文本檢查關(guān)鍵信息提取穩(wěn)定性相同輸入多次運(yùn)行的結(jié)果一致性同一 prompt 重復(fù)運(yùn)行多次觀察輸出差異3.2 工程性能維度工程性能維度通常包括首 token 延遲、生成速度、顯存占用、上下文窗口利用率和并發(fā)能力。首 token 延遲決定了流式輸出的體驗(yàn)生成速度決定了批量任務(wù)的吞吐顯存占用決定了顯卡選型上限上下文窗口利用率決定了長(zhǎng)文本場(chǎng)景的可行性并發(fā)能力決定了能否作為服務(wù)對(duì)外提供。這些指標(biāo)有一個(gè)關(guān)鍵前提采樣參數(shù)必須統(tǒng)一。如果模型 A 用 temperature0.7模型 B 用 temperature0.9那對(duì)比結(jié)果就不公平。建議在評(píng)測(cè)配置里固定 temperature、top_p、max_new_tokens 和隨機(jī)種子。4. 本地復(fù)現(xiàn)評(píng)測(cè)的環(huán)境準(zhǔn)備如果你想把這份橫評(píng)在自己機(jī)器上復(fù)現(xiàn)或者擴(kuò)展成自己的模型對(duì)比體系建議先走一遍通用環(huán)境檢查。4.1 硬件環(huán)境檢查清單GPU建議 N 卡顯存 8G 起步。如果跑 1B 到 3B 的量化模型4G 也可能夠但要看具體量化格式和輸入長(zhǎng)度。CPU純 CPU 推理也可以但 7B 模型的速度會(huì)明顯偏慢評(píng)測(cè)耗時(shí)成倍增加。內(nèi)存16G 起步32G 更穩(wěn)。加載大模型權(quán)重和測(cè)試集時(shí)內(nèi)存占用會(huì)比較高。磁盤模型文件和評(píng)測(cè)結(jié)果需要空間預(yù)留 30G 以上比較穩(wěn)。操作系統(tǒng)Windows、Linux 均可Linux 下容器方案更省心。4.2 軟件環(huán)境檢查清單Python 3.10 或更高版本。PyTorch 版本需要和 CUDA 驅(qū)動(dòng)匹配。推理框架按評(píng)測(cè)需求選擇 transformers、llama.cpp、Ollama 或 vLLM 中的一個(gè)。評(píng)測(cè)數(shù)據(jù)準(zhǔn)備好測(cè)試提示詞文件純文本或 JSON 格式均可。還沒有拿到項(xiàng)目原始代碼之前建議先用一個(gè)通用評(píng)測(cè)腳本模板。這個(gè)模板把加載模型 - 跑提示詞 - 記錄結(jié)果和耗時(shí) - 保存 JSON做成標(biāo)準(zhǔn)流程后續(xù)不管是換模型還是換測(cè)試集都很方便。5. 部署與啟動(dòng)評(píng)測(cè)流程5.1 評(píng)測(cè)工程目錄結(jié)構(gòu)一個(gè)可維護(hù)的評(píng)測(cè)工程建議這樣組織目錄arena-eval/ ├── configs/ │ └── eval_config.json ├── prompts/ │ ├── reasoning.jsonl │ ├── code.jsonl │ └── chat.jsonl ├── models/ │ ├── chat_model_a/ │ └── chat_model_b/ ├── scripts/ │ ├── run_eval.py │ └── aggregate.py └── results/ ├── raw/ └── reports/configs放評(píng)測(cè)參數(shù)。prompts放測(cè)試集按任務(wù)類型分文件。models放本地模型權(quán)重。scripts放評(píng)測(cè)腳本和匯總腳本。results/raw存每次運(yùn)行的原始結(jié)果results/reports存匯總報(bào)告。5.2 評(píng)測(cè)配置示例用 JSON 統(tǒng)一保存采樣參數(shù)避免每次運(yùn)行手改代碼{ model_path: ./models/chat_model_a, task: general_chat, sampling: { temperature: 0.7, top_p: 0.9, max_new_tokens: 512, seed: 42 }, prompt_file: ./prompts/chat.jsonl, output_dir: ./results/raw/chat_model_a }5.3 批量評(píng)測(cè)腳本模板這里給一套通用模板核心是遍歷提示詞文件逐條推理并記錄結(jié)果。這個(gè)模板基于 HuggingFace Transformers 編寫如果你的推理框架是 Ollama、llama.cpp 或 vLLM需要把模型加載和推理部分替換成對(duì)應(yīng)接口但記錄結(jié)果和耗時(shí)的邏輯可以復(fù)用。import json import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path ./models/chat_model_a prompt_file ./prompts/chat.jsonl output_file ./results/raw/chat_model_a.jsonl model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(model_path) with open(prompt_file, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] with open(output_file, w, encodingutf-8) as fout: for task in tasks: prompt task[prompt] inputs tokenizer(prompt, return_tensorspt).to(model.device) start time.time() outputs model.generate( **inputs, max_new_tokens512, temperature0.7, top_p0.9, do_sampleTrue ) elapsed time.time() - start response tokenizer.decode(outputs[0], skip_special_tokensTrue) record { prompt: prompt, response: response, elapsed_seconds: round(elapsed, 3) } fout.write(json.dumps(record, ensure_asciiFalse) \n) fout.flush()5.4 接入 Ollama 的評(píng)測(cè)思路如果你評(píng)測(cè)的模型已經(jīng)用 Ollama 管理加載方式會(huì)更簡(jiǎn)單。Ollama 的優(yōu)勢(shì)是模型權(quán)重和推理參數(shù)統(tǒng)一管理適合做多模型快速切換對(duì)比。# 拉取模型具體模型名以實(shí)際需要為準(zhǔn) ollama pull qwen2.5:3b # 通過 API 調(diào)用 curl http://127.0.0.1:11434/api/generate \ -d { model: qwen2.5:3b, prompt: 解釋一下什么是局部重繪, stream: false }這種方式的評(píng)測(cè)腳本只需要關(guān)注 HTTP 請(qǐng)求的發(fā)送和響應(yīng)的保存不需要處理顯存加載細(xì)節(jié)。代價(jià)是對(duì)推理參數(shù)的掌控力弱一些適合快速評(píng)測(cè)不適合需要精確控制采樣參數(shù)的場(chǎng)景。6. 8 款模型評(píng)測(cè)對(duì)比結(jié)果的解讀方法拿到橫評(píng)報(bào)告后最忌諱只看總榜不看分項(xiàng)。對(duì)比表應(yīng)該拆成質(zhì)量和性能兩張表看選型結(jié)論才可靠。6.1 質(zhì)量榜怎么讀質(zhì)量榜看的是模型實(shí)際回答水平。要關(guān)注三個(gè)點(diǎn)第一是高分模型是否有偏科。一個(gè)模型如果代碼分極高但多輪對(duì)話分很低它更適合做代碼任務(wù)而不是通用助手。第二是分?jǐn)?shù)差距是否有實(shí)際意義。0.1 分的差異可能只是隨機(jī)波動(dòng)要多看多次運(yùn)行均值或置信區(qū)間。第三是失敗樣本長(zhǎng)什么樣。結(jié)論比分?jǐn)?shù)重要——模型在哪類任務(wù)上失敗決定了你能不能用在業(yè)務(wù)里。6.2 性能榜怎么讀性能榜決定的是部署方式。每秒 token 數(shù)決定交互體驗(yàn)峰值顯存決定顯卡選型首 token 延遲決定流式輸出體驗(yàn)。舉例來(lái)說兩張卡都能跑同一個(gè) 3B 模型但如果一張卡的生成速度是另一張的兩倍選型結(jié)論就完全不同。這也是為什么橫評(píng)一定要附上設(shè)備和推理框架信息。6.3 綜合選型參考表如果沒有原始橫評(píng)數(shù)據(jù)可以用下面這個(gè)模板來(lái)組織你自己的選型對(duì)比對(duì)比項(xiàng)模型 A模型 B模型 C參數(shù)規(guī)模待填入待填入待填入量化格式待填入待填入待填入生成質(zhì)量5分制待填入待填入待填入指令遵循待填入待填入待填入推理速度token/s待填入待填入待填入顯存占用GB待填入待填入待填入多輪穩(wěn)定性待填入待填入待填入適用任務(wù)待填入待填入待填入選型結(jié)論待填入待填入待填入把這份表填完選型基本就清晰了。如果項(xiàng)目原始橫評(píng)報(bào)告里已有數(shù)據(jù)直接對(duì)照項(xiàng)目給出的模型名單來(lái)讀表效果更好。7. 資源占用與性能觀察小模型評(píng)測(cè)里資源占用是最容易被忽略但實(shí)際影響最大的部分。只看跑分不看顯存容易在部署階段翻車。7.1 顯存占用怎么看推薦用 nvidia-smi 周期性采樣。在評(píng)測(cè)運(yùn)行的另一個(gè)終端執(zhí)行下面的命令就能記錄推理過程中的顯存曲線nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 1觀察重點(diǎn)有兩個(gè)峰值顯存和持續(xù)顯存。峰值顯存決定了顯卡夠不夠用持續(xù)顯存決定了同時(shí)跑多路請(qǐng)求時(shí)會(huì)不會(huì)爆顯存。7.2 CPU 推理與 GPU 推理的差異GPU 推理的優(yōu)勢(shì)在生成階段非常明顯尤其是 batch size 大于 1 時(shí)。CPU 推理在小批量單請(qǐng)求下也能用但顯存壓力轉(zhuǎn)移到內(nèi)存速度通常慢一個(gè)數(shù)量級(jí)。如果你的評(píng)測(cè)機(jī)器只有 CPU重點(diǎn)關(guān)注內(nèi)存占用而不是顯存同時(shí)把 max_new_tokens 調(diào)小否則一次評(píng)測(cè)要跑很久。7.3 影響性能的主要參數(shù)max_new_tokens 越大單次推理耗時(shí)越長(zhǎng)batch size 越大顯存上升但吞吐提升temperature 只影響采樣隨機(jī)性不影響速度但影響質(zhì)量穩(wěn)定性上下文長(zhǎng)度越長(zhǎng)顯存占用越高所以長(zhǎng)文本任務(wù)要單獨(dú)測(cè)試。評(píng)測(cè)時(shí)這些參數(shù)要固定否則對(duì)比結(jié)果會(huì)出現(xiàn)偏差。8. 常見問題與排查方法8.1 問題排查表問題現(xiàn)象可能原因排查方式解決方案依賴安裝失敗Python 版本或 CUDA 版本不匹配查看安裝日志檢查 python --version 和 nvidia-smi按項(xiàng)目要求的 Python/CUDA 版本重建虛擬環(huán)境模型文件缺失權(quán)重下載不完整或路徑配置錯(cuò)誤檢查模型目錄和配置中的 model_path重新下載模型確認(rèn)目錄下有 config.json 和權(quán)重文件CUDA 不可用驅(qū)動(dòng)版本過舊或 PyTorch 與 CUDA 不匹配執(zhí)行 torch.cuda.is_available() 檢查更新驅(qū)動(dòng)或安裝匹配版本的 PyTorch顯存不足模型過大或 batch size 過高觀察 nvidia-smi 的顯存占用換更小模型、開量化或減小 batch size推理結(jié)果全部相同采樣參數(shù)被固定或模型處于貪心模式檢查 temperature、do_sample 配置打開采樣參數(shù)并確認(rèn)隨機(jī)種子批量任務(wù)卡住單條請(qǐng)求超時(shí)或顯存耗盡查看日志最后一條記錄增加超時(shí)控制分批次重試輸出質(zhì)量不穩(wěn)定采樣參數(shù)過高或多輪上下文丟失對(duì)比同一 prompt 多次輸出調(diào)低 temperature簡(jiǎn)化上下文8.2 常見阻塞點(diǎn)評(píng)測(cè)最?？ㄔ谀Ｐ拖螺d和依賴安裝。建議模型下載優(yōu)先走官方渠道或可信鏡像依賴版本盡量鎖定到具體版本號(hào)避免環(huán)境不一致導(dǎo)致結(jié)果不同。另外一個(gè)容易被忽略的坑是提示詞格式。不同模型的 chat template 不同同一個(gè)提示詞在 A 模型上能正?；卮鹪?B 模型上可能格式錯(cuò)亂。跑全量評(píng)測(cè)之前一定要先跑一兩條 prompt 驗(yàn)證流程確認(rèn)輸出格式正常后再放開完整評(píng)測(cè)。9. 最佳實(shí)踐與使用建議9.1 評(píng)測(cè)前先跑通最小閉環(huán)把評(píng)測(cè)集裁到 2 到 3 條 prompt先驗(yàn)證輸出格式、保存邏輯、顯存占用都正常再放開全量評(píng)測(cè)。這個(gè)習(xí)慣能避免大半流程問題尤其是提示詞模板不匹配、模型路徑寫錯(cuò)這類低級(jí)錯(cuò)誤。9.2 記錄評(píng)測(cè)環(huán)境快照評(píng)測(cè)報(bào)告必須附帶環(huán)境信息否則結(jié)論無(wú)法復(fù)用。至少記錄推理框架及版本、模型權(quán)重版本和量化格式、采樣參數(shù)、GPU 型號(hào)和顯存、評(píng)測(cè)日期。這些信息在后續(xù)選型和問題排查中非常關(guān)鍵。9.3 分目錄管理模型與結(jié)果模型權(quán)重、測(cè)試集、輸出結(jié)果一定要分開目錄。批量評(píng)測(cè)會(huì)生成大量 JSONL 文件建議按模型名和時(shí)間戳命名結(jié)果目錄避免覆蓋。同時(shí)定期清理無(wú)用結(jié)果防止磁盤被評(píng)測(cè)日志占滿。9.4 接口服務(wù)限制訪問范圍如果評(píng)測(cè)結(jié)果要開放查詢或評(píng)測(cè)腳本要變成常駐服務(wù)接口必須限制訪問。評(píng)測(cè)耗時(shí)通常較長(zhǎng)不設(shè)鑒權(quán)很容易被外部請(qǐng)求拖垮。即使只是本機(jī)使用也建議綁定 127.0.0.1避免局域網(wǎng)內(nèi)其他設(shè)備誤訪問。9.5 使用邊界與合規(guī)提醒小模型評(píng)測(cè)本身是技術(shù)研究行為但在實(shí)際使用中要注意邊界。涉及人臉、語(yǔ)音、版權(quán)文本等內(nèi)容生成時(shí)必須確認(rèn)素材來(lái)源合法、已獲授權(quán)。評(píng)測(cè)過程中產(chǎn)生的數(shù)據(jù)如果包含隱私信息處理完要及時(shí)清理。測(cè)試集設(shè)計(jì)應(yīng)聚焦技術(shù)指標(biāo)不要誘導(dǎo)模型生成違法違規(guī)內(nèi)容。10. 總結(jié)與下一步karminski 發(fā)布的這個(gè)小模型競(jìng)技場(chǎng)橫評(píng)最值得參考的地方不是某個(gè)模型得了第一而是提供了一個(gè)把 8 款模型放在同一標(biāo)準(zhǔn)下對(duì)比的評(píng)測(cè)思路。這類評(píng)測(cè)對(duì)本地部署用戶的價(jià)值非常直接你可以知道某個(gè)小模型在真實(shí)推理環(huán)境中大概是什么水平顯存吃多少、速度怎么樣、穩(wěn)定性如何避免選型時(shí)只看跑分、不看實(shí)際表現(xiàn)。如果你要自己復(fù)現(xiàn)建議第一步先跑通 2 到 3 條 prompt 的最小閉環(huán)確認(rèn)環(huán)境、采樣參數(shù)、輸出格式都沒問題再放開全量評(píng)測(cè)。最容易踩的坑是依賴環(huán)境不一致導(dǎo)致的跑分失效以及只看總榜不看分項(xiàng)導(dǎo)致的選型偏差。把評(píng)測(cè)腳本、目錄結(jié)構(gòu)、配置模板準(zhǔn)備好后面模型越多這套流程的價(jià)值越大。后續(xù)值得擴(kuò)展的方向包括加入量化格式對(duì)比、加入不同推理框架對(duì)比、加入真實(shí)業(yè)務(wù)測(cè)試集以及把評(píng)測(cè)流程封裝成可復(fù)用的批量腳本。把這套流程搭好之后新增模型只需要改配置就能得出對(duì)比結(jié)果。