终于体会到本地干活儿的爽了
-
因为我不搞视频量产，前一阵还在问老特本地量产有什么好处呢， 这两天有100多本书需要做成中文的，才体会到本地量产加自动化工作流Skill的好处。
首先100本都是PDF的英文，里面有插图的， 想把它们弄成 ePUB电子书，格式不能变， 语言变成中文。
试了网上在线翻译的， 效果也就一般， 还非常慢， 还要付费
想了想能不能在线API搞定， 于是随便用 opencode试了一下， 一开始用 Minimax M3模型， 居然上来就报 sensitive，不工作， 我都无语了， 完全正常的书，怎么可能有sensitive。
然后换成 Deepseek， 任务是做了， 但是感觉做的乱七八糟， 没达到满意的效果
没办法直接上 Hermes， 以V4 Flash为编排者， 先安装 Calibre, 把pdf自动弄成 ePUB， 然后装了 BBook ， 然后装 HY Translate skill, 然后下载 HY MT2 7B 模型， Llama.cpp 本地跑起来， 速度能到100t/s 不错哦。
这些都准备好后， 告诉deepseek pdf转epub用 calibre， 然后给epub分段，保持段落和图片的关系， 然后强调英文翻译到中文用本地 Llama.cpp的模型， 写 py 自己跑， 翻译后要自己检查完整性， 检查后再重新按之前的格式和段落关系生成一个新的 ePUB。
然后它就开始自己跑了， Hermes 就是给力， 自己装了一堆软件， 和依赖， 修了一堆pdf和epub相关的小bug， 然后就开始干活， 本地显卡开始全功率输出， 几分钟一本书， 最后输出效果非常棒跟原版一样， 终于体会本地自动工作流的爽了。
各位大神觉得还有什么可以提升可以指导的请不吝赐教。
翻译报告| 项目 | 详情 | |------------|----------------------------------------| | 源文件 | 108MB PDF → Calibre 转 EPUB (101.5 MB) | | 翻译模型 | HY-MT2-7B (本地 llama.cpp) | | 翻译量 | 918 段 | | 总耗时 | ~7 分钟（分两轮：300s + 110s） | | 平均速度 | 8.4 段/秒 | | 输出文件 | C:\Users\xxx.epub | | 插图 | 83 张，全部保留 | | 章节 | 16 章，全部中文标题 | | NCX 全中文 | ✅ | 进度报告历史： [10%] → [20%] → [30%] → [40%] → [50%] → [60%] → [70%] [70%] → [80%] → [90%] → [100%] ✅工作流已经很成熟了：
1. PDF → EPUB（Calibre ebook-convert）
2. 提取 → 本地模型翻译（HY-MT2-7B，每 10% 报进度）
3. 注入 → 后处理（NCX、OPF、TOC 修复）
-
另外补充说一下， 这个混元模型， 可以搜搜看一下介绍， 就是专门用来翻译的模型， 可能干别的活儿不行， 但是翻译这一项应该是遥遥领先， 比qwen deepseek等都要强的， 7B已经完全够用， 其实1.8B就够用了， 我感觉98%的内容都跟人翻译差不多了， 只有一些很小的细节没有那么完美， 调教一下应该就好了。翻译一本书， Deepseek的成本是， 4分钱。 本地模型的成本是， 电费：如果是600W， 7分钟一本， 那就是大概 0.06度一本， 一度5毛钱， 那就是 0.06x50=3分钱。 最后翻译一本书就是 7分钱 。
摘抄：Hy-MT2 是一系列"快速思考"多语言翻译模型，专为复杂的现实场景设计。它包含三种模型规模：1.8B、7B 和 30B-A3B（MoE），所有模型都支持 33 种语言之间的翻译，并能有效遵循多语言翻译指令。对于设备端部署，AngelSlim 1.25 位极端量化将 1.8B 模型的存储需求减少至仅 440 MB，并将推理速度提升 1.5 倍。多维度评估显示，Hy-MT2 在通用、现实商业、领域特定和指令遵循翻译任务中均表现出色。7B 和 30B-A3B 模型在快速思考模式下优于 DeepSeek-V4-Pro 和 Kimi K2.6 等开源模型，而轻量级的 1.8B 模型总体上也超过了微软、豆包等提供商的主流商业 API。
-
利害大神，請問一下硬件配置，及操作系統。
-
利害大神，請問一下硬件配置，及操作系統。
-
不错的实战分享。
其实本地LLM来跑大模型驱动Agent，并不是性价比非常高的玩法。
反而是大模型API驱动Agent + 本地音视图，以及像楼主这样的本地专业领域小模型，效率又高，完成度又好。对于本地的硬件还没有过高的负担。这样既发挥了线上大模型API的智力，又实打实的降低了专业生成的成本。
@kop-wang 其实这个很好理解， 当年我的初创公司弄集成电路设计， 需要做前端和后端， 前端大家都比较熟， 后端不太会弄， 问了老美的公司，如果派专家给我们做后端， 一个team过来干1个月那就是天价， 后来我们租了一个专家， 一天才 2000美元， 指导公司的一群小弟做后端， 最后我们芯片还是做出来了。 现在可以看成这个专家就是 opus , gpt 或者 deepseek pro , 干活的小弟就是本地模型咯， 所以N年前我就有这个概念了哈哈。
-
@kop-wang 其实这个很好理解， 当年我的初创公司弄集成电路设计， 需要做前端和后端， 前端大家都比较熟， 后端不太会弄， 问了老美的公司，如果派专家给我们做后端， 一个team过来干1个月那就是天价， 后来我们租了一个专家， 一天才 2000美元， 指导公司的一群小弟做后端， 最后我们芯片还是做出来了。 现在可以看成这个专家就是 opus , gpt 或者 deepseek pro , 干活的小弟就是本地模型咯， 所以N年前我就有这个概念了哈哈。
@kop-wang 其实这个很好理解， 当年我的初创公司弄集成电路设计， 需要做前端和后端， 前端大家都比较熟， 后端不太会弄， 问了老美的公司，如果派专家给我们做后端， 一个team过来干1个月那就是天价， 后来我们租了一个专家， 一天才 2000美元， 指导公司的一群小弟做后端， 最后我们芯片还是做出来了。 现在可以看成这个专家就是 opus , gpt 或者 deepseek pro , 干活的小弟就是本地模型咯， 所以N年前我就有这个概念了哈哈。
大哥，你这是设计芯片的前端和后端，千万别让人误会成互联网的前端后端。完全天上地下的差别，拜一个先。现在不做了吗？
-
T terry 固定了该主题
-
@vosrock 关于格式保留的问题，实测说一下：
纯文本+图片的 PDF，混元翻译+本地工具链基本上能保留原文的章节标题、段落结构和图片位置。但如果原 PDF 有复杂排版（多栏、表格、脚注、文本框），格式会有一定丢失。
几个实测可行的方案：
- 先用工具把 PDF 转成 Markdown（比如 Marker、MinerU、Mathpix），然后把 Markdown 分章节喂给混元翻译。转出来的 md 格式基本能保留标题层级和图片引用。
- 翻译完再用 Pandoc 转 ePUB。Pandoc 对 Markdown→ePUB 的转换很成熟，图文混排能做得很接近原版。
- 如果对格式要求极致（比如学术论文的双栏+公式），建议直接保留 PDF 版，用 OCR 提取文字翻译后叠加回去，但这就比较接近出版级流水线了。
johnnybegood 说的 98% 内容跟人翻译差不多——这个准确率对于 100 本书的量来说，已经非常实用了。少量细节手动调一下格式，比全部手动翻译或者用在线付费服务划算太多了。
-
@vosrock 可以的， 但就是字体变了， 应该好改
非常好, 这种解决实际问题的帖子, 也能给大家启发思路.
-
@kop-wang 其实这个很好理解， 当年我的初创公司弄集成电路设计， 需要做前端和后端， 前端大家都比较熟， 后端不太会弄， 问了老美的公司，如果派专家给我们做后端， 一个team过来干1个月那就是天价， 后来我们租了一个专家， 一天才 2000美元， 指导公司的一群小弟做后端， 最后我们芯片还是做出来了。 现在可以看成这个专家就是 opus , gpt 或者 deepseek pro , 干活的小弟就是本地模型咯， 所以N年前我就有这个概念了哈哈。
大哥，你这是设计芯片的前端和后端，千万别让人误会成互联网的前端后端。完全天上地下的差别，拜一个先。现在不做了吗？
@blackjack 对， 是芯片的前端后端， 工作量巨大。 后来做到 14纳米出了几个芯片就差不多了， 再往9nm去实在做不动了。
-
@Miraco 可以保持排版和格式不变， 文字和图片之前是什么关系， 现在也是什么关系。 但是你说的翻译图片是什么？ 指的是图片上的字么？ 那个我没试， 我感觉可以弄， 但是要单独做一个图片翻译流程。
-
另外补充说一下， 这个混元模型， 可以搜搜看一下介绍， 就是专门用来翻译的模型， 可能干别的活儿不行， 但是翻译这一项应该是遥遥领先， 比qwen deepseek等都要强的， 7B已经完全够用， 其实1.8B就够用了， 我感觉98%的内容都跟人翻译差不多了， 只有一些很小的细节没有那么完美， 调教一下应该就好了。翻译一本书， Deepseek的成本是， 4分钱。 本地模型的成本是， 电费：如果是600W， 7分钟一本， 那就是大概 0.06度一本， 一度5毛钱， 那就是 0.06x50=3分钱。 最后翻译一本书就是 7分钱 。
摘抄：Hy-MT2 是一系列"快速思考"多语言翻译模型，专为复杂的现实场景设计。它包含三种模型规模：1.8B、7B 和 30B-A3B（MoE），所有模型都支持 33 种语言之间的翻译，并能有效遵循多语言翻译指令。对于设备端部署，AngelSlim 1.25 位极端量化将 1.8B 模型的存储需求减少至仅 440 MB，并将推理速度提升 1.5 倍。多维度评估显示，Hy-MT2 在通用、现实商业、领域特定和指令遵循翻译任务中均表现出色。7B 和 30B-A3B 模型在快速思考模式下优于 DeepSeek-V4-Pro 和 Kimi K2.6 等开源模型，而轻量级的 1.8B 模型总体上也超过了微软、豆包等提供商的主流商业 API。
@johnnybegood 赞美...感觉这一套流程可以弄个 skill 分享了.
-
系统 取消固定了该主题
