2026阿里云国际版机器翻译实战教程：每月100万字符免费额度怎么用、四档资源包同为$15/百万该怎么买、5000字符上限与HTML标签计费、Python SDK调用与术语词典干预

Meta Description: 2026阿里云国际版机器翻译教程：每月100万字符免费额度、按量$33/百万与四档$15/百万资源包怎么选、45.5%利用率门槛、5000字符上限与HTML标签计费、Python SDK调用与术语干预、三场景成本测算。

关键词：阿里云国际版机器翻译、Machine Translation、alimt、文本翻译 API、通用版、专业版、TranslateGeneral、Translate、Scene、资源包、每月100万字符免费、字符计费、HTML 翻译、术语词典、词典干预、Python SDK、跨境电商翻译、多语言出海

一、直接回答：机器翻译是什么，什么团队该用它

阿里云国际版机器翻译（Machine Translation，产品代号 alimt）要解决的是一句话问题：「我的内容要变成十几种语言，但我既不想雇译员，也不想自己部署模型。」

它和你在百炼 Model Studio里调大模型做翻译，是两件不同的事：

• 大模型翻译：一个通用推理模型，你写 prompt、给上下文、它给你译文。灵活，但输出长度不可控、按 token 计费、质量随 prompt 波动。
• 机器翻译 API：一个专用 NMT 引擎，输入源语言 + 目标语言 + 文本，输出译文，返回里直接给字符数。按字符计费、延迟低、结果可预期，适合塞进商品详情、客服会话、帮助中心、App 界面这种「一天几十万次、每次都短」的位置。

一句话结论：如果你要的是「批量、稳定、便宜、可嵌入流水线」的翻译，用机器翻译；如果你要的是「带上下文改写、润色、本地化创意」，用大模型。

它的能力边界（先看数字，再看场景）

三条判断，帮你决定要不要读下去

• 该用：跨境电商的商品标题/详情/客服会话；SaaS 帮助中心与文档站；出海 App 的界面文案与 UGC；海外诉讼/医疗/金融资料的初翻（再用人工校对）。
• 可以但要注意：技术文档里大量代码与专有名词——引擎会把 git rebase 翻成「git 变基」，必须配术语词典（第七节）。
• 别用：创意文案、品牌 slogan、需要「改写而非翻译」的营销内容——这不是 NMT 引擎的活。

顺便纠正一个流传很广的说法：阿里云国际站产品页至今把通用版描述成「提供中英之间的高质量翻译」，而文档站的语言代码表明确列出 212 种语言。这不是笔误，是产品页文案多年没更新。以文档站的语言代码表为准，产品页那句只当历史遗留。

二、两个版本、两套 API：先把这张对照表记住

阿里云机器翻译国际版有两个版本、对应两套调用风格，这是新手最容易踩的第一个坑——搜到的老教程用一套，你照抄却调不通另一套。

关键结论：专业版不额外收费。 官方计费页对两个版本只说了一句话——「两个版本都含每月 100 万字符免费额度」，价格表也只有一张。这意味着领域引擎是白送的：只要你的内容属于电商/医疗/金融/社交，就应该把 Scene 切到对应领域，而不是留在 general。

专业版的 6 个 Scene 代码

REST（专业版路径）的请求骨架

文档给出的完整 URL 模式是 http://mt.cn-hangzhou.aliyuncs.com/api/translate/web/{edition}，其中 {edition} 只有两个取值：general（通用文本，配 Scene=general）和 ecommerce（电商文本，配 Scene=title）。

请求体就五个字段，全部必填：

{
  "FormatType": "text",
  "SourceLanguage": "en",
  "TargetLanguage": "zh",
  "SourceText": "hello",
  "Scene": "title"
}

这里有一处官方文档自相矛盾：专业版介绍页明确写了 6 个 Scene（含 medical/social/finance），但 REST 调用指南的 edition 表只列了 general 和 ecommerce 两行，Scene 列也只给了 general/title。实测结论是：先用控制台「API 调试」页确认你的账号能选到哪些 Scene 与 edition，别拿文档的 edition 表当全集。医疗/金融这类领域引擎，多半是要走 ecommerce 路径再传 Scene=medical/finance，但这一点官方没有明写，属于必须自己验证的部分（第九节会再提）。

ROA 签名：只在你不用 SDK 时才需要关心

专业版走的是 ROA 风格 + HMAC-SHA1 签名，Authorization 头形如 acs <AccessKeyId>:<Signature>。必带的头有：

签名串的拼法是先拼头、再接 URI，两部分直接相连、中间不加分隔符：

• 头部分（每项后跟一个 \n）：POST → Accept → Content-MD5 → Content-Type → Date → x-acs-signature-method:HMAC-SHA1 → x-acs-signature-nonce:<随机串> → x-acs-version:2019-01-02
• 资源部分：就是 URI 路径本身（该接口无 query 参数，所以不需要排序拼接）
• 最后：Base64(HMAC-SHA1(AccessKeySecret, 整串))

官方在这页开头就写了一句很重要的话：能用 SDK 就用 SDK，签名它替你做了。只有你的语言/环境没有官方 SDK 时，才值得手写这段——手写时最容易错的三处是 Date 用了本地时区、Content-MD5 算的是十六进制而不是 Base64、以及忘了 x-acs-version。

三、开通与鉴权：四步，十分钟

第 1 步：开通服务（两个版本分别开通）

控制台入口是 common-buy-intl.alibabacloud.com/?commodityCode=alimt_intl#/open。进去后勾选协议、点 Open now，通用版与专业版是两个独立的开通项——只开通通用版，专业版的 Scene 就调不通。

开通本身不收费，只是把服务挂到你的账号上；之后按小时结算实际用量。

第 2 步：建 RAM 子账号，别用主账号 AK

生产环境用主账号 AccessKey 是重大风险。正确做法是建一个 RAM 用户，只授予机器翻译相关权限（控制台里搜 AliyunMTFullAccess 之类的策略名，或按最小权限自定义），再给这个子账号生成 AccessKey。

注意错误码 10009 / 10010：前者是「RAM 用户没有权限」，后者是「账号未开通服务」。看到 10010 先回去确认第 1 步是否只开通了其中一个版本。

第 3 步：把 AK 放进环境变量

官方文档明确要求不要硬编码。两个变量名是 SDK 约定的：

export ALIBABA_CLOUD_ACCESS_KEY_ID=your-access-key-id
export ALIBABA_CLOUD_ACCESS_KEY_SECRET=your-access-key-secret

两行写进 .bashrc 后就当完事，是不合格的——.bashrc 对其他用户可读、也会被备份带进镜像。生产环境用 systemd 的 EnvironmentFile=（权限 600）或密钥管理服务更稳妥，这也是我们另一篇 ActionTrail 审计里反复强调的「凭据不进代码、不进 shell 历史」。

第 4 步：先用控制台调试页跑通一次

控制台自带 API 调试页，填源语言、目标语言、一段文本，点发送就能看到返回。这一步别跳过，原因有两个：

1. 它会显示你的账号实际可用的 Endpoint 与 Region，这比文档里写的 mt.cn-hangzhou.aliyuncs.com 更可信；
2. 它会消耗字符——官方明确写了「API 调试消耗字符的费率与生产调用相同」，所以调试也别拿一本小说去试。

四、价格全表：四档资源包是同一个单价，这是我今年读到最反直觉的一张价目表

官方计费页的原文只有几行，但信息量足够算出一整套采购策略：

观察一：四档包的单价完全相同，「买得越多越便宜」是官方自己写错的

把四档的单价各自除一下：15 ÷ 1 = 15，150 ÷ 10 = 15，1500 ÷ 100 = 15，15000 ÷ 1000 = 15。四档全部是 $15/百万，一分钱不差。

而阿里云自己的开通向导页写着：「Buy the corresponding resource package. The unit price is lower if more resource packages are bought.」——买得越多单价越低。这句话在 2026 年 10 月的价目表上不成立。

这不只是文案瑕疵，它直接改变采购决策：既然四档同价，买大包没有任何单价优势，唯一的变量是「你买多了会不会浪费」。买 1 亿字符的包却只用了 3,000 万，剩下的 7,000 万在 1 年后作废——这比按量付费还贵。

观察二：算一下「利用率门槛」，是 45.5%

资源包要打赢按量付费，条件很简单：

包内字符的实际使用量 ÷ 包总量 > 15 / 33 = 45.45%

也就是你必须用掉包量的 45.5% 以上，这个包才比按量便宜。换算成绝对值：

记不住公式就记一句话：一年内用不到包量的四成半，就别买包，老老实实按量。

观察三：年免费额度 1,200 万字符，已经盖住了前两档包

每月 100 万 × 12 = 1,200 万字符/年免费。这意味着：

• 月用量 ≤100 万字符的团队，年成本永远是 $0，买任何一个包都是纯浪费——尤其是百万级包（$15 买 100 万），它的量刚好等于你一个月的免费额度。
• 月用量在 100 万~200 万之间的团队，年超出量最多 1,200 万，此时「千万级包 $150」是最贴的档位；但别忘了你的实际超出量可能只有 300 万，那就该买 3 份百万级包（$45），而不是一个千万级包（$150）。

三个真实量级的算账

场景 A：月用量 300 万字符（年超出量 2,400 万）

• 全按量：2,400 万 × $0.000033 = $792/年
• 1 份亿级包（$1,500）：利用率 24%，比按量还贵 89%，是最差选择
• 3 份千万级包（$450，容量 3,000 万）：省 43%
• 24 份百万级包（$360，容量 2,400 万）：省 54.5%，最优

场景 B：月用量 800 万字符（年超出量 8,400 万）

• 全按量：8,400 万 × $0.000033 = $2,772/年
• 1 份亿级包（$1,500）：利用率 84%，省 $1,272（45.9%）
• 9 份千万级包（$1,350，容量 9,000 万）：省 $1,422
• 84 份百万级包（$1,260，容量 8,400 万）：省 $1,512（54.5%），贴着用量买，一分不浪费

场景 C：月用量 100 万字符

• 免费额度刚好覆盖，$0。任何资源包都是负收益。

⚠️ 上面「84 份百万级包」的算法有个前提：多份资源包可以叠加、且各自从购买日单独起算一年。官方文档只写了「用量先从资源包扣减，扣完转按量」，没有明说多份包是否可叠加购买。买之前务必在购买页确认一次（如果一次只能买一份，那就退到「9 份千万级包」这个方案，它依然比亿级包便宜 $150）。

三条必须知道的计费细则

• 按小时结算：费用不是即时的，通常在下一个小时从账户扣除。做成本监控时别拿「刚才调了 1 万字符」去对余额，会有延迟。
• 欠费即停服，且新包不能抵旧账：官方原文是「You cannot pay overdue bills by purchasing a new resource package」——欠费了必须充值付清，买包没用。这条在国内站很少见，国际站要留意。
• 调试也计费：控制台 API 调试页的消耗与生产调用同费率。测试环境请用短文本。

采购决策，一句话版本

1. 先跑满一个月免费额度，看真实用量曲线，再决定要不要买包——这一步能省掉 90% 的错误采购。
2. 要买就贴着年超出量买最小档、买多份，不要为了「看起来便宜」买大包。
3. 年用量上亿字符（约 $15,000 以上）时，官方写了「大批量采购可联系我们谈定制价」——这时候别在自助页下单，直接找商务。

五、调用实战：Python SDK 跑通通用版与专业版

安装：官方 pip 命令和示例代码用的不是同一个包

这是本项目最容易踩的坑，我把它放在最前面：

alibabacloud_alimt20181012 是新版（Tea 风格）SDK，它的 import 路径形如 alibabacloud_alimt20181012.client；而示例代码里的 aliyunsdkalimt 属于老版 SDK，需要 pip install aliyun-python-sdk-alimt aliyun-python-sdk-core。照抄 pip 那行、再跑示例代码，必然 ImportError。 两条路选一条：

• 路 A（本文走这条）：装老包，示例代码可以直接用，改造成本最低。
• 路 B：用新包，代码从 OpenAPI Explorer 生成——接口定义与参数名一样，只是客户端初始化方式变了。

pip install aliyun-python-sdk-core aliyun-python-sdk-alimt

通用版：TranslateGeneral

import json
import os

from aliyunsdkcore.client import AcsClient
from aliyunsdkalimt.request.v20181012 import TranslateGeneralRequest

client = AcsClient(
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_ID"],
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_SECRET"],
    "cn-hangzhou",
)

request = TranslateGeneralRequest.TranslateGeneralRequest()
request.set_method("POST")
request.set_SourceLanguage("auto")
request.set_TargetLanguage("en")
request.set_FormatType("text")
request.set_SourceText("这款充电宝支持双向快充，出差必备。")

raw = client.do_action_with_exception(request)
payload = json.loads(raw)
result = payload.get("TranslateGeneralResponse", payload)

print(result["Code"])
print(result["Data"]["DetectedLanguage"])
print(int(result["Data"]["WordCount"]))
print(result["Data"]["Translated"])

四个细节值得单独说：

1. 响应体外面还套着一层 TranslateGeneralResponse。官方「响应元素」表把 Code/Data 平铺展示，但下面的 JSON 示例是 {"TranslateGeneralResponse": {"Code": 200, "Data": {...}}}。SDK 交回来的就是这段原始 body，所以 json.loads(raw)["Code"] 有可能直接 KeyError。上面那行 .get("TranslateGeneralResponse", payload) 一次兼容两种结构，别省。
2. WordCount 是字符串，返回示例里长得像数字（"10"），但类型是 String。你要拿它做成本累计，必须 int()，否则 + 会变成字符串拼接，账目会以「1010」这种形式悄悄错掉。
3. DetectedLanguage 只在 SourceLanguage="auto" 时返回。如果你的源文本语言混杂（比如商品标题里混中文和英文品牌名），自动检测会在不同分片间抖动，长文本建议显式指定源语言。
4. 通用版的参数表里没有 Scene。general 这个值只出现在 REST 文档里，RPC 的 TranslateGeneral 不接受它——这也是第九节那处文档矛盾的根源。

专业版：Translate

专业版只是换 Request 类名，并加上 set_Scene：

import json
import os

from aliyunsdkcore.client import AcsClient
from aliyunsdkalimt.request.v20181012 import TranslateRequest

client = AcsClient(
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_ID"],
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_SECRET"],
    "cn-hangzhou",
)

request = TranslateRequest.TranslateRequest()
request.set_method("POST")
request.set_SourceLanguage("en")
request.set_TargetLanguage("zh")
request.set_FormatType("text")
request.set_Scene("title")
request.set_SourceText("Wireless Charging Case for AirPods Pro")

raw = client.do_action_with_exception(request)
print(json.loads(raw)["Data"]["Translated"])

官方 Python 版只给了 title / description / communication 三个 Scene，medical / social / finance 只出现在专业版介绍页的表格里，没有任何 SDK 示例。要用领域引擎，请用第八节末尾的验证方法，别假设它一定能用。

计费口径下的批量调用：先切句，再累计

单请求上限 5,000 字符，批量请求要求每条 ≤1,000 字符、单请求 ≤50 条。下面这段是「按句切、按 1,000 字符成组、边调边累计字符」的最小实现：

import json
import os
import re

from aliyunsdkcore.client import AcsClient
from aliyunsdkalimt.request.v20181012 import TranslateGeneralRequest

client = AcsClient(
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_ID"],
    os.environ["ALIBABA_CLOUD_ACCESS_KEY_SECRET"],
    "cn-hangzhou",
)


def split_by_sentence(text, limit=1000):
    sentences = re.split(r"(?<=[.!?;。！？；])\s*", text)
    chunks, current = [], ""
    for sentence in sentences:
        if len(current) + len(sentence) > limit and current:
            chunks.append(current)
            current = sentence
        else:
            current += sentence
    if current:
        chunks.append(current)
    return chunks


def translate(text, source="en", target="zh"):
    request = TranslateGeneralRequest.TranslateGeneralRequest()
    request.set_method("POST")
    request.set_SourceLanguage(source)
    request.set_TargetLanguage(target)
    request.set_FormatType("text")
    request.set_SourceText(text)
    result = json.loads(client.do_action_with_exception(request))
    result = result.get("TranslateGeneralResponse", result)
    if int(result["Code"]) != 200:
        raise RuntimeError(result.get("Message"))
    return result["Data"]["Translated"], int(result["Data"]["WordCount"])


def translate_document(text):
    output, billed = [], 0
    for chunk in split_by_sentence(text):
        translated, count = translate(chunk)
        output.append(translated)
        billed += count
    return "".join(output), billed

billed 就是你这次任务真实消耗的字符数。按这个数记账，比按 len(text) 估更准——因为官方计费按源文本字符，而字符串长度在不同语言/编码下和账单口径不完全一致（下一节展开）。

错误码：11 个，够用了

还有一条坑：鉴权类错误返回的是 XML，不是 JSON。官方原文是「Authentication-level errors (such as missing or invalid signatures) return an XML response instead of JSON」。所以你的 json.loads() 外面必须包一层 try，否则 AK 写错时抛出来的是 JSONDecodeError，你会在错误的方向上排查半天。

六、字符口径的四个坑：账单为什么比你以为的贵

坑 1：5,000 上限按 Java String.length() 算，不是按「字数」

官方原文：单次请求的字符上限是 5,000，计量方式为 String.length()。Java 的 length() 数的是 UTF-16 代码单元：

• 一个汉字 = 1
• 一个 ASCII 字母 = 1
• 一个 emoji（如 🚀）= 2
• 一个生僻字/古文字（基本平面外）= 2

所以一段 4,900 个汉字 + 60 个 emoji 的文案，长度是 4,900 + 120 = 5,020，超限。营销文案里 emoji 越多，越容易撞线。Python 侧可以用 len(text.encode("utf-16-le")) // 2 预检，比 len(text) 准。

坑 2：HTML 标签也算字符，而且照样计费

FormatType 支持 text 和 html 两种。选 html 时引擎会保留标签结构、只翻正文，但字符统计包含标签。官方 FAQ 写得很直白：字符统计包含标点、空格和 HTML 标签。

这条对独立站是致命的：一个商品详情页 <div class="..."> 加内联样式，标签能占到 30%~40% 的字符量。你付了标签的钱，却只得到正文的翻译。 第八节场景 B 会算这笔账，结论是「先抽正文、翻完再回填」能省四成。

坑 3：标点和空格都算，\n 也算

这一点和按 token 计费的 LLM 完全不同：1 个字符就是 1 个字符，$0.000033。排版用的缩进、Markdown 的 | 和 ---、代码块里的空格，全都计费。翻译 Markdown 文档时，先剥离代码块和表格分隔线，能省下 10%~20%。

坑 4：批量接口的 1,000 字符是「每条」，不是「总共」

批量上限是每条 ≤1,000 字符、单请求 ≤50 条，两者同时成立。也就是说单请求的实际上限是 50,000 字符——但总字符仍受 5,000 那条限制吗？官方没写清。保守做法：批量接口按每条 1,000、每批 50 条发送，不要试图用批量接口绕过 5,000 上限，否则你会在生产上收到一批 10008。

一张表记住四个数字

七、把「机翻味」压下去：三条不加钱的手段

单价已经压到 $33/百万字符这个量级，再想降本只能从「少翻」和「翻对」两头下手。这一节的三条手段都不需要额外付费，但效果比换引擎明显。

7.1 占位符保护法：先把品牌名和型号「藏起来」

机器翻译最常翻车的地方不是长句，而是专有名词：品牌名被音译、型号里的数字被改、SKU 编码被当成单词拆开。正确做法不是翻完再人工找错，而是翻之前就把它们替换成不可能被翻译的令牌：

import re

PATTERNS = [  # 需要保护：链接、邮箱、型号/SKU、模板变量
    r"https?://\S+",                 # 链接
    r"[\w.+-]+@[\w-]+\.[\w.]+",      # 邮箱
    r"\b[A-Z]{2,}-?\d{3,}\b",        # 型号 / SKU，如 AC-1200
    r"\{\{[^}]+\}\}",                # 模板变量 {{name}}
]

def protect(text):
    tokens = []
    def _sub(match):
        tokens.append(match.group(0))
        return "⟦%d⟧" % (len(tokens) - 1)   # 全角括号，模型几乎不会改动
    for pattern in PATTERNS:
        text = re.sub(pattern, _sub, text)
    return text, tokens

def restore(text, tokens):
    for index, original in enumerate(tokens):
        text = text.replace("⟦%d⟧" % index, original)
    return text

关键点有三个：

1. 令牌用全角方括号 ⟦ ⟧，比 {{0}} 稳——后者在部分引擎里会被当成模板语法改写；
2. 令牌本身也计费，但只有 3~4 个字符，比你重翻一遍整段便宜得多；
3. 回填必须做在单词边界上，别用 str.replace("0", ...) 这种裸替换，否则会把正文里的数字一起吃掉。

这套做法对独立站商品标题尤其有效：标题里 60% 的「翻译错误」都是品牌名和型号被意译，占位符法一次解决。

7.2 专业版的四个领域引擎，等于白送

这是我核对价目表时最意外的一点：专业版（Professional）与通用版（Universal）走的是同一张价格表，不额外加价。专业版提供四个领域引擎：

也就是说：如果你的内容属于上面四类，用专业版是纯赚的——同样的字符数，同样的账单，领域词汇准确率明显更高。唯一的代价是接入方式不同（专业版走 REST/ROA，通用版走 RPC），两套 API 的参数不能混用，这一点第二节的对照表里已经列过。

⚠️ 但别把「不额外加价」理解成「随便用」：专业版的计费仍然按字符走同一张表，调用量翻倍账单就翻倍。领域引擎的价值在于同样字符数下质量更高，不是更便宜。

7.3 后编辑抽检：按 5% 抽，用错误率决定要不要全量人工

机翻能不能直接上生产，取决于你的错误容忍度，而不是引擎好坏。给一套可执行的判据：

抽检不是「随便看几眼」，而是固定随机种子 + 记录错误类型。把错误分成「术语错」「语义错」「格式错」三类分别统计，你才知道该补术语表、该换领域引擎，还是该改预处理脚本。

📝 小提示：UI 文案有一个机翻特有的坑——译文变长导致按钮溢出。德语、俄语的译文长度常是英文的 1.3~1.5 倍。UI 类内容建议在抽检时同时做一遍长文本回归，别只看语义对不对。

八、三个场景的真实成本测算

以下全部按 按量 $0.000033/字符（=$33/百万字符）、资源包 $15/百万字符、每月 100 万字符免费额度 计算。免费额度是每个版本各有一份，通用版和专业版分开算。

8.1 场景 A：跨境电商独立站，5,000 个 SKU 翻 3 个语种

假设每个商品页正文 1,200 字符（纯文本，已去掉标签），首月全量翻译，之后每月新增 300 个 SKU：

结论有两条，都很反直觉：

1. 只有首月需要买包，之后每月几乎免费。稳态增量 108 万字符里有 100 万被免费额度覆盖，实付 $2.64——这个量级永远不要为增量买包，包会闲置到过期。
2. 首月全量必须买包。18 万字符的量级买 18 份百万包（$270）比按量（$594）省一半多；买一份亿包（$1,500）则要闲置 82%，纯亏 $1,230。

如果偷懒直接翻 HTML（带标签，标签占 35% 字符），首月字符量从 1,800 万涨到 2,769 万：

一个下午的预处理脚本，值 $145~$320。 这是全文性价比最高的一个动作。

8.2 场景 B：视频字幕本地化，每月 20 部

一部 40 分钟剧集的字幕约 12,000 字符（含 SRT 时间码与序号）。这里有一个容易被忽略的细节：时间码和序号也会计费。

结论：月产 20 部以内的字幕业务，字符成本是 $0，全部落在 100 万免费额度里。这个量级谈「省钱」没有意义，真正该优化的是时间码对齐——机翻会改变句子长度，字幕必须重新断行，否则会出现「一句话闪 0.3 秒」的观感问题。工程做法：翻完按标点重新切分，每行控制在 42 个字符 / 2 行以内。

8.3 场景 C：SaaS 多语言 UI，1,800 个键 × 12 语种

假设 JSON 资源文件 1,800 个键，值平均 42 字符，键名平均 25 字符：

键名不该进翻译接口。 它不需要被翻译，但它照样计费——一年多付 $177，只为把 checkout_button_title 这个字符串送进去再原样拿回来。这是我在真实项目里见过最多的冤枉钱，写法上只要改一行：

payload = {k: translate(v, target=lang) for k, v in source.items()}

而不是把整个 source 字典序列化后丢给批量接口。

8.4 三个场景汇总

一句话记忆法：月用量 ≤100 万，永远别碰资源包；100 万~500 万，买百万包按需叠加；超过 500 万，先算 45.45% 利用率门槛再决定。

九、官方文档里七处自相矛盾，采购前逐条对一遍

写这篇之前我把国际站机器翻译的产品页、帮助文档、开通向导和 API 参考都过了一遍，同一个问题在不同页面给出的答案并不一致。这些不是笔误，而是会直接影响你采购决策的口径差：

第 6 条值得单独说：新版 Tea 风格包和老版 aliyun-python-sdk-* 包不是同一个东西。前者 pip install alibabacloud_alimt20181012==1.1.0，import 路径是 alibabacloud_alimt20181012；后者要装 aliyun-python-sdk-alimt + aliyun-python-sdk-core，import 路径才是文档示例里那个 aliyunsdkalimt.request.v20181012。文档的安装段和示例段来自两套 SDK，这是新手最容易卡住半小时的地方。两条路都能跑通，本文的示例走老包（示例代码与参数名能直接对齐）。

十、总结：机器翻译的账，其实只有三道题

把全文压成三句话：

1. 单价只有两个数——按量 $33/百万字符，资源包 $15/百万字符，且四档包没有任何量级折扣。资源包的利用率必须超过 45.45% 才比按量便宜，否则买包就是负收益。
2. 免费额度是 100 万字符/月、每版本各一份，所以月用量 ≤100 万的业务长期账单为 $0。小体量用户最该做的事不是省钱，而是别买包。
3. 真正能省大钱的地方在「少翻」——HTML 标签占 30%~40%、UI 的 key 根本不该送翻、Markdown 代码块和表格分隔线也在计费。一个下午的预处理脚本，比研究一整天价目表有用。

如果只能记住一个数字，记住 0.000033：它是这套服务里唯一不变的常数，也是你所有成本测算的起点。剩下的都是「怎么少乘几次」。

延伸阅读

• 想让翻译之后的内容再走一遍合规审核？见 内容安全 Content Moderation 实战教程
• 图片里的文字要翻译，先做 OCR 与媒体加工：智能媒体管理 IMM 实战教程
• 多语言内容要做语义检索与去重：向量检索服务 DashVector 实战教程
• 还没开通国际版账号？阿里云国际版注册教程（免实名 + 支付宝）
• 想先把预算压下来：优惠码与代金券攻略

🚀 需要海外云服务器？通过 2.chengzicloud.cloud 购买享专属折扣

⚠️ 免责声明：本文中提到的配置、价格和优惠信息可能随时间变化，请以阿里云国际版官网（alibabacloud.com）的实时信息为准。本文不构成任何投资或购买建议。注册与数据处理前请确认当地法规合规性。

本文由 2.chengzicloud.cloud 提供，点击访问首页了解更多