Dataset Generator v1.0.3-beta 提供本地 LLM 支持 — 在不为 API 花一分钱的情况下微调你的模型

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

概述

前段时间，我发布了一个生成 LLL‑微调数据集的桌面应用程序。
它运行良好：我的 Qwen2.5‑Coder‑7B 微调在 HumanEval 上从 55.5 % → 72.3 % 提升。
整个流水线在 OpenRouter 上运行——选择模型，点击 Generate，即可得到 JSONL 文件。

v1.0.3‑beta 现在支持 多供应商 LLM——Ollama、LM Studio、llama.cpp，或任何自定义的兼容 OpenAI 的端点，以及原来的 OpenRouter。
随意组合使用：在本地的 Qwen3‑14B 上生成，在廉价的云模型上评估，或完全离线运行。

下面是对已发布功能、意外困难以及经验教训的快速概述。

新功能

1️⃣ 一键本地 LLM 检测

• 路径： Settings → Providers → "Auto‑detect local"
• 应用会探测以下端口：

• 任意响应的端点都会出现 一键 “Add” 按钮。
• 对离线优先的用户来说，入门时间现在约为 ≈ 30 秒。

2️⃣ 混合模式流水线

• 每个 category 可以使用自己的提供者。
  • 示例：在本地 Qwen2.5‑Coder‑14B 上运行 Gen，在廉价云模型（例如 GPT‑4‑mini）上运行 Judge。
  • 或者为不同的 category 使用不同的生成器——例如在代码专用本地模型上运行 algorithm category。
• 流水线会自动将每次调用路由到对应的后端。

3️⃣ 自定义端点

• 任意 OpenAI 兼容的 URL 都可使用（vLLM、TGI、自托管网关等）。
• 只需粘贴基础 URL + 可选的 bearer token → 完成。

4️⃣ 本地任务即时取消

• 云 API 在几秒内完成，协作式取消非常简单。
• 本地 14B 模型在单次聊天补全上可能会运行几分钟。
• v1.0.3‑beta 将 asyncio.Task.cancel() 直接接入正在进行的 HTTP 请求，使取消感觉 即时（≈ 1 秒），而不是等待超时（≈ 8 分钟）。

5️⃣ 推理模型自动处理

• 像 Qwen3、DeepSeek‑R1 等模型会输出 … 块，在产生任何实际输出前就消耗完全部 token 预算。
• 流水线会检测 “推理饥饿”（empty content + finish=length + reasoning present），并自动使用 4 倍更大预算 重试。
• 无需手动干预。

6️⃣ 跨提供者的 Token 计数

结果： Quality Report 与每个示例的 token 计数现在保持一致。

7️⃣ 基于能力的提供者抽象

• 早期版本在代码中到处散布 if provider.kind == "ollama" 检查。
• 重构为 ProviderCapabilities 标志：

supports_provider_routing
supports_reasoning
requires_api_key
has_pricing
supports_embeddings

• 现在添加新后端只需 一个类 + 一个注册表条目 —— 对 job_runner.py 零 改动。

8️⃣ 默认提供者重新分配的用户体验

• 旧行为：禁用默认提供者（例如 OpenRouter）后，系统进入静默孤儿状态；下一次任务会因 “Provider ‘openrouter‑default’ is disabled”（422）而失败。
• 新行为：后端会 自动提升 下一个已启用的提供者为默认，并在前端弹出 4 秒的 toast —— “Default switched to Ollama (local)”。

这是一处小 bug，发现后即可轻松修复。

解锁的用户角色

经验教训

1️⃣ 14B 本地模型是实际底线

• 7B/9B 变体可以生成技术上有效的输出，但会 偏离主题、重复模式并误解类别。
• 在云端节省的时间会在被拒绝的示例上花费 5 倍。
• 14B 是最低要求；如果显存足够，32B 使用起来更舒适。

2️⃣ 判官模型比生成模型更重要

• 小型本地判官（≈ 8B）往往会 机械打分（95‑100），不论质量如何。
• 更大的判官（≥ 14B）可能会 漏掉 好的示例，因为它们没有把握住类别。
• 在云端投入资金用于判官，或者如果硬件允许，使用 32B+ 本地判官。

3️⃣ 混合模式是关键特性

• 原本预期“完全离线”是主要优势，但大多数用户想要的是：

cheap local model → generate volume (≈ 7 000 examples)
strong cloud model → judge (quality control)

• v1.0.3‑beta 使其成为 单行配置 —— 从一个提供商选择生成器，从另一个提供商选择判官，然后部署。

4️⃣ 每个提供商的并发限制带来复杂性却收益甚微

• 原型：配置 “Ollama: 1, OpenRouter: 10”，以防全局信号量淹没本地 GPU。
• 实际上，单用户、单 GPU 的设置占主导（≈ 99 % 的用户）。
• 此功能已在 v1.0.3‑beta 中 移除，并为未来企业使用保留。

接下来是什么？

• 企业级并发控制（需求出现时重新引入）。
• 更好的令牌预算内省，用于隐藏推理令牌的提供商。
• 更多提供商能力标志，随着生态系统扩展（例如，流式传输、函数调用）。

欢迎尝试 beta 版，报告错误，并提出改进建议！ 🚀

多GPU vLLM – 实际需要它的人？

模型选择器中的提供者徽章
当两个提供者提供相同的模型名称（例如，llama‑3.1‑8b 同时在 Ollama 和 OpenRouter 上）时，选择器会显示两个外观相同的条目。我草绘了一个小徽章 UI 来区分它们，随后意识到典型的部署并不会出现名称冲突（你知道每个模型放在哪）。于是把它留到以后打磨时再处理。

相同的基础，全新层

架构迁移

• providers 表 在 v6 中新增，并对旧的单一 OpenRouter 密钥进行回填。
• 现有部署在首次启动时会静默迁移。

测试

• 460 项通过（相较上个版本从 329 项提升）
• 完整覆盖四个后端、注册表解析、自动检测、混合模式任务。

许可证与发行

• AGPL‑3.0（保持不变）
• 单文件发行（Linux AppImage，Windows .exe）。

开源仓库

• 应用仓库 (v1.0.3‑beta)：
• 原始发布帖子（含 HumanEval + 16pp 基准）：previous dev.to post
• 数据集（2,248 条示例）：
• 微调模型：

接下来

1. 系统托盘版本

   • 长时间生成（在本地硬件上 5,000+ 示例 = 数小时）需要比永久打开窗口更安静的用户体验。
   • 托盘图标，“下一个任务已就绪”通知，点击即可恢复仪表盘。

2. 嵌入提供商选择器

   • 去重在后端支持多提供商，但 UI 只展示 OpenRouter 的嵌入模型。
   • 添加一个小下拉框，让本地用户也能通过 Ollama 使用 nomic‑embed‑text 进行去重。

3. 针对 LiveCodeBench 和 BigCodeBench 的两个新类别

   • 之前的帖子解释了为什么这些基准几乎没有变化（LCB 的格式不匹配，BCB 的库类别过于宽泛）。
   • 两项修复正在进行中：
     • 为 LCB 添加覆盖边缘案例的算法练习。
     • 为 BCB 提供库‑API‑精确的分类法。

4. 社区反馈

   • 如果你在本地生成数据集，使用的模型规模是多少，接受率如何？
   • 特别想了解是否有人从 ** Disclosure: I drafted this post with AI help — the same way I built the app. 中获得了真实价值。