Sluke的夹生饭 - 闲言碎语
type: channel
link: https://luweiqing.com/category/gossip/
items: Token 工厂：AI 时代最热门的生态，创业者该站在哪个位置？
items: AI Infra：市场缺少 Token 运维服务（Token Runtime Platform）
items: AI Infra：解构 DSpark，Speculative Decoding 的三层逻辑
items: Workspace：从文件仓库到Token提炼车间
items: AI Infra：企业 Token 精炼厂是企业 AI 落地的下一阶段
items: AI Infra：Token 工厂的商业模式研究
items: Databricks Genie 战略解读：从数据平台到上下文平台的跃迁
items: AgentMesh：“Agent 虚拟组网 + 能力结算”的基础设施产品
items: AI 存储的真正机会在推理，但训练远未到天花板
items: 语言是思想的 KV Cache

Token 工厂：AI 时代最热门的生态，创业者该站在哪个位置？
type: item
date: 2026-07-27T22:26:27+08:00
description: 当一台数据中心不再被当作"存储电力和芯片的仓库"，而被当作一条"把电力冶炼成智能的产线"，整个 AI 产业的商业逻辑就被重写了一遍。这篇文章想回答一个问题：在这条产线周围，一个三五个人的团队，到底该站在哪个位置才能启动自己的飞轮。一、先说清楚：什么是"Token 工厂"过去我们理解数据中心，习惯用两个词：算力、存储。你交电费、买显卡、租机柜，本质是在囤积一堆能算数的铁疙瘩。但 2026 年前后，一种新的说法开始成为主流叙事——数据中心不再是存储中心，而是 Token 工厂。这个转变听起来只是换了个名字，实际上换了一整套记账方式。在固定的电力包络下，一座 AI 工厂把电力、芯片、网络、冷却、模型和调度系统，工业化地转化成一个个 token（词元），再以 token 为计量单位，把"智能"卖出去。换句话说，输入是电、卡、网、数据、模型；输出不再是"算力小时"，而是 token，以及 token 之上的 Agent、决策和业务结果。这套逻辑一旦成立，工厂老板关心的 KPI 就完全变了。他不再问"我有多少张卡"，而是问四个更锋利的问题：每秒能吐多少 token（吞吐）？每一度电能榨出多少 token（能效）？每个 token 的成本是多少（单价）？产线的利用率和可用性有多高？有芯片厂商甚至把这件事说得更直白：在 AI 工厂时代，"每瓦每秒产出的 token 数"几乎直接等价于收入。这句话值得每个想进入这个赛道的人抄在笔记本第一页。而且 token 本身开始"分级"，像工业品一样被商品化：面向 C 端轻量场景的消费级 token，往往免费或低价引流；嵌进金融风控、工业质检这类刚需场景的专业级 token，能卖出溢价；用于高复杂推理、科研突破的前沿级 token，则是最贵的那一档。定价维度也从单纯的"快不快"，扩展到智能密度、上下文长度、响应时延、合规与可靠性等级。一句话总结：Token 工厂的本质，是在电力约束下，把训练成果和推理基础设施抽象成一条 token 产线，再按分层定价把智能按需卖出去。理解了这个底座，我们才能谈生态，谈创业。二、把复杂生态讲简单：三侧市场任何一个成熟的产业，最终都会分化出清晰的分工。Token 工厂生态也一样。与其画一张让人眼花的产业链长图，不如用一个更好记的框架：三侧市场。第一侧，生产侧（Token Producers）。 目标只有一个——更便宜、更稳定、更高性能地生产 token。这里住着 GPU 云、训练工厂、推理引擎、调度系统。他们卷的是成本优势、性能优势和供给稳定性。这一侧最重、最烧钱，也最像"重工业"。第二侧，渠道侧（Token Distributors）。 这一侧最容易被忽略，却可能是整个生态里最有意思的位置。它负责把 token 能力包装、分发、销售、嵌入到具体场景里——开发者生态、Marketplace、账户体系、增长通道都在这里。它回答的是一个关键问题：谁把 token 能力，变成了可购买、可使用、可信任、可传播的产品？第三侧，消费侧（Token Consumers）。 token 在真实业务、真实应用、真实 Agent 场景里被消耗掉。企业的 Copilot、客服、风控、代码生成，都在这一侧烧 token。它追求的是真实场景、高频使用、高留存、高消耗。为什么一定要把"渠道侧"单独拎出来，而不是简单粗暴地分成"生产"和"消费"两端？因为在互联网的历史里，控制渠道的人，往往比控制生产的人活得更好。生产侧拼的是规模经济，渠道侧拼的是网络效应。前者越做越便宜，后者越做越离不开。App Store 不生产 App，却定义了整个移动应用的分发规则；这就是渠道的力量。对一个创业团队来说，这个框架的价值在于：它帮你排除掉两个几乎不可能的选项，聚焦到那个真正可行的位置。生产侧太重，不适合小团队起步；消费侧容易掉进"做项目"的陷阱，一个客户一个交付，长不成平台。唯一适合小团队做楔子（wedge）的，是渠道侧。三、两个引擎：Token 工厂的双飞轮如果说三侧市场解释的是"生态里有哪些参与者"，那么双飞轮解释的是"这个生态靠什么转起来"。Token 工厂真正的护城河，不来自单点的模型能力，而来自两个相互耦合、彼此强化的飞轮。飞轮一：生产飞轮，创造价格空间这个飞轮的唯一核心变量，是 Cost per Token（单位 token 成本）。它的转动逻辑是一条自我强化的链条：更好的推理引擎，带来更高的每瓦 token 产出；成本随之下降；成本下降释放出利润空间；利润空间允许你降价；降价吸引更多业务进来；业务规模扩大提高了利用率；利用率提升又进一步摊薄成本……于是成本继续下降。GPU、KV 缓存、推理调度、Prefill/Decode 分离——所有这些眼花缭乱的技术名词，其实都在为同一个目标服务：让每一个 token …

AI Infra：市场缺少 Token 运维服务（Token Runtime Platform）
type: item
date: 2026-06-30T10:53:24+08:00
description: Token Runtime Platform 将像云时代的 CMP+APM+FinOps 一样，成为 AI Native 企业的软件新基础设施，只是管理对象从计算资源变为 Token Runtime。核心部分是：可观测性和 FinOps一、市场三阶段：每阶段6-12个月企业关注“怎么用上 AI”（AI Gateway、Prompt、RAG），管理 Model。关注“怎么稳定运行”（成本、Agent 资源、Workflow ROI），管理对象从 Prompt → Context → Token → Workflow，Token Runtime Platform 需求出现。关注“怎么运营 AI”（数千 Agent、万亿 Token/天），管理 Enterprise AI Runtime，平台成为基础设施。二、为什么必然出现AI Runtime 与 Kubernetes 演化路径一致：LLM → Gateway → Context → Agent → Token Runtime → Governance，复杂度驱动。三、市场空间企业 AI 成本中，GPU 占比下降，模型 API、Context、Agent Runtime 和 Token 快速增长，最终 Business Tokens 指数增长，管理 Token 的需求同步上升。四、产品架构（四层）Runtime Access：统一入口（API/Model/Agent/MCP Gateway），采集全部运行时数据。Runtime Intelligence：数据平面，为 Prompt、Context、Embedding、Agent 等生成 Trace/Metrics/Events/Logs。Runtime Analytics：核心壁垒，解析 Token 用量、成本、延迟、业务 KPI，建立 Prompt→Context→Agent→Workflow→部门的映射。Runtime Governance：运营层，含 FinOps（预算/计费/ROI）、Policy（限流/审批/配额/模型选择）、Optimization（Prompt 压缩/KV 缓存/模型路由），形成 Observe→Analyze→Optimize→Govern 闭环。未来第五层 Autonomous Runtime：系统自动发现成本过高→压缩 Context、模型过大→切换、Cache Miss→预热、ROI 下降→修改 Workflow。五、竞争空白现有产品（AI Gateway、LLM Observability、APM、FinOps、Agent 平台）只覆盖局部，缺少整合 Runtime Intelligence + Business Intelligence + FinOps + Governance 的 Token Runtime Platform。六、投资价值市场：早期，需求显现。技术门槛：高（需深入 Runtime、模型、Agent、业务语义）。客户价值：高（直接降本增效）。替换成本：高（沉淀全链路运行数据和治理策略）。平台潜力：高（可扩展为 AI Control Plane）。窗口期：全球尚无明确领导者。6.1 两大护城河：运行时语义数据（Prompt 演化、Context 模式、Agent 协作等）治理策略资产（路由/预算/压缩/调度规则）6.2 长期判断企业软件从云计算（CPU/内存→CMP）→云原生（容器/服务→K8s）→AI Native（Token/Context/Agent/Workflow→Token Runtime Platform），未来管理核心从资源转向智能执行过程。该平台将从运维工具进化为 AI 运行控制面，统一连接模型、Agent、上下文、业务语义，构建可观测+成本治理+自动优化+运营管理。率先建立数据与策略双重壁垒者，有望成长为 AI Native 的基础设施。

AI Infra：解构 DSpark，Speculative Decoding 的三层逻辑
type: item
date: 2026-06-29T11:36:00+08:00
description: DSpark 底层采用"空间换时间"的设计，通过预测、并行执行、验证、回滚四个步骤，将串行 Token 生成转换为块级并行执行；在预测和验证阶段，利用 KV Cache 对 Transformer 的中间状态进行复用，实现增量计算，从而进一步提升执行速度。以下是对 DSpark（及整个 Speculative Decoding 架构）的理解：层次核心机制核心作用第一层空间换时间 (Memory → Compute)增加缓存与中间状态存储，减少重复计算第二层预测 + 并行 + 验证 + 回滚将串行生成转化为并行执行流第三层KV Cache 复用支撑预测和验证阶段的高速增量计算这三层共同作用，缺一不可。第一层：空间换时间 (Space for Time)这是整个系统设计的根本基石，究竟增加了哪些“空间”？Draft Model（草稿模型）Draft KV Cache（草稿缓存）Target KV Cache（目标缓存）Hidden State（隐藏状态）Confidence State（置信度状态）这些都是额外占用的 GPU Memory。而它们换来的是什么？更少的 Forward 调用更少的 Attention 计算更高的 Token/s 吞吐因此，从系统设计的宏观视角来看，其逻辑链条十分清晰：更多 Memory (空间) ↓ 更少 Compute (计算) ↓ 更低 Latency (延迟)这就是典型的以空间换时间策略。第二层：预测 + 并行 + 验证 + 回滚真正让推理性能发生数量级跃迁的是这一层。对比传统 Decoder 与 DSpark 的执行流差异：传统 Decoder（串行的囚徒）：Predict ──↓── Forward ──↓── Predict ──↓── Forward ...每一步都等待上一步的结果，无法并行。DSpark（并行的突围）：Predict 8 Tokens ↓ 一次 Parallel Verification ↓ Accept / Rollback（按需修正）在此过程中，Forward 的次数发生了本质变化：8 次 Serial ↓ 缩减为 2 次 BatchGPU 不再不断等待单个 Token 的产出，而是转为一次性处理整个 Token Block。这里的核心贡献在于：把串行依赖改造成块级（Block-level）的并行执行。第三层：KV Cache 的角色定位KV Cache 在整个流程中承担的是加速器的角色，而非并行机制本身。以 Draft 模型预测一个序列 ABCDEFGH 为例：如果没有 KV Cache：A —— 重新算 Prompt B —— 重新算 Prompt+A C —— 重新算 Prompt+A+B每一步都在空转过去的计算。如果有 KV Cache：Prompt ——→ KV ↓ A ——→ KV+ ↓ B ——→ KV+它解决的问题非常具体且关键：每生成一个 Token，不需要重新计算前面的 Attention。因此，它的加速范围是明确的：Draft Prediction（草稿预测）Target Verification（目标验证）但它并不直接决定：Prediction Accuracy（预测准确率）Parallelism Capability（并行能力）需要特别强调的是： 严格来说，KV Cache 加速的是“状态复用”，而不是“并行”本身。并行来自于 Speculative Decoding 的算法设计。即使完全没有 KV Cache，理论上仍然可以进行并行预测和验证，只是每一步都会重复计算 Attention，导致性能急剧下降。超越 LLM：一种预测驱动的并行范式结合近期对 Token Factory 的探索，我们可以将上述机制抽象为一种更通用的基础设施优化范式：State (状态) ↓ Prediction (预测) ↓ Parallel Execution (并行执行) ↓ Verification (验证) ↓ Commit / Rollback (提交或回滚)在这个通用框架下：State： 对应 KV Cache、Workspace、Business Memory、Ontology 等可复用的上下文状态。Prediction： 用于提前推测未来的执行路径或结果。Parallel Execution： 将原本线性的流程转换为块级并行处理。Verification： 保证最终结果与原始基准完全一致。Rollback： 处理预测失败的局部修正机制。这套“预测驱动的并行执行”范式已经超出了 LLM 推理本身的范畴。CPU 的分支预测、数据库的事务执行、现代 AI 推理优化，甚至未来 Agent 的工作流编排，都可以归纳到这一套逻辑中，将业务流程中的“预测、验证、…

Workspace：从文件仓库到Token提炼车间
type: item
date: 2026-06-28T18:02:00+08:00
description: Workspace里面存放着文档、代码、SQL、配置文件、日志和Git仓库。它的作用，是将这些文件组织起来，方便团队协作。对于Agent而言，Workspace不再只是一个文件系统，而是一个持续产生、提炼和沉积“上下文”（Context）的动态空间。每一次修改文档、执行SQL、调用工具、编写Prompt，乃至与Agent的每一轮对话，都会留下全新的语义信息。Agent真正需要理解的，不再是某一个孤立的文件，而是整个Workspace当前所表达的整体状态。因此，Workspace正在经历一场根本性的蜕变：从“文件仓库”演进为“Token提炼车间”。一、文件只是原材料一个成熟的Workspace，往往容纳着多种类型的数据：核心文档：PRD、设计文档、Roadmap数据结构：SQL、Schema、数据库定义行为规范：agent.md、CLAUDE.md思考方式：Prompt、Agent Conversation演进轨迹：Git Commit、Issue、TODO执行记录：Tool Call、CLI操作这些要素，过去是孤立的岛屿，而今在Agent的视野里，已接连成一片大陆。一份PRD向Agent阐明产品目标，一组SQL映射出业务模型，agent.md定义了工作规范，Prompt体现着思考方式，Git Commit记录了系统的演化过程，Agent Conversation则留存了每一项决策的原始依据。真正有价值的信息，不存在于任何一个独立的文件中，而存在于这些元素之间的关系之中。这些隐形的“关系”，正是Token的原始矿脉。Workspace真正生产的是Token很多人认为，大模型时代生产的是推理Token。但事实上，在企业内部，还存在着另一种价值更高的Token——它们并非模型凭空生成的文本，而是从真实的业务活动中提炼出来的语义单元。原始数据提炼后的Token产品文档产品目标、业务能力SQL业务实体、业务关系、核心指标Prompt思考模式、执行策略agent.md项目规范、团队约束Git Commit系统演化方向Agent对话决策过程Tool调用执行行为这些Token不描述文件本身，它们描述的是Workspace在某一时刻的 “运行状态”。例如，一条SQL：SELECT * FROM Orders WHERE status='Pending'数据库看到的是查询语句，而Agent更关心的是：企业高度关注“待处理订单”。“订单”是核心业务实体。当前业务架构围绕订单生命周期展开。这条SQL，就这样被“提炼”为了一个业务Token (Business Token)。同样，一个Prompt：先分析，再规划，最后执行。它不仅仅是提示词，更表达了一种认知模式：规划先行，执行后置，并且要具备反思能力。 这个Prompt，因此被提炼为一个认知Token (Cognitive Token)。Agent并非直接“阅读”文件，而是在“翻译”和“萃取”它们的语义精髓——也就是Token。Agent工作的实质，并非逐字阅读文件，而是在持续不断地“生产”Token。二、Workspace：持续运行的Token工厂如果将Workspace视为一条流水线，其工作流程会变得清晰可见：原料投入：文档、SQL、Prompt、对话、Git记录、日志等。语义解析：理解每种数据的结构和含义。Token萃取：从语义中提炼出关键信息单元。图谱构建：将Token连接形成关系网络。状态估算：基于关系网络，推断Workspace的当前状态。未来预测：根据演化轨迹，预测下一步可能的最佳行动。Workspace的每一次变动，都会催生新的Token。这些Token不断累积，最终形成一个动态的、自更新的语义图谱 (Semantic Graph)。Agent真正“理解”的是这张图谱，而非文件本身。正因如此，一个具备Token生产能力的Workspace，可以回答许多传统IDE无法企及的问题：洞悉这个项目真正的核心目标是什么。推演当前项目的实际进展阶段。理解团队采用特定架构的决策逻辑。识别哪些业务实体最为关键。预测哪些模块在未来最可能变更。建议下一步最应该优先完成什么。这些问题的答案，不存在于某个Markdown文件里，而存在于Token之间形成的那张复杂而精确的关系网络中。三、从Business Token到Cognitive Token这种能力不仅适用于企业。对于企业，Workspace提炼出的是业务Token (Business Token)。对于个人，Workspace提炼出的是认知Token (Cognitive Token)。一个人的Workspace同样包含着丰富的数据：笔记、浏览记录Prompt、Agent对话记录日历、Git仓库、邮件、文档经过语义提炼，系统可以恢复出他的：当前目标、…

AI Infra：企业 Token 精炼厂是企业 AI 落地的下一阶段
type: item
date: 2026-06-27T16:55:42+08:00
description: 从模型军备竞赛到业务语义战争过去两年，企业AI的讨论始终围绕三个关键词展开：更大的模型、更便宜的推理、更长的Context。这三个方向本质上都是在优化「大模型处理通用信息的能力」，而当GPU算力不再是瓶颈、开源模型效果追平头部闭源模型、RAG与Agent框架成为通用组件时，企业AI的「通用基建红利」已经见顶。进入2026年新的产业周期，核心关注点正在发生明确转移。Databricks发布Genie One、Genie Ontology、Genie Agents，将企业AI的核心从SQL Copilot升级到Business Context（业务上下文）。官方将Genie Ontology定义为「持续演化的业务知识图谱与上下文层」，用于为Agent提供统一、可信的业务语义。SelectDB在最新（20260626）产品战略中，将AI能力深入数据库内核，强调语义理解、企业知识以及Agent与数据系统的一体化，不再停留在传统数据库查询能力，产品方向明确从「数据库」转向「AI数据基础设施」。这两家公司分别代表了两条技术路线：Databricks从湖仓平台向上延伸做语义封装，SelectDB从数据库内核向上做语义内嵌，路径不同，却共同指向同一个产业共识：企业 AI 的竞争中心，已经开始从 Model Layer 转向 Business Context Layer。这正是 Business Token Factory（企业Token精炼厂） 对应的下一代产业机会。一、企业AI缺的不是模型，是Business Token当前企业已经配齐了所有AI落地的基础能力，且均已形成标准化的开源或商用方案，不存在不可逾越的技术壁垒：能力是否成熟GPU算力是基座模型是推理框架是向量数据库是数据仓库是MCP（模型上下文协议）是理论上，一个Agent已经可以打通企业所有业务系统。但真正的核心问题是：Agent 能连接数据，并不代表理解业务。举个最常见的场景：你问Agent「本月华东区的销售额完成率是多少」，它能从ERP里拉出所有订单数据，但它不知道：华东区要不要算刚并入的安徽区域？销售额按下单时间还是回款时间计算？经销商的退换货要不要倒扣？这些规则散在各个部门的SOP、财务的私人Excel、业务负责人的经验里，从来没有被结构化、统一化、持续更新过。原始数据库里只有Customer（客户）、Order（订单）、Inventory（库存）这类基础字段，但Agent真正需要回答的是：哪些客户存在流失风险？哪些订单需要优先审批？哪些库存正在影响利润？当前销售目标有没有缺口？这些信息既不存在于原始数据库中，也无法靠单次查询得到，它需要基于统一的业务规则持续计算、动态更新，最终形成全公司对齐的标准语义。我们把这种经过业务语义校准、可直接被Agent理解和推理、携带完整业务上下文的最小信息单元，叫做Business Token。它既不是数据库的原始字段，也不是大模型的分词Token，更不是静态的元数据，而是企业业务状态的动态抽象。因此，企业AI落地的真正缺口从来不是数据，也不是模型，而是Business Token。二、产业已经验证：Context Layer正在成为新的平台层Databricks发布最核心的产品，不是面向终端的Genie One，而是位于整个技术栈中间的Genie Ontology，它的出现，意味着Databricks的产品结构已经发生了本质变化：Genie One（终端应用） ↓ Genie Agents（智能体层） ↓ Genie Ontology（业务语义层） ↓ Unity Catalog（数据目录） ↓ Lakehouse（湖仓平台）这里最大的变化是：Genie Ontology不再只是传统意义上的元数据，它开始承担业务实体、KPI定义、业务规则、业务关系、权限管控等核心职能，官方将其描述为「持续学习、持续更新的企业Context Layer」，所有Agent的回答和执行都必须建立在这层业务语义之上。意味着Agent不再直接连接数据库，而是连接统一的Business Context。SelectDB的产品演进则验证了另一个方向：过去数据库的核心能力是SQL查询，现在大量语义理解、AI算子、Agent接口、业务逻辑正在向数据库内核迁移，数据库厂商已经明确意识到：未来企业的核心竞争点从来不是SQL引擎的性能，而是Business Semantic Engine（业务语义引擎）。一条从应用层往下封装，一条从基础设施层往上内嵌，两条路线最终的目标完全一致：业务语义内嵌。三、Business Token Factory：企业业务上下文的生产线如果基于这个趋势重新梳理整个企业Agent技术栈，会得到一个非常清晰的分层结构：Enterprise Agent（…

AI Infra：Token 工厂的商业模式研究
type: item
date: 2026-06-26T17:30:09+08:00
description: 别再叫它 API 聚合了，它正在控制 AI 世界的“石油管道”上周和一个做投资的朋友聊天，他抱怨说现在看 AI 项目看到头秃。基础模型那波已经卷成麻花，应用层又虚头巴脑，找不到护城河。我给他画了张图，他一下就懂了。我说，你别盯着挖金矿的（模型厂商）和卖水的（云厂商），你应该去看那条“输油管道”。而这条管道里流淌的，不是石油，是 Token。管道的控制者，我把它叫做 Token Factory（Token 工厂）。OpenRouter、Portkey、LiteLLM Cloud 这些公司，都在这条赛道上。它们生产的不是模型，而是一个标准化的产品：推理 Token。这玩意儿才是 AI 商业化的真正咽喉。为了讲清楚这个逻辑，我把 Token Factory 的商业模式拆成了五层。这五层，从低到高，价值完全不同。一、最底层：Token 转售，听着像二道贩子，其实是“AI界的Stripe”最早期，这门生意听起来一点都不性感，甚至有点 low。说白了，就是个二道贩子。比如 OpenRouter，它自己一个模型都不训。它先从 OpenAI、Anthropic 那儿批量“批发”模型推理能力，再零售卖给我们这些开发者。用户付 $100 │ ▼ OpenRouter（过一手） │ │ 付 $95 ▼ OpenAI / Anthropic收入哪来？就挣那 5% 左右的差价和充值手续费。乍一看，这护城河也太浅了，不就是个倒买倒卖的生意吗？但有意思的地方在于它的定位。它刻意保持 Token 的官方原价，然后靠服务费赚钱。这招非常聪明，它不是在跟模型厂商抢利差，而是在做支付和渠道的基础设施。所以，准确的定义不是“AI 代理商”，而是 AI 时代的 Stripe。它解决的是一个极其无聊但极其重要的问题：让开发者用一行代码，就能接入全世界所有的模型，不用管后面那一堆账单、密钥和对账。这一层，赚的是辛苦钱，但也是所有故事的起点。二、第二层：路由，从“管道”到“大脑”，真正值钱的来了如果只做一层，Token Factory 永远只是个微利的管道工。真正让它开始值钱的，是第二层：Routing（路由）。这玩意儿我天天在用，感受太深了。比如我随手发一个请求：“帮我用 Python 写个二分查找。”一个好的 Router，它脑子里会瞬间闪过一堆决策：任务分析：这是一个标准代码任务。模型匹配：Claude Sonnet 干这活最利索，性价比最高。成本计算：不用上 GPT-4，浪费钱。执行：直接把任务甩给 Sonnet。如果我再问：“帮我研究一下最近 AI 制药的新突破。”Router 又会立刻判断：这是深度研究任务，得调用具备联网或深度推理能力的模型，比如有 Deep Research 功能的 GPT 或 Gemini。看到了吗？从此以后，作为用户，我们根本不需要关心模型叫什么。我们只关心三个词：最便宜，最快，最准。但对企业来说，这背后还有更深的逻辑：成本调度、延迟调度、SLA 调度、自动灾备、多云切换……这些能力让 Router 瞬间从一个管道工，变成了一个指挥交通的操作系统（Inference OS）。护城河一下子就冒出来了——算法和调度数据，是模型厂商自己都无法轻易复制的。三、第三层：算力市场，当“AI司机”的 Uber再往下走一层，事情就更有意思了。现在越来越多的独立推理服务商（Inference Provider）爆发式增长，比如 Groq、Together、Fireworks。他们手里有海量的 GPU，专门优化推理速度，比通用云快得多、也便宜得多。Token Factory 做了什么？它把这些分散的“算力司机”全部接入了自己的网络。于是，商业模型变成了一个双边市场：供给侧：成千上万的 GPU 集群，随时待命。需求侧：数百万开发者，嗷嗷待哺地发出推理请求。平台：Token Factory 居中调度，撮合交易。这像极了 Uber。Uber 不拥有任何一辆车，但它控制了出行服务的调度和定价。Token Factory 也一样，它不拥有任何一块 GPU，但它控制着推理能力的生产和分发。这也是为什么现在很多投资人不再提“API 聚合”，而开始用 AI Compute Marketplace（AI 算力市场） 这个概念。这个叙事，比卖接口要性感十倍。四、第四层：Token 财务治理，比“省钱”更重要的是“知道钱花哪儿了”好了，当一个公司开始大规模使用 AI 时，一个恐怖的场景出现了：Token 花费完全失控。财务总监会发现，他不知道那 10 万美金的账单是怎么来的。是研发部在疯狂调优？是市场部在批量生成文案？还是某个失控的 Agent 陷入了死循环，一夜之间花掉 800 万 Token？Token Factory 在这里找到了第四层价值：Token FinOps（Tok…

Databricks Genie 战略解读：从数据平台到上下文平台的跃迁
type: item
date: 2026-06-24T18:58:22+08:00
description: 核心观点：企业 AI 的竞争焦点已从数据基础设施（Data Infrastructure）转向上下文基础设施（Context Infrastructure）。一、战略背景：为什么是现在？Databricks 此次发布了Genie系列产品，Genie One, Genie Agents, and Genie Ontology，是一次架构升级。战略意图清晰：将 Databricks 从传统的 Lakehouse（湖仓）升级为企业 Agent 的运行平台。架构演进路径：Data Platform（数据平台） ↓ Context Platform（上下文平台） ↓ Agent Platform（智能体平台）核心驱动因素：外部驱动： 企业 AI 应用落地受阻，模型能力虽强但缺乏业务语境。内部驱动： Databricks 需构建新的增长曲线，从存储计算转向智能决策。二、环境分析：企业 AI 的真实瓶颈Databricks CEO Ali Ghodsi 指出："Enterprise AI has a context problem."（企业 AI 存在上下文问题）2.1 核心痛点企业 AI 失败的原因并非模型推理能力不足，而是缺乏企业语境（Business Context）。场景示例： 销售 Agent 回答“哪些客户值得重点跟进？”所需上下文： CRM 数据、历史订单、组织结构、Slack 讨论、Jira 项目、产品文档、KPI 定义等。现状： 信息散落在 50+ 不同系统中，传统 RAG（检索增强生成）难以解决。2.2 差距分析传统方案： Document + Vector Search + LLM。缺失环节： 缺乏统一的业务语义层，导致 Agent 无法理解数据背后的业务含义。三、核心战略：从 Data 到 Context 的跃迁Databricks 新战略的核心在于抽象出了Context Layer（上下文层）。这是此次架构升级最大的战略价值。新三层架构：Genie One（用户入口） ↑ Genie Agents（执行单元） ↑ Genie Ontology（核心语境） ↑ Lakehouse（数据底座）战略定位变化：传统 Lakehouse： 管理 Data（数据）。新 Genie 平台： 管理 Meaning（含义/语境）。四、产品战术：Genie 三层架构解析4.1 核心层：Genie Ontology（上下文本体）这是投资人应关注的核心资产。定义： Self-improving Context Layer（自进化上下文层）。功能： 自动抽取业务指标、组织关系、业务规则、数据血缘、实体关系。构成： Knowledge Graph（知识图谱）+ Semantic Layer（语义层）+ Metadata Layer（元数据层）。价值： 形成统一的企业语义层，让 Agent 理解业务逻辑。4.2 执行层：Genie Agents（智能体）Databricks 对 Agent 的重新定义：Agent = Prompt + Ontology + Workflow机制： 任何 Genie 对话均可保存为 Agent。继承能力： Memory（记忆）、Instruction（指令）、Context（语境）、Workflow（工作流）、Tool（工具）。场景： 每周销售分析、库存监控、客户流失预警等重复性问题自动化。4.3 入口层：Genie One（用户界面）类似“企业版 ChatGPT"，但具备更强的业务执行力。能力维度ChatGPTGenie One查询企业数据部分强调用业务工具部分强执行业务动作弱强示例： 销售经理输入“分析过去 90 天高潜客户并安排会议”，Genie One 可一次性完成读取、分析、生成文档、调用工具及执行任务。五、支持活动：全域知识整合为实现 Context Layer，Databricks 构建了强大的生态整合能力。数据源整合： 支持 Databricks、Google Drive、Slack、Jira、Confluence、SharePoint、CRM、ERP 等 50+ 系统。价值链优化： 将散落在各系统的非结构化数据转化为结构化业务语境。核心能力： 持续学习企业知识，确保上下文随业务变化而更新。六、行业演进：数据基础设施的四代变迁从行业演进角度看，Databricks 正在重复数据库三十年的发展路径，试图成为数据库 + 语义层+Agent 平台的统一体。代际核心产品管理对象代表企业第一代数据库数据 (Data)Oracle, MySQL第二代数仓分析 (Analytics)Snowflake, Databricks第三代语义层业务知识 (Context)dbt, Genie Ontology第四代Ag…

AgentMesh：“Agent 虚拟组网 + 能力结算”的基础设施产品
type: item
date: 2026-06-23T21:19:00+08:00
description: 一、项目背景与执行摘要1.1 项目背景驱动因素：外部趋势： AI Agent 爆发式增长，单一 Agent 能力有限，多 Agent 协作成为必然；现有网络架构无法支撑 Agent 间的自动发现与安全互联；缺乏标准化的能力交易与结算机制。内部机遇： 构建 Agent 时代的网络层与交易层基础设施，抢占“身份 - 地址 - 权限 - 价格 - 账本”的关键入口。1.2 执行摘要产品定义： AgentMesh 是为多个 Agent 提供虚拟内网自动发现、互联协作，并按协议完成计费、授权和结算的基础设施平台。核心价值：虚拟组网： 隐藏真实 IP，实现私有逻辑网络内的自动发现与安全访问。能力支付： 将 Agent 能力商品化，支持可定价、可授权、自动结算。战略意图： 成为 Agent 时代的网络层和交易层基础设施，构建“网络效应 + 结算闭环”的核心壁垒。二、市场环境与营销现状2.1 市场机会与痛点痛点维度现状问题AgentMesh 机会点网络连接Agent 暴露公网 IP，风险高，发现难虚拟组网协议：逻辑内网地址，自动发现，安全互联能力交易调用即 RPC，无定价，无结算能力支付协议：能力商品化，按次/按量/按结果付费协作信任组织间协作互不信任，数据不敢共享联邦式网络：多组织协作，互不暴露真实网络2.2 典型应用场景企业内协作： 部门间 Agent 像在同一局域网，安全高效。外包能力调用： 临时购买外部 Agent 能力（如 OCR、推理）。AI 工具市场： 能力像 API 一样被交易，形成生态。私有推理集群： 调度、计费、审计一体化。三、营销目标与营销战略3.1 战略定位定位陈述： Agent 时代的网络层和交易层基础设施。关键入口要素：要素作用身份 (Identity)谁在网络里 (Agent DID)地址 (Address)它能被谁找到 (Overlay Address)权限 (Permission)它能调用什么 (Capability Token)价格 (Price)调用要付多少钱 (Micropayment)账本 (Ledger)发生过什么交易 (Audit Log)3.2 商业模式三层收入结构：基础设施订阅： 月费/年费（面向企业和开发者）。交易抽佣： 每笔能力交易抽成（市场越大，收入越高）。高级网络服务： 专线、中继、审计、合规（面向高要求客户）。增值包策略： 企业私网包、能力市场包、结算包。3.3 竞争壁垒壁垒类型核心内容护城河效应网络协议组网、路由、穿透、密钥轮换技术门槛，难以复制支付协议微支付、预授权、结算、争议处理信任机制，迁移成本高生态网络能力供给方越多，网络效应越强最强壁垒：网络效应 + 结算闭环四、营销组合与营销策略4.1 产品策略 (Product)核心架构：层级模块职责接入层SDK / Agent Runtime一行代码接入网络层Overlay Mesh发现、路由、转发、加密支付层Micropayment Protocol预授权、计量、结算市场层Capability Registry能力上架、搜索、定价审计层Receipt Ledger调用凭证、支付凭证、争议记录关键协议设计：AMP (Agent Mesh Protocol)： 虚拟组网协议。定义 Join, Discover, Dial, Heartbeat 消息。特征：临时身份、地址抽象、端到端加密。CPP (Capability Payment Protocol)： 能力支付协议。定义 Quote, Reserve, Authorize, Prove, Settle 动作。支持按次、按量、按结果付费。4.2 价格策略 (Price)基础服务： 免费 tier 吸引开发者，付费 tier 解锁高级功能。交易抽佣： 初期低抽佣鼓励流通，后期随生态成熟调整。差异化定价： 针对企业私网、高合规需求提供溢价服务。4.3 渠道与推广 (Place-Promotion)开发者社区： 通过 SDK 易用性（30 分钟接入）在 GitHub、技术社区传播。生态合作： 与大模型厂商、Agent 平台合作预装。标杆案例： 打造企业内多 Agent 协作、外包能力调用等标杆场景。五、支持活动与业务流程5.1 关键业务流程接入流程： Agent 启动 -> 注册临时身份 -> 获取虚拟地址 -> 加入 Mesh。交易流程： 发现能力 -> 获取报价 -> 锁定预算 -> 授权调用 -> 提交证明 -> 自动结算。审计流程： 全程记录调用凭证与支付凭证，支持争议处理。5.2 核心能力建设安全技术： mTLS 短期证书、端到端加密、中继不可见明文。结算系统： 高并发微支付处理能力、争议仲裁机制。开发者体验： 极简 SDK、完善文档、沙箱环境。六、实施计划与行动方案6.1 最小…

AI 存储的真正机会在推理，但训练远未到天花板
type: item
date: 2026-06-22T17:20:00+08:00
description: 在投资视角下，仅关注存储总容量的增长远远不够。决定企业价值的核心，是存储被用于何处。下表清晰对比了各存储层级在容量与市场价值上的错配。层级存储容量占比市场价值占比增长驱动力训练存储高中模型训练与后训练推理存储中高Token 规模持续膨胀归档存储很高低全量数据长期保留未来 AI 存储市场最大的结构性变化，并非容量增加，而是价值重心从训练存储向推理存储迁移。然而，训练存储自身仍有可观的增长空间——后训练市场才刚刚拉开帷幕。一、AI 存储的需求拆解AI 时代的存储需求大致可拆为三个部分：训练数据推理状态（如 KV Cache、会话上下文等）归档数据对应的总量公式为：AI 存储总量 = 训练存储 + 推理存储 + 归档存储二、全球市场总规模根据预测，2030 年全球总存储容量约 35 ZB。其中，AI 相关存储的占比将从目前的 10% 以上提升至 30%～40%，对应市场规模约 10～14 ZB。三、训练存储：后训练打开新空间训练存储服务于模型训练的全流程，包括预训练、后训练、SFT、RLHF 以及合成数据训练等。典型厂商有 DDN、WEKA、VAST Data、Hammerspace 等。过往存在一种判断：大模型数量有限，一旦训练集群建成，存储需求便会回落。这一看法忽略了一个关键变化——后训练正在成为主战场。预训练产出的是基础模型，数量确实受限。而后训练则让模型适配具体场景，企业、行业乃至单个任务都需要独立进行：银行为风控模型，医院为病历分析模型等。此类后训练任务成百上千，每个任务都需要海量高质量标注数据、对比数据和合成数据。后训练的特性进一步放大了存储需求：数据高频更新，业务规则变化意味着需要重新处理数据，而非一次定型。数据来源分散，涉及企业自有数据、第三方数据以及合成数据，均需长期保存。实验迭代频繁，同一模型会反复调参比对，大量中间状态和 checkpoint 必须保留。因此，训练存储的利用率并不会如过去预想那样快速下滑。虽然预训练的超大模型数量趋于收敛，但后训练的长尾需求将持续拉动存储增长。至 2030 年，训练存储预计占 AI 存储总量的 20%～25%，约为 2～3 ZB。由于其性能要求高，单价达普通存储的 5～10 倍，对应市场规模约 400～600 亿美元。后训练的进一步扩张还可能推高这一数字。四、推理存储：最大的价值机会推理时代催生了全新的数据类别。过去是“数据进，模型出”，现在则是“状态进，Token 出”。新增的关键数据包括：KV Cache（缓存历史对话的中间计算结果，避免重复推理）会话状态（用户与 AI 交互的完整上下文）Agent 记忆（ AI 助手对用户习惯与偏好的长期记录）业务上下文（如企业的客户数据和流程信息）工作流状态（多步任务的当前进度）这些数据的增长逻辑与训练存储截然不同。训练规模取决于模型数量，而推理规模取决于用户数、Agent 数量以及调用频率。以 ChatGPT 为例，2023 年用户约 1 亿，到 2026 年可能超过 10 亿；Token 消耗的增速远快于模型迭代速度。一名员工现在仅用 1 个 ChatGPT，未来可能同时调用 10 到 100 个 Agent。因此，推理存储的增速将远超训练存储。至 2030 年，推理存储占 AI 存储总量的 40%～50%，约为 4～7 ZB。推理存储对时延极度敏感（亚毫秒级访问），并且要求 KV 共享、GPU 直连和分层缓存，价值密度极高。估算市场规模约 800～1,200 亿美元，将成为最大的 AI 存储细分市场。五、归档存储：量大但价值偏低归档存储用于长期保留原始训练数据集、企业业务数据、日志、视频及 IoT 数据等。其容量占比最大，但单位价值最低，价格趋近于普通云存储。2030 年，归档存储预计占 AI 存储总量的 30%～40%，约 3～5 ZB，对应市场规模 150～250 亿美元。六、中国市场的分化按全球 15%～20% 的比例估算，2030 年中国 AI 存储规模约 1.5～2.5 ZB。细分结构如下：训练存储：0.3～0.5 ZB，市场价值 60～100 亿美元推理存储：0.7～1.2 ZB，市场价值 120～220 亿美元归档存储：0.5～0.8 ZB，市场价值 30～50 亿美元七、投资落脚点2030 年 AI 存储的价值分布将进一步分化：赛道容量占比市场价值占比投资价值训练存储20%～25%30%～35%中高推理存储40%～50%50%～60%很高归档存储30%～40%10%～15%低对应到代表性公司：DDN 深耕训练存储，WEKA 同时覆盖训练与推理，VAST Data 主攻推理存储，MinIO 则立足于归档层。未来十年最值得关注的无疑是推理存储市场，但训练存储同样不容忽视。后训练带来的数据高频迭代、多版本管理以及跨企业数据…

语言是思想的 KV Cache
type: item
date: 2026-06-12T21:41:00+08:00
description: 语言是思想的 KV Cache，使用人数和时间更长的语言，会有一些优势语言像 KV Cache 的地方维度语言KV Cache作用保存和传递上下文保存和复用推理上下文价值让思考可以连续累积让模型推理可以低成本延续特征用得越久，表达越稳定命中越高，推理越高效结果沉淀出更强的协作效率沉淀出更强的计算效率语言使用人数越多、使用时间越长，通常会形成三类优势：1. 语义约定更稳定长期使用会把大量含糊表达，压缩成更固定的含义。同一个词、一个缩写、一句行话，大家默认理解趋同，沟通成本下降。例如：场景效果商业条款、指标、分工更标准化技术概念、接口、术语更统一组织协作和交接更顺滑2. 语料和表达资产更厚使用人数越多，语言里的高质量文本、案例、模板、知识库就越多。这会带来一个累积效应：后来的使用者可以直接站在前人的表达之上，而不必从零开始。这和 KV Cache 的逻辑很像。前面已经生成和验证过的上下文，后面可以直接复用。这也是很多人认为中文成语是“压缩包”的原因。3. 网络效应更强语言不仅是交流工具，也是分发协议。谁掌握了更大的语言网络，谁就更容易获得内容、社区、教育、出版、软件生态的外溢优势。这会进一步带来：优势具体表现信息密度高更容易形成专业分工协作半径大更容易跨地域连接迁移成本高重新学习另一套语言体系成本更大4. 补充说明语言的优势不只是“人数多”和“时间长”，更关键是：条件说明统一程度高否则语义碎片化，复用困难书写体系成熟才能沉淀可检索、可传递的知识教育和制度支持才能把语言优势转成长期资产跨行业渗透深才能形成真正的上下文积累语言使用越广、沉淀越久，就越像一个高命中率的长期上下文缓存。它会同时提升沟通效率、知识复用效率和组织协同效率。