Kimi背后的AI基建如何支撑海量用户并发访问

想象一下，你对着Kimi K2.6的Agent模式随口说了一句：“帮我搭个读书笔记网站，带登录和搜索，能导出的那种。”

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

几分钟后，你收到的不是一个需要自己部署的代码包，也不是一个仅供演示的静态页面，而是一个真实、可访问的URL链接。

前端、后端、独立的数据库、完整的用户账号体系……一应俱全。你可以直接把链接分享给朋友，他注册后存入的任何数据，都会稳稳地保存在你这套系统的独立数据库里。

与v0或Lovable这类AI建站工具相比，Kimi实际上接管了从开发、托管到数据库运维的全生命周期。

然而，这种丝滑体验的背后，真正的工程挑战才刚刚浮出水面：

如果有一百万个用户都随口提出了类似请求，后台就需要瞬间承载一百万个独立的生产级数据库——每一个都可能被真实用户长期读写。

在传统数据库的产品形态下，这种规模的工作负载几乎是无法承接的。

那么，Kimi究竟是如何在成本、规模与性能的“不可能三角”中，实现了这种近乎奢侈的“人手一个数据库”配置？

为什么“传统答案”都不成立

AI建站这类场景，对模型厂商而言，其经济模型有一个基本结构：

主要的算力消耗集中在Agent生成代码的短暂瞬间，服务上线后则按月收取订阅费。

一旦应用运行起来，托管所需的基础设施成本（如Web服务器、带宽、数据库）相对于高昂的模型算力成本要低得多，厂商的利润空间主要依赖于此。

但这套商业模式成立有一个铁的前提：基础设施成本必须能被有效压低。

将Kimi K2.6面临的工程约束拆解开，有三条要求尤为突出。

第一条：数据库实例的粒度，是“每终端用户一个”

十万用户，就是十万个数据库。一百万用户，就是一百万个。

更棘手的是，其中绝大多数实例将长期处于极低活跃状态——用户建完站后，可能很久都不会再打开。

按照传统云数据库的定价模型，一个最小规格的实例月费大约在十几到二十美元。乘以百万级数量，账单将是天文数字。问题不在于数据库本身昂贵，而在于这种商业模型根本无法规模化。

第二条：数据库的结构（Schema）由LLM现场生成

（注：Schema指数据库模式，即定义数据如何存储的逻辑结构。）

在过去二十年里，Schema设计是一个需要数据库管理员（DBA）参与、需要评审、需要版本管理的慢决策流程。

但在Kimi K2.6这里，Schema是LLM对用户一句自然语言的即时翻译。比如“读书笔记需要哪些字段？”“评分存整数还是文本？”，瞬间就能决定。

更复杂的情况在于，用户会持续对话。

下一次用户说“帮我加个收藏功能”，Agent又得去修改一次表结构。

而此时数据库里已经存有真实的用户数据。Schema一旦修改出错，轻则导致查询失败、用户报错，重则引发数据写入紊乱，甚至造成不可恢复的损失。

第三条：负载分布呈“零-峰两极”分化

大多数站点建成就闲置。但只要有一个站点被小红书推荐，或在X平台被热转，其并发访问量瞬间就能飙升百倍。

因此，数据库必须同时扛住“绝大多数近乎零、少数瞬间爆量”的极端负载曲线，并且必须确保爆量的租户不会拖垮其他所有租户。

这三条约束合在一起，在传统数据库的产品形态下，几乎是无解的：

• 路径A：单实例+Schema隔离
  几百个租户或许可行，但几万个租户就足以打爆查询规划器。一旦出现爆款站点，还会连累所有“邻居”。Kimi工程团队实际测试过这条路：用一个大型PostgreSQL实例做多Schema隔离，单实例在万级规模时就开始不堪重负，更不用说复杂的流量控制、故障隔离、数据安全等更深层的问题。
• 路径B：一个用户分配一个RDS实例
  无论是AWS RDS，还是Neon、Supabase这类Serverless PostgreSQL服务，本质都是为每个用户分配一个真实的PostgreSQL实例。到了百万级租户规模，仅实例存在的基础月费就已无法承受。

Kimi的选择，以及为什么是这个选择

经过评估，Kimi后端最终选择了TiDB Cloud。

其工程团队做出了三个关键决策，每一个都精准对应并解决了上述的一条核心约束。

决策一：极致低成本——利用Serverless Cluster的多租户能力，承接“每个用户一个独立数据库”

既然问题的症结在于“每用户一个真实实例”的成本，TiDB Cloud走了另一条路：引入一层“虚拟数据库界面”。

对于长尾的、绝大多数时间没有请求的租户，平台并不真实分配完整的数据库实例资源；只在Agent或终端用户实际发起请求的瞬间，由一个常驻的数据库会话网关（DB Session Gateway）维持连接，其他所有资源均按需弹性供给。

落到Kimi K2.6的场景里，这意味着“为百万用户提供建站后端”在单位经济模型上终于跑通了。

为了更直观地呈现这种技术代差，我们将其与以Supabase为代表的典型Serverless数据库架构进行了对比：

下图展示了TiDB Cloud的多租户架构：

决策二：统一技术栈——Vector + SQL + JSON，将Agent的“写代码”难度压到最低

在Kimi K2.6的建站Agent中，LLM生成的典型查询经常需要一条SQL同时完成多件事——按用户过滤、按标签筛选（JSON字段）、按向量相似度排序、再按时间倒序。

在技术栈分离的架构里，同样的需求需要LLM协调三个不同的客户端、自行管理事务、手动合并结果……这在LLM写代码的场景下，错误率会呈指数级上升。

而在TiDB里，这只是一条SQL语句。

统一技术栈在这里的价值，并非仅仅是“性能更好”，更是让Agent有机会把代码写对的前提条件。

决策三：最小化摩擦——Warm Pool + Scale-to-Zero，让Agent在1秒内拿到完全就绪的数据库实例

Agent生成应用时，数据库的创建绝不能是一个需要等待几分钟的资源供给（Provisioning）流程。

它应该像运行时资源一样：需要时立即可用，用完后成本足够低。

TiDB Cloud通过预热池（Warm Pool）预先维护一批已完成底层准备的启动器（Starter）实例。

当Kimi需要新实例时，不再走完整的创建链路，而是直接从预热池中分配；再叠加Starter实例“缩容至零”（Scale-to-Zero）的能力，闲置实例的计算成本可以被压到极低。

这让一用户一实例不仅在隔离性和成本上成立，也在用户体验上成立——

Agent可以在1秒内拿到完全就绪的实例，继续生成Schema、写入数据、启动应用，而无需将等待、轮询、失败重试等复杂逻辑写进自己的代码里。

这不是Kimi一家的选择

如果Kimi K2.6的这次技术选型是孤立事件，那它或许只是一则产品新闻。

但将其置于更大的行业坐标系中观察，便会发现，它是一条正在形成的行业曲线上的一个关键节点。

这里有一个来自平台侧的数据：如今在TiDB Cloud上新建的集群中，超过90%是由AI Agent直接创建的，而非人类工程师。这个比例在一年前还远未达到如此高度。

数字背后，是一批AI Agent团队在各自完成基础设施选型后，不约而同地走向了同一类架构。几个关键案例放在一起看，趋势尤为明显：

去年，某全球知名的AI Agent平台选择TiDB作为其核心数据层，并在其技术博客和开发者社区公开了架构细节。当时他们强调的是“Agent将数据库作为工作台”。

更早之前，专注于LLMOps的低代码平台公司Dify，曾为每个开发者租户分配独立的数据库容器，规模扩大到一定程度后运维不堪重负，最终将所有租户合并迁移到一套TiDB Cloud上，实现了基础设施成本降低80%、运维负担降低90%。

△来自Dify官网

今年，Kimi K2.6将TiDB用到了更复杂的场景——Agent直接向终端用户交付由数据库驱动的完整应用。

几个团队各自完成工程评估后，得出的答案却惊人相似。

这种不谋而合本身就是一种强烈的行业信号，通常意味着底层的工程约束已经稳定到一定程度，形成了共识。

再把视角拉远一层看，每一代AI基础设施其实都对应着一种新的“计算单位”。

Web时代是“用户”，一个产品要服务几亿人同时在线。

移动时代是“会话”，一个 App要处理几亿个并发会话。

而Agent时代，计算单位就是Agent本身。每个真实用户身边可能围绕着10个、100个独立运行的Agent实例，每一个都需要自己的状态、记忆和数据。

△图片由AI生成

Agent在运行时需要的不仅仅是一个数据库，还需要一个独立的沙箱（Sandbox）来执行代码，一份独立的存储（Storage）来存放工作产物。

一个Agent，一个沙箱；一份存储，一个数据库。这套“为每个Agent提供独立运行环境”的架构，正在成为Agent原生应用唯一可行的基础假设。

从Kimi、Dify到Plaud，以及全球各地不断涌现的Agent团队，都不约而同地做出了相同的判断。

写在最后

新的默认标准正在悄然形成。过去一年，TiDB的产品演进，正是在将这些行业共识逐一落实到具体产品功能中。

Kimi等团队的选型，正是这一趋势的独立验证。

当然，TiDB团队的目标，远不止于数据库这一层。

△图片由AI生成

Agent作为新一代应用的核心计算单位，它需要的不只是一个数据库，还需要持久化工作产物的存储层（Storage）、维持跨会话上下文的记忆层（Memory），未来还会有更多组件。

TiDB正在沿着这条路径，为Agent这一代应用补齐一整套通用的运行时基础设施：

• mem9：是这条产品线上已经落地的第一个组件。Agent每次重启不应从零开始，mem9为Agent提供持久化、跨会话可检索的记忆层。
• drive9：是第二个组件。Agent的沙箱可以随时创建和销毁，但其工作成果不能随之消失。drive9为Agent沙箱提供持久化、可共享、可挂载的工作空间。

后续还会有更多组件落地。面向Agent原生应用的标准运行时，正在一块一块地拼凑成型。

AI应用的上半场比拼模型能力，下半场则较量地基的稳固与否。

当Agent进入“为终端用户交付完整应用”的阶段，模型能力本身已不再是决定胜负的唯一变量。

能否选对一套坚实的数据底座，确保交付出去的应用能在真实用户面前稳定、高效地运行，正在演变为模型厂商的核心运营能力与竞争壁垒。