AI日报｜DeepSeek降价75%背后的100x陷阱、Google表格基础模型、代码生成不是企业AI的答案
2026年7月15日
一、DeepSeek降价75%，但"100x问题"让价格战失去意义
DeepSeek最新将其V4-Pro模型价格下调75%——按常理，这对开发者和企业AI供应商是重大利好。但VentureBeat的一篇深度分析揭示了一个反直觉的现实：更便宜的模型不等于更健康的利润率，因为Agent系统消耗token的速度比价格下跌快得多。
核心概念：Token放大效应（Token Amplification）
- 单轮Chatbot：用户一条消息 → 约1次模型调用，输入/计费比约1:5
- 多步骤Agent（客服、销售、财务、法律、工程）：输入/计费比轻易达到1:700
- 一个看似简单的查询"上周客户最关心什么？"，实际触发7次计费操作：
- 用户prompt（~50 tokens）
- 系统prompt+工具定义（~3,000 tokens，每次调用重复）
- 检索（~5,000 tokens上下文）
- 模型调用#1：工具选择（8,000入/200出）
- 工具执行返回（~4,000 tokens）
- 模型调用#2：总结（12,000入/400出）
- 模型调用#3：后续决策（12,400入/100出）
- 一句话进，约35,000个输入token计费。在前沿模型上约合$0.10–$0.40/次
乘以企业级月均百万次查询，就是六位数级别的成本中心。
我的分析： 这个"100x问题"戳破了一个行业叙事——人们普遍假设AI推理成本会随模型降价而趋向于零。但这个假设只对单轮Chatbot成立，对Agent工作流反而可能走向反面：模型越便宜，越容易滥用；token放大效应越明显，成本失控越严重。
这直接挑战了当前企业AI的主流商业模式——按座位/月收费的SaaS定价。如果一个power user每天发起50次Agent调用，$40/座/月的计划可能覆盖不了它的推理成本。价格战打的是模型层，但Agent架构的成本结构是另一套账。下一阶段的企业AI定价将不得不从seat-based向usage-based或outcome-based迁移，这不是趋势，是被迫的。
原文链接：VentureBeat - DeepSeek cut prices 75%. The 100x problem remains
二、Google发布TabFM：无需训练即可预测任意表格数据
Google Research本周发布了一篇博客，详细介绍了TabFM（Tabular Foundation Model）——一个将表格预测从"为每个数据集单独训练模型"转变为"单次前向传播即出结果"的零样本基础模型。
传统ML的债务问题
构建一个可靠的梯度提升树模型，数据科学家需要：清洗数据、填补缺失值、编码分类变量、设计特征交叉、运行超参优化循环以对抗数据漂移……整个流程耗时数周，且需要持续维护。
而TabFM的思路完全不同：不给定数据集重新训练，而是把历史样本和目标行一起作为prompt输入，模型在运行时从上下文推断关系。 也就是说，预测一个新表格，不需要任何权重更新，一次API调用搞定。
为什么LLM不能直接处理表格？
LLM用自然语言训练，处理结构化表格有三个天然缺陷：
- 上下文耗尽快：几千行、几百列的表格轻松撑爆context window
- Tokenization破坏数值精度：数字被奇怪地切分，数学运算精度受损
- 结构失明：2D表格被序列化为1D文本串后，模型丧失行列对应关系
TabFM通过将数据作为grid而非text string处理，解决了LLM的结构失明问题，同时借鉴了TabPFN（ Prior Labs）的零样本分类能力和TabICL的in-context学习框架。
我的分析： 表格数据是企业数据的默认形态——数据仓库、CRM、财务账本全是表格。这个领域的ML落地长期依赖"每个表建一个pipeline"的劳动密集型模式，TabFM相当于把GPT在文本上实现的"通用能力"迁移到了结构化数据。
这对企业AI的工程实践有直接影响：时间-to-production从数周降到一次API调用。 但需要注意TabFM的边界——它最适合中小规模表格的分类/回归任务，大规模实时预测场景可能仍需要专门模型。更值得关注的是这个方向代表的第一性原理思考：与其针对每个数据集精调，不如让模型学会理解"表格"这个数据结构本身。
原文链接：Google Research Blog - Introducing TabFM: A zero-shot foundation model for tabular data
三、代码生成不是企业AI的答案：SAP揭示落地失败的真正原因
SAP CPO Michael Ameling在VentureBeat发表了一篇深度客座文章，直指企业AI落地的核心矛盾：81%的企业有详细AI战略，但只有12–16%能真正执行。 原因几乎从来不是生成的代码质量不行。
生成代码 vs 运营化代码：两个完全不同的命题
"生成代码很快，但让代码在大型企业内可靠运行——与实时系统集成、受合规治理、可维护数年——需要的底层工作远超组织预期。" Ameling写道。
典型失败路径：团队做出了令人印象深刻的概念验证，然后发现：
- 缺少代码所依赖数据的访问权限
- 缺少代码假设的集成接口
- 缺少在真实环境运行的权限
"AI放大了组织现有的数据和流程成熟度，但不能替代它们。" 当AI从生成代码转向执行工作流时，延迟、成本和系统负载都会飙升——自主Agent在跨国事务系统上运行的性能要求，与开发者copilot完全不在一个量级。
两个身份模型解决治理问题
当AI从助手变成操作者，治理问题变得尖锐。两种可行的身份模型：
- 主体传播（Principal Propagation）：Agent代表用户行事，继承该用户的权限范围
- 系统触发Agent：Agent拥有自己的身份和基于角色的特权，更像自动化HR角色而非个人助理
两者都需要相同的底层基础设施：一个Agent Hub，让运营者看清哪些Agent存在、能访问哪些API、被授权做什么。
我的分析： 这篇文章的价值在于它不是在讲AI技术本身，而是在讲企业在引入AI时系统性地低估了非技术债务。集成层、数据治理、身份层、观测体系——这些不是"AI的补充"，而是"AI能跑起来的先决条件"。这和昨天报告中提到的"71%的Agent其实是Chatbot"形成了完整的逻辑链：Agent落地率低的根本原因不是模型能力不够，而是企业基础设施没准备好。
对技术决策者的启示：下一个12个月，企业AI的真正机会不在模型层，在集成层、治理层、观测层。这些才是卖铲子的地方。
原文链接：VentureBeat - The enterprise AI challenge nobody solves with code generation alone
小结： 今天的三条新闻从三个不同维度切入企业AI的现实：DeepSeek的价格调整揭示了成本结构的根本性挑战；TabFM代表了基础模型层向企业数据形态的延伸；SAP的分析则指向集成和治理这个被严重低估的落地障碍。三条合在一起，说明同一个事实——AI在企业的落地，远不只是"部署一个模型"那么简单。
#AI #大模型 #DeepSeek #Google #TabFM #企业AI