上个月社区里最热闹的事，就是那个31B参数的开源模型出来了。一开始大家只是当又一个“中杯”模型来看，毕竟之前也不是没见过20B、30B的模型，跑起来中规中矩，跟真正的百亿千亿选手还是有差距。结果这波测评一出来，直接炸了：MMLU、代码生成、数学推理这些硬指标上，它把不少千亿参数的模型都按在地上摩擦。更关键的是，31B这个体量，刚好卡在消费级显卡能跑、个人开发者能玩、企业私有化部署也负担得起的甜蜜点上。本地部署的格局，确实被这一个小参数模型给彻底改写了。

作为一个常年折腾本地模型的玩家，我第一时间就把它拉下来实测了一轮。这篇文章不写测评报告，我把整个部署过程、参数调优、坑点排查，以及它和千亿级模型之间到底怎么选，全部梳理一遍。不管你是刚入门的萌新，还是已经在搞私有化部署的老手，这里面应该都有你能直接拿走的东西。

1. 这个项目到底改变了什么：本地部署的“不可能三角”

1.1 本地部署的长期痛点

本地部署大模型这件事，过去几年一直是“不可能三角”：大模型效果好，但吃显存吃到怀疑人生；小模型吃得少，但智商也肉眼可见地下降；中间档位则往往两边不讨好。

就拿千亿参数模型来说，光是把权重以FP16精度跑起来，就需要大约200GB显存。这是什么概念？主流消费级显卡最大也就24GB，服务器端常用的高显存卡也就80GB左右。要跑千亿模型，通常得凑4到8张卡，光是硬件成本就不是个人开发者能承受的，更别提电费和散热了。

就算你把模型量化到INT8，也还是要100GB左右。即便勉强加载进去，推理速度也会被显存带宽和计算瓶颈按在地上。所以很长一段时间里，本地部署千亿模型基本是“能跑的买不起，买得起的跑不动”的尴尬局面。

中间档位的模型，比如10B到20B这一档，情况也没好到哪去。早期这些模型普遍是从更大模型蒸馏或者直接小规模预训练出来的，能力差距非常大。做点闲聊和简单翻译还行，一遇到复杂推理、长上下文、结构化代码生成，就原形毕露了。所以我以前给朋友的建议永远是：想要效果，老老实实走API，本地部署只适合折腾玩具或者跑些隐私敏感的小任务。

1.2 “31B打平千亿”的真实含义

这次31B模型的突破，核心在于它真正把“能力密度”拉高了一个量级。过去我们说一个模型的智商主要看参数量，基本上是“力大砖飞”的逻辑，谁参数多谁就强。但这个31B模型证明了一件事：参数量的绝对值没那么重要，重要的是模型内部有没有把知识高效组织起来。

实际测试里，它在多个权威评测集上和千亿模型的差距被压缩到了几个百分点以内，有些子项甚至反超。这意味着，大多数日常任务上，用户几乎感觉不到差异。

举个直观的例子：一段复杂的金融文本摘要，千亿模型给出的结论和这个31B模型基本一致；要求写一段带特定约束条件的业务代码，31B模型输出的代码规范度和可运行性也完全不落下风。只有到了极长上下文推理、超高难度的多步数学证明这类极端测试里，千亿模型的深厚底蕴才看得出来。

所以“打平”并不是说所有领域都完全相等，而是在绝大多数真实使用场景里，你的体感差距已经被压缩到可以忽略不计。配合合理量化，这个31B模型在16GB显存的中高端消费级显卡上就能流畅运行，推理速度甚至比服务器上的千亿级模型还快不少。这直接把“准顶级能力”下发到了个人电脑和中小企业机房里，这就是格局被改写的本质。

1.3 对个人开发者和企业的直接冲击

对个人开发者来说，以前你想玩一个接近顶尖能力的模型，基本只有云端API一条路。现在31B模型本地一跑，不光延迟更低、不花API费用，更重要的是数据全程不出本机，写代码、处理私人文档、搞点副业自动化，再也不用担心隐私泄露。

对企业和机构来说，这个模型的吸引力更是致命的。很多行业受合规约束，数据根本不允许上传到公网API，私有化部署是刚需。过去他们必须花大价钱买多卡服务器来跑千亿模型，现在一台单卡工作站就能顶大部分场景。硬件成本直接降一个数量级，部署和运维门槛也大幅下降。我认识的一个做内部知识库问答的团队，原来预算都在租卡上，现在直接切换到本地部署这个31B模型，响应速度还更快了。

说到底，这个项目的意义不在于“又发了一个新模型”，而在于它把高性能AI的实用门槛切切实实拉到了大众可及的位置。

2. 以小博大的核心技术拆解

2.1 架构与训练方法：把“聪明”装进更小的瓶子里

一个31B模型凭什么打平千亿模型？光是堆训练数据肯定不够，关键是架构设计和训练方法上做了几件很聪明的事。

首先是混合专家架构的广泛采用。传统稠密模型处理每个token都要激活全部参数，31B的“总参数”虽然多，但每个token实际只激活一小部分专家网络。也就是说，模型“记得”的东西很多，但每次回答问题只需要动用其中一小块知识，计算成本远低于理论上31B全量计算。这有点像公司里虽然注册了两万人，但每处理一个项目只需要抽调一个精英小组，大幅提升了知识利用效率和组织运作效率。

其次是知识蒸馏和训练配方的进步。小模型想继承大模型的能力，不再简单靠“看大模型的输出”来模仿，而是通过多级蒸馏、对比学习、课程学习等一系列手段，让模型学会大模型的推理路径和决策逻辑，而不只是记住答案。再加上后期用强化学习对齐人类偏好，模型的指令遵循能力和格式规范性都会明显强于早期同体量模型。

还有一个被很多人忽略的因素：数据质量与训练配方的精细化。过去预训练就是海量数据往里灌，杂质很多；现在这套流程会做多轮数据清洗、质量过滤、去重、配比调整，让每一G的数据都尽量“有用”。同样的参数量，脑子里装的全是精炼干货，自然比装一堆垃圾信息强得多。

所以，别看到31B就下意识觉得“不过是个中杯”。这个模型背后其实是三套班子的协同优化：架构上做稀疏化、训练上做蒸馏对齐、数据上做精筛。三管齐下，参数量的劣势被大幅弥补了。

2.2 量化与推理优化：部署层面的隐形加成

如果说架构和训练是模型本身素质的提升，那么量化技术和推理框架的进步，就是让这个素质能顺利落地的关键。

先说量化。模型权重默认是FP16格式，每个参数占2字节；31B模型光权重就是62GB，消费级显卡根本装不下。常见的做法是量化为INT8或者INT4，把权重精度降低，换体积和显存占用的大幅缩减。例如4bit量化之后，单个权重只占约0.5字节，31B模型权重降到16GB左右，一张24GB显卡就能装下，还留出上下文缓存的空间。

这里很多人担心量化会严重损害模型能力。其实，现代量化技术的精度损失已经非常可控。比如用Q4_K_M这类量化格式，实测下来在绝大多数任务上只比FP16低一到两个百分点，体感几乎无差异。原因在于，量化不光是把数字粗暴截断，还会做混合精度处理、关键层保留更高精度、以及基于校准集的误差补偿。尤其对于几B级以上模型，冗余度本身就高，压到4bit往往还是“余量充足”。

另一边，推理框架的优化也在同步发力。现在主流的本地推理引擎普遍支持KV Cache量化、连续批处理、FlashAttention、投机采样这类的技术，能做到逐token生成时缓存更小、并发利用率更高，长上下文场景下也不会因为缓存爆炸而OOM。这些工程层面的优化，很多时候比硬件升级带来的体感提升更明显。

所以你看到的现象是：同一个31B模型，在好的推理框架加合适量化下，生成速度可能比裸跑FP16快两到三倍，而输出质量几乎不变。这就是部署层面的“隐形加成”。

2.3 评测指标之外的真实能力边界

只看MMLU这类基准分数，容易陷入“唯指标论”的误区。我在实测中格外关注的是几个“评测不会告诉你”的能力维度。

一是长文本一致性。很多评测只测试短问答，但真实场景经常要模型读几千字的文档再总结。31B模型在几万字上下文内，前面说过的细节能不能在几十轮后还记得住，这个很考验工程本事。实测下来，这个模型的长期记忆能力相当不错，只要上下文窗口给足，多轮对话前面提过的偏好和要求都能守住，这点比我很早前玩过的一些百亿级模型都好。

二是代码生成的“工程可用度”。能跑通单元测试不等于能直接用于工程。真实业务里，代码要处理边界条件、异常分支、可读性、风格一致。这个模型生成的代码整体结构非常清晰，函数命名和注释都接近人类工程师习惯，直接进仓库的改造成本很低。

三是“结构化输出”的稳定性。做自动化流程时，最烦模型输出一堆格式混乱的JSON。这个31B模型在指令里要求输出JSON并指明字段，生成结果基本每次都能严格合规，无需后处理修正。这对做Agent类应用的人来说是刚需。

当然短板也是有的：最极端的高难推理、跨越超大知识面的复杂规划、需要大量专业知识精确记忆的场景，它和千亿模型还是有肉眼可见的差距。所以我的判断是，在80%甚至90%的业务场景里，它可以完全替代千亿模型；剩下10%的极限场景，才需要把千亿模型请出来坐镇。

3. 本地部署31B模型全流程实操

3.1 第一步：硬件评估与显存预算

想把31B模型部署起来，第一步不是下载模型，而是算清楚你的硬件到底撑不撑得住。显存是决定性的瓶颈，内存也不能拖后腿。

我给大家一个简单的估算公式：模型权重显存占用 = 参数量 × 每个权重的字节数。以31B为例：

• FP16（2字节）：约62GB
• INT8（1字节）：约31GB
• INT4（约0.5字节）：约16GB

但这只是模型权重本身，上下文KV Cache还要额外占显存。上下文越长，缓存越大。大致估算，8K上下文在4bit量化下额外占2到3GB，16K上下文可能吃到5GB以上。

我实测的推荐配置如下表，大家可以对照自己的硬件来判断：

如果你的显卡只有12GB显存，也不是完全不能玩，但建议选择Q2_K或者Q3_K这类低档量化，并把上下文长度限制到4K以内，必要时把一部分层卸载到内存跑CPU。整体能跑，但速度和效果都会有妥协。

如果你完全没有独立显卡，想纯靠CPU跑，也不是不行，但至少要有64GB以上内存。把模型全部放内存里，靠CPU算，速度会比较感人，可能只有每秒一两个token，只适合验证性测试，不适合实际使用。

我给新手的建议是：别一上来就追求最高质量，先在自己硬件允许的范围内把流程跑通，再慢慢调高量化档位和上下文长度。这个循序渐进的过程能帮你避免很多挫败感。

3.2 第二步：模型与量化版本选择

确定硬件后，就是选模型文件和量化版本。社区里这个31B模型发布时会同时放出FP16原版、以及多个社区的量化转换版。

这里一定要理解原版和量化版的关系。FP16原版是“母版”，量化版是基于它转换压缩出来的，而量化过程也会因为工具和校准集不同产生质量差异。有些人图省事直接下最小的Q2版本，结果发现输出质量崩了，然后痛骂模型不行，这其实是版本选错了。

我的经验是：优先选择文件名里带有Q4_K_M标记的版本，这是目前质量和体积比较均衡的档位。如果你显存确实紧张，再退而求其次选Q3_K_S之类的版本，但要做好心理准备，某些复杂任务表现会有明显波动。

下载一定要从官方或大型可信镜像站点获取，不要贪图某个不明来源的“超小体积版”，里面可能被插入恶意代码或者故意阉割了关键能力。我见过有人下到一个小体积版本，跑起来速度飞快，但回答质量极其拉胯，后来才发现是被别人反复压缩过好几轮的“压榨版”，信息损失已经不可逆了。

下载完成后记得核对校验值，保存好源文件。后续如果要重新量化或者对比不同档位，母版还在就随时能重来。

3.3 第三步：推理框架部署与参数设置

模型文件到手后，就轮到推理框架登场了。目前社区最通用的方案是加载GGUF格式模型文件，配合命令行推理工具来跑。这套组合的好处是跨平台、依赖少、支持CPU和GPU混合推理，对新手最友好。

部署流程大致分三步。

第一步，安装运行环境。以常见的Linux服务器或者Windows系统为例，你需要先准备好Python环境和显卡驱动，确认显卡能正常被系统识别。然后在终端里安装模型运行框架，这里以主流开源推理引擎为例。安装本身不复杂，主要坑在于版本匹配。框架版本太旧可能不支持最新模型架构，太新又可能要求更高的显卡驱动版本。建议直接安装最新稳定版，如果运行报错，再根据提示调整驱动。

第二步，用命令行加载模型。这一步相当于把模型文件装进推理引擎这个“枪膛”里。最常见的启动格式是：

./runner -m /path/to/31b-model.Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192 --threads 8

这里有几个参数非常关键：

• -m指定模型文件路径，不解释。
• --n-gpu-layers控制把模型多少层放进显卡。设成999意思是全部交给GPU跑，速度最快；如果显存不够，就要适当调低这个值，比如设成20或者30，让剩余层跑CPU。
• --ctx-size是上下文窗口长度。8192适合大部分场景，太小容易截断长对话，太大会吃显存。
• --threads是CPU线程数。如果你有部分层跑CPU，这个参数对速度影响很大。

第三步，基于命令行做交互测试。加载完成后，进入交互模式，就能直接输入问题。这一步主要目的是确认模型有没有正常跑起来，先问几个简单问题验证响应，再逐步提高问题复杂度。

这里建议新手务必先用命令行方式跑通，再考虑图形界面封装。因为命令行模式能直接看到日志输出、显存占用、token生成速度，排查问题比图形界面直观得多。我之前习惯一步到位上图形界面，一旦出问题，日志被界面吞掉大半，排查起来非常痛苦。

3.4 第四步：快速验证与基础脚本

跑通命令行交互后，我建议马上用一个最简单的Python脚本把模型调用固化下来，后面做批量测试、接入自己的工具链都会方便很多。推理框架一般都提供了对应的编程接口，安装好对应的依赖库，几十行代码就能调用模型。

这里分享一个最小可用的调用脚本，假设你已经装好了相应的运行时库：

from llm_engine import LlmModel model = LlmModel() model.load("/path/to/31b-model.Q4_K_M.gguf") response = model.generate( "用三句话总结一下本地部署大模型的优缺点。", max_tokens=256, temperature=0.7, top_p=0.9, ) print(response)

每个框架的接口名称可能略有不同，但整体结构都一样：加载模型、发送请求、带采样参数、拿回结果。

temperature和top_p这两个参数尤其值得新手注意。temperature控制随机性，越高回答越发散，越低越保守；top_p控制候选词采样范围。做事实性问答建议把temperature调到0.3以下，做创意写作可以调到0.8以上。很多老手跑模型感觉效果不稳定，往往就是这两个参数没调好，而不是模型本身的问题。

还有一个小技巧：把模型加载和请求推理分离。模型加载一次后留在内存里，后续多次调用就不用反复加载了。否则每跑一次脚本重新加载，31B模型光加载时间可能就要几分钟，效率极低。

4. 性能调优实录与多场景实测

4.1 我的实测环境与测试方法

为了帮大家组一个可直接参考的配置，我用自己的主力机跑了一轮完整测试。机器配置是主流消费级水平：24GB显存的显卡，64GB内存，八核CPU。这套配置不是顶配服务器，但对个人开发者来说有一定代表性。

部署方案上，我选择了Q4_K_M量化版本，全部模型层加载到显卡，上下文长度设置为8192。测试任务分成四类：知识问答、代码生成、长文本摘要、多轮推理对话。每类任务跑10轮，统计平均生成速度和主观质量评分。

为了公平对比，我还用同一个31B模型跟一个千亿参数模型（跑在云服务器上）做了同题测试，测试维度包括首字延迟、生成速度、答案完整度和指令遵循度。

这里先说一个容易踩的测试误区：评价生成速度不能只看“每秒多少token”，还要看首字延迟。本地模型LLM是逐token流式生成的，首字延迟普遍比云端API高一些，尤其在首次请求时模型要经历预热。我测试时专门把首字延迟和稳态生成速度分开统计，这样对比才客观。

4.2 不同量化档位的速度与质量对比

我针对同一个31B模型，分别测试了Q2_K、Q4_K_M、Q5_K_M、Q8_0四个档位。结果非常有意思，这里放出来给大家参考：

显存占用和生成速度都是实测平均值。可以看到，Q2_K速度确实最快，但质量折损严重，复杂问答经常出现逻辑断裂，不建议日常使用。Q4_K_M是我最推荐的档位，显存占用只比Q2多了4GB，速度依然很快，质量却能拿到8.5分，性价比极高。Q8_0虽然质量最高，但显存需求一下子跳到32GB级别，很多消费级卡根本装不下，而且速度明显下降，反而不划算。

这组数据说明一件事：在一定范围内，量化档位对质量的影响远大于对速度的影响。新手没必要为了省那几GB显存去硬上低档量化，优先保证质量体验才是关键。

还有一个小发现：Q5_K_M跟Q8_0的质量差距其实很小，两者差10倍以上的体积，但主观感受几乎没差异。所以大模型本地部署真的别过度焦虑精度损失，除非你跑的是科学计算这类需要严格数值一致性的任务，否则日常使用4bit、5bit完全够用。

4.3 长文本、多轮对话与代码生成专项测试

常规问答只能算热身，真正考验模型实力的还是长文本和多轮对话。

长文本摘要测试里，我丢给它一份20页左右的项目报告，要求提取核心结论和风险点。Q4_K_M档位在8192上下文下完整吞下全文没问题，摘要结果从结构到信息完整性都很接近千亿模型。最让我意外的是，它还能准确引用原文里的具体数据，比如某项目的成本上升比例、某个时间节点，这种细节型信息对推理模型的记忆容量要求很高，以前30B档位模型很容易丢。

多轮对话测试则体现了指令遵循的稳定性。我模拟了一个包含前置条件的复杂任务：第一轮要求它记住“所有回复不要用数字”，然后后续几轮不断追加约束。这个31B模型撑到第五轮依然没有破功，回答的格式和内容都符合要求。千亿模型在这个测试里表现确实更稳，能撑到第八轮，但对于日常工具型应用，第五轮的稳定性已经足够用。

代码生成方面，我让它写一个带异常处理的文件解析脚本，要求兼容多种输入格式、输出标准化结构。生成的代码结构良好，包含完整的try-except分支和日志埋点，几乎可以直接放进生产环境。相比之下，我之前在同类30B模型上得到的代码经常缺边界条件，稍一加压就崩。这说明架构和训练方法的改进，在代码生成这条赛道上提升特别明显。

4.4 调优后的最佳配置参考

经过几轮调整，我最终在稳定性和速度之间找到了一个比较满意的平衡点。说下我的最终配置：Q4_K_M量化档位，全部层加载到GPU，上下文长度设置为12288，线程数保持默认，采样参数temperature设0.7、top_p设0.9。

实际体验下来，稳态生成速度稳定在35 token/s以上，手速远远跟不上它输出，交互体感非常顺畅。上下文长度从8192提升到12288之后，处理长文档的容错空间大了不少，而显存占用只多了不到3GB，性价比很高。

这组配置不是唯一最优解，我建议你根据自己的实际任务微调。如果你主要在写代码，temperature可以降到0.4以下，让输出更确定；如果你在做创意写作，temperature调到0.9也问题不大。关键是理解每个参数对输出的影响，而不是死记一个固定值。

调优过程中我习惯用同一组固定的测试问题反复对比，这样参数改没改好一测便知。不建议每次换问题，那样变量太多，根本看不出哪个参数起效。

5. 常见问题与排查技巧实录

5.1 显存溢出（OOM）的排查与解决

显存溢出是本地部署31B模型最常见的修罗场，新手遇到基本都是一脸懵。典型表现是加载模型或者生成到一半，程序直接报错退出，提示显存不足。

排查顺序应该从三个角度入手。第一，看量化档位是否过高。如果你直接用Q8_0跑24GB显卡，加载就会爆，这种情况直接换Q4_K_M。第二，看上下文长度是否设置过大。很多人喜欢一上来就拉满32K上下文，结果KV Cache直接把剩余显存吃穿。可以先用4096跑通，再逐步往上加。第三，看是不是模型全部加载进GPU导致的。如果显存只差一点点，可以把--n-gpu-layers从999降到一个合适值，比如30，让顶层留在CPU，这样显存压力小很多，速度损失有限。

我遇到过最隐蔽的OOM是通过图形界面工具间接启动模型，工具默认开了超大上下文，界面里还没地方改，一加载就爆。这种问题只能回归命令行模式，自己控制参数。

5.2 生成速度过低的瓶颈定位

如果模型能正常生成，但速度只有每秒几个token，就需要系统性找瓶颈了。我发现大部分速度问题出在三个环节：GPU层数不够、内存带宽瓶颈、CPU线程数设置不合理。

先用系统监视器确认显卡占用率。如果显卡占用率很低但显存被占满，说明模型大部分权重被放到了CPU，计算在CPU上跑，GPU只是存数据，自然慢。解决办法是把--n-gpu-layers调高，让更多层进入显卡计算。

如果CPU占用率拉满但速度依然慢，就要考虑是不是因为显卡显存不足，导致一部分权重放在内存，每次计算都要通过PCIe总线搬运，这种场景下内存带宽成了瓶颈。对策是优先保证权重量化足够低、尽量全部进显存，或者降低上下文减少缓存占用，把显存腾给权重。

另外，笔记本用户要特别留意散热和电源策略，很多笔记本在插电和电池模式下性能差两倍，跑模型必须接电源并调整系统性能模式为最佳。

5.3 量化后效果变差的补救方案

不少人按我说的选了Q4_K_M，但跑起来还是觉得效果不对，第一反应就是“量化毁智商”。其实量化只是个替罪羊，很多时候问题出在别处。

先检查你的采样参数。temperature太高会导致输出发散，尤其在代码生成和逻辑推理上，高随机性会让模型看起来“变笨了”。把temperature降到0.5以下再试，很多“降智症状”会瞬间消失。

再看看是不是上下文被截断。如果模型看不到完整的输入，或者关键信息已经在窗口滑出范围，回答质量自然崩。处理长文档时，优先保障上下文长度，必要时把文档分段摘要再拼接。

最后才是考虑量化本身。如果你已经排除了以上因素，仍然觉得质量差，可以试Q5_K_M或者Q8_0做对比测试。我实测Q5_K_M相比Q4_K_M的提升空间其实很小，但每个模型、每个任务的表现不完全一样，值得试试。我遇到过某个特定数学任务，Q4_K_M死活做不对，换成Q5_K_M后一次过，这种事情没有规律可言，只能实测。

5.4 什么时候该用千亿模型，什么时候31B就够

写这篇博文的时候，估计很多人心里还在纠结：就算31B再强，到底能不能完全替代我现在的千亿模型方案？我的观点是，先冷静梳理你的真实需求。

如果任务类型是文档处理、知识库问答、日常工作流自动化、一般代码生成、内容改写这类的高频场景，31B模型完全够用，而且它的部署成本、响应速度都远超云端千亿模型，数据还不用出内网。

如果任务涉及极高难度的长链条推理，比如多步数学证明、复杂系统架构规划、跨领域专家级问答，或者需要模型在几十万字上下文中精确回溯和推理，那么千亿模型依然有不可替代的优势。这时候最理性的做法不是二选一，而是把两者做成级联架构：先用31B模型处理大量常规请求，遇到置信度低的请求再自动升级到千亿模型。这种混合方案既能控制成本，又能保证极端场景的质量下限。

从我个人的实际测试来看，正在跑的生产系统里，架构升级到千亿模型的请求比例通常不超过10%，也就是说90%的流量完全可以让31B模型本地消化。这个数字足以说明它对现有部署格局的冲击有多大了。

5.5 本地部署的日常维护与升级

最后聊点日常维护的细节。模型部署不是一锤子买卖，后续的模型更新、量化版本替换、运行日志监控都要花心思。

我建议养成写部署脚本的习惯，把模型文件路径、运行参数、显卡分配都写清楚，不要靠记忆填一堆参数。这样遇到模型升级，只需要改一下模型文件名重新跑脚本，不用每次都从头折腾。

模型文件建议保留母版和常用量化版两个副本，磁盘占用虽然大一些，但省去重复下载的麻烦。给不同任务准备不同量化档位的模型也值得考虑：日常快速交互用Q4_K_M，需要精确输出时切到Q8_0版本。

在实际操作中，我最大的体会是：本地部署这条路上，最稀缺的不是硬件，而是调试的耐心。很多人被一次报错劝退，就再也不敢碰了。但只要你肯多试几次参数组合，多看一下日志信息，慢慢会发现每一个报错背后都是有规律可循的。踩过几十次坑之后，我现在看到错误提示基本能秒判断出问题出在量化档位、上下文长度还是驱动版本上。这行当没什么捷径，经验就是一次次试错堆出来的，但这个31B模型值得你为它花这点时间。