Together AI / Fireworks：给开源模型做托管推理的“水电公司”

一句话定义：Together AI 和 Fireworks 是提供托管推理（hosted inference）服务的厂商。用户把请求发给它们，它们在自家 GPU 集群上运行开源模型（open-weight model），并按用量计费。用户不必购买显卡、搭建环境或运维集群。

理解这些服务，可以把开源模型想成一台免费赠送的好车：车不要钱，但油费、车库、保养和司机都要自己配。自建 vLLM（一个高吞吐的开源推理引擎）就像自己建车库，要采购 GPU、处理驱动与显存、调整批处理参数、应对流量高峰和机器故障，还要有人值守。托管推理更像打车：模型权重由服务商准备好，用户拿到一个 API key，按 token 付费，服务商负责机器、扩容和故障切换。

Fireworks 更强调推理层面的工程优化，让开源模型跑得更快更稳；Together AI 除了推理，还提供模型库、微调等能力。两者有个共同的产品取向：接口刻意做得像闭源 API，切换模型往往只需改一个 model 名字。

和相邻概念的区别：

• 与直接调用闭源 API 相比：托管开源服务的可控性更高，可以指定具体模型、权重版本和上下文长度，部分场景还能拿回权重自行部署；单价通常低于顶级闭源模型，但总账要看流量曲线，具体价格以官方页面为准。闭源 API 的优势在于开箱即用的能力上限和零运维。
• 与自建 vLLM 相比：自建在流量稳定、GPU 能被充分利用时，单 token 的边际成本可能更低；代价是固定成本、闲置浪费和运维人力。托管按量付费，流量小或波动大时更划算。

一个粗糙的选型判据：

对从业者来说，这一层常被当作中间台阶：先用托管服务验证产品与模型选型，等调用量稳定后再算自建账，避免一开始就预支大笔 GPU 预算；它也适合做批量评测、微调和 agent 类高频短请求负载。对普通职场人，意义在于模型正变成可替换的零件：值得投的不是某一家 API，而是一层能随时换模型的抽象接口。

一句话收尾：托管推理卖的不是模型，而是把模型变成水电的那根管道。