同一张 1024×1024 的图，交给模型做两件事，走的是两本完全不同的账。
第一件事：把它发给模型，让它描述图里有什么。这张图会先被换算成一定数量的 tokens，再和你的文字一起计费。换算出来的数，跟着图片的分辨率走。
第二件事：让模型画一张同样大小的图。这一次 tokens 跟你的图长什么样没有关系------用哪个模型、选哪个分辨率档位、要不要传参考图，三个条件一查表，消耗就定了。
"读一张图"和"画一张图"，虽然都以 token 结算，但 token 的来历是两套机制。这篇把两边都拆开，最后放到同一张表里对比。以下数字全部来自腾讯云大模型服务平台 TokenHub 的价格页与调用文档，来源与抓取日期见文末。
一、生成侧：tokens/张 是查出来的
TokenHub 的《模型价格》页里，图片生成这一段的开头写着计费公式：
参考费用 = Token 用量 × Token 单价
单价这一列，页面上所有图像生成模型全部是同一个数：10 元/百万 tokens。真正的差异全在"Token 用量"这一列------每个模型、每个分辨率档位，对应一个写死的 tokens/张。
同一页还给了一个照抄就能用的算例：
成功调用 HY-Image-3.0 模型生成一张图片，使用功能为文生图，实际费用为 1 张 × 20,000 tokens/张 × 10元/百万 tokens = 0.2 元。
把 1K 档（约百万像素级）这一档拉出来看，差异一目了然（页面更新 2026-10-24，2026-10-26 抓取）：
| 模型 | 1K 档 Token 用量 | 折合参考费用 |
|---|---|---|
| Seedream-Image-v5.0-flash | 12,000 tokens/张 | 0.12 元/张 |
| WAND-Vega-Image-1.0-Lite | 13,500 tokens/张 | 0.135 元/张 |
| Hy-Image-3.5-preview | 15,000 tokens/张 | 0.15 元/张 |
| Kling-Image-v3（1K/2K 同价） | 20,000 tokens/张 | 0.2 元/张 |
| Hy-Image-3.0（不区分分辨率） | 20,000 tokens/张 | 0.2 元/张 |
| Seedream-Image-v5.0-lite（不区分） | 22,000 tokens/张 | 0.22 元/张 |
| WAND-Vega-Image-1.0-Flash | 45,000 tokens/张 | 0.45 元/张 |
| WAND-Vega-Image-1.0-Pro | 95,000 tokens/张 | 0.95 元/张 |
同样是"1K"，最贵和最差的那档差约 7.9 倍 （95,000 ÷ 12,000）。把 4K 档也算进来，整张表从 12,000 到 171,000 tokens/张，跨约 14.3 倍。
还有一个不按像素比例走的细节：Hy-Image-3.5-preview 的 1K 和 2K 档都是 15,000 tokens/张，加到 4K 才变成 20,000；WAND-Vega-Image-1.0-Flash 则是 1K 45,000 → 2K 67,500（×1.5）→ 4K 100,800（再 ×1.49）。也就是说，分辨率档位是计费档位，不是像素的线性函数------预估成本时不能拿"像素翻了四倍所以费用翻四倍"来推。
二、生成侧的两行容易漏看：输入图也计费
图生图、参考生图要把图传进去。这张"输入图"怎么计费，价格表里是单独两行：
- WAND-Vega-Image-1.0-Pro：输入图片前 3 张免费，第 4 张起每张 10,000 tokens/张（折合 0.1 元/张）；
- Seedream-Image-v5.0-pro：输入图片首张免费，第二张起 2,000 tokens/张（折合 0.02 元/张）。
注意这里"输入图"的计费逻辑已经和理解侧完全不同：理解侧按分辨率折算，生成侧按"第几张"给固定值，甚至免费。同一个动作------把一张图递给模型------在两张表里是两种东西。
三、理解侧：tokens 是按分辨率算出来的，而且一家平台就有三套算法
理解侧没有"tokens/张"这种查表值。一张图折多少 tokens，由各模型自己的算法决定。有意思的是，就在 TokenHub 这一个平台上，官方文档写明的算法就有三套，互不相同：
第一套：混元对话视觉（HY-Vision 系列）。 《图片理解》文档给了两个示例值：1024×1024 每张约消耗 1,058 tokens，768×768 每张约 602 tokens（页面更新 2026-08-27）。同一页还专门提醒：
以上数量估算以 HY-Vision（混元视觉）系列模型 的图片 Token 占用逻辑为参考；第三方视觉模型可能采用不同的图片 Token 算法，并设有各自的图片数量上限，实际可传入数量请以对应模型实测为准。
第二套：多模态向量模型（Kinfra-VL-Embedding）。 《向量模型》文档把规则写到了公式级：图片先按 28×28 像素切 patch，再按 2×2 合并，合并后的 patch 数就是图片 tokens------1024×1024 是 324 ，1280×720 是 264 ，512×512 是 81（页面更新 2026-07-09）。
第三套：DeepSeek 视觉。 DeepSeek 官方 Vision 文档的写法是：推理前先把图缩放，大图等比压到总像素约 1300×1300 的水平，然后按尺寸转成 tokens。原文是 "As a result, there is an upper bound of 1024 tokens per image"------单张图片以 1,024 tokens 封顶，2000×2000 和 5000×5000 的图缩放后消耗相同（2026-10-26 抓取，中文为本文转述）。
同一张 1024×1024 的图，三套算法给出三个数：约 1,058、324、不超过 1,024。前两个都在同一家平台的价格体系里，差约 3.3 倍------差别不在图，在"哪个产品线在数"。
四、放到一张表里：一张 1K 图的三本账
把 1024×1024 这张图的三种去向放在一起（单价均取自 2026-10-26 抓取的同一张价格页）：
| 动作 | 计费 tokens | 单价（元/百万 tokens） | 一张图约花 |
|---|---|---|---|
| 读（HY-Vision-2.0-Instruct 输入） | 约 1,058 | 7.5 | 约 0.0079 元 |
| 向量化（Kinfra-VL-Embedding-8b 图片输入） | 324 | 0.9 | 约 0.00029 元 |
| 画（生成侧 1K 档，8 个模型区间） | 12,000--95,000 | 10 | 0.12--0.95 元 |
生成一张 1K 图的钱，是读一张同尺寸图的 15 倍到 120 倍（0.12 ÷ 0.0079 ≈ 15；0.95 ÷ 0.0079 ≈ 120）。
这里有一个口径提醒：**跨计费项比 token 倍数没有意义。**95,000 是 324 的约 293 倍，但因为两边单价不同（10 元 对 0.9 元/百万），金额差是约 3,300 倍而不是 293 倍。token 数只在同一种计费项内可比；跨项比较，直接算钱。
五、拿这张表做预估，两边是两种做法
生成侧可以在开跑前精确到分：查表取 tokens/张，乘 10 元/百万即可。官方计费示例就是这么算的------Vidu-Image-q2 生成一张 4K、参考生图（4～7 张）规格的图，1 × 93,750 × 10 ÷ 1,000,000 = 0.9375 元，页面照录。
理解侧恰恰相反：官方不给"逐像素精确值"，给的是参考逻辑加回读口径。向量模型文档的原句是"实际 token 数以接口响应中的 usage.prompt_tokens_details.image_tokens 为准"；图片理解文档则建议对第三方模型"以对应模型实测为准"。
所以两类任务的预估方法不同：生成侧先查表再调用，数字在调用前就定死；理解侧先按参考值粗估、再拿 usage 字段回读校准。最容易踩的错，是拿"一张图大概一千 tokens"这个理解侧的直觉，去估生成任务------差出一个数量级还不止。
六、总结
回到开头那张 1024×1024 的图，这篇讲的东西可以收成五条：
- **生成侧是查表制。**tokens/张 由"模型 × 分辨率档位"写死，单价统一 10 元/百万 tokens；1K 档从 12,000 到 95,000 tokens/张，加上 4K 档全表跨约 14.3 倍。分辨率档位是计费档位，不随像素线性走。
- **生成侧的输入图单独算。**按"第几张"给固定值甚至免费（前 3 张免费 / 首张免费两档），不按分辨率折算------这已经和理解侧不是一个逻辑。
- **理解侧是算图制。**同一家平台就有三套算法：HY-Vision 约 1,058、向量模型 324（28×28 patch 合并）、DeepSeek 单图 1,024 封顶。同一张图差约 3.3 倍，差别不在图，在哪个产品线在数。
- **三本账放到一起看。**读一张 1K 图约 0.0079 元，向量化约 0.00029 元，画一张 0.12--0.95 元------画是读的 15 到 120 倍。跨计费项别比 token 倍数（293 倍 ≠ 3,300 倍），直接算钱。
- **预估方法两套，别混用。**生成侧先查表再调用，数字在调用前就定死；理解侧先按参考值粗估，再拿 usage 字段回读校准。最容易踩的错，是拿理解侧"一张图大概一千 tokens"的直觉去估生成任务。
生成侧能查表，理解侧要回读，两套方法一旦混用，预估就会整体偏掉。你这边图片相关的调用，最近一次账单超出预期的是哪一笔？多出来的消耗，最后是在哪一行里找到的？如果重新做一次图片任务的预估，你会先把哪条规则定下来？