Mistral API 价格与计费（2026）：输入、输出与成本控制

Mistral API 的账单不是“调用一次收一次钱”，而是按输入 Token、输出 Token、缓存命中情况，以及 OCR、语音等专用模型的独立单位计算。很多团队按价格页上的一个数字做预算，上线后却发现账单高出一截，原因往往不是单价变了，而是输入结构、上下文长度和重试次数与估算时不同。

本文把 Mistral API 的计费拆成可计算的部分：哪些单位在计费、输入和输出如何叠加、上下文为什么会让成本随轮数增长、缓存和重试怎样影响账单，以及如何用真实日志做预算并与发票对账。具体单价以 Mistral 官方价格页和站内模型价格为准，本文不写死任何单价。

说明：Mistral、Mistral AI 是其权利人的商标。本文以 2026 年 10 月的公开文档为例，模型名称、计费单位与价格可能调整，采购前请再次核对 Mistral 官方文档与站内模型价格。

一、先分清计费单位：不是所有模型都按 Token

Mistral 的语言模型按 Token 计费，但 OCR、语音、Embedding 等专用模型各有自己的单位。把不同单位的费用直接相加，是预算失真的第一个来源。

计费对象	计费单位	常见场景	预算时要注意
语言模型	输入、输出 Token	对话、抽取、代码、Agent	输出通常高于输入，缓存输入有折扣
OCR	页，含缓存页	扫描件、PDF 转文本	与 Token 账单分开统计
语音转写	分钟，含缓存时长	会议录音、客服录音	按时长而非字数
语音合成	字符	播报、配音	输入与输出分别标注
Embedding	输入 Token	检索、聚类、去重	通常只计输入侧
内容审核	Token	内容安全、风控	是否收费以价格页当前标注为准

价格页通常还区分 Standard、Batch、Priority 等档位。它们面向不同的时效要求，能否用 Batch，取决于任务能否等待。

二、输入与输出：同一段对话，两边都在计费

一次请求里，进入模型上下文的内容都算输入：system prompt、历史消息、用户问题、工具定义、检索到的文档，以及多模态输入折算出的部分。模型生成的内容算输出，包括正文、结构化字段和推理过程（如果该模型返回思考内容）。

这带来两个常见误判：

只数用户问题，不数上下文。 用户只写了二十个字，但系统提示、工具 schema 和前五轮历史可能才是大头。
只比较输入单价，不看输出比例。 客服场景输入多、输出短；长文生成输入短、输出长。两者的单次成本不能用同一个平均值估算。

多模态输入的折算方式与推理内容是否计入输出，以官方文档和账单口径为准，不要直接套用其他厂商经验。

三、上下文长度：每轮都在为“前面的话”付费

语言模型本身不保存对话记忆。多轮对话之所以能接上，是因为客户端每轮都把历史消息重新发过去。于是上下文越长，每次请求的输入 Token 越多，成本会随轮数累积，而不是只随“新增的那句话”增长。

一个直观的例子：第一轮只发系统提示和问题；第五轮要带上前四轮问答；第二十轮要带上前面全部内容。即使每轮新增内容很少，第二十轮的输入也可能是第一轮的数倍。

控制方法不复杂：

只保留最近几轮原始消息，更早的内容做摘要。
检索只召回相关片段，不要把整份手册塞进上下文。
把稳定内容放前面、变化内容放后面，为缓存创造条件。
长文档先分段处理，再汇总，而不是每轮重复全文。

四、缓存、批处理与重试：三个常被低估的变量

缓存输入。 Mistral 为文本模型提供缓存输入价格，通常明显低于普通输入。缓存能否命中，取决于请求前缀是否稳定。把时间戳、随机 ID、用户名放在 system prompt 开头，或者每次重排工具定义，都会让缓存失效。缓存通常是尽力而为，预算应按“部分命中”估算，而不是假设全部命中。

批处理档位。 标注、摘要、离线分类、批量翻译这类不要求实时返回的任务，可以评估 Batch 档位。它牺牲的是等待时间，换来的是不同的价格档；具体折扣和限制以价格页为准。

重试。 429、超时、连接中断后的重发，会增加实际请求量。失败请求是否计费、重试是否重复计费，要以账单和官方说明为准。工程上应使用指数退避、设置最大重试次数，并对创建类操作做幂等处理，避免“钱花了两次，结果只成功一次”。

五、用 usage 和日志做一次真实估算

不要凭字数猜 Token。每次调用后读取响应里的 usage，连续记录一周，就能得到自己业务的真实结构。下面这段代码通过 OpenAI 兼容接口调用，模型名从环境变量读取，避免把会变化的名称写死。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url="https://ai.zhongshangqihang.com/v1",
)

resp = client.chat.completions.create(
    model=os.environ["MISTRAL_MODEL"],  # 模型名以站内价格页为准
    messages=[
        {"role": "system", "content": "你是客服助手，回答不超过三句话。"},
        {"role": "user", "content": "订单发货后还能改地址吗？"},
    ],
    max_tokens=256,
)

u = resp.usage
print("输入", u.prompt_tokens)
print("输出", u.completion_tokens)
print("合计", u.total_tokens)

记录字段至少包括：时间、项目、模型、输入 Token、输出 Token、是否命中缓存、重试次数、是否流式。金额等到月底再乘价格页单价，过程指标每天都要看。

六、从估算到发票：预算要留出哪些余量

做预算时，建议按“基准用量、峰值用量、重试与失败、缓存未命中”四块分别估算，再相加。

对账时注意三个口径差异：

预付余额通常按含税金额扣减，而消费上限往往按税前金额计算，两者可能不同步。
组织级月度消费上限会约束所有 Workspace，单个 Workspace 的上限不能超过组织上限。
余额不足时，超出套餐包含用量的请求可能返回 HTTP 402；这不是模型故障，而是账单状态。

Mistral 的账单后台提供发票列表和 PDF 下载，预付充值、套餐费用和按量费用会分别体现在账单中。企业报销时应把发票、订单号、付款凭证和用量明细放在一起归档，具体开票流程可参考同站的 Mistral API 充值教程。

七、降本的顺序不要反

先量化：用 usage 和日志算清每个功能的输入、输出结构，不凭感觉。
再提缓存命中：固定 system prompt、工具定义和知识前缀，把动态内容移到末尾。
再减输入：历史消息做摘要，检索只带相关片段，工具输出只保留必要字段。
限制输出：设置合理的 max_tokens，要求固定字段或 JSON，减少重复解释。
做模型分流：分类、抽取、改写走轻量模型，复杂推理再升级。
评估批处理：不要求实时的任务排队跑，换取不同的价格档。
监控与告警：按项目、模型、场景三个维度看用量，设置预算上限和余额提醒。

顺序反了，常见结果是：换了更便宜的模型，但输入没治理、缓存没命中，账单没降多少，质量却先下降了。

常见问题

Mistral API 按调用次数还是按 Token 计费？

语言模型按输入和输出 Token 计费，不是按调用次数。OCR、语音转写、语音合成等专用模型使用页、分钟或字符等独立单位，具体以官方价格页为准。

为什么上下文越长，账单涨得越快？

因为每轮请求都会重新发送历史内容，输入 Token 随轮数累积。即使新增问题很短，只要历史不裁剪，成本就会持续上升。

缓存输入为什么没有生效？

常见原因是前缀不稳定：开头混入时间戳、随机 ID、用户信息，或者每次重排工具和文档顺序。先把变化内容移到请求末尾，再观察一段时间。

重试的请求会计费吗？

要看失败发生在计费之前还是之后，以及官方当前的账单口径。工程上应限制重试次数、使用退避，并对写操作做幂等，避免重复消耗。

估算和发票对不上怎么办？

先核对是否漏算历史消息、工具定义、重试、缓存未命中和批处理档位差异，再用请求 ID 对照用量日志。仍无法解释时，拿发票明细和用量记录一起排查。

下一步

先在中商起航 AI 网关创建测试 Key，用真实任务跑一周，记录输入、输出和缓存命中，再按模型价格折算预算。模型可用性与价格以价格页为准。