把翻译模型搬上消费级显卡：一次端侧迁移的完整复盘

团队之前翻译走云端 API，账单逐月爬坡之后我们起了心思：能不能把翻译模型搬到本地显卡上。折腾三周，跑通了，也踩了一身泥。这篇复盘把决策、选型、调优的完整过程摊开——给同样在算这笔账的朋友一个参照。

系列前情：批处理失效恢复（一）（二）讲的是任务层，这篇回到算力层。

为什么是消费级显卡

RTX 4060 8G，二手不到两千块。翻译模型普遍 1B~7B 级别，量化后塞进 8G 显存绰绰有余——这和「3G 内存装下 35B 多模态」的端侧压缩是同一个思路：模型体积从来不等于显存占用，量化、卸载、稀疏激活三件套能把实际占用压到标称的几分之一。

迁移的三周时间线

第 1 周：选型。跑了三个开源翻译模型的小参版本，用自己的技术文档语料做回归——通用基准分数接近，但术语密集语料拉开了差距。教训：选型语料必须用自己的，通用榜单在垂直场景会骗人。

第 2 周：量化。INT8 起步，显存占用从 13G 压到 4.2G，质量回归几乎无感。试过 4Bit，显存再省一半，但长句译文出现肉眼可见的「翻译腔加重」——最终定档 INT8，宁可贵一点显存。

第 3 周：吞吐调优。batch size、KV Cache 复用、词表裁剪（只留双语词表，词表小了 60%，解码快了一截）。单卡 QPS 从 3 提到 11，日常团队量够了。

账面对比

迁移前：API 月账单按 token 计，用量涨账单线性涨。迁移后：电费+折旧摊下来约为原账单四成，一次投入半年回本。前提是我们的调用量已经稳定在每天百万 token 级——如果只是偶尔翻几页文档，别折腾，API 更省心。

真正的代价不在硬件

三周里写代码的时间不到三分之一，剩下都在：处理上下文窗口的取舍（长文档分段的边界问题）、术语表的热更新、和办公网显存抢占（同事中午拿这卡跑 Stable Diffusion，翻译服务直接 OOM——最后上了显存预留配额）。

复盘清单

1. 端侧迁移的启动条件：调用量稳定 + 有垂直语料做回归 + 有人维护
2. 量化档位用质量回归定，不用显存数字定
3. 显存是共享资源，上配额管理比事后排查 OOM 划算
4. 留 10% 流量走云端做对照——自建的翻译质量也需要「对照组」持续验证

迁移完成不是终点。下周讲讲端侧模型的更新策略：开源模型迭代很快，什么时候跟、怎么无痛切换，这是自建路线的长期成本。

---

写文里这些翻译场景，来自我日常在用的「随心翻译」：Edge/Chrome 浏览器插件，本地优先架构，不用不花钱。官网 suanlinfang.cn/translate?from=cnblogs