大模型 1.8 million是多少m

看模型规格时经常撞见 1.8 million、1M、200K 混着写，一会儿说字数一会儿说 token，算显存和费用时很容易搞混。这篇只干一件事：把 million 和 m 的换算关系讲清，再告诉你在哪几步会用到这个数字，以及什么情况下这个换算根本不适用。

看模型规格时经常撞见 1.8 million、1M、200K 混着写，一会儿说字数一会儿说 token，算显存和费用时很容易搞混。这篇只干一件事：把 million 和 m 的换算关系讲清，再告诉你在哪几步会用到这个数字，以及什么情况下这个换算根本不适用。

先把结论摆前面：1.8 million 就是 1.8m，两者是同义写法，不存在换算损耗。真正会让你算错账的，是它后面跟着的那个量到底是什么。上下文、参数量、训练数据量都可能用 million 当后缀，指代不同，后续所有估算都得推翻重来。所以别急着按数字计算，先确认口径。

先分清 million 说的是什么量

million / m

数量级前缀，1.8 million 等于 1.8m，只是写法繁简不同，不是两个单位

上下文长度

单次请求里模型能吃下的 token 上限，注意是 token，不是汉字数

token 与汉字

中文大致一字一 token 上下浮动，英文一个词约一到两个 token，实际分词结果因平台而异

参数量 B

参数量的单位通常是 B（十亿），跟上下文用的 m 完全是两个维度，别混用

换算本身没什么可算的，难的是分辨这个数字在修饰什么。规格页写 1.8 million，如果上下文那一栏，就是 token 上限；如果写在参数或训练数据那一栏，它跟你能塞多长的文档毫无关系。看到只写 million 不写 token 的页面，先去找口径说明，别自己脑补单位。

• 先看数字出现在规格表的哪一行：上下文、参数、训练数据三行含义完全不同
• 上下文行后面有没有跟 token 字样，没跟就去找同页的口径说明或对照表
• 确认是 token 之后再折算汉字量，中文按一字一 token 上下浮动估，别当成精确值
• 同一模型在不同平台的中文分词可能不一致，算出来差十几个百分点属于正常范围

为什么换算完还是对不上账

很多人换算完发现还是对不上，原因不在单位，在口径。上下文窗口、最大输入、最大输出经常是三个不同的数。有的模型把输入输出合在一起算总量，有的把输出单独限额。你按窗口上限估，自然会高估能塞进去的正文量。

另一个常见误区是把窗口上限当计费用量。计费按你实际发出去的 token 走，不是按上限走。窗口大只说明它能接，不代表你一定会被按满额计费。反过来，多模态任务里图片、音频转成 token 的倍率各不相同，这套文本换算只对纯文本部分成立。

这个数字在哪些动作里真的用得上

换算出 token 上限只是第一步，真正落地在三个动作上：估显存、算成本、做长文档任务前的可行性确认。这三步用的都是实际 token 量，不是窗口上限那个数字。

1. 估显存注意力开销随上下文增长，长上下文主要吃 KV cache。到 部署测算（/models/deploy） 按你的模型规格和量化档位过一遍，比自己手算靠谱
2. 算成本先估你每次请求实际会发进去多少 token，再乘单价。单价去 官方 API 价格（/official-api） 看当时的数字，别拿窗口上限当用量
3. 确认任务可行性长文档任务先看切分后单次请求会不会超上限，超了是分片处理还是换更长窗口的模型，术语先把 基础概念词典（/ai-dict/category/basics） 对一遍
4. 横向对比窗口大小只是入场券，同样标称长上下文的模型，实际检索效果差距不小，得看实测而不是只看数字

什么情况下这套换算不适用

有几种场景，你就算把 1.8 million 换算得再准也没用。第一种是模型规格里那个 million 根本不指上下文，比如标的是参数量，参数量单位通常是 B，跟上下文长度是两个维度，可以到 模型底层概念对照（/ai-dict/category/tech） 把这两个概念分开看。

第二种是本地部署。你实际能跑多长，受限于显存能塞下的 KV cache，标称窗口再大，显存不够就是跑不动，这个换算帮不了你。第三种是走中转或第三方接口，对方可能对上下文做截断或改写，标称值只能当参考。判断这类服务靠不靠谱，先到 模型可信度排行（/rankings） 看当时的检测结果，再决定是否依赖它宣称的长上下文。

• 规格只标参数量：把 B 当成上下文 m 用，属于看错行，先回去核对规格表
• 本地部署：受限于显存能容纳的 KV cache，标称窗口只是理论上限
• 中转或第三方接口：可能存在静默截断，标称值仅供参考，先查可信度检测
• 纯短问答、分类、抽取：纠结千万级窗口没意义，反而可能拉高延迟和单价