企业内网自建翻译服务：成本、语种与合规的取舍
「数据不能出内网」这条要求一旦提出来，多数团队的第一个反应是买最贵的本地部署方案。但真实算完账会发现，小团队自建翻译服务的成本大头不是算力，是没人维护。
一、自建的真实成本有四项，不是只有一项
- 算力与硬件。这一项反而常被高估。本地部署翻译模型可以从中小参数起步，真正的瓶颈是显存，一台工作站级别的机器往往就够起步。
- 语种与授权。这是最容易被漏算的一项。部分翻译引擎的商业授权是按语种或按用户数计费的，自建不等于免费，用到第 N 个语种时账单会突然出现。
- 维护人力。模型版本升级、依赖环境更新、接口兼容调整、服务监控，这些都要人。没有专人维护的自建服务，三个月内一定会退化，退化方式是「翻译效果变差但没人知道为什么」。
- 效果落差。本地开源模型与一线商业 API 之间的质量差距存在且不小，尤其在小语种和长文档上。差距有多大取决于语种，要自己测出来。
二、按数据敏感度分级，不是按预算分级
判断该不该自建，标准是数据敏感度而不是公司规模：
- 公开信息（官网、产品页、公开文档）：直接用云服务，没必要自建。
- 内部一般信息（内部流程文档、常规沟通）：用云服务，但选有数据不用于训练承诺的企业档，并在合同里写明。
- 涉密或受监管信息（合同、薪酬、未公开财务、人事）：这部分单独走私有通道，不追求全量自建。
第三档是唯一真正需要自建的场景，而它的量通常不大。这也是最经济的做法：只把真正敏感的那部分自建，其余继续用云服务。全量自建的投入产出比通常很差。
三、口译服务这类场景要单独算
很多公司谈自建时，实际需求里混着人工服务。这类服务无法用技术替代，成本口径完全不同——通常按小时计费，且区分会议口译、陪同口译、培训口译等不同类型，计费还要看人员资质。模板化的口译服务预算文件里，这些分类和「按小时单价 + 资质系数」的结构是通用的。 所以第一件事是把需求拆开：哪部分是机器能做的，哪部分必须是人。把「陪同客户考察」这种必须由人做的场景和「内部文档翻译」这种机器完全能做的场景放在一个预算里算，必然算不准。
四、还有一条中间路线
很多团队忽略了折中方案：云端处理常规内容，敏感内容人工或半自动处理。 半自动指的是：敏感文档由机器初译，再由内部人员校订。这比纯人工快，比纯机器可控。它的成本模型是「机器成本 + 校订人力」，而不是「机器成本 + 全人工成本」，通常是可接受的。 另一种折中是先在本地做脱敏再上云：把合同里的主体、金额、日期替换成占位符，云端翻译后再还原。脱敏规则和还原脚本都很简单，但这套做法要求术语和占位符规则维护得足够严谨，否则还原时会出错，风险不可控，要慎用。
五、如果确实要自建，先做这三件事
- 先测质量再买硬件。用目标语种的真实文档样本，跑一遍本地模型和云 API 的对比，量化差距。差距在可接受范围内再往下走。
- 认领维护责任人。没有名字写在排期上的自建项目，一定会烂尾。这一条比技术选型重要。
- 留出退出路径。保持接口与主流服务兼容，将来要换供应商时能平滑迁移。
小结
自建的成本大头是维护人力而不是算力，容易漏算的是语种授权，效果落差要自己实测。判断标准是数据敏感度不是公司规模：公开和内部一般信息直接用云服务，只有涉密或受监管的部分需要单独走私有通道，且通常不需要全量自建。先把机器能做的和必须人做的需求拆开算账，再考虑半自动初译加人工校订这条中间路线。真要自建，先测质量、认领责任人、留退出路径。 本机方案的延伸场景见 浏览器翻译扩展的隐私边界；合同类文本的处理另见 法律合同翻译流程；工具选型见 文档翻译工具怎么选。
来源说明：本文参考了人人文库《口译服务成本预算》文档模板（https://www.renrendoc.com/paper/340766011.html）中关于口译服务的分类方式（会议口译、陪同口译、培训口译、其他）、按小时计价并考虑人员资质因素、以及服务内容与时间范围需在合同中明确的结构。该文档为空白合同模板，所有单价与合同编号均为待填占位符，未包含任何实际价格、行业均价或统计数据，本文未引用任何数值。本文中的四项成本拆解、按数据敏感度分级、先测质量再买硬件、以及半自动初译加人工校订的中间路线为作者基于企业部署选型的补充判断。