一个聊天产品要有好几百个并发用户，专用 GPU 才划得过按 token 计价。而一个智能体只需要十来个工作单元——因为它每一步都要把整个上下文重发一遍，单位墙钟时间里烧掉的 token 高出一个数量级。真正该决定你在这四家里选谁的，是这道算术题，而不是每百万 token 的单价；因为你迟早会向它们要的那样东西，是一条离开你起步那一级台阶的路。
一览
2026 年一支智能体团队真会列进候选名单的四家托管推理厂商，以及各自押的注。
| 厂商 | 核心押注 | 入门计价 | 专用算力 |
|---|---|---|---|
| Together AI | 最宽的开放模型目录，外加微调与裸算力同在一份合同里 | 按 token——70B 档约 $1.04/M | 专用端点，H100 约 $6.49/小时；HGX 集群每 GPU 约 $3.99/小时起 |
| Fireworks AI | 自研引擎上的极致提速，价格压在同行之下 | 按 token——70B 档约 $0.90/M | 按需部署，H100/H200 约 $7/小时 |
| Baseten | 把你自己的权重送上生产，算力从多家云代为撮合 | 在一份精选模型清单上按 token 计价 | 专用部署，H100 约 $6.50/小时 |
| Modal | Python 原生容器，冷启动极快；服务栈由你自带 | 没有按 token 这一级——从第一个请求起就按 GPU 秒计费 | 按秒计费，可缩容到零 |
智能体会跨过那条平衡线，而聊天产品永远跨不过
先把唯一要紧的那道算术做一遍，做一次就够。一块专用 H100 约 $7.00 一小时，对上一个 70B 档开放模型约 $0.90 每百万 token 的按量服务，等于每一个 GPU 小时的钱能买下约 780 万 token 的无服务器用量。这就是那条线。线以下按 token 更便宜，线以上按硬件更便宜。
一个聊天用户在真正重度使用的一小时里，大概产生两万 token。你需要接近四百个这样的用户，同时在线、整整一小时，才能碰到那条线——这正是"按 token 的无服务器计价"长期以来对一切对话类产品都是显然正确的默认，也是整个行业围着这条假设定价的原因。
而智能体打破这条假设，靠的是结构，不是靠受欢迎。单条轨迹每一步都要重发系统提示词、工具定义、累积下来的观察结果与此前的推理，所以一个二十步、工作上下文三万 token 的任务，会吃掉约 65 万个提示词 token，而输出也许只有八千。于是一个智能体工作单元烧掉的量，约等于三十个聊天用户；十来个持续运行，就是每小时花掉一个 H100 小时。十二个并发工作单元算不上什么规模里程碑，它对一支跑后台编码智能体的团队来说只是个普通的星期二。
在花费上跨过平衡线，不等于一块 GPU 就扛得住这份负载。一块 H100 跑 70B 模型能否以你要的时延撑住十二条并发多步轨迹，要看量化方式、批次形状，以及每条上下文里有多少命中了缓存。这道算术告诉你何时该去做那个实验，不告诉你实验结果是什么。
对选厂商的推论很直接。如果你的负载是智能体形态的，你要选的就不是"未来三年的按 token 厂商"，而是"在按 token 计价不再合理的那一天，你仍然愿意和它待在一起"的那一家——这是一个关于阶梯的问题，不是关于入门那一级的问题。
智能体的账单，真正是在前缀缓存上赢下来的
那份让智能体变贵的重发上下文，只要厂商把它缓存住，也正是让智能体变便宜的东西。Fireworks 在无服务器模型上自动启用基于前缀的提示词缓存，命中的提示词 token 默认打约五折，首 token 时延最多可降八成。对于"提示词共享一大段稳定前缀"的负载——系统提示词、工具 schema、仓库上下文、迄今为止的对话记录——这不是边际优化，而是智能体经济账算不算得过来的分水岭。
这里有一个价格页不会告诉你的运维褶皱，也是整篇对比里最强的实务论点。前缀缓存活在某一个具体节点上。在共享的无服务器机群里，你的请求由厂商的负载均衡器路由；一旦落到一台没见过你前缀的机器上，你就照全价付钱、照全额等延迟。厂商会暴露会话亲和性请求头来引导这件事，而配错它是一次静默且昂贵的回退——它表现为成本方差，而不是一个报错。
所以对智能体来说，缓存命中率有一部分是你控制不了的基础设施的性质——直到你搬去专用部署，那时机群是你的，前缀也就不再乱跑。这是"阶梯比入门单价更重要"的第二条独立理由，其完整展开见上下文缓存经济学。
在比较任何 token 单价之前，先拿一天真实的智能体流量把"缓存命中 token 占比"测出来。一家单价贵 15%、却让你的前缀缓存命中率翻倍的厂商，才是更便宜的那一家——而这一点，任何公开价目表都不会告诉你。
四条阶梯，以及各自在哪里断掉
把这四家当作阶梯而不是价格点来读，它们就排得很清楚。Together 是唯一横跨全程的——按 token 的无服务器、H100 约 $6.49 一小时的专用端点，以及每 GPU 小时约 $3.99 起、这份名单上没有第二家转售的裸 HGX 集群。Fireworks 覆盖上面两级，并把第一级的价格压在同行之下：70B 档模型约 $0.90 每百万，对 Together 的 $1.04；在更新的开放模型上也有相仿的差距。Baseten 同样覆盖上面两级，但它的专用算力是从约二十家云厂商那里撮合来的，而不是自有——这是一个关于韧性与成本套利的故事，不是关于峰值性能的故事。Modal 没有按 token 这一级：从第一个请求起你就为 GPU 时间付费；这在原型阶段看着贵，而恰恰在上面那道算术开始生效的那一刻，它就不再贵了。
阶梯断掉的地方，就是迁移开始的地方；而这些平台之间的迁移并不免费——模型目录、微调产物、可观测性集成与限流行为，全都是平台特有的。"你最终会需要它顶上那一级"的厂商，价值高过"你今天站着那一级上打的 15% 折扣"。这条论证的一般形式见预置吞吐与用量承诺。
冷启动是你为下一级台阶付的价
一旦离开始终热着的无服务器层，缩容到零就可用了，而冷启动也就成了你的问题。四家在这里的分野最尖锐，且分在工程上而非商务上。Modal 把整个产品建在这件事上——Rust 编写的容器栈与内存快照，让多数启动落在一秒以内；这正是"按 GPU 秒计费"能被接受的原因。Baseten 靠容器缓存把冷启动往下压得很狠，不过公开数字随模型体量与配置差异很大。Together 与 Fireworks 则在各自的无服务器层上基本绕开了这个问题——它们替你把热门模型保持热态；这是实打实的好处，也正是那两层卖那个价的原因。
对智能体来说，这比对批处理更要紧，因为智能体的调用既突发又交互：一次冷启动拖住的不是一个作业，而是一条有人正盯着的轨迹。如果你在智能体底下跑缩容到零，那么冷启动这个数字就是一个时延数字，它该和并发与扩缩容里的其他项目共用同一份预算。
两条比价格更能定生死、却从不出现在对比表里的轴
这些权重是谁的
如果你跑的是现成的开放模型，四家都行得通，决策就是商务问题。如果你要跑自己的微调权重，候选立刻收窄：Baseten 的全部主张就是把自定义与微调模型送进生产，背后配一套真正的服务工具链；而 Modal 你递给它什么容器它就跑什么。Together 与 Fireworks 也都支持微调与适配器服务，但它们的重心在自家托管目录上。早点定下这一条，比任何价格比较都更值，因为这是那条回头很贵的轴——至于你到底该不该走这条路，见微调 vs RAG vs 提示词。
是尾延迟，不是中位吞吐
每家厂商的宣传数字都是中位数。而一次智能体回合是一条链，链会把尾部风险乘起来：如果单次调用有百分之一的概率慢得离谱，那么一条十五步的轨迹里出现一次的概率大约是 14%。这就把一个罕见事件变成了一件家常事，也意味着你真该跑的对比，是在你自己的批次形状与上下文长度下做的 P99 对比，而不是读一张排行榜。
这也正是专用那一级凭着与成本无关的理由挣回本钱的地方：在共享的无服务器算力上，你的尾部是别的租户的流量；在专用部署上，你的尾部是你自己的。对于给智能体回合定了时延 SLO 的团队，这份可预测性往往才是搬家的真实理由，而成本是事后写在工单上的说辞。
什么情况下选谁
| 情形 | 选 | 理由 |
|---|---|---|
| 智能体负载增长很快，模型选型尚未定下 | Together AI | 唯一三级俱全的阶梯，所以"长出按 token 计价"是一次配置改动，而不是一次迁移。 |
| 用现成开放模型，被盯着看的账单项就是 token 费 | Fireworks AI | 主流模型的 token 单价一贯压在同行之下，且自动前缀缓存对智能体的好处不成比例地大。 |
| 你要在生产里跑自己的微调权重 | Baseten | 它就是为这件事造的，且专用算力是从多家云撮合而来，不被钉在一家上。 |
| 自定义服务栈、突发流量、Python 原生的团队 | Modal | 亚秒级冷启动让缩容到零变得可行，而引擎与容器的控制权完全留在你手里。 |
如果以上都不像你，那么诚实的答案是：你还在平衡线以下，应当继续用你手上那个按 token 的端点，并把它放在一个能让切换保持廉价的网关后面——这正是LiteLLM、Portkey、Cloudflare AI Gateway 与 Kong AI Gateway 里的论证。把服务层整个自建，是同一条阶梯上再往下一步，见 vLLM、SGLang、TensorRT-LLM 与 llama.cpp。
常见问题
智能体负载到什么程度就该离开按 token 计价？
当持续 token 吞吐越过每小时约 780 万时——这正是按约 $0.90 每百万计价时、一个专用 H100 小时所值的量。对智能体流量而言，那大约是十来个持续运行的工作单元，远低于一个聊天产品所需的数百并发用户。请去量你自己的每小时 token 数，不要照搬这个比例。
同样的墙钟时间，智能体为什么比聊天多吃这么多 token？
因为上下文每一步都要重发。一条携带三万 token 工作上下文的二十步轨迹，会把那份上下文发二十遍，于是提示词 token 以接近两个数量级压过输出 token。这个效应随轨迹长度增长，所以最先压垮按 token 经济账的，正是长程智能体。
提示词缓存会改变那条平衡线吗？
会，而且改得不小，方向是让你在无服务器上多待一阵。命中的提示词 token 通常打约五折，而智能体的前缀又格外稳定，所以一个好的命中率能把交叉点显著往外推。代价是：在共享机群上，命中率取决于你控制不了的请求路由。
Modal 和另外三家真的可比吗？
只有在你愿意自己扛服务栈时才可比。Together、Fireworks 与 Baseten 交给你的是一个模型的端点；Modal 交给你的是一个冷启动极快的容器运行时，并预期你自带 vLLM 或与之等价的东西。那是更多的活也是更多的控制权，而当你的需求塞不进一份托管目录时，这笔交换是对的。
我是不是该拿这些去和前沿模型 API 比？
它们回答的是不同的问题。这四家托管的是你自己挑选、且可以在其间搬迁的开放权重模型；一个前沿 API 卖给你的是一个搬不走的特定模型。多数生产级智能体栈最后两者都用，按任务路由——这正是模型路由描述的模式。
延伸阅读
本站相关：
- 推理服务商——谁在提供模型服务、又如何计费的概念级地图。
- 智能体成本控制——一个智能体的 token 一步一步花到了哪里。
- 上下文缓存经济学——前缀复用及其价值的完整处理。
- 面向智能体的自托管推理——这四家再往下的一级台阶。
- 预置吞吐与用量承诺——在不过度承诺的前提下锁定算力。
- vLLM、SGLang、TensorRT-LLM 与 llama.cpp——这些平台底下的服务引擎。