7 产品边界

7.1 六类产品

市场把 GPU 租赁、托管推理、MaaS、聚合路由和 token 工厂并列着讲，但同样一句卖推理，交付物可能完全不同。要看清实际交付，把它们拆成六种正式产品。六种产品共享 GPU 和模型，分界线在于客户买到什么、谁控制运行栈、按什么计费、闲置和故障风险由谁承担。

第一类，机房托管。客户购买空间、电力、制冷和互联，按机柜、功率、端口或期限计费，自己提供并控制服务器与软件。供应方只承诺设施可用性，不对某个模型的 token 吞吐负责。机房方希望长期锁定功率，客户却希望保留设备代际和需求弹性，这对矛盾贯穿所有托管谈判。

第二类，GPU 租赁或 IaaS。客户购买裸机或 GPU 实例时长，控制操作系统、容器、模型和服务栈。Lambda 的公开计费说明显示，按需实例在运行期间即使没有活跃负载仍然计费。核这类产品把硬件可用性风险留给供应商，把模型部署、服务集成和闲置风险交给客户。低卡时价只说明一种上游输入便宜，不能证明单位 token 成本低。

第三类，托管专用端点。客户保留单租户 GPU，供应商运行服务软件。它解决多租户干扰、版本稳定和性能可预测问题，按 GPU 时间或端点时间计费。Together 的官方文档把共享、按 token 的 serverless 与单租户、保留 GPU 的 dedicated 明确分开。核这类产品并没有消除闲置，而是让客户用固定付款购买隔离和确定性。

第四类，预置吞吐。客户不关心底层是哪组 GPU，而是购买特定模型的保留服务能力。AWS Bedrock 用 model unit 表示相应模型的输入输出 token 速率，按小时或承诺期计费。核供应商负责在模型边界内组织硬件和软件，客户承担承诺没用满的风险；合同必须说明超出容量后是排队、拒绝、按量溢出还是自动扩容。

第五类，MaaS 或 serverless 推理。客户只通过 API 使用模型，供应商控制模型、运行时、多租户池和大部分运营。客户不为具体 GPU 的闲置直接付费，却通过更高单价、限流、尽力而为的性能或数据条款间接承担。它适合突发、小规模和多模型试验；用量稳定后客户会转向专用端点或预置吞吐，单价下降的同时接过更多固定承诺。

第六类，聚合路由。聚合器提供统一 API、模型目录和账单，按价格、延迟、吞吐、故障与政策选择底层供应商。它降低接入与切换成本，但未必控制底层资产、模型版本和故障恢复；路由回退提高可用性，也可能改变数据位置、输出行为和费用。客户合同必须说明区域和供应商偏好是硬约束还是尽力而为。

7.2 工作概念

token 工厂不在这六类正式产品里，因为截至研究截止日它不是边界统一的行业术语：NVIDIA 的 AI factory 覆盖从数据摄取、训练到推理的完整生命周期，其他厂商用 Token Factory 指代范围各不相同的推理或托管产品。核本册只把它当作工作概念：把可控制的 GPU 容量、合法模型、推理软件、运维、计量和结算组合成满足明确服务目标的可计费 API 系统。

这个工作定义用来防止名称替代证据。任何自称 token 工厂的方案，都要继续回答五个问题：交付单位是 GPU 时长、模型端点、保留吞吐还是 token；资产、模型、运行栈、路由和账单由谁控制；客户是真实终端、渠道还是另一层转售商；谁签 SLA、谁开票、谁收款、谁承担信用额；可售产能来自哪组可复现实测，而不是哪张峰值表。

7.3 五维选择

选产品时不要只比目录价。按量服务的单价可能高，却避免大量闲置；专用端点单价可能低，却要求稳定利用；聚合器接入快，却增加一层数据和故障责任；GPU 租赁控制高，却要求客户自己完成整套服务。若一方报价的是 GPU 租赁，另一方拿 MaaS 的 token 价格比较，差额里混着模型、软件、运维、弹性和风险，不能直接称为利润空间。

7.4 风险移动

产品越靠近物理层，客户拥有越多技术控制，也承担越多集成与利用率风险；越靠近 API 层，供应商承担越多池化、模型和服务风险，客户则更依赖价格、限流与条款。模式没有统一的高低顺序，产品价值取决于控制权组合与负载是否匹配：有的企业宁愿买 IaaS，因为需要模型和数据控制；有的开发者宁愿为 serverless 付较高单价，因为需求尚不确定；有的聚合器价值高于自持 GPU，因为它掌握真实需求入口。

产品边界定下来，五张经营表才有共同分母：收入按什么单位确认，成本计入哪个主体，资产除了设备还有哪些权利，风险随边界怎样转移，激励在哪里冲突。第 9 章的六流审查和第 28 章的合同审查都建立在这一步之上。

7.5 货架许可

权重能下载不等于能拿去卖。上架前要确认的是许可证原文，不是模型卡上写的开源两个字。

开放权重与开源许可是两件事。开放权重指权重文件可公开获取；许可证决定能不能托管对外提供服务、要不要署名、有没有用户规模阈值、有没有用途限制。多数争议出在中间那一档：权重随便下，但托管给第三方用属于另一种授权。

上架前固定做四个动作。第一，把许可证原文和版本号存档，不存链接，因为页面会改。第二，确认服务形态落在授权范围内，托管推理通常按 hosted service 判断，与自己内部用不是一回事。第三，确认地域限制，有些许可对特定法域另有条款。第四，确认署名与命名要求怎样体现在 API 文档、模型标识和账单上。

许可证会变，而且不追溯到旧版本。同一个模型的新版本可能换许可，旧版本拿到的授权不会自动延伸过去。货架上每个模型都要记录版本号与对应的许可证快照，升级模型时重新走一遍这四个动作。

下架比上架贵。撤一个模型要通知客户、给迁移期，可能触发 SLA 条款，还会影响聚合平台上的评分。许可存疑的模型不要抱着先上再说的想法，因为撤下来的成本落在商务侧，不落在决定上架的那个人身上。

7.6 渠道上架

产能卖不出去的原因通常不是价格，是没有通路。四条通路的账期和定价权都不同，选错通路，租金的付款日会先于回款日到。

聚合平台上的位次是跑出来的，不是谈出来的。平台按价格、延迟、吞吐、错误率和可用性在多个供应商之间路由。核新上架的供应商拿到的流量取决于这几项的实测表现，所以上架后第一件事是把可用率和错误率做稳，价格战排第二。用低价换首批流量、再被高错误率打下去，是最常见的浪费。

上架材料是固定的一份。一个 OpenAI 兼容端点、模型清单与定价、区域与数据处理说明、限流与配额策略、结算主体与收款信息、故障联系人与升级路径。这份材料对所有聚合平台大同小异，准备一次可以复用；难点从来不在材料，在于端点背后的产能是不是真的稳定。

谁做记录方决定谁承担责任。平台合同由谁签、平台追责找谁、发票由谁开，三件事绑在同一个主体上。产能方不便出面时，中间主体要真的承担这三件事，包括故障时的赔付和内容合规的连带责任；只赚价差不担责的中间层，在第一次事故时就会被平台绕过去。

同一批产能不能在两条通路上重复承诺。聚合平台的预留容量和直签客户的最低承诺量如果指向同一批卡，峰值撞车时必然违约一边。产能台账要按通路分配，而不是按销售额分配。