Fable 5是过去半年最受市场期待的模型，而在真正发布之后，它又迅速成为“最具争议”的模型。除了安全禁令外，它的使用体验反差也相当明显：在一些任务里，Fable 5更像一位能独立推进任务的同事，而不再是只会执行的实习生；与此同时，也有一部分开发者却给出相反结论：在很多真实生产任务里，它并没有带来底层智能的质变。
评价的两极其实并不矛盾：只有在高价值任务上，模型的上限才看得见；在那些已经“够用”的任务上，最强模型和低价模型的差距会被迅速抹平。这个分歧本身才是最值得关注的信号：模型能力与收入的分化正在发生。
而GLM 5.2之所以引发讨论，本质上也是“Mythos级别模型”竞争的另一面：Fable 5（以及传闻中即将发布的GPT 5.6）赚取塔尖高价值任务的溢价，而能够迅速追平SOTA的国产模型有机会在吞掉塔基的海量token。
这两股力量指向的是同一个结构。这个结构，也是我们认为下半年最值得下注的判断：前沿模型拿走80%的收入，开源与低价模型处理80%的token。模型能力的分化，正在变成模型收入的分化；而真正决定高价模型收入厚度的，是金字塔顶端的高价值任务到底有多厚。
Insight01
评价分化：高价值任务才看得到模型上限
一线开发者体感
1.在Fable 5的用户使用感受中，有一个很有趣也十分值得重视的分化趋势：
•一方面，不少用户认为Fable 5已经接近project owner的角色：它能主动补充上下文、拆解任务、调用工具、推进流程并验证结果；
•与此同时，也有用户给到完全相反的结论，甚至认为Fable 5相比Opus 4.7/4.8，智能上没有本质变化；
•最有趣的是，即便同是开发任务，Fable在SQL语言任务的表现被认为很强，但在Python类任务里，则被用户评价“与GPT-5.5表现更接近”。
2.这个分歧的本质其实是测试任务的不同。如果具体看两类反馈的实际测试任务，会发现在生活规划、文本格式、常规的coding等已经能被现有模型很好完成的任务上，很难直接、直观地看出Fable 5与GPT-5.5、Opus 4.8、Sonnet级模型的差异，但如果涉及到复杂工程、反编译、auto research、安全攻防、大型系统改造等高价值任务，反而更加容易展示Fable在主动推进、反思纠错、造工具和调度sub-agents的能力。
3.有AI Researcher提到，Mythos在部分开放研究方向选择上已经接近人类研究者判断。在从Claude切回Gemini 3.5继续推进同一类研究工作时，能明显感觉到切换模型带来的任务推进质量下降：原本用Claude已经推进到约70%的研究进度，换回Gemini后可能因为hallucination、instruction following不稳定、无法持续沿着既定实验路径推进等问题，被迫返工或回退，体感进度可能掉到约50%。
4.用户对Fable 5的评价分化，也和在使用时实际运行的模型状态有关。
有用户把Fable 5调到low effort后，使用体感更像一个“稳定版Opus 4.6”，质量仍可用但token消耗可能明显下降；也有人观察到，Fable 5在sub-agent任务里会把简单步骤交给Haiku等更便宜的模型；再加上部分任务会触发safety fallback，实际承接任务的也可能变成Opus 4.8或其他模型。因此不同用户看到的Fable 5，可能对应不同effort、不同routing和不同成本结构，最终评价自然不会完全一致。
5.不过，开发者用户对于Fable的模型体验一定程度上也受到了Fable的安全分类器和访问权限影响，因此，对于绝大多数开发者而言，他们未必能接触到Fable 5的完整能力。比如目前网络安全、生物化学、模型蒸馏等方向更容易被拒答、限制，或路由至Claude Opus 4.8。
6.一个普遍的猜想是，AI for Science、网络安全等高敏感能力未来可能不会完全通过公众模型开放，而是以授权、白名单或专用模型方式提供。
7.资本市场对Fable 5的分歧，也可以放回这套用户体验框架里看。从乐观角度看，Fable 5让高价值任务、超级工程和自动化研究更接近可用，说明模型能力仍在加速；从谨慎角度看，Fable 5还没有体现足够强的TAM扩张driver，使用门槛高，高价值任务的价值量仍没有结论。
Benchmark表现
8.Fable 5在红杉中国Xbench的测评结果更直观地说明了为什么开发者对Fable 5的体感会出现分歧：
•首先，Fable 5的提升没有直接表现为所有benchmark分数全面上涨；
•在ScienceQA等测试里，安全路由、拒答和fallback会拉低总分，但把输出token等细项拆开看，它在部分任务上能用更短的推理链完成回答。
成本
9.综合Xbench中Fable 5平均输出token更低的结果，以及部分开发者把effort调到low后的实际体验，可以得到一个粗略的成本估算：Fable 5的token单价虽然约为Opus 4.8的5倍，但在一些任务里，由于输出token和中间推理消耗更少，token用量约只有Opus 4.8的1/2，甚至如果将effort调成low，中间过程用量会低于1/5，因此，Fable 5在low effort综合成本可能低于Opus 4.8。
10.但这并不意味着Fable 5在所有场景里都更省钱。在更接近真实coding agent的CursorBench里，成本和性能的关系会变得更复杂。
11.CursorBench 3.1显示，Fable 5 Max分数最高，但cost/task也最高；同时，test-time compute scaling已经比较平缓，继续增加推理预算仍能换来更高分，但单位成本带来的边际提升已经下降。
Insight02
Use Case：企业Workflow重塑
12.有创业团队提到，Fable 5已经几乎重塑了他们的工作流程。现在更多是由人来确定目标、边界和验收标准，模型负责拆解任务并推进执行。随着Fable 5在端到端任务上的能力提升，人和agent的分工也在变化：团队越来越像一个file system，每个人都是独立IC，把任务交给模型后持续跟进结果。
13.虽然Fable 5能自己补上下文、拆任务、开sub-agent、自检和修正，但这不意味业务流程就自动化了。因为模型能并行调用100个sub-agent，也可能把错误路线放大；真正可复用的workflow需要稳定输入、输出、状态管理、异常处理和验收标准。无论是Opus 4.8还是Fable 5，从0到1搭建一个可复用workflow仍然很费劲，最后常常需要人花一两周重新整理和改写。
14.企业提效的基础框架仍然是workflow加toolchain，AI只是让后两步发生变化。
15.企业AI转型的关键，不只是用AI替代现有流程，而是重构流程本身。减少信息传递、压缩协作层级、简化决策链路，往往比单纯给员工配更强的模型更能创造价值。
16.随着模型能力提升，面向coder和非coder的agent将走向两条不同路径：
•Coder需要更开放、更可编程的系统；
•非coder需要更简单、更稳定的任务界面，依赖GUI、预定义工作流完成工作。
17.大部分用户没有必要同时扮演生产者和消费者，harness的价值是把模型能力封装成可直接使用的工作界面。
18.设计、3D和交互demo
用户在three.js、3D世界构建和one-shot网站设计中感受到Fable 5的design taste有明显提升。比如Fable 5能生成更复杂的3D demo，复杂度从简单小游戏提高到接近“Minecraft”风格的互动场景；在one-shot网站设计中，Fable 5第一次生成的网站就已经有一定美感，AI配色感更弱，也更会在视觉表达上做减法，呈现出一些“less is more”的design taste。
19.反编译和隐藏上下文获取
在这类任务里，Fable 5需要从网页、混淆JS、Android App、游戏ROM和运行逻辑里获取上下文，再还原产品功能或游戏机制。
一个例子是把web游戏还原到Godot，Fable 5能通过混淆JS还原第一关逻辑，代码可以运行，主要元素也能复现。短板主要出现在视觉细节上，元素大小、重叠、缩放和参考图对齐不够稳定，即使用户提供参考图，模型也未必能把所有视觉细节调准。
“混淆JS”通常指JavaScript代码混淆（JavaScript Obfuscation），就是把原本容易阅读和理解的JavaScript源代码转换成难以阅读但功能不变的代码。
有开发者认为，类似于“混淆JS”这类能力其实从Opus 4.6开始就可能已经逐步形成，这类能力与安全和黑客技巧相关训练被模型吸收有关，也给网络安全提出了更高要求。
20.TypeScript Eval
这个任务相当于写一个Excel，规格文档有几千行。Fable 5用了约3小时、花费约200美元一次完成，是第一个完成该任务的模型。相比之下，GPT-5.5 xhigh大约需要10小时，功能完成度接近90%，但工程决策和性能较弱。
这个例子一定程度上可以说明Fable 5已经能搞定一些旧模型容易卡住的复杂POC。不过，虽然这类复杂任务后续可以交给Fable 5，但日常开发场景里，开发者认为自己大概率还是会优先用Codex。
21.Long Horizon任务
一位CTO级用户过去一年AI编程超过100万行，最近3个月日均AI coding成本超过1000美元。Fable 5开放后，他拿之前做过的生产任务重新对比和延续测试，两天花费超过1万美元。实际体验下来，他认为Fable 5相比Opus 4.7/4.8，主要提升在工具调用熟练度和稳定性上，智能水平没有本质变化。
也有开发者基于OpenClaw自研了一个飞书上层插件系统，在企业内部部署了约300套，用户希望模型写一个每天定时自动升级这个系统的workflow：能自动找到最新版本，处理OpenClaw和Hermes升级，保留自研patch，修复上游merge后的冲突，并能持续复用。在已有1.0基础上，Fable 5能处理具体版本问题，也能理解部分升级和patch修复工作，但它反复把“写一个通用升级workflow”误解为“针对0606版本修一个patch”。
也有开发者提到，在使用Fable 5直接跑一些long horizon任务时，主要卡点是任务跑得很久以后忘掉前面的信息。虽然Fable的long horizon能力有增强，但距离“无限上下文和无限可靠执行”还存在距离。
Insight03
模型能力分化带来模型收入分化
22.Fable 5实测中的“体验分化”会指向一个潜在趋势，即人们在使用模型时，会开始判断任务本身是否值得消耗最强模型。比如对于“Mythos级别”模型而言，一个好标准是：不要只问“Fable能不能做”，更要看“Sonnet/Opus是否也能做得差不多”。如果旧模型也能凑合完成，Fable的溢价就不一定成立；如果任务超出用户和旧模型的能力边界，Fable才更容易体现差异。
23.相对应，高价值任务也可以用三条标准判断：
•模型需要主动获取上下文，
•结果可以被清晰验收，
•任务本身能承受更高探索成本。
当模型要自己读代码、查环境、补背景、拆步骤、调用工具并验证结果时，Fable 5更容易体现价值；当用户只把Fable当执行器、交给它已经定义清楚的小任务时，Fable与其他模型之间的差距会被压缩。普通coding、生活规划、聊天和结果较fuzzy的任务容易低估Fable 5，通常就是因为验收不清或成本不值得摊开。
24.Fable 5的ROI取决于任务价值，token价格只是其中一个变量。对于上亿规模的投资决策，或支撑上亿DAU应用的核心infra，额外token成本相对业务价值已经不再是主要约束。虽然当前我们还无法完全信任Fable 5/Mythos承接这类高价值任务，但方向已经可见。如果未来1–2年模型成本再下降两个数量级，这类场景的可行性将明显提升。
25.但在普通白领和C端场景里，Opus 4.6、国产模型或低价模型可能已经够用，因此前沿模型的商业问题变成：金字塔顶端的高价值任务有多厚、能产生多少收入、是否足够支撑持续扩张。
•模型价值分布可能比人类社会更偏向头部，因为模型供给比顶级人才供给更具弹性，小幅能力提升也可能带来显著价值差异。
•模型市场可粗略看作P×Q：P是单个任务价值，Q是任务数量。随着模型成本下降，更多高价值任务会被释放出来，头部模型的价值集中度可能进一步提升。
26.AI时代的ToB生产力市场可能是ToC的很多倍，推荐系统、搜索系统、底层infra、企业内部工具链和大型工程重构，都会消耗大量token。Fable 5的multi-agent/sub-agent能力让超级工程更可行，或许未来模型可以做到自主写一个Google、一个Office或重构大型系统。
27.其实在Fable 5的sub-agent workflow里，并不一定每个环节都由最强模型完成，一些简单子任务可能会被路由给更便宜的Haiku。比如，在一些case中，如果在Codex/Claude Code等环境里接入DeepSeek、Gemini API或本地小模型，这些模型也可能进入可调用的模型池。但当前的问题是routing还不够透明，用户很难知道每个步骤到底用了哪个模型、为什么这样分配，以及最终是否真的省钱。
28.未来一种可能的格局是，前沿模型拿走80%revenue，开源或低价模型处理80%token，也就是说，高价值任务继续交给frontier model，低价值或可批量化任务交给便宜模型。
29.低价模型需求不只来自C端，也来自ToB任务里的大量中低难度步骤。很多企业任务虽然整体是long horizon，但拆开后，大量step只需要GPT-4 level intelligence。
30.一位做ToB场景的开发者提到，他团队内部bench显示，DeepSeek V4可能已经接近GPT-4o mini水平。因此，只要低价模型能够稳定提供GPT-4级别的智能水平，就有机会在ToB场景中承接大量任务。
31.虽然frontier lab也可以通过蒸馏把小模型做得很好，但在推理算力稀缺、高价客户供不应求时，frontier lab缺少动力去卷低价模型市场。
32.专门打高性价比的模型，也可能在training、架构和推理infra上做不同选择，比如Google这类拥有芯片、Infra、模型和产品线的公司，可能通过Flash等路线把成本优化做到极致。
33.国产半导体供应链和国产模型会一起进入“自主可控”叙事。国产模型的机会来自两方面：
•后发蒸馏和低成本推理；
•大量普通场景只需要足够好的智能。
34.但如果头部模型公司愿意优化同等智能小模型，国产模型的单位成本优势能否长期保持，还需要观察。
35.Routing的商业机会可能更集中在harness层：
•Coding可能是特殊场景，因为coding agent能看到仓库、sandbox、日志和测试，比较容易端到端闭环。很多vertical agent只知道一次LLM API call给了什么context，并不知道任务ROI最高的模型是哪一个。
•真正有价值的routing，需要理解任务目标、上下文、验收方式、用户偏好、成本约束和可用模型池，因此可能成为intelligence allocation的核心位置。
Insight04
Eval和任务设计决定下一代模型迭代方向
36.Fable在implicit intent上的表现更强，包括什么时候改代码、什么时候不改、什么时候拒绝危险请求；这种能力可能来自大量用户trace和trajectory的分析、清洗和再训练。
37.从模型训练角度，到了Fable 5这一代，Eval和任务设计会更直接地塑造模型迭代方向。过去6到12个月，用户还能凭日常体感感受到模型迭代，但现在，即使用户在日常使用中没有aha moment，也不能直接说明模型能力没有提升，可能只是用户的任务想象力、需求定义能力和工作环境没有跟上。
38.对模型公司来说，选择什么eval、把什么行为定义成“好模型”，会直接决定下一代模型擅长什么。
39.ToC和ToB可能走向两套模型优化体系：
•ToC场景需要围绕用户体验建立商业模式。用户更关注快（速度）、好（效果）、省（成本），模型推理成本需要接近微信、抖音等头部C端应用能够承受的用户成本，AI才能大规模进入生活场景。工作提效只是其中一部分，陪伴、娱乐、学习和个人服务等场景同样重要。
•ToB场景会继续追求更高水平的智能。企业愿意为大型工程、高价值业务流程和决策支付溢价，因此模型能力、可靠性和可控性仍然是核心竞争力。
40.从长期看，市场划分可能进一步从ToC/ToB演变为To human/To agent，未来机器人也可能成为巨大的智能消耗终端。
41.Anthropic和OpenAI的差异，既体现在模型大小，也体现在训练方向、产品harness和商业打法上：
•Anthropic更相信scaling，也更聚焦text/code based data、企业级场景和大模型规模；OpenAI的RL、产品矩阵、迭代速度和商业打法更强；
•Anthropic的harness让模型更会组织任务、调用工具、维护上下文、分配sub-agent、把中间结果汇回主agent。GPT-5.5还没有像Claude那样训练dynamic workflow能力，如果OpenAI补齐multi-agent和workflow，与Fable 5在multi-agent任务上的差距可能收窄。
42.理想情况下，模型需要先理解用户真实意图，再判断自己有没有能力完成。但很多用户无法把真正想要的东西说清楚，隐性意图、使用习惯、工具偏好和项目背景都需要模型推断。
43.需求定义能力正在成为新的瓶颈，很多token浪费来自需求本身不清楚。“一句话让模型完成复杂任务”往往难以奏效，就像人类团队也无法仅凭老板的一句话就准确交付复杂项目。
44.随着任务复杂度提升，需求需要被结构化表达，包括背景、目标、边界、验收标准和迭代方式。OPP（Objective-Problem-Proposal）等框架，本质上是在将需求对齐工程化。无论是人与AI，还是AI与AI协作，缺少清晰的需求对齐机制，产出都难以稳定复现。
45.这个判断也能放到GPT-5.5与Fable的工程对照里看。有团队把GPT-5.5长期用在真实代码库中，发现它并非不能跑长程工程；只要任务被拆得足够清楚，并配套规范、AGENTS.md和验收条件，GPT-5.5也能连续跑几十个小时，交付出可接受的结果。
•测试体系迁移就是一个例子。有一个项目里原来有3000多个依赖mock的测试用例，需要迁移到真实环境，当团队把目标拆成“把mock用例改成真实测试用例”后，GPT-5.5基本完成了迁移，上线可控性明显提高。这说明，当任务足够小、验收足够明确时，GPT-5.5也能跑完数量很大的长程工程。
•大文件重构则提供了反向参照。团队让GPT-5.5自由重构时，它会改一小部分就停下来；后来团队加入“文件行数必须降到1000或2000行以下”这类硬约束后，模型才连续跑了接近两天，把8到9个大文件拆得更细。
Insight05
Tokenmaxxing减速≠AI泡沫
46.Tokenmaxxing可能是阶段性难题，本质原因在于企业暂时选错了KPI。
•如果企业把token用量当成AI转型排行榜，就会出现reward hacking，大家为了证明自己AI-native而狂烧token；
•更健康的KPI应该转向valuemaxxing：哪些人、哪些practice group、哪些workflow、哪些任务消耗了token，它们是否流向更高价值工作。
47.数据库和Snowflake时代已经出现过类似问题：大量query带来高账单，企业需要dashboard看清查询是否支持了业务价值。AI时代的dashboard更复杂，可能需要FDE或现场工程团队为客户定制。
48.普通用户和重度用户的成本差异过大，订阅制会越来越难支撑。重度用户会把每月固定订阅迅速用完，普通用户又不愿为高额度买单。
49.Codex和Claude Code自身也在承受高token成本压力，未来可能出现更细的任务计价、额度控制、模型路由、企业预算包和结果导向定价。
50.企业token dashboard的核心，未必是直接衡量价值，第一步是让用户知道token花在哪里。很多vertical场景中，供应商无法准确知道某次输出给客户创造了多少价值，这只有客户自己知道，客户如果认可token流向更值钱的工作，就更容易接受预算增长。如果token value能被dashboard展示清楚，AI行业增长可能回到更健康的状态，甚至出现二次加速。
51.国内token压力还没有全面爆发，原因是客户铺开程度和成本结构不同：
•真正有钱的客户还没有全面铺开token消耗；
•在电商、招聘、广告等场景中，token使用更容易形成明确的价值正反馈；
•国内token成本更低。
Insight06
RSI：AI Labs共同的“高价值任务”
52.对前沿模型公司来说，价值最高的一类任务可能发生在内部，也就是让模型参与并加速下一代模型的研究、训练、评估、方向选择。Recursive Self Improvement是下半年最重要的技术主题之一。
53.RSI和tokenmaxxing是一体两面：能close loop的任务更容易证明token价值。人和agent共同协作时，很难拆清价值到底来自人、模型、工具还是组织流程，只能粗略看token；因此容易评估的任务可以通过RSI或closed-loop eval直接优化，不容易评估的需要先构建benchmark和KPI。
54.目前头部labs基本都在做closed-loop research或automated research。如果内部模型持续领先于外部模型，并率先用于研究自动化，模型能力与研发效率之间就会形成飞轮。一旦飞轮转起来，最强模型可能长期优先服务于内部研发。这会拉大实验室之间的差距，也解释了为什么labs内部研究者对Mythos/Fable的评价更积极。
55.未来可能出现的两个发展路径是：
•某一家实验室率先把模型自己的迭代速度提高，建立领先优势；
•所有头部实验室都在一定程度上用RSI解决更难的research问题，但因为实验资源和边际收益限制，提升速度逐渐放缓。
56.RSI也会改变组织架构：当模型能端到端跑研究或工程任务，人类的瓶颈从操作执行转向目标定义和结果评估。真正重要的是写清loop、goal和eval rubrics，让agent知道什么算完成，什么算有价值。这也会反过来要求企业建立更强的任务环境、数据接口、权限体系和安全边界。
Insight07
AI基建瓶颈：算力与存储
Sub-agents对存储的影响
57.Mythos最大的特点之一是Sub-agents workflow，它训练的难点在于，从“同一个模型分饰两角”走向“主模型调度小模型”后，算法和training infra都会变复杂。
58.当前更直接的做法是end-to-end训练同一个checkpoint，让它在同一环境里同时扮演主agent和sub-agent：主agent偏规划，sub-agent偏执行，相当于用两个loss function一起优化。这种做法的前提是二者共享同一套模型架构和参数。
59.更复杂的下一步，由大模型主Agent调度一个或多个小规模的sub-agent模型，这样就从训练单一模型，升级为同时训练和对齐多套模型。小模型如果只学执行，可能会损失必要的planning能力，因此还需要额外任务设计、数据清洗和评估体系。
60.Sub-agents workflow其实可以看成一种memory scaling：
•主agent不再把所有细节都塞进自己的context window，任务会先被拆给多个sub-agent；
•每个sub-agent在自己的上下文里处理一部分信息，完成后只把结论、代码改动或关键结果汇总回主agent。
•这种设计会减慢主agent context window的消耗，也能缓解1M context window继续扩大带来的硬件和batch size压力。
61.这个结构的关键成本在共享context。主agent分配任务给多个sub-agent时，往往会重复传递用户背景、项目约束、工具偏好、任务目标等信息；
•如果这些内容能作为shared prefix复用，prefix caching和batch inference就能显著降低KV cache转移成本。
•一个例子是，50K token的KV cache如果作为shared prefix复用，batch inference中的KV cache转移开销可能下降约20倍。
62.Sub-agent也会提高batch size，从而改善推理侧毛利：
•普通场景下，一个用户同时打开的并行thread数量有限，batch size可能只有34到35左右；
•agents-workflow一次拉起几十个sub-agent后，可以让batch size长期维持在更高水平。
对模型公司来说，batch size更高意味着单位推理成本下降；对用户来说，这表现为任务并行推进更强，但token消耗和底层资源开销更不容易被感知。
63.Sub-agents workflow对存储的影响存在Jevons paradox。
•单位任务的存储成本可能下降。更多sandbox runtime可以放在NAND里，利用率提升后，单次任务的存储成本可能下降；多个thread/sub-agent反复读取共享状态，也会让CXL内存池更有用。
•但总存储需求可能反而上升。高价值任务会持续增加存储和内存消耗，而这类硬件供给更接近线性增长，未必追得上智能需求扩张。workflow把单次调用做得更省后，用户可能会运行更多任务，最终推高总存储和内存需求。
Jevons Paradox（杰文斯悖论）指的是当一种资源的使用效率提高后，人们往往会更多地使用它，结果导致该资源的总消耗反而增加，而不是减少。
算力供给决定能否打价格战和ARR上限
64.算力供给决定了模型公司短期ARR的天花板，也影响模型公司能否打价格战。因此，相比Anthropic，OpenAI不仅更有动力，也有充分的算力空间通过降价来抢夺市场份额。比如最近GPT-5.6传出降价预期，可能也是为了抢企业ARR和市场份额。
•Anthropic：Anthropic非常缺算力，有市场消息，Anthropic的算力量级大概在2-3GW，其中约一半用于training，真正用在inference上的供给更紧；
•OpenAI：OpenAI算力更充足，有人猜测OpenAI的算力可能超过了5GW，因此更有空间用降价抢份额。OpenAI的价格空间主要来自两点：
1）B卡带来的推理效率提升；
2）如果OpenAI的模型激活规模能做到小于Fable，那么单位推理成本就会更低。
65.一个潜在的趋势是，旗舰模型长期会变便宜：虽然模型的reasoning token和参数量在增加，但API价格仍在下降。事实上，模型在生命周期内的降价并不罕见，例如GPT-4o发布时API价格较GPT-4 Turbo低约50%，相比之下，Anthropic的降价频率较低。
66.Anthropic短期能否盈利，关键看算力采购是否匹配收入增长。如果算力买少，模型供给会受限，企业ARR增长会受到压制；如果算力买多，短期折旧和租赁成本会拉高亏损。
67.长期看，如果头部模型公司的ARR能做到3000亿美元级别，即使每年training cost达到300亿到500亿美元，inference毛利维持在60%左右，盈利模型仍然可能成立。
68.在每GW能支持多少收入这个问题上，市场的估算范围在25-45B之间，估算差异很大。
69.Fable/Mythos的访问限制和监管风险，可能会增加企业对备用模型和硬件的需求。如果企业担心前沿模型因监管或安全风险被限制访问，会更重视备选方案，包括自研模型、基于开源模型微调、内部模型储备和多供应商部署。即使不考虑Fable 5这种最前沿模型，仅Opus 4.6到4.8这一代的需求也已经很旺盛，硬件产业链仍然处在瓶颈状态。"