企业官网建设流程全解析

1. 一台旧笔记本和两个 G 的空闲显存：我为什么盯上了这个轻量开源模型

发布公告挂出来的第二天，我就把权重拉下来了。原因很朴素：我手边没有一张能舒舒服服跑大模型的卡，主力是一张 12G 显存的消费级显卡，外加一台 32G 内存的老笔记本和一台纯 CPU 的办公机。过去半年我用过不少开源模型，但绝大多数都要我在“效果”和“跑得动”之间做取舍，要么动辄二三十 G 显存起步，要么量化到 4bit 之后中文能力直接塌方。这次放出来的这一系列走的是轻量路线，官方给了两个规格，还同时放了预训练和指令微调两套权重，这个组合正好戳中我的需求点。

我更关心的是三件事，而不是跑分榜上的名次。第一，小参数规模下中文能力还剩多少，能不能应付写作润色、文本清洗这类日常活；第二，量化之后掉点有多严重，尤其是指令遵循和结构化输出这两项，一旦不稳就没法接进脚本；第三，工具链成熟度，模型放出来当天能不能顺利跑通，还是得等社区补齐转换脚本、对话模板、量化支持。这三件事决定了它是“能玩的玩具”还是“能干活的工具”。

这篇记录就是我完整的上手过程，包括我怎么算显存、走了哪几条部署路线、拿六类任务实测的结果，以及四个把我卡了快两小时的坑。适合谁看：手里只有消费级显卡或者干脆只有 CPU、想在自己机器上跑一个能干活的小模型的人；也适合已经在用大模型 API、但想搞清楚本地部署到底能到什么水平的人。我不会只给结论，每一条实测数据后面都会说清楚为什么是这样。

1.1 先把硬件底牌摊开：我用的三台机器

不讲清楚测试环境的效果评测基本都是耍流氓，所以先把三套环境列出来。主力机是 12G 显存的消费卡配 32G 内存，系统盘是固态，模型权重放在另一块盘上；第二套是一台只有集成显卡的笔记本，32G 内存，8 核处理器；第三套是一台更老的办公机，16G 内存，4 核，专门用来看最低配能不能跑。三套环境覆盖了“有独显”“纯 CPU 大内存”“纯 CPU 小内存”三种典型情况，也能把量化前后的差异看得更清楚。

我刻意没有去借服务器卡。原因在于，如果我只在 24G 以上的卡上测，得出的结论对你我这种普通用户意义不大——那种环境下几乎所有模型都“能跑”，真正的分水岭在 8G 到 12G 这一段。这一段里，显存不是“够不够”的问题，而是“够跑多长的上下文、能开多大的批”的问题，细节差一点，体验就是天壤之别。

顺带提一句准备工作：权重文件不小，两个规格、两套权重加起来几十个 G，下载前先看一眼磁盘剩余空间。我第一次就是下到一半提示空间不足，回头清理了半天缓存目录。另外，权重文件的校验别跳过，我有一次因为网络抖动导致分片损坏，加载时报了一个非常误导人的错误，排查了半小时才发现是文件本身的问题。

1.2 两个规格、四套权重，选哪个其实有讲究

这个系列给了两个参数规模，每个规模都有预训练版和指令微调版。很多人第一反应是“无脑选大的、选指令版”，但实际用下来，这个选择得看你要干什么。

预训练版和指令版不是“新旧版本”的关系，而是两种完全不同的东西。预训练版权重只学会了“预测下一个词”，你直接拿它对话，它会把你输入的指令当成文章开头继续往下续写，这在第一次用的时候非常容易误解成“模型坏了”。指令版是在预训练权重基础上做过对齐的，能听懂“请把下面这段话改写成正式语气”这种要求。我见过不少人拿预训练版测对话效果，然后得出“这模型不行”的结论，其实是选错了权重。

我的建议很直接：除非你要做微调，否则一律下指令版。要做微调的话，预训练版才是对的起点，因为指令版已经被对齐过一轮，你在上面继续训容易把原有能力带偏。至于 2B 还是 7B，把这句话记住就行——2B 用来做“转换”，7B 用来做“生成”。让它把一段非结构化文本转成 JSON、把长句压成短句、把表格转成描述，2B 完全够用而且快得多；让它写一段有逻辑的说明文、写一个能跑的脚本，7B 才开始有像样的表现。

2. 上手前先算一笔显存账：为什么你的 8G 卡跑 7B 会卡在最后一步

很多人部署失败不是操作错了，而是对显存占用的构成没有概念，看到“7B 模型 4bit 量化后 4G 多”就以为 8G 卡绰绰有余，结果一跑就爆。显存占用从来不是只有权重那一块，它是三部分叠加：权重 + KV 缓存 + 框架运行时开销。只算第一项，必然翻车。

2.1 权重、KV 缓存、运行时开销，三块显存怎么拆

权重这部分好算，公式是“参数量 × 每个参数占的字节数”。半精度（fp16 或 bf16）每个参数 2 字节，7B 就是 7 × 10⁹ × 2 ≈ 14 GB，2B 就是约 4 GB。8bit 量化每参数 1 字节，7B 约 7 GB。4bit 理论上每参数 0.5 字节，但实际不能按 0.5 算——量化时会按块存储缩放系数和零点，这些额外开销实打实占空间，我实测下来按每参数 0.65 字节估比较稳，7B 大概 4.5 GB 左右，2B 大概 1.3 GB 左右。这个 0.65 的系数是我踩过坑之后固定下来的估算值，按 0.5 算出来的数字往往会让你在长上下文时突然爆掉。

KV 缓存是最容易被忽略的一块，也是最容易在长文本场景下突然把你打死的。它的大小和序列长度成正比，公式是：

KV 字节数 = 2 × 层数 × KV 头数 × 每头维度 × 序列长度 × 批大小 × 每元素字节数

2 是因为要同时存 Key 和 Value。拿 7B 这一档举例，假设 32 层、32 个 KV 头、每头维度 128、半精度存储，那么每个 token 的 KV 开销是 2 × 32 × 32 × 128 × 2 = 524288 字节，也就是 512 KB。听起来很小，但乘上 4096 的上下文长度就是 2 GB，乘上 8192 就是 4 GB。如果模型用了分组查询注意力（GQA），KV 头数只有 8 个，那这个数字直接降到四分之一，4096 上下文只要 512 MB。这就是为什么有些模型“看起来参数一样”，实际显存需求差一大截。

运行时开销这块最玄学，取决于框架、显卡驱动、计算后端的版本，一般按 0.6 到 1.2 GB 估。我第一次部署时就是因为没预留这部分，权重加载完显示还剩 800 MB，一推理立刻 OOM。

把三块加起来，7B 4bit + 4096 上下文 + 半精度 KV 的实际占用大约是 4.5 + 2 + 0.8 ≈ 7.3 GB。8G 卡理论上能跑，但基本没有任何余量，稍微把上下文拉到 8192 或者开个批就爆。这就解释了为什么很多人“明明按 4G 权重算的，8G 卡却跑不起来”。

2.2 我整理的一张对照表，直接对号入座

这张表是我一台一台机器实测填出来的，不是拍的。有个反直觉的点值得说：纯 CPU 跑 7B 4bit 在 32G 内存的机器上其实可用，因为内存便宜、容量大，上下文可以拉得很长，代价是生成速度慢。如果你的任务是离线批处理——比如晚上跑一批文档清洗，第二天早上看结果——纯 CPU 方案完全可行，而且不用跟显卡抢资源。

2.3 为什么我最后选了 4bit 而不是半精度

12G 卡其实能跑 7B 半精度，权重 14 GB 装不下，所以严格说跑不了。但 2B 的半精度是能跑的，我也试了。结论是：在这个参数规模上，4bit 量化带来的精度损失，远比显存节省带来的收益小。

我拿同一个测试集（一百条中英混排的指令，覆盖摘要、改写、格式转换）分别跑了 2B 半精度和 2B 4bit，用同一套提示词、同样的采样参数（温度 0.2、top_p 0.9）。差异主要体现在两处：一是生成长文本时的重复率，4bit 版本偶尔会把同一个短语重复两遍；二是在需要精确数字的任务上，4bit 偶尔会把数字写错一位。这两类问题都可以通过降低温度和加一条“不要重复表达”的约束显著缓解。而在显存上，2B 从 4 GB 降到 1.3 GB，意味着我可以在同一张卡上并行跑两三个实例做批处理，这个收益是实打实的。

对于 7B，我的选择更没悬念——半精度根本装不下，4bit 是唯一能在我机器上跑起来并且留出上下文的方案。这里有个实操心得：量化时优先选带“K 量化”变体的方案（把部分层用更高位宽保存），这类方案在同样的平均位宽下对精度更友好，代价是体积略大一点。我在 7B 上对比过普通 4bit 和 K 量化 4bit，前者在长文本续写上更容易出现语气漂移，后者明显稳一些，体积只多了不到 0.3 GB，非常划算。

3. 三条部署路线我都跑了一遍：谁快、谁省事、谁适合进生产

同样的权重，部署方式不同，体验能差出好几倍。我把三种主流路线都跑通了，下面把每一步的操作、耗时和实测表现摊开讲。这一段我会尽量把命令写全，你可以直接照着改路径用。

3.1 路线一：标准 Python 推理栈，最稳但最吃资源

这条路是最“正统”的，加载权重、写推理循环，全都自己控制。好处是你能碰到模型内部的一切——可以改采样逻辑、可以取出每层的隐状态、可以自己实现流式输出。坏处是它对显存最不客气，因为框架本身要占一块，而且默认不会做任何优化。

import torch from transformers import AutoTokenizer, AutoModelForCausalLM MODEL_PATH = "./weights/l-series-7b-instruct" tokenizer = AutoTokenizer.from_pretrained(MODEL_PATH) model = AutoModelForCausalLM.from_pretrained( MODEL_PATH, torch_dtype=torch.bfloat16, device_map="auto", ) model.eval() messages = [ {"role": "user", "content": "把下面这段话压缩成两句，保留所有数字：..."} ] prompt = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True ) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): out = model.generate( **inputs, max_new_tokens=512, do_sample=True, temperature=0.3, top_p=0.9, repetition_penalty=1.1, ) print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

这段代码有几个地方值得单独说。apply_chat_template这行是重中之重，它负责把对话结构拼成模型训练时见过的格式，少了它模型的表现会莫名其妙地差——这个坑我在第 5 节详细讲。torch_dtype用 bfloat16 而不是 float16，是因为前者动态范围更大，长文本生成时不容易出现数值溢出导致的乱码。repetition_penalty我基本都会开，小模型在长生成时更容易陷入重复循环，1.1 到 1.15 是比较安全的区间，再高会让表达变得生硬。

实测下来，7B 4bit 在这条路线上（用支持量化的加载方式）在 12G 卡上的生成速度大约是每秒 18 到 22 个 token，首 token 延迟 0.3 到 0.5 秒。速度不算快，但胜在可控。如果你要做的是研究性质的实验，或者需要修改模型内部行为，这条路没得选。

3.2 路线二：量化推理引擎，老机器也能跑起来

这条路是我最推荐的日常方案。它的核心思路是：先把权重转成专门的量化格式，然后用一个高度优化的推理引擎加载，引擎会针对不同硬件做算子融合和内存布局优化。我第一次在纯 CPU 的老机器上跑出每秒 7 个 token 的时候还是挺惊讶的，因为同样的模型用标准 Python 栈在那台机器上几乎是不可用的。

整个流程分两步。第一步是格式转换和量化：

# 把原始权重转成引擎可读的中间格式 ./bin/convert --input ./weights/l-series-7b-instruct \ --output ./gguf/l-series-7b-f16.bin \ --type f16 # 再量化到 4bit（K 量化变体，对精度更友好） ./bin/quantize ./gguf/l-series-7b-f16.bin \ ./gguf/l-series-7b-q4k.bin \ q4_k_m

这里的q4_k_m就是前面提到的 K 量化变体，不同引擎的命名不一样，但思路一致：大部分层用 4bit，少数敏感层用 5bit 或 6bit。转换过程在 8 核 CPU 上大概跑了七八分钟，量化又花了五六分钟，总共不到一刻钟。这个时间成本是可以接受的，而且是一次性的。

第二步是加载和推理：

./bin/run -m ./gguf/l-series-7b-q4k.bin \ -p "把下面这段话压缩成两句，保留所有数字：..." \ -n 512 \ --temp 0.3 \ --top-p 0.9 \ --repeat-penalty 1.1 \ -c 8192 \ --threads 8

-c 8192是上下文窗口，这个参数直接决定 KV 缓存的显存/内存占用，按第 2 节的公式算就行。--threads在纯 CPU 场景下很关键，设成物理核心数通常最优，设成逻辑核心数反而会因为超线程争抢而变慢——我在 8 核 16 线程的机器上试过，8 线程比 16 线程快大约 15%。

这条路线的实测数据：12G 显卡上，7B 4bit 生成速度每秒 26 到 34 个 token，比标准 Python 栈快了差不多一半；纯 CPU 8 核上每秒 6 到 9 个 token；2B 4bit 在同样的 CPU 上能到每秒 25 个 token 以上，做批处理完全够用。首 token 延迟也明显更低，短提示词下能压到 0.1 秒出头。

3.3 路线三：一键式管理工具，五分钟出结果

如果你只是想“先看看它长什么样”，不想碰任何转换和参数，这条路最省事。这类工具帮你把权重下载、格式转换、服务启动全包了，一条命令拉起一个本地接口。

# 拉取并启动（首次会自动下载权重） local-model run l-series:7b-instruct-q4 # 直接对话 local-model run l-series:7b-instruct-q4 "用三句话解释什么是 KV 缓存"

从敲命令到看见输出，我这台机器上花了不到五分钟（不含权重下载时间）。它会自动起一个本地 HTTP 服务，默认监听一个端口，你直接用普通的 POST 请求就能调：

curl http://127.0.0.1:11434/api/generate -d '{ "model": "l-series:7b-instruct-q4", "prompt": "把这段文本转成 JSON：张三，28 岁，负责后端", "stream": false, "options": {"temperature": 0.2} }'

方便是真方便，但代价是你能调的参数少了很多，底层用的是哪个量化变体、上下文怎么分配，都不太透明。我把它定位成“探索期工具”：想快速判断一个模型值不值得深入，用它最省时间；真要接进生产流程，我还是会切回路线二，因为参数可控、行为可预测。

3.4 三条路线的实测数据摆在一起看

这张表里最值得琢磨的是“从零到跑通耗时”这一行。路线二看着最麻烦，但它的一次性成本换来的是长期的效率优势；路线三最省时间，但你会在调参上把省下的时间还回去。我的实际做法是：路线三用来做初筛，路线二用来做正式工作，路线一留着做实验。

3.5 选型结论：按你的场景对号入座

不给模糊建议，直接分场景说。如果你要跑批处理——比如几千份文档的清洗、分类、摘要——选路线二，把上下文设小一点（2048 就够），开多个进程并行，性价比最高；2B 4bit 在这种场景下比 7B 划算得多，速度快三四倍，效果损失在“转换类”任务上几乎察觉不到。

如果你要做交互式使用——边写东西边问它——选路线二或三都行，但记住把温度调低（0.2 到 0.4），小模型在高温下容易跑偏。如果你要研究模型行为，比如想知道某一层在干什么、想换一种采样策略，那只能选路线一。如果你只有 CPU 且内存不大，老老实实上 2B 4bit，别硬撑 7B，加载失败反复重试的时间成本远高于收益。

还有一个我踩过的坑值得提前说：不管走哪条路线，第一次跑通之后先把版本号记下来。我有一次隔了两周回来重跑，发现引擎升级了，默认的量化方案变了，同样的提示词输出风格完全不一样，排查了半天才想起来是版本问题。

4. 六类任务实打实跑分：参数小到底亏在哪里

跑通只是开始，能不能干活才是关键。我设计了六类任务，每类准备了 20 到 30 条测试样例，同一套提示词、同样的采样参数（温度 0.3、top_p 0.9、repetition_penalty 1.1），用 7B 指令版 4bit 跑。评分是我人工看的，标准很简单：能不能直接用，还是必须大改。

4.1 中文长文写作：句子通顺，但“记得住”是个问题

让它写 800 字左右的说明文，开头两段的质量经常让我有点意外——句式不僵硬，连接词用得也对，甚至会主动分段。问题出在中后段：写着写着就开始重复前面说过的意思，或者突然插入一句和前文无关的话。我统计了一下，20 条写作任务里有 14 条在后三分之一出现了明显的逻辑漂移，需要人工修剪。

这类问题的根源在于小模型的上下文利用效率。参数少意味着它能同时“记住”的约束少，你在提示词里给了五六条要求（字数、语气、结构、不能出现某类词），它往往只能守住前三四条。我的应对办法是把要求按重要性排序，最重要的放最前面，并且把“字数”这类硬约束放在最后单独强调一句。这个调整之后，逻辑漂移的比例从七成降到了四成左右。

还有一个实用技巧：分段生成比一次生成好得多。让它一次写 800 字，后半段质量必然下滑；改成先让它列提纲，再逐段生成，每段 200 字以内，整体质量提升非常明显。代价是调用次数变多，但在本地跑，这个成本基本可以忽略。

4.2 代码补全：小模型的高光区

这是它表现最好的地方，好到有点超出预期。让它写一个读取目录下所有文本文件、按行去重、输出统计结果的 Python 脚本，20 条任务里有 17 条一次跑通，剩下 3 条是有小问题（比如没处理编码、路径拼接用了字符串相加）。函数级别的补全更稳，我给一个函数签名和注释，它补出来的实现基本可以直接用。

为什么代码任务表现好？我理解是因为代码的“约束密度”高——语法结构本身就限制了输出空间，模型不需要做太多自由发挥。而自然语言写作的自由度太大，小模型的短板就暴露了。这个特性很有用：如果你要用小模型，优先把它用在输出格式确定的场景，代码、JSON、表格、固定模板的文本，都是它的舒适区。

不过有个坑要注意：它写出的代码经常“看起来对但跑不通”，尤其是涉及第三方库的 API 时。我遇到过它把一个常见库的函数参数顺序写反了，语法完全合法，运行才报错。所以我的习惯是——它写的代码必须先跑一遍再说，绝不直接粘进项目。

4.3 数学与多步推理：这是它的明确短板

两位数乘法的正确率大概七成，三位数乘法掉到四成以下，涉及多步推理的应用题基本全军覆没。这不是这个系列独有的问题，小参数模型在这个方向普遍不行。让它算“一件商品打八折后再减 20 元，原价 350，最终多少钱”，它有一半的概率会在中间步骤算错，而且错得很自信。

我试过用“一步一步想”的提示词引导，正确率提升有限，从五成到六成左右。真正有效的办法是让它写代码算，而不是让它心算。同一个问题，我改成“请写一段 Python 代码计算这个结果”，正确率立刻到九成以上——因为它把计算交给了代码执行，自己只负责翻译题意。这个思路在实务中非常有用：凡是涉及精确计算的，都让它输出代码而不是输出数字。

4.4 指令遵循与格式约束：JSON 输出稳不稳

这是我最看重的一项，因为它决定能不能接进自动化流程。我让它把非结构化文本转成指定 schema 的 JSON，20 条里 18 条格式完全正确，2 条在字段值里加了不必要的解释性文字（比如把"age": 28写成"age": 28（根据文本推断））。这个成功率是可以接受的，但我加了两道保险。

第一道保险是在提示词里给一个完整的示例，包括输入和期望输出，这比单纯描述字段类型有效得多。第二道保险是解析失败时自动重试，重试时把上一次的错误输出和“请只输出 JSON，不要任何解释”一起塞回去，实测重试一次能把成功率提到 95% 以上。

import json, re def extract_json(text): # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 兜底：抓第一个大括号块 match = re.search(r"\{.*\}", text, re.S) if match: try: return json.loads(match.group()) except json.JSONDecodeError: return None return None

这个函数看着简陋，但在我实际跑批处理时救回来不少条。小模型经常会在 JSON 前后加一句“好的，结果如下”，正则兜底能把这层壳剥掉。

4.5 长上下文：注意力被稀释的现场

我把上下文拉到 8192 做了个测试：在一段约 6000 字的技术文档开头埋一个特定的事实，然后在末尾提问。7B 4bit 能答对的概率大概六成，而且位置越靠前越容易漏。把同样的事实放在文档最后 1000 字内，正确率能到九成。这符合“中间信息丢失”的普遍规律，小模型上更明显。

实操建议就一条：关键信息别埋在长文档中间。如果必须处理长文档，先做一次切分或者摘要，把关键段落提到提示词末尾。我处理长合同时的做法是先用 2B 模型按章节切分并生成每节摘要，再把摘要和需要精确回答的原文片段一起喂给 7B——两级处理之后，准确率提升非常明显，而且总耗时反而更短，因为不用让 7B 啃整篇。

4.6 一张表看清哪些活能放心交给它

这张表的用法是反着看的：先看你的任务落在哪一行，一次可用率低于 70% 的，要么换思路（比如数学改成写代码），要么加人工环节，别硬上。

5. 四个把我卡了快两小时的坑：从“输出乱码”到“上下文溢出”

这一节是整篇里我觉得最有价值的部分，因为这些问题在官方说明里基本不会写，但你几乎一定会遇到。我会把排查链路完整写出来，包括我一开始的错误判断。

5.1 坑一：对话模板没对上，模型开始自问自答

第一次跑的时候，我直接用了最朴素的拼接方式，把用户输入前面加一句“用户：”，后面加一句“助手：”，然后丢给模型。结果它输出的内容是“助手：好的，我来回答。用户：请问还有什么问题吗？助手：没有了。”——自己跟自己聊起来了。

我一开始怀疑是模型权重有问题，重新下载了一遍，问题依旧。后来才想明白：指令微调模型在训练时用的是一种特定的对话格式，格式里包含特殊的控制标记，你用自然语言的“用户：”“助手：”去模拟，模型认不出来，它就按预训练时学到的“续写对话文本”的模式继续编下去了。

正确的做法是用分词器自带的模板方法，它会按模型训练时的格式拼好，包括那些你看不见的特殊标记。这个改动带来的效果差异巨大——同一个问题，改之前输出是自问自答，改之后是干净的一段回答。这个坑的排查成本很高，因为报错信息完全没有，输出也不是乱码，只是“行为怪异”，很容易往模型能力上归因。

顺带说一句，用一键式工具的时候这个问题会自动被处理掉，这也是为什么很多人用工具测觉得“挺好”，自己写代码就“变傻”了——差的往往就是这一行模板调用。

5.2 坑二：量化后指令遵循明显变差，问题出在什么环节

我最早用的是最朴素的 4bit 量化，量化完发现格式输出开始不稳——本来能老老实实输出 JSON 的，现在经常在前面加一段解释。我一度以为是量化必然带来的损失，准备接受。后来对比了 K 量化变体，发现同样的位宽下，K 量化版本的格式遵循明显更好。

原因不难理解：朴素的均匀量化对所有层一视同仁，但模型里有些层对精度更敏感（通常是注意力输出投影层和最后几层），这些层被压到 4bit 之后，模型对“格式约束”这种精细指令的响应就变差了。K 量化的思路是把这些敏感层保留在更高位宽，平均位宽还是 4bit，但关键位置没被压坏。体积上多了不到 0.3 GB，这个代价我认为完全值得。

排查这个问题的正确顺序应该是：先确认提示词和模板没问题，再怀疑量化方案，最后才怀疑模型能力。我一开始顺序搞反了，先去调提示词，浪费了不少时间。

5.3 坑三：显存明明够却 OOM，罪魁是缓存没释放

有一次我写了个循环，连续处理一批文档。第一批跑得好好的，第二批就 OOM。看显存占用，跑完第一批之后并没有完全释放，剩下的部分越积越多。原因是我在循环里每次都重新构造输入张量，但没有主动清理中间变量，而框架的缓存分配器会保留已分配的内存块以备复用，它判断的依据是“还有没有引用”。

解决办法有两个层次。浅层的做法是在每轮结束时显式清空缓存并回收内存：

import torch, gc for doc in docs: result = run_inference(doc) save(result) del result gc.collect() if torch.cuda.is_available(): torch.cuda.empty_cache()

深层的做法是干脆别在循环里反复构造——把推理封装成一个常驻的服务，输入输出走队列，这样内存分配只发生一次。我后来改成了后者，稳定性好了非常多，也顺带解决了模型反复加载耗时的问题（加载一次 7B 权重就要十几秒，循环里重复加载是巨大的浪费）。

5.4 坑四：中文分词方式让我误判了上下文长度

这个坑比较隐蔽。我一直按“字符数”来估算上下文够不够用，觉得 8192 上下文能放八千个汉字。实际测试发现，中文文本被切出来的 token 数经常是字符数的 0.6 到 1.2 倍不等，取决于内容——纯口语化的短句切得碎，token 数可能比字符数还多；文言或者专有名词多的文本，切得更碎。

有一次我喂了一段七千多字的文本，自以为没超，结果被截断了，模型回答时明显缺失后半段的信息。后来我改成每次调用前先用分词器算一下真实长度：

tokens = tokenizer(text, add_special_tokens=False)["input_ids"] print(f"字符数 {len(text)}，token 数 {len(tokens)}") if len(tokens) > MAX_CTX - RESERVED_FOR_OUTPUT: text = truncate_smart(text, MAX_CTX - RESERVED_FOR_OUTPUT)

注意RESERVED_FOR_OUTPUT这个预留，很多人只算输入不算输出的空间，结果输入刚好塞满，模型没有余量生成，输出被截在半句话上。我一般预留 512 到 1024 个 token 给输出。

6. 把它缝进日常工作流：三个我每天都在用的用法

模型跑通、效果摸清之后，剩下的问题就是怎么让它真正省下时间，而不是变成一个偶尔打开玩玩的 demo。我最后固化下来三个用法，都是每天在跑的。

6.1 批处理脚本：让 2B 干脏活

我每天要处理一批从各种渠道收集来的文本，格式五花八门——有的是带 HTML 标签的，有的是带一堆空格的，有的是中英混杂需要统一。这些活的共同特点是：量大、规则模糊、写正则太费劲。用 2B 模型做正合适，速度快、成本低，效果损失在“转换类”任务上几乎看不出来。

关键设计是把任务拆到最小。不要让模型“清洗这段文本”，而是明确说“删除所有 HTML 标签，保留文字内容，把连续空格压成一个，不要改动任何文字本身”。任务描述越具体，小模型的表现越稳定。我一开始图省事写了个笼统的提示词，结果它经常“顺手”帮我改写句子，把原文的措辞都动了。

还有一个提升吞吐量的技巧：把多条短文本打包成一批送进去，让模型按编号逐条输出。实测下来吞吐量能提升两到三倍，因为省掉了大量重复的上下文开销。代价是偶尔会有编号错位，所以我在解析时加了编号校验，对不上就退回逐条处理。

6.2 起一个本地接口，给编辑器插件用

这是我最常用的一个。路线二起一个本地服务，监听本机端口，然后在编辑器里配一个自定义的补全源，选中代码按快捷键就发给本地模型。好处是代码不出本机，而且没有调用次数限制，用起来毫无心理负担。

配置的关键是控制上下文长度。编辑器里如果无脑把整个文件都塞进去，很容易超上下文，而且速度会很慢。我的做法是只取光标前后各 100 行，再附上文件路径和语言类型作为提示。这样响应时间稳定在 1 秒以内，体验就接近可用了。

另一个细节是流式输出。本地模型生成一个完整回答可能要几秒，但流式输出能让第一个字秒出，主观感受差别很大。大部分推理引擎都支持流式，接口层面就是用 SSE 或者按行返回，接起来不复杂。

6.3 提示词模板固化：别每次现编

用过一段时间之后我发现，同一个任务每次手写提示词，效果波动很大。后来我把常用任务的提示词全部固化成模板文件，只替换变量部分。这件事看着笨，但收益很高——它把“调模型”变成了“调模板”，而模板是可以版本管理的。

我的模板文件长这样：

# 模板：结构化抽取 v3 # 变更记录：v2 增加了“不要推测”约束，v3 把示例改成两条 你是一个信息抽取工具。请从下面的文本中抽取字段，只输出 JSON，不要输出任何解释。 要求： 1. 字段不存在时填 null，不要推测 2. 数字保持原样，不要单位换算 3. 日期统一格式为 YYYY-MM-DD 示例输入：... 示例输出：... 待处理文本： {{text}}

模板里那三条要求是被踩出来的。第一条是它经常自己“脑补”缺失的字段；第二条是它爱把“三万元”转成 30000，看着聪明，但下游处理时就对不上了；第三条是日期格式不统一会让后面解析崩掉。这些都不是模型的问题，是提示词没约束到。

顺带说一个经验：模板的变更记录一定要写。我有一次改了一个模板，忘了记录，过了两周发现效果变差了，完全想不起来改了什么，只能从头对比。现在每个模板文件开头都有变更记录，改一行记一行，看着啰嗦，但真能救命。

最后分享一个我自己的体会。这类轻量开源模型最容易被误用的方式，是拿它去对标那些参数量大一个数量级的模型，然后得出“不行”的结论。我早期也这么干过，试了半天觉得哪哪都不如，差点放弃。后来换了思路——不问“它能做到什么”，而是问“我手上有哪些活，是它刚好能干、而且我原来干得很烦的”——才发现它的真正价值在那些“不值得调用大模型”的琐碎任务上：格式转换、批量清洗、代码补全、结构化抽取。这些活占了日常工作的很大比例，交给它之后，我省下的不是钱，是注意力。

另一个反直觉的点是：小模型的效果对提示词质量极其敏感。同样一个任务，提示词写好写坏，效果能差出三成。这意味着投入时间打磨模板的回报率，比在小模型上投入时间调参数高得多。我现在花在写提示词上的时间，大概是在调采样参数上的五倍，这个比例我觉得是对的。