这次我们来看一个评测类项目karminski 发布的小模型竞技场横评。项目核心是把 8 款小尺寸模型放到同一套评测体系里做横向对比覆盖生成质量、指令遵循、推理速度、显存占用、多轮稳定性等关键维度最终输出一份可以直接指导选型的对比结论。对本地部署玩家来说这类项目比官方 benchmark 更有参考价值因为评测环境更接近真实使用场景普通显卡、本地推理框架、默认参数下的实际表现。小模型在本地部署里越来越受关注原因很直接不需要顶配显卡8G 到 12G 显存就能跑数据不用离开本机还能通过量化进一步压缩资源需求。但小模型的问题也很明显——版本多、量化格式多、评测数据分散用户很难判断哪个模型真正适合自己。这个竞技场评测项目解决的就是8 款模型到底怎么选这件事。它把零散的评测结果整合成统一对比让选型成本大幅降低。从项目标题来看这个横评有几个值得关注的点第一评测对象是 8 款小模型而不是动辄几十 B 的大模型普通消费级显卡就能复现第二评测方式是竞技场模式即统一环境、统一测试集、统一采样参数降低变量干扰第三输出形式是横向对比报告而不是单个模型的独立跑分方便直接做选型决策。本文会围绕这个项目拆解三块内容一是小模型评测的维度设计和指标含义二是如何在本地复现一套类似的评测流程三是如何解读横评结果、把分数转化成部署选型依据。如果你正在纠结该选哪个小模型或者想搭一套自己的模型对比测试流程这篇文章可以直接收藏。1. 小模型竞技场横评项目概览先明确这个项目的定位。从标题看这是由 karminski 发布的一个小模型竞技场评测项目。所谓竞技场借鉴的是大模型对战评测的思路把多个模型放到同一套条件下用统一任务、统一打分规则做对比最终输出排名和结论。和普通榜单最大的区别在于竞技场模式更强调可控对比而不是简单罗列各自的基准测试分数。这类评测项目对本地部署用户的价值体现在三个层面。第一解决信息不对称问题。开源小模型生态非常碎片化同一个模型可能有 base、chat、instruct 等多个版本还有 GGUF、GPTQ、AWQ 等不同量化格式普通用户很难快速搞清楚差异。第二评测环境更贴近实际。官方 benchmark 通常在特定评测集上跑分换到真实业务场景往往失效而竞技场模式会统一采样参数、统一推理框架更能反映真实部署表现。第三结果可复现。横评如果附带了测试集、配置参数和运行脚本读者就能在自己机器上重新验证。1.1 核心能力速览能力项说明项目类型小尺寸模型横向评测竞技场模式评测对象8 款小参数模型评测范围通用对话、指令遵循、推理能力、运行性能、资源占用环境要求以项目仓库 README 为准常规 N 卡环境即可启动方式脚本或评测框架具体以仓库说明为准输出形式指标对比表、排名、选型建议是否支持批量评测本身即批量任务需要脚本批量推理适合场景本地选型、量化对比、推理框架对比上表中标注以仓库为准的部分是因为目前公开信息有限。真实的硬件要求、模型名单、启动脚本要以项目仓库里给出的 README 和配置文件为准。2. 为什么小模型评测值得关注小模型通常指参数规模在 1B 到 8B 之间的模型。这个量级的模型在普通消费级显卡上就能运行配置到位后还能通过量化进一步降低显存需求。但小模型的选择难度其实比大模型更高。首先是生态碎片化问题。同一款开源模型往往有多个版本分支不同量化方式又会产生不同精度的权重文件用户很难直接比较。比如一个 7B 模型F16 精度、8bit 量化、4bit 量化的显存占用和生成质量差异很大不看实测数据根本没法判断。其次是评测结果不一致。不同评测集、不同推理框架、不同采样参数都会影响最终分数两份榜单放到一起经常出现矛盾结论。最后是性能与质量的取舍不直观。有的模型跑得快但回答质量差有的模型质量好但显存占用高没有综合对比就只能靠挨个试错。karminski 这个横评项目解决的并不是AI 模型原理问题而是我该选哪个模型、怎么跑、跑起来怎么样的工程选型问题。对本地部署用户而言这比单纯刷高分更重要。更关键的是这类评测方法本身是可以复用的。你用同一套测试脚本换一批模型、换一个推理框架就能得到自己业务场景下的对比结论。3. 评测维度与指标体系小模型横评最核心的是评测维度。维度设置不合理跑分再高也没有参考价值。综合常见的小模型评测实践建议从通用能力和工程性能两个方向切入。3.1 通用能力维度维度说明观察方式指令遵循模型能否按要求的格式、长度、结构输出固定提示词检查输出格式是否符合知识问答事实性问题的准确率使用带标准答案的测试集逻辑推理数学题、逻辑题的分析能力使用 GSM8K、MMLU 子集或自建题库代码生成能否生成可运行的代码用代码生成测试集并实际执行检查多轮对话上下文记忆和指令追踪连续多轮对话测试长文本处理超过模型默认上下文后的表现分段输入长文本检查关键信息提取稳定性相同输入多次运行的结果一致性同一 prompt 重复运行多次观察输出差异3.2 工程性能维度工程性能维度通常包括首 token 延迟、生成速度、显存占用、上下文窗口利用率和并发能力。首 token 延迟决定了流式输出的体验生成速度决定了批量任务的吞吐显存占用决定了显卡选型上限上下文窗口利用率决定了长文本场景的可行性并发能力决定了能否作为服务对外提供。这些指标有一个关键前提采样参数必须统一。如果模型 A 用 temperature0.7模型 B 用 temperature0.9那对比结果就不公平。建议在评测配置里固定 temperature、top_p、max_new_tokens 和随机种子。4. 本地复现评测的环境准备如果你想把这份横评在自己机器上复现或者扩展成自己的模型对比体系建议先走一遍通用环境检查。4.1 硬件环境检查清单GPU建议 N 卡显存 8G 起步。如果跑 1B 到 3B 的量化模型4G 也可能够但要看具体量化格式和输入长度。CPU纯 CPU 推理也可以但 7B 模型的速度会明显偏慢评测耗时成倍增加。内存16G 起步32G 更稳。加载大模型权重和测试集时内存占用会比较高。磁盘模型文件和评测结果需要空间预留 30G 以上比较稳。操作系统Windows、Linux 均可Linux 下容器方案更省心。4.2 软件环境检查清单Python 3.10 或更高版本。PyTorch 版本需要和 CUDA 驱动匹配。推理框架按评测需求选择 transformers、llama.cpp、Ollama 或 vLLM 中的一个。评测数据准备好测试提示词文件纯文本或 JSON 格式均可。还没有拿到项目原始代码之前建议先用一个通用评测脚本模板。这个模板把加载模型 - 跑提示词 - 记录结果和耗时 - 保存 JSON做成标准流程后续不管是换模型还是换测试集都很方便。5. 部署与启动评测流程5.1 评测工程目录结构一个可维护的评测工程建议这样组织目录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放评测参数。prompts放测试集按任务类型分文件。models放本地模型权重。scripts放评测脚本和汇总脚本。results/raw存每次运行的原始结果results/reports存汇总报告。5.2 评测配置示例用 JSON 统一保存采样参数避免每次运行手改代码{ 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 批量评测脚本模板这里给一套通用模板核心是遍历提示词文件逐条推理并记录结果。这个模板基于 HuggingFace Transformers 编写如果你的推理框架是 Ollama、llama.cpp 或 vLLM需要把模型加载和推理部分替换成对应接口但记录结果和耗时的逻辑可以复用。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 的评测思路如果你评测的模型已经用 Ollama 管理加载方式会更简单。Ollama 的优势是模型权重和推理参数统一管理适合做多模型快速切换对比。# 拉取模型具体模型名以实际需要为准 ollama pull qwen2.5:3b # 通过 API 调用 curl http://127.0.0.1:11434/api/generate \ -d { model: qwen2.5:3b, prompt: 解释一下什么是局部重绘, stream: false }这种方式的评测脚本只需要关注 HTTP 请求的发送和响应的保存不需要处理显存加载细节。代价是对推理参数的掌控力弱一些适合快速评测不适合需要精确控制采样参数的场景。6. 8 款模型评测对比结果的解读方法拿到横评报告后最忌讳只看总榜不看分项。对比表应该拆成质量和性能两张表看选型结论才可靠。6.1 质量榜怎么读质量榜看的是模型实际回答水平。要关注三个点第一是高分模型是否有偏科。一个模型如果代码分极高但多轮对话分很低它更适合做代码任务而不是通用助手。第二是分数差距是否有实际意义。0.1 分的差异可能只是随机波动要多看多次运行均值或置信区间。第三是失败样本长什么样。结论比分数重要——模型在哪类任务上失败决定了你能不能用在业务里。6.2 性能榜怎么读性能榜决定的是部署方式。每秒 token 数决定交互体验峰值显存决定显卡选型首 token 延迟决定流式输出体验。举例来说两张卡都能跑同一个 3B 模型但如果一张卡的生成速度是另一张的两倍选型结论就完全不同。这也是为什么横评一定要附上设备和推理框架信息。6.3 综合选型参考表如果没有原始横评数据可以用下面这个模板来组织你自己的选型对比对比项模型 A模型 B模型 C参数规模待填入待填入待填入量化格式待填入待填入待填入生成质量5分制待填入待填入待填入指令遵循待填入待填入待填入推理速度token/s待填入待填入待填入显存占用GB待填入待填入待填入多轮稳定性待填入待填入待填入适用任务待填入待填入待填入选型结论待填入待填入待填入把这份表填完选型基本就清晰了。如果项目原始横评报告里已有数据直接对照项目给出的模型名单来读表效果更好。7. 资源占用与性能观察小模型评测里资源占用是最容易被忽略但实际影响最大的部分。只看跑分不看显存容易在部署阶段翻车。7.1 显存占用怎么看推荐用 nvidia-smi 周期性采样。在评测运行的另一个终端执行下面的命令就能记录推理过程中的显存曲线nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 1观察重点有两个峰值显存和持续显存。峰值显存决定了显卡够不够用持续显存决定了同时跑多路请求时会不会爆显存。7.2 CPU 推理与 GPU 推理的差异GPU 推理的优势在生成阶段非常明显尤其是 batch size 大于 1 时。CPU 推理在小批量单请求下也能用但显存压力转移到内存速度通常慢一个数量级。如果你的评测机器只有 CPU重点关注内存占用而不是显存同时把 max_new_tokens 调小否则一次评测要跑很久。7.3 影响性能的主要参数max_new_tokens 越大单次推理耗时越长batch size 越大显存上升但吞吐提升temperature 只影响采样随机性不影响速度但影响质量稳定性上下文长度越长显存占用越高所以长文本任务要单独测试。评测时这些参数要固定否则对比结果会出现偏差。8. 常见问题与排查方法8.1 问题排查表问题现象可能原因排查方式解决方案依赖安装失败Python 版本或 CUDA 版本不匹配查看安装日志检查 python --version 和 nvidia-smi按项目要求的 Python/CUDA 版本重建虚拟环境模型文件缺失权重下载不完整或路径配置错误检查模型目录和配置中的 model_path重新下载模型确认目录下有 config.json 和权重文件CUDA 不可用驱动版本过旧或 PyTorch 与 CUDA 不匹配执行 torch.cuda.is_available() 检查更新驱动或安装匹配版本的 PyTorch显存不足模型过大或 batch size 过高观察 nvidia-smi 的显存占用换更小模型、开量化或减小 batch size推理结果全部相同采样参数被固定或模型处于贪心模式检查 temperature、do_sample 配置打开采样参数并确认随机种子批量任务卡住单条请求超时或显存耗尽查看日志最后一条记录增加超时控制分批次重试输出质量不稳定采样参数过高或多轮上下文丢失对比同一 prompt 多次输出调低 temperature简化上下文8.2 常见阻塞点评测最常卡在模型下载和依赖安装。建议模型下载优先走官方渠道或可信镜像依赖版本尽量锁定到具体版本号避免环境不一致导致结果不同。另外一个容易被忽略的坑是提示词格式。不同模型的 chat template 不同同一个提示词在 A 模型上能正常回答在 B 模型上可能格式错乱。跑全量评测之前一定要先跑一两条 prompt 验证流程确认输出格式正常后再放开完整评测。9. 最佳实践与使用建议9.1 评测前先跑通最小闭环把评测集裁到 2 到 3 条 prompt先验证输出格式、保存逻辑、显存占用都正常再放开全量评测。这个习惯能避免大半流程问题尤其是提示词模板不匹配、模型路径写错这类低级错误。9.2 记录评测环境快照评测报告必须附带环境信息否则结论无法复用。至少记录推理框架及版本、模型权重版本和量化格式、采样参数、GPU 型号和显存、评测日期。这些信息在后续选型和问题排查中非常关键。9.3 分目录管理模型与结果模型权重、测试集、输出结果一定要分开目录。批量评测会生成大量 JSONL 文件建议按模型名和时间戳命名结果目录避免覆盖。同时定期清理无用结果防止磁盘被评测日志占满。9.4 接口服务限制访问范围如果评测结果要开放查询或评测脚本要变成常驻服务接口必须限制访问。评测耗时通常较长不设鉴权很容易被外部请求拖垮。即使只是本机使用也建议绑定 127.0.0.1避免局域网内其他设备误访问。9.5 使用边界与合规提醒小模型评测本身是技术研究行为但在实际使用中要注意边界。涉及人脸、语音、版权文本等内容生成时必须确认素材来源合法、已获授权。评测过程中产生的数据如果包含隐私信息处理完要及时清理。测试集设计应聚焦技术指标不要诱导模型生成违法违规内容。10. 总结与下一步karminski 发布的这个小模型竞技场横评最值得参考的地方不是某个模型得了第一而是提供了一个把 8 款模型放在同一标准下对比的评测思路。这类评测对本地部署用户的价值非常直接你可以知道某个小模型在真实推理环境中大概是什么水平显存吃多少、速度怎么样、稳定性如何避免选型时只看跑分、不看实际表现。如果你要自己复现建议第一步先跑通 2 到 3 条 prompt 的最小闭环确认环境、采样参数、输出格式都没问题再放开全量评测。最容易踩的坑是依赖环境不一致导致的跑分失效以及只看总榜不看分项导致的选型偏差。把评测脚本、目录结构、配置模板准备好后面模型越多这套流程的价值越大。后续值得扩展的方向包括加入量化格式对比、加入不同推理框架对比、加入真实业务测试集以及把评测流程封装成可复用的批量脚本。把这套流程搭好之后新增模型只需要改配置就能得出对比结果。 
长河君 · 2026/9/2 12:54:57 · 阅读 1.2k 小模型竞技场横评：8款本地部署模型选型指南
这次我们来看一个评测类项目karminski 发布的小模型竞技场横评。项目核心是把 8 款小尺寸模型放到同一套评测体系里做横向对比覆盖生成质量、指令遵循、推理速度、显存占用、多轮稳定性等关键维度最终输出一份可以直接指导选型的对比结论。对本地部署玩家来说这类项目比官方 benchmark 更有参考价值因为评测环境更接近真实使用场景普通显卡、本地推理框架、默认参数下的实际表现。小模型在本地部署里越来越受关注原因很直接不需要顶配显卡8G 到 12G 显存就能跑数据不用离开本机还能通过量化进一步压缩资源需求。但小模型的问题也很明显——版本多、量化格式多、评测数据分散用户很难判断哪个模型真正适合自己。这个竞技场评测项目解决的就是8 款模型到底怎么选这件事。它把零散的评测结果整合成统一对比让选型成本大幅降低。从项目标题来看这个横评有几个值得关注的点第一评测对象是 8 款小模型而不是动辄几十 B 的大模型普通消费级显卡就能复现第二评测方式是竞技场模式即统一环境、统一测试集、统一采样参数降低变量干扰第三输出形式是横向对比报告而不是单个模型的独立跑分方便直接做选型决策。本文会围绕这个项目拆解三块内容一是小模型评测的维度设计和指标含义二是如何在本地复现一套类似的评测流程三是如何解读横评结果、把分数转化成部署选型依据。如果你正在纠结该选哪个小模型或者想搭一套自己的模型对比测试流程这篇文章可以直接收藏。1. 小模型竞技场横评项目概览先明确这个项目的定位。从标题看这是由 karminski 发布的一个小模型竞技场评测项目。所谓竞技场借鉴的是大模型对战评测的思路把多个模型放到同一套条件下用统一任务、统一打分规则做对比最终输出排名和结论。和普通榜单最大的区别在于竞技场模式更强调可控对比而不是简单罗列各自的基准测试分数。这类评测项目对本地部署用户的价值体现在三个层面。第一解决信息不对称问题。开源小模型生态非常碎片化同一个模型可能有 base、chat、instruct 等多个版本还有 GGUF、GPTQ、AWQ 等不同量化格式普通用户很难快速搞清楚差异。第二评测环境更贴近实际。官方 benchmark 通常在特定评测集上跑分换到真实业务场景往往失效而竞技场模式会统一采样参数、统一推理框架更能反映真实部署表现。第三结果可复现。横评如果附带了测试集、配置参数和运行脚本读者就能在自己机器上重新验证。1.1 核心能力速览能力项说明项目类型小尺寸模型横向评测竞技场模式评测对象8 款小参数模型评测范围通用对话、指令遵循、推理能力、运行性能、资源占用环境要求以项目仓库 README 为准常规 N 卡环境即可启动方式脚本或评测框架具体以仓库说明为准输出形式指标对比表、排名、选型建议是否支持批量评测本身即批量任务需要脚本批量推理适合场景本地选型、量化对比、推理框架对比上表中标注以仓库为准的部分是因为目前公开信息有限。真实的硬件要求、模型名单、启动脚本要以项目仓库里给出的 README 和配置文件为准。2. 为什么小模型评测值得关注小模型通常指参数规模在 1B 到 8B 之间的模型。这个量级的模型在普通消费级显卡上就能运行配置到位后还能通过量化进一步降低显存需求。但小模型的选择难度其实比大模型更高。首先是生态碎片化问题。同一款开源模型往往有多个版本分支不同量化方式又会产生不同精度的权重文件用户很难直接比较。比如一个 7B 模型F16 精度、8bit 量化、4bit 量化的显存占用和生成质量差异很大不看实测数据根本没法判断。其次是评测结果不一致。不同评测集、不同推理框架、不同采样参数都会影响最终分数两份榜单放到一起经常出现矛盾结论。最后是性能与质量的取舍不直观。有的模型跑得快但回答质量差有的模型质量好但显存占用高没有综合对比就只能靠挨个试错。karminski 这个横评项目解决的并不是AI 模型原理问题而是我该选哪个模型、怎么跑、跑起来怎么样的工程选型问题。对本地部署用户而言这比单纯刷高分更重要。更关键的是这类评测方法本身是可以复用的。你用同一套测试脚本换一批模型、换一个推理框架就能得到自己业务场景下的对比结论。3. 评测维度与指标体系小模型横评最核心的是评测维度。维度设置不合理跑分再高也没有参考价值。综合常见的小模型评测实践建议从通用能力和工程性能两个方向切入。3.1 通用能力维度维度说明观察方式指令遵循模型能否按要求的格式、长度、结构输出固定提示词检查输出格式是否符合知识问答事实性问题的准确率使用带标准答案的测试集逻辑推理数学题、逻辑题的分析能力使用 GSM8K、MMLU 子集或自建题库代码生成能否生成可运行的代码用代码生成测试集并实际执行检查多轮对话上下文记忆和指令追踪连续多轮对话测试长文本处理超过模型默认上下文后的表现分段输入长文本检查关键信息提取稳定性相同输入多次运行的结果一致性同一 prompt 重复运行多次观察输出差异3.2 工程性能维度工程性能维度通常包括首 token 延迟、生成速度、显存占用、上下文窗口利用率和并发能力。首 token 延迟决定了流式输出的体验生成速度决定了批量任务的吞吐显存占用决定了显卡选型上限上下文窗口利用率决定了长文本场景的可行性并发能力决定了能否作为服务对外提供。这些指标有一个关键前提采样参数必须统一。如果模型 A 用 temperature0.7模型 B 用 temperature0.9那对比结果就不公平。建议在评测配置里固定 temperature、top_p、max_new_tokens 和随机种子。4. 本地复现评测的环境准备如果你想把这份横评在自己机器上复现或者扩展成自己的模型对比体系建议先走一遍通用环境检查。4.1 硬件环境检查清单GPU建议 N 卡显存 8G 起步。如果跑 1B 到 3B 的量化模型4G 也可能够但要看具体量化格式和输入长度。CPU纯 CPU 推理也可以但 7B 模型的速度会明显偏慢评测耗时成倍增加。内存16G 起步32G 更稳。加载大模型权重和测试集时内存占用会比较高。磁盘模型文件和评测结果需要空间预留 30G 以上比较稳。操作系统Windows、Linux 均可Linux 下容器方案更省心。4.2 软件环境检查清单Python 3.10 或更高版本。PyTorch 版本需要和 CUDA 驱动匹配。推理框架按评测需求选择 transformers、llama.cpp、Ollama 或 vLLM 中的一个。评测数据准备好测试提示词文件纯文本或 JSON 格式均可。还没有拿到项目原始代码之前建议先用一个通用评测脚本模板。这个模板把加载模型 - 跑提示词 - 记录结果和耗时 - 保存 JSON做成标准流程后续不管是换模型还是换测试集都很方便。5. 部署与启动评测流程5.1 评测工程目录结构一个可维护的评测工程建议这样组织目录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放评测参数。prompts放测试集按任务类型分文件。models放本地模型权重。scripts放评测脚本和汇总脚本。results/raw存每次运行的原始结果results/reports存汇总报告。5.2 评测配置示例用 JSON 统一保存采样参数避免每次运行手改代码{ 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 批量评测脚本模板这里给一套通用模板核心是遍历提示词文件逐条推理并记录结果。这个模板基于 HuggingFace Transformers 编写如果你的推理框架是 Ollama、llama.cpp 或 vLLM需要把模型加载和推理部分替换成对应接口但记录结果和耗时的逻辑可以复用。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 的评测思路如果你评测的模型已经用 Ollama 管理加载方式会更简单。Ollama 的优势是模型权重和推理参数统一管理适合做多模型快速切换对比。# 拉取模型具体模型名以实际需要为准 ollama pull qwen2.5:3b # 通过 API 调用 curl http://127.0.0.1:11434/api/generate \ -d { model: qwen2.5:3b, prompt: 解释一下什么是局部重绘, stream: false }这种方式的评测脚本只需要关注 HTTP 请求的发送和响应的保存不需要处理显存加载细节。代价是对推理参数的掌控力弱一些适合快速评测不适合需要精确控制采样参数的场景。6. 8 款模型评测对比结果的解读方法拿到横评报告后最忌讳只看总榜不看分项。对比表应该拆成质量和性能两张表看选型结论才可靠。6.1 质量榜怎么读质量榜看的是模型实际回答水平。要关注三个点第一是高分模型是否有偏科。一个模型如果代码分极高但多轮对话分很低它更适合做代码任务而不是通用助手。第二是分数差距是否有实际意义。0.1 分的差异可能只是随机波动要多看多次运行均值或置信区间。第三是失败样本长什么样。结论比分数重要——模型在哪类任务上失败决定了你能不能用在业务里。6.2 性能榜怎么读性能榜决定的是部署方式。每秒 token 数决定交互体验峰值显存决定显卡选型首 token 延迟决定流式输出体验。举例来说两张卡都能跑同一个 3B 模型但如果一张卡的生成速度是另一张的两倍选型结论就完全不同。这也是为什么横评一定要附上设备和推理框架信息。6.3 综合选型参考表如果没有原始横评数据可以用下面这个模板来组织你自己的选型对比对比项模型 A模型 B模型 C参数规模待填入待填入待填入量化格式待填入待填入待填入生成质量5分制待填入待填入待填入指令遵循待填入待填入待填入推理速度token/s待填入待填入待填入显存占用GB待填入待填入待填入多轮稳定性待填入待填入待填入适用任务待填入待填入待填入选型结论待填入待填入待填入把这份表填完选型基本就清晰了。如果项目原始横评报告里已有数据直接对照项目给出的模型名单来读表效果更好。7. 资源占用与性能观察小模型评测里资源占用是最容易被忽略但实际影响最大的部分。只看跑分不看显存容易在部署阶段翻车。7.1 显存占用怎么看推荐用 nvidia-smi 周期性采样。在评测运行的另一个终端执行下面的命令就能记录推理过程中的显存曲线nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 1观察重点有两个峰值显存和持续显存。峰值显存决定了显卡够不够用持续显存决定了同时跑多路请求时会不会爆显存。7.2 CPU 推理与 GPU 推理的差异GPU 推理的优势在生成阶段非常明显尤其是 batch size 大于 1 时。CPU 推理在小批量单请求下也能用但显存压力转移到内存速度通常慢一个数量级。如果你的评测机器只有 CPU重点关注内存占用而不是显存同时把 max_new_tokens 调小否则一次评测要跑很久。7.3 影响性能的主要参数max_new_tokens 越大单次推理耗时越长batch size 越大显存上升但吞吐提升temperature 只影响采样随机性不影响速度但影响质量稳定性上下文长度越长显存占用越高所以长文本任务要单独测试。评测时这些参数要固定否则对比结果会出现偏差。8. 常见问题与排查方法8.1 问题排查表问题现象可能原因排查方式解决方案依赖安装失败Python 版本或 CUDA 版本不匹配查看安装日志检查 python --version 和 nvidia-smi按项目要求的 Python/CUDA 版本重建虚拟环境模型文件缺失权重下载不完整或路径配置错误检查模型目录和配置中的 model_path重新下载模型确认目录下有 config.json 和权重文件CUDA 不可用驱动版本过旧或 PyTorch 与 CUDA 不匹配执行 torch.cuda.is_available() 检查更新驱动或安装匹配版本的 PyTorch显存不足模型过大或 batch size 过高观察 nvidia-smi 的显存占用换更小模型、开量化或减小 batch size推理结果全部相同采样参数被固定或模型处于贪心模式检查 temperature、do_sample 配置打开采样参数并确认随机种子批量任务卡住单条请求超时或显存耗尽查看日志最后一条记录增加超时控制分批次重试输出质量不稳定采样参数过高或多轮上下文丢失对比同一 prompt 多次输出调低 temperature简化上下文8.2 常见阻塞点评测最常卡在模型下载和依赖安装。建议模型下载优先走官方渠道或可信镜像依赖版本尽量锁定到具体版本号避免环境不一致导致结果不同。另外一个容易被忽略的坑是提示词格式。不同模型的 chat template 不同同一个提示词在 A 模型上能正常回答在 B 模型上可能格式错乱。跑全量评测之前一定要先跑一两条 prompt 验证流程确认输出格式正常后再放开完整评测。9. 最佳实践与使用建议9.1 评测前先跑通最小闭环把评测集裁到 2 到 3 条 prompt先验证输出格式、保存逻辑、显存占用都正常再放开全量评测。这个习惯能避免大半流程问题尤其是提示词模板不匹配、模型路径写错这类低级错误。9.2 记录评测环境快照评测报告必须附带环境信息否则结论无法复用。至少记录推理框架及版本、模型权重版本和量化格式、采样参数、GPU 型号和显存、评测日期。这些信息在后续选型和问题排查中非常关键。9.3 分目录管理模型与结果模型权重、测试集、输出结果一定要分开目录。批量评测会生成大量 JSONL 文件建议按模型名和时间戳命名结果目录避免覆盖。同时定期清理无用结果防止磁盘被评测日志占满。9.4 接口服务限制访问范围如果评测结果要开放查询或评测脚本要变成常驻服务接口必须限制访问。评测耗时通常较长不设鉴权很容易被外部请求拖垮。即使只是本机使用也建议绑定 127.0.0.1避免局域网内其他设备误访问。9.5 使用边界与合规提醒小模型评测本身是技术研究行为但在实际使用中要注意边界。涉及人脸、语音、版权文本等内容生成时必须确认素材来源合法、已获授权。评测过程中产生的数据如果包含隐私信息处理完要及时清理。测试集设计应聚焦技术指标不要诱导模型生成违法违规内容。10. 总结与下一步karminski 发布的这个小模型竞技场横评最值得参考的地方不是某个模型得了第一而是提供了一个把 8 款模型放在同一标准下对比的评测思路。这类评测对本地部署用户的价值非常直接你可以知道某个小模型在真实推理环境中大概是什么水平显存吃多少、速度怎么样、稳定性如何避免选型时只看跑分、不看实际表现。如果你要自己复现建议第一步先跑通 2 到 3 条 prompt 的最小闭环确认环境、采样参数、输出格式都没问题再放开全量评测。最容易踩的坑是依赖环境不一致导致的跑分失效以及只看总榜不看分项导致的选型偏差。把评测脚本、目录结构、配置模板准备好后面模型越多这套流程的价值越大。后续值得扩展的方向包括加入量化格式对比、加入不同推理框架对比、加入真实业务测试集以及把评测流程封装成可复用的批量脚本。把这套流程搭好之后新增模型只需要改配置就能得出对比结果。