最近社区里关于小模型Small Language Model的讨论明显多了起来。大模型虽然能力强但部署成本和推理延迟让很多团队开始重新审视“够用就好”的路线。karminski 发布的小模型竞技场横评把 8 款主流小模型放到同一套评测框架下对比涵盖基础能力、推理速度、显存占用和中文支持等维度对后端开发、端侧部署和 AI 应用集成都有直接参考价值。本文不会只搬运结论而是结合这份横评的评测思路完整拆解小模型选型时需要关注的指标、部署环境和测试方法。无论你是刚接触小模型的新手还是已经在做私有化部署的工程师都能在文中找到可复用的方案。涉及代码和命令的地方我会尽量给出可以直接复制运行的示例并解释每一步的用途。1. 小模型为什么越来越受关注1.1 什么是小模型小模型通常指参数量在 0.5B 到 13B 之间的语言模型。相比动辄 70B、上百 B 的大模型小模型的参数量少、权重文件小对显存和内存的要求低很多。常见的 7B 模型在 FP16 精度下权重约 14GB经过 INT4 量化后可以压到 4GB 以内很多消费级显卡和开发板都能运行。但小模型并不是“缩小版的大模型”那么简单。它在训练数据配比、上下文长度、量化策略和推理引擎选择上都有自己的一套逻辑。用得好小模型在垂直场景中的表现可以接近大模型用不好可能连基本的对话流畅度都保证不了。1.2 小模型解决了什么问题小模型最核心的价值是降低部署门槛。成本可控单台普通服务器或 GPU 工作站即可运行不需要多卡集群。数据隐私模型在本地运行敏感数据不需要上传到云端。低延迟没有网络传输开销推理请求在本地即可完成。离线可用适合内网环境、移动设备、嵌入式设备等场景。这也是为什么“微信小程序运行深度学习模型”这类话题会越来越热。小程序端如果直接调用云端大模型 API一方面要考虑网络波动另一方面还有数据合规和费用问题。如果在端侧运行一个小模型处理部分简单任务体验会稳定很多。1.3 竞技场评测的意义在 karminski 的小模型竞技场评测中“竞技场”这个词借鉴了 Chatbot Arena 的思路即把不同模型放在相同的提示词和评分规则下进行横向比较。但是小模型竞技场有一个天然难点小模型的能力边界差异很大同一个测试集下模型擅长的任务类型可能完全不同。因此评测不能只看一个总分还要拆开看。语言理解、逻辑推理、代码生成、数学计算、中文问答、长文本处理每一项都分开打分才能还原一个模型的真实画像。本文后面的评测框架就是按照这个思路设计的。2. 参评模型范围与版本说明2.1 8 款模型的选择标准karminski 的横评选取了社区中较具代表性的 8 款小模型。选择标准大致有三点参数量在 0.5B 到 9B 之间属于典型小模型区间。开源权重可下载方便本地部署复现。覆盖不同技术路线包括整体预训练、增量预训练、蒸馏模型和 MoE 结构。这里需要说明一点模型迭代速度非常快你在实际部署时拿到的版本可能已经更新。横评中的结论反映的是评测时间点的表现建议你部署时以官方仓库最新稳定版本为准。2.2 模型列表与基本特点以下为通常纳入小模型竞技场对比的模型类型每个模型的侧重点不同模型参数量范围特点Qwen 系列0.5B / 1.8B / 3B / 7B中文能力强社区生态完善工具调用支持好Llama 3.21B / 3B英文为主多语言能力和工具调用不错Phi-33.8B微软出品在较小参数下推理表现稳定Mistral7B欧洲模型英文和代码能力均衡支持多种量化格式Gemma 22B / 9BGoogle 出品指令遵循和安全性做得比较细DeepSeek 蒸馏系列1.5B / 7B由大模型蒸馏得到推理和编程表现突出GLM 系列4B / 9B中文场景针对性强支持联网检索和工具调用Yi 系列1.5B / 6B / 9B中文和数学能力不错社区量化版本多各模型实际表现会随版本变化。本文不展开具体的冠军排名而是提供一个评测框架。把你自己选中的模型放到这套框架里跑一遍就是一个符合你业务场景的专属“横评”。2.3 为什么不直接看官方 Benchmark很多模型的 README 里都贴了 MMLU、GSM8K、HumanEval 等榜单分数。这些分数当然有参考意义但直接套用到自己业务里会有几个问题。榜单测试集是固定的和你的业务数据分布可能差异很大。官方测试使用的推理框架和量化位数不一定和你生产环境一致。同一模型在不同推理引擎比如 llama.cpp、Ollama、vLLM、MLC下的表现可能差很多。中文场景的评测集覆盖不够尤其缺乏中文业务指令评测。所以更推荐的做法是参考官方分数做初步筛选再用自己的评测集做第二轮测试。karminski 的横评本质上也是在“官方分数”之外补一份可复现的社区测试。3. 评测环境与部署准备3.1 硬件与系统小模型评测对硬件要求不算高但如果你想一次跑完全部 8 款模型一台拥有 16GB 以上显存的显卡会更省心。常见的组合有NVIDIA RTX 3090 / 409024GB 显存RTX 4070 Ti Super16GB 显存Mac Studio / MacBook ProApple Silicon 统一内存纯 CPU 环境适合 3B 以下模型速度较慢操作系统方面Windows、Linux、macOS 都支持主流推理框架。生产环境更推荐 Linux尤其是 Ubuntu 20.04 / 22.04 LTS因为驱动和 CUDA 环境更稳定。3.2 推理框架选择评测环境和生产环境尽量保持一致这样测试结果才有意义。目前社区使用最多的小模型推理方案有三种。Ollama 适合快速启动和体验一条命令拉起模型服务内置 OpenAI 兼容接口对大多数人来说是最友好的选择。llama.cpp 适合需要精细化控制推理参数和量化格式的场景纯 C/C 实现CPU 上也能跑移动端和嵌入式设备常用它来做底层引擎。vLLM 适合需要高并发和较大吞吐量的生产服务依赖 GPU显存管理比前两者高效但部署复杂度稍高。考虑到大部分开发者先做评测再从评测结果中选型本文以 Ollama 为主因为它在“快速横向对比”这个场景下效率最高。3.3 安装 Ollama如果你还没安装 Ollama可以先按照下面的命令操作。Linux / macOS 用户直接在终端执行curl -fsSL https://ollama.com/install.sh | shWindows 用户可以从 Ollama 官网下载安装包安装后命令行输入ollama --version验证是否成功。不同版本号可能会影响部分命令参数但基础用法通常保持兼容。示例中以常见版本为准具体以官方文档为准。3.4 拉取模型Ollama 中拉取模型使用ollama pull命令格式为模型名:标签。例如ollama pull qwen2.5:7b ollama pull llama3.2:3b ollama pull phi3:mini ollama pull mistral:7b ollama pull gemma2:9b拉取默认是 Q4_K_M 量化版本即 INT4 量化质量和体积比较均衡。如果你的显存充足可以改为半精度版本例如ollama pull qwen2.5:7b-fp16这里要提醒一下不同模型在 Ollama 仓库中的标签名不完全一致拉取前可以用ollama search或者直接去 Ollama 模型库页面确认最新标签。3.5 验证服务是否启动模型拉取完成后可以用一个最简单的请求测试服务状态。ollama serve如果服务没有启动上面的命令会在前台启动服务。然后新开一个终端执行ollama run qwen2.5:7b 你好请简单介绍一下你自己。能够正常返回文本说明环境没问题可以开始评测了。4. 小模型竞技场的评测维度设计评测维度是整个竞技场的灵魂。如果维度设计不合理即使模型跑完结论也没有说服力。karminski 的横评把评测拆成了 7 个维度下面逐一说明每个维度的评测思路和测试方式。4.1 基础语言理解这个维度主要测模型的语义理解、常识问答和信息抽取能力。测试方式准备 20 到 50 道中文问答题包含常识、因果、指代消解、观点识别等类型。例如“小明比小红高小红比小刚高请问三个人中谁最矮”参考答案应该是“小刚”。这种题不需要复杂推理但能反映模型对中文长句的理解能力。4.2 逻辑推理逻辑推理是区分模型好坏的关键维度。小模型在这里经常翻车。测试方式使用包含假言推理、类比推理、归纳推理的题目。例如“所有 A 都是 B所有 B 都是 C那么是否能推出所有 A 都是 C”同时可以加入一些“反常识”问题观察模型是否会被带偏。4.3 数学计算与解题数学题对模型的符号运算和分步推理能力要求更高。测试方式准备 20 道小学到初中水平的数学题既有纯计算也有应用题。例如“一个水池进水管 4 小时注满出水管 6 小时放空同时打开两个管子多久能注满”与上一节逻辑题不同数学题需要模型输出完整的解题步骤而不是只给答案。步骤的合理性也要纳入评分。4.4 代码生成与理解代码能力是很多开发者最关心的维度。测试方式准备 10 个到 15 个编程题目覆盖 Python、JavaScript、Java 或 SQL。要求模型生成可运行代码并解释代码思路。示例题目“用 Python 写一个函数输入一个整数列表返回列表中第二大的数列表可能包含重复元素。”评分时不仅看代码能不能跑还要看有没有处理边界条件比如输入为空、只有一个元素、全是重复值等情况。4.5 中文理解与生成小模型大多以英文语料为主中文能力参差不齐。这个维度需要单独测。测试方式包含中文成语解释、古诗词理解、中文歧义句分析、中文摘要生成等任务。例如“请解释‘塞翁失马焉知非福’的含义并用它造一个句子。”这个维度可以结合你自己的业务场景扩展比如你是做客服系统的就该多准备一些客服问答数据。4.6 指令遵循能力同一个模型对不同措辞的指令反应差异很大。指令遵循能力直接关系到模型在业务系统中的可用性。测试方式给出明确格式要求的指令看模型是否严格遵守。“请用 JSON 格式回复包含 name、age、city 三个字段其中 age 必须是数字。”模型输出必须是合法 JSON而且字段类型正确才算通过。还可以测试多步指令比如“先总结这段文字再用表格输出最后给出三个关键词”。4.7 推理速度与资源占用速度与资源是选型的关键指标一般用三个数据衡量。首 Token 延迟从发送请求到返回第一个 Token 的耗时。生成速度每秒生成的 Token 数单位 tokens/s。显存占用加载模型并生成过程中的峰值显存。记录方式如下在 Ollama 中可以通过环境变量拿到耗时或者直接观察 GPU 显存# 使用 nvidia-smi 监控显存 watch -n 1 nvidia-smi生成速度可以用官方脚本或ollama run配合测试提示词来估算。更精确的方式是使用 OpenAI 兼容接口调用在代码里记录耗时。5. 完整实战搭建一个小模型竞技场评测脚本5.1 项目结构为了便于后续扩展和复现建议把评测代码按结构组织起来。示例目录如下llm-arena/ ├── data/ │ ├── questions.json │ └── answers_reference.json ├── scripts/ │ ├── run_eval.py │ └── collect_metrics.py └── results/ └── eval_result.csv5.2 准备测试题目在data/questions.json中按维度组织题目每个题目包含id、category、question和reference字段。{ questions: [ { id: logic_001, category: logic, question: 所有 A 都是 B所有 B 都是 C那么是否能推出所有 A 都是 C请回答能或不能。, reference: 能 }, { id: math_001, category: math, question: 一个水池进水管 4 小时注满出水管 6 小时放空同时打开两个管子多久能注满, reference: 12小时 }, { id: code_001, category: code, question: 用 Python 写一个函数输入一个整数列表返回列表中第二大的数列表可能包含重复元素。, reference: def second_largest(nums): return sorted(set(nums))[-2] } ] }5.3 编写评测脚本评测脚本的核心逻辑是读取题目调用模型接口记录输出和耗时。Ollama 提供 OpenAI 兼容接口所以我们可以用openaiPython 库来调用。pip install openai pandas下面是一个完整的评测脚本示例。文件路径scripts/run_eval.pyimport json import time import csv from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # Ollama 本地接口不校验 key但参数不能为空 ) MODEL_NAME qwen2.5:7b def load_questions(path): with open(path, r, encodingutf-8) as f: data json.load(f) return data[questions] def ask_model(question): start time.time() response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: question}], temperature0.2, max_tokens1024, streamFalse ) elapsed time.time() - start answer response.choices[0].message.content usage response.usage return { answer: answer, elapsed: round(elapsed, 2), prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens } def evaluate(): questions load_questions(../data/questions.json) results [] for q in questions: print(f\n正在处理题目: {q[id]} [{q[category]}]) try: result ask_model(q[question]) results.append({ id: q[id], category: q[category], question: q[question], reference: q[reference], answer: result[answer], elapsed: result[elapsed], prompt_tokens: result[prompt_tokens], completion_tokens: result[completion_tokens] }) except Exception as e: print(f调用失败: {e}) results.append({ id: q[id], category: q[category], question: q[question], reference: q[reference], answer: fERROR: {e}, elapsed: -1, prompt_tokens: 0, completion_tokens: 0 }) with open(../results/eval_result.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[id, category, question, reference, answer, elapsed, prompt_tokens, completion_tokens]) writer.writeheader() writer.writerows(results) print(f\n评测完成共 {len(results)} 道题结果已保存到 results/eval_result.csv) if __name__ __main__: evaluate()这个脚本会自动遍历所有题目把模型的回答和耗时记录到 CSV 文件。encodingutf-8-sig是为了让 Excel 打开 CSV 时中文不乱码。5.4 批量对比多个模型上面脚本只测一个模型如果想把 8 个模型都跑一遍可以在脚本外层加一个模型列表循环。MODELS [ qwen2.5:7b, llama3.2:3b, phi3:mini, mistral:7b, gemma2:9b ] for model in MODELS: MODEL_NAME model print(f\n 正在评测模型: {model} ) evaluate()每次运行会生成一份独立的 CSV文件名可以加上模型名加以区分。5.5 生成速度统计除了记录单题耗时还需要统计生成阶段的 Token 速度。可以这样改造请求部分def ask_model_with_speed(question): start time.time() response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: question}], temperature0.2, max_tokens1024, streamFalse ) elapsed time.time() - start completion_tokens response.usage.completion_tokens speed completion_tokens / elapsed if elapsed 0 else 0 return speed注意这里计算的是“平均生成速度”包含了首 Token 和网络传输时间。如果你需要精确到排除首 Token可以使用流式接口streamTrue做更细统计后面会提到。5.6 运行结果解读运行完脚本后CSV 中会包含模型原始回答。你可以采用打分制来量化每题根据参考答案人工或使用自动脚本打 0 到 2 分最后按维度汇总。这里要特别强调小模型的回答经常“格式对但内容偏”自动评分时不要只看关键词最好结合人工抽检。建议至少抽检每个维度的前 5 道题确认自动评分标准没有跑偏。6. 横评中常见的关键差异点分析6.1 量化版本对结果的影响在竞技场对比中所有模型都使用默认的 Q4_K_M 量化这保证了各模型运行在相对接近的资源水平上。但不同模型对量化的敏感度不同有的模型 Q4 下依然稳定有的模型则明显出现“胡说”现象。如果你在评测中发现某个模型表现异常差先不要急着否定模型可以尝试 FP16 或 Q8 版本再跑一遍。量化对 3B 以下的模型伤害更大因为参数量少信息冗余度低。在实际选型时建议把“量化后表现”作为决策依据因为生产环境大概率不会用 FP16 部署。6.2 上下文长度的影响小模型虽然支持长上下文但真实处理能力会随长度衰减。竞技场评测中如果测试题目包含长文档需要额外观察模型在 2K、4K、8K 不同长度下的表现。测试方式很简单把一段 5000 字的中文文本输入模型要求它回答文本中的细节问题。不同模型对长上下文的关注能力差别很大有的模型开头部分能记住但中后段信息容易混淆。6.3 中文能力的赛道差异很多模型在英文榜上分数很高但一到中文场景就明显下滑。Qwen 系列中文表现最稳定这和预训练语料中中文占比大有直接关系。Llama 和 Mistral 中文能力偏弱但在加了中文微调后也可以使用。Gemma 2 对中文理解不错但在中文生成风格上偏向书面语。Yi 系列数学和中文能力均衡适合中文数学题场景。所以如果你的业务是纯中文那么横评中的中文维度权重应该调高。如果你的业务以代码为主代码能力权重可以占到 40% 以上。6.4 指令遵循的“不听话”问题小模型在指令遵循上的问题比大模型严重得多。常见表现有要求输出 JSON结果输出了一段解释文字。要求只回答“是/否”结果把推理过程也写了。要求使用中文结果一半中文一半英文。这些问题的根源在于模型的指令跟随能力弱本质上是对“输出约束”的理解不足。在评测时这一项分数需要真实记录因为部署到业务中解析失败就是事故。7. 从横评到落地以微信小程序运行小模型为例7.1 端侧推理的可行性“微信小程序运行深度学习模型”之所以能成为热点是因为端侧推理的硬件基础已经具备。手机端的 NPU、GPU 性能逐年增强加上 WebAssembly 和 WebGPU 技术的普及让浏览器和小程序环境跑轻量模型成为可能。但也要清醒认识一个问题微信小程序不是一个完整的浏览器环境它的 WebAssembly 支持有一定限制直接加载 PyTorch 模型不现实。常见的做法是将模型转为 ONNX 或 TFLite 格式。使用 Transformer.js 或 TensorFlow.js 的适配版本。在服务端完成模型转换把 WebAssembly 产物打包进小程序。7.2 一个可行的实现思路假设我们已经训练或选好了一个 0.5B 或 1B 的小模型在小程序端做文本分类或情感分析流程可以设计为模型转换将 PyTorch 模型导出为 ONNX再转为适合移动端的格式。模型压缩使用 INT8 或 INT4 量化把模型体积控制在 100MB 以内。小程序集成通过 WebAssembly 模块加载模型在本地完成推理。云端兜底模型无法处理的复杂问题再转发到服务器上的大模型。下面是一个前端加载 ONNX 模型的示例片段使用 onnxruntime-web// pages/model/model.js const ort require(onnxruntime-web); Page({ async loadModel() { const session await ort.InferenceSession.create(/models/text_classifier.onnx); this.session session; console.log(模型加载成功); }, async predict(text) { const inputTensor new ort.Tensor(float32, this.tokenize(text), [1, this.maxLen]); const feeds { input_ids: inputTensor }; const results await this.session.run(feeds); const logits results.output.data; const label logits[0] logits[1] ? 正面 : 负面; return label; }, tokenize(text) { // 这里需要接入分词器简化示例中直接返回固定长度的 Array return new Array(128).fill(0); } });注意上面的tokenize方法只是一个占位实现。在实际项目中你需要把 Hugging Face Tokenizer 转换为 JavaScript 版本或者提前在服务端把文本转成 token ID 再下发到小程序后者更简单但会引入网络请求。7.3 小程序端部署的坑点小程序包体积有大小限制单个分包压缩包不能超过 2MB整个小程序所有分包大小不超过 20MB不同平台政策可能会调整。量化后的小模型动辄几十 MB直接放到小程序包里不现实。更常见的方案有两种模型放在服务器小程序首次启动时下载到本地缓存通过wx.getFileSystemManager().saveFile持久化。使用小程序的插件机制或云开发能力把模型作为云函数的一部分但这样推理就在云端了不是纯粹的端侧推理。所以在“微信小程序运行深度学习模型”这个方向上建议优先考虑 0.5B 以下且经过 INT4 量化的超小模型并且把模型加载做成异步、带进度条的体验避免小程序闪退或白屏。8. 小模型竞技场评测中的常见问题8.1 模型拉取失败或速度很慢问题现象常见原因解决思路ollama pull卡住网络连接不稳定配置代理或镜像源确认网络畅通模型下载到一半失败磁盘空间不足清理磁盘或更换下载路径模型文件名找不到标签名拼写错误用ollama search查看可用模型列表8.2 推理速度忽快忽慢问题现象常见原因解决思路首次请求特别慢模型需要从磁盘加载到显存预热请求提前发一个空请求多轮请求后变慢显存不足触发换页缩小模型版本或降低并发数速度不稳定其他进程占用 GPU用nvidia-smi检查进程闲置资源释放8.3 模型回答质量明显偏低问题现象常见原因解决思路答非所问量化精度太低改用 Q8 或 FP16 版本中文乱码模型本身中文能力弱选择 Qwen、GLM 等中文向模型输出不符合格式要求指令遵循能力不足在提示词中增加示例适当降低 temperatureJSON 解析失败模型输出了多余文字使用约束解码功能例如 Ollama 的format: json参数8.4 不同框架下结果不一致同一个模型在 Ollama、llama.cpp、vLLM 中采样逻辑不同输出会有细微差异。评测时要固定一个推理框架并在报告中注明框架和版本否则结果不可复现。这就是为什么本文前面强调“评测环境和生产环境保持一致”。如果你打算用 vLLM 上线评测就在 vLLM 上跑如果你只是在调研可以先用 Ollama 快速出结果但对最终结论保持谨慎。8.5 评测集过小导致结论不稳定20 道题可能看不出差距至少每个维度准备 30 道以上题目8 个维度加起来至少 200 道题才能得到一个相对可信的横向对比。如果时间有限优先保证“逻辑推理、代码、中文理解”这三个维度题量充足。9. 基于横评结果的选型建议与最佳实践9.1 按场景选型根据竞技场评测的维度差异可以给出以下选型参考。注意这只是通用建议具体还是要以你自己的测试结果为准。业务场景推荐的模型方向理由中文客服/对话Qwen、GLM 系列中文语料充分指令遵循相对稳定代码辅助/自动补全DeepSeek 蒸馏、Qwen-Coder代码能力经过专项优化英文内容生成Llama、Mistral 系列英文自然度和多样性更好端侧部署手机/小程序Qwen 0.5B/1.8B、Llama 3.2 1B体积小量化后可控性好数学题目解答Yi、DeepSeek 蒸馏系列数学推理能力相对突出9.2 评测数据管理小模型迭代速度快评测数据要版本化。建议在项目仓库里维护一个eval_sets/v1/目录如果题目有调整就创建v2/不要原地覆盖。每次评测记录评测集版本模型名称和标签推理框架和版本量化位数硬件配置运行时间评测结果文件这样后续模型更新时可以直接用同一套评测集复测对比前后差异。9.3 提示词设计的一致性横向对比时所有模型必须使用完全相同的提示词。不同模型对提示词格式的敏感度不同但竞技场对比看的是“默认通用提示词下的表现”这是最公平的比较方式。如果需要为某个模型专门优化提示词建议单独记录“最优提示词”版本不要混在横评里。9.4 部署时的量化策略如果你已经通过横评选定了一个模型部署前建议做一次“量化敏感性测试”用 Q4 量化模型跑一遍业务核心场景的 50 道题。记录分数和失败案例。改用 Q8 或 FP16 跑同样 50 道题。对比差异是否在可接受范围内。如果 Q4 和 FP16 差异很小可以直接上 Q4 省显存。如果差异明显可能需要增加量化位数或改用更大的模型。9.5 安全与合规建议小模型本地部署在数据安全方面有优势但也要注意几个问题模型可能生成不合规内容需要加一层输出过滤或敏感词检测。不要在模型微调数据中包含未经脱敏的个人信息。对模型的输出进行日志留存方便问题回溯。涉及生产环境变更时先在测试环境完整验证再灰度上线。10. 总结与下一步学习建议本文围绕 karminski 的小模型竞技场横评梳理了小模型评测的方法论和完整落地流程。从评测维度设计、环境准备、脚本编写到结果解读覆盖了一次横向对比评测的全部环节。同时补充了小模型在微信小程序这类端侧场景中的部署思路和注意事项。如果你接下来想继续深入可以从这几个方向入手。先动手复现一次横评。按照本文第 5 章的脚本选 3 到 5 款模型跑一遍完整评测。不用追求题目数量多先跑通流程再逐步扩充你自己的业务评测集。接着研究量化技术。理解 Q4、Q8、FP16 对模型效果和速度的影响是部署环节的重要技能。建议从 llama.cpp 的量化工具入手自己动手转换一个模型。然后学习推理引擎的优化。对比 Ollama、llama.cpp、vLLM 在不同场景下的性能差异尤其是并发请求下的表现。最后关注端侧推理。如果你对微信小程序运行深度学习模型感兴趣可以先从 ONNX Runtime Web 或 TensorFlow.js 入手把一个小文本分类模型跑通。小模型的价值不在于“复刻大模型”而在于用更低的成本解决实际业务问题。希望这份横评框架能帮你找到适合自己业务的那一款模型。如果本文对你有帮助可以先收藏备用后续做模型选型时直接对照执行。