- OpenAI 发布 GPT-6 Sol 与 GPT-6 Luna，在同一模型家族内形成面向复杂 Agent 与高吞吐任务的价格梯度；长上下文、处理层级和接口选择仍会改变实际费用。
- Anthropic 发布 Claude Opus 5.5，输入、输出和缓存读取标价均低于 Opus 5，并报告典型任务总成本下降；相关幅度来自厂商测试，迁移还伴随思考模式与工具调用的兼容性变化。
- Together 的灰度发布和 vLLM 0.30.0 的启动、内存机制显示，生产成本还包含切换期重叠容量、人工处置、冷启动与 GPU／主机内存占用，不能只由每百万 Token 的价格推导。
模型价格先形成面向不同任务的梯度
OpenAI 在 9 月 22 日发布 GPT-6 Sol 与 GPT-6 Luna，两者均通过 Responses 和 Chat Completions API 提供，模型页列出 1,050,000 Token 上下文和 128,000 Token 最大输出。对不超过 272K 输入 Token 的 Standard 请求，Sol 每百万输入、缓存输入和输出 Token 分别为 2、0.20 和 10 美元；Luna 分别为 0.10、0.01 和 0.50 美元。OpenAI 将前者定位于复杂编码和 Agent 工作流，将后者定位于聚焦且高吞吐的任务；这种定位与价格差并不证明两者在同一任务上能力等价。
Anthropic 同日发布 Claude Opus 5.5，标准价格为每百万输入 Token 4 美元、输出 Token 20 美元，5 分钟缓存写入 5 美元、缓存读取 0.20 美元。相较 Opus 5 的 5 美元输入、25 美元输出和 0.50 美元缓存读取标价，这些项目分别下降 20%、20% 和 60%。Anthropic 还称默认设置下的典型工作负载总成本可低 40%、输出速度可快 30% 以上；这些是厂商测试与早期用户口径，不是跨企业生产环境的独立测量。
对企业落地而言，单位 Token 价格适合做预算的第一层输入，却不能替代同一业务任务上的成功率、总输入输出、工具调用、重试、端到端时长与人工复核记录。不同模型面向的任务强度、推理设置和服务层级不同，因此价目表不能直接换算为单位任务的成本排序。
迁移边界会改变价目表之外的工作量
OpenAI 的模型文档列明，Sol 与 Luna 都不支持微调；欧盟数据驻留只在 Standard 处理层可用。输入超过 272K Token 时，整次请求的输入与缓存费率按 2 倍、输出费率按 1.5 倍计价；Chat Completions 仅在 reasoning effort 设为 none 时支持函数调用，内置工具和常规函数调用应使用 Responses API。因而，同一家供应商内部的任务路由仍需同时检查上下文长度、数据地域、接口和工具链条件。
截至 9 月 23 日核验的 Anthropic 官方迁移文档列出四类不兼容变化：Opus 5.5 的思考不能关闭，强制指定工具会返回错误，思考块与模型及对话绑定，旧版 computer 工具在部分平台不再接受。该模型默认 effort 也从 Opus 5 的 high 改为 medium；Fast mode 仍是仅在 Claude API 提供的研究预览，价格为每百万输入和输出 Token 8 与 40 美元。迁移不是只替换模型名称，原有提示、工具选择、对话续接和预算假设都可能需要回归验证。
对企业落地而言，迁移成本应包含接口改造、权限和数据驻留复核、基准集重跑以及失败回退，而不能只比较新旧单价。公开文档说明了兼容边界，但没有给出特定企业系统完成迁移所需的人时或故障率。
灰度发布把重叠容量与人工处置写进账单
Together 在 9 月 22 日介绍 Dedicated Inference 的新发布引擎，支持 canary、blue-green 和 rolling 三种策略。Canary 可按阶段迁移流量并检查错误率、延迟和在途请求；blue-green 在旧版本排空前保留两侧完整容量；rolling 在步骤中通常多保留一个副本。三种方式的风险隔离和切换速度不同，切换期所需的额外 GPU 容量也不同。
这套机制的边界比页面标题更具体：指标门触发后系统进入 SYSTEM_PAUSED 并冻结当前流量比例，不会自动执行回滚；操作方需取消当前发布，再交换源与目标发起反向发布。厂商以各一张 H100、5 次请求每秒的 Qwen2.5-7B 至 Qwen3.5-9B 切换演示称，在 10% 流量阶段发现目标 p95 延迟为 1,740 毫秒、源为 734 毫秒，超过 25% 的回归预算并暂停。该结果是单一厂商演示，不能外推为其他模型、硬件或负载的性能结论。
对企业落地而言，模型更新的成本还包括并行保留旧新容量、观察窗口、故障期间的人工判断和反向发布时间。分阶段门控可以限制影响范围，却不等于自动恢复，也没有消除业务侧对回退条件和责任人的定义。
自托管运行时把启动与内存占用显性化
vLLM 在 9 月 22 日发布 0.30.0，新增 DeepSeek-V4.1-Flash、GLM-5.3-Flash 等模型支持，并提供 CUDA、ROCm、CPU 与 XPU 等构件。Fast Start 通过每 GPU 的持久权重缓存守护进程保留量化后、按张量并行切分的权重，运行引擎重启时用 CUDA IPC 映射，而不是重新从磁盘加载；这项机制以持续占用相应 GPU 内存为代价。
同一版本的 HiSparse 面向 sparse-MLA 解码，把 KV 页溢出到锁页主机内存，并在 GPU 保留每个请求的热缓冲。Release 还包含需要显式启用 scale-out endpoint、移除旧环境变量等破坏性变化。项目披露的启动与性能数字来自特定硬件和配置；模型能够被运行时加载，也不等于已经获得生产验证、服务等级或在目标数据上的质量证明。
对企业落地而言，自托管成本同时受冷启动频率、GPU 与主机内存配比、版本升级和监控处置影响。运行时优化可能缩短特定路径，却会引入适用条件和资源交换，仍需在目标模型、量化方式、并发与上下文配置下测量。
后续观察
- 同一业务任务在不同模型与服务层级下的完成率、总 Token、工具调用、重试和端到端时长能否形成可复现对照。
- 灰度切换的重叠 GPU 用量、暂停时长和人工反向发布时间，是否会被供应商纳入可导出的成本与审计记录。
- Fast Start 与 HiSparse 在不同量化、上下文和并发条件下的显存／主机内存交换，是否有独立生产负载数据。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准；“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析，不构成对第三方产品的背书。
← 返回每日观察