优化本地 LLM 推理用于数据标注和增强任务

本地 LLM 推理将数据准备从完全手动的流程转变为人机协作的工作流。ML 工程师或领域专家不再从零开始标注每个文档，而是审查和纠正 AI 生成的预标注。这些预标注的质量——以及生成速度——取决于本地推理栈的配置水平。

本指南涵盖了在数据标注和增强中使用本地 LLM 的实用优化：选择哪些模型、量化如何影响标注准确率、如何构建提示词以获得一致输出，以及吞吐量瓶颈在哪里。

数据准备任务的模型选择

并非所有模型都同样适合数据准备工作。需求与对话式 AI 不同：

指令遵循：模型必须始终一致地遵循结构化输出指令。如果你要求具有特定键的 JSON，它应该每次都生成那些键——而不是 95% 的时间。
短而结构化的输出：大多数标注任务产生 10-200 个 token 的输出（一个标签、一个 JSON 对象、一段简短的提取）。为长文本生成优化的模型在这里是浪费的。
领域词汇：模型应该处理专业术语而不对其进行改写。医学代码、法律引用和工程术语需要原样通过。

按任务推荐的模型

任务	推荐模型	大小	说明
文本分类	Mistral 7B Instruct, Llama 3.1 8B Instruct	7-8B	快速、准确的类别分配
命名实体提取	Qwen 2.5 14B Instruct, Llama 3.1 8B Instruct	8-14B	14B 提高罕见实体的准确率
情感/主题分析	Mistral 7B Instruct, Phi-3 Mini	3.8-7B	简单任务；较小模型效果良好
文档摘要	Qwen 2.5 14B Instruct, Llama 3.1 8B Instruct	8-14B	较长输出；14B 产生更连贯的摘要
合成数据生成	Qwen 2.5 14B Instruct, Mistral 7B Instruct	7-14B	生成质量随模型大小提升
多标签分类	Qwen 2.5 14B Instruct	14B	更好地处理同时存在的多个标签

7B 甜蜜点：对于大多数分类和提取任务，7B 指令调优模型以 2-3 倍吞吐量提供大模型 90-95% 的准确率。从 7B 开始。仅当你在特定任务上测量到准确率差距时才升级到 14B。

量化权衡

量化将模型精度从 16 位浮点降低到更低的位宽，缩小模型大小并提高推理速度。代价是准确率。

量化级别对比

量化	大小（7B 模型）	VRAM	速度（RTX 4070）	质量影响
F16（无量化）	~14 GB	~15 GB	~20 tok/s	基线
Q8_0	~7.5 GB	~8 GB	~35 tok/s	损失可忽略
Q6_K	~5.8 GB	~6.5 GB	~42 tok/s	损失极小
Q5_K_M	~5.1 GB	~5.8 GB	~48 tok/s	细微任务上轻微损失
Q4_K_M	~4.3 GB	~5 GB	~55 tok/s	复杂提取上可测量损失
Q4_0	~3.8 GB	~4.5 GB	~58 tok/s	明显退化
Q3_K_M	~3.3 GB	~4 GB	~62 tok/s	质量显著下降
Q2_K	~2.7 GB	~3.5 GB	~65 tok/s	不推荐用于数据准备

数据准备的量化建议

分类任务（二分类、多分类）：Q4_K_M 即可。分类输出短且受限。模型要么选对类别要么选错——Q4 保留了足够的精度用于此决策。

实体提取：首选 Q5_K_M 或 Q8_0。提取要求模型从输入中识别并复制特定字符串。较低的量化会导致微妙的 token 级错误（拼写错误、截断实体），在审查中发现这些错误代价高昂。

合成数据生成：最低 Q5_K_M。低于 Q5 时生成文本质量明显下降——句子变得不连贯，专业术语被歪曲，输出需要更多人工编辑。

通用建议：从 Q4_K_M 开始进行初步测试。如果特定任务的准确率可接受，保持使用以获得吞吐量。如果你看到质量问题，升级到 Q5_K_M 或 Q8_0。数据准备工作不要低于 Q4_K_M。

推理后端：Ollama vs llama.cpp vs vLLM

Ollama

最适合：大多数数据准备设置。简单的模型管理，OpenAI 兼容 API，自动 GPU 检测。

配置数据准备：

# 设置并发请求限制（默认为 1）
OLLAMA_NUM_PARALLEL=4 ollama serve

# 拉取模型
ollama pull mistral:7b-instruct-v0.3-q4_K_M

关键设置：OLLAMA_NUM_PARALLEL 控制 Ollama 同时处理多少个请求。数据准备时，如果 GPU 有足够 VRAM，设为 2-4。

llama.cpp（直接使用）

最适合：Ollama 模型注册表无法访问的离线环境，或需要对推理参数进行细粒度控制时。

llama-server \
  --model ./models/mistral-7b-instruct-v0.3.Q4_K_M.gguf \
  --ctx-size 4096 \
  --n-gpu-layers 99 \
  --parallel 4 \
  --batch-size 512

vLLM

最适合：多个并发请求的高吞吐量批处理。除非你在 100K+ 文档上运行批量推理，否则对大多数数据准备场景来说过度。

大多数服务提供商的建议：使用 Ollama。它是通往可用本地推理的最简路径。

批量推理策略

顺序单文档处理

一次处理一个文档。简单，易于调试，中断时易于恢复。

吞吐量：对于生成约 50 个 token 每个标签的 7B Q4 模型，RTX 4070 上预计每分钟 30-50 个标签。即每小时 1,800-3,000 个标签。

并行批处理

并发发送多个推理请求。使用 Ollama 的 OLLAMA_NUM_PARALLEL 或 llama.cpp 的 --parallel。

吞吐量提升：2-4 个并行请求通常将吞吐量提高 1.5-3 倍。RTX 4070 上 4 个并行请求，预计每小时 4,500-8,000 个标签。

提示词批处理（每次请求多个文档）

在单个提示词中包含多个短文档，要求模型对所有文档进行标注。这摊销了每次请求的开销。

权衡：更高的吞吐量（更少的请求），但更复杂的错误处理。最适合错误容易检测的简单分类任务。

数据准备提示词工程的一致性

结构化输出提示词

你是一个文档分类器。将以下文档分类为确切的一个类别。

类别：合同、发票、信函、报告、其他

规则：
- 仅输出小写类别名称
- 无解释、无标点、无额外文本
- 如果不确定，输出"其他"

文档：
{document_text}

类别：

数据准备的关键提示词原则

约束输出空间：明确列出所有有效标签。
精确指定输出格式："仅小写「、」仅 JSON「、」无解释"。重复约束。
为模糊类别提供 2-3 个示例。少样本示例是改进标签一致性最有效的方法。
分类和提取任务将温度设为 0。你需要确定性输出，而非创意变化。

按配置的吞吐量估计

任务	模型	量化	硬件	吞吐量
二分类	Mistral 7B	Q4_K_M	RTX 4070	~3,000 文档/小时
多分类（5 类）	Mistral 7B	Q4_K_M	RTX 4070	~2,500 文档/小时
实体提取（3-5 实体）	Qwen 2.5 14B	Q5_K_M	RTX 4080	~1,200 文档/小时
文档摘要（100 词）	Qwen 2.5 14B	Q4_K_M	RTX 4080	~400 文档/小时
合成生成（500 词）	Qwen 2.5 14B	Q4_K_M	RTX 4080	~120 文档/小时

并行推理（2-4 个并发请求）可将这些数字提高 1.5-3 倍。

准确率与速度的权衡

预标注不需要完美。它需要足够好，让人工审查和纠正比从零开始标注更快。

阈值：如果预标注准确率超过 80%，人工审查员的大部分时间花在确认正确标签（快）上，而不是纠正错误标签（慢）上。准确率超过 90% 时，工作流以确认点击为主。

实际意义：不要以吞吐量为代价过度优化准确率。一个准确率 85%、每小时 3,000 个文档的 7B Q4 模型，比一个准确率 92%、每小时 800 个文档的 14B Q8 模型更有用——因为额外 7% 准确率节省的人工审查时间无法抵消 3.7 倍吞吐量下降。

在提交模型配置之前，在你实际数据的样本上测量准确率。

实际配置

Ertas Data Suite 将本地 LLM 推理作为内置协同工具集成到标注和增强流程中。应用程序与运行在 localhost 上的 Ollama 或 llama.cpp 通信。分类、提取和生成的提示词模板已内置，可按项目自定义提示词。

原生桌面应用加本地推理后端的组合意味着标注界面和模型之间没有网络跳转。点击文档，查看预标注，接受或纠正——所有操作在本地硬件上进行，没有数据离开机器。

对于优化数据准备工作流的服务提供商来说，最大的杠杆是模型选择和量化，而非奇特的基础设施。在具有足够 VRAM 的工作站上使用正确的模型和正确的量化，吞吐量自然随之而来。