计算不是资产：从 KV Cache 到云计算的流动性革命

真正昂贵的，往往不是你买不起的计算机，而是你必须为它提前承担的计算能力。

这听起来像一句关于云计算的判断，但它同样适用于一个只有 6B 参数的语言模型：同样的显卡，同样的量化精度，模型能生成 1119 个字符，还是至少 8192 个字符，差别不只在于模型“更聪明”或“更先进”，而在于它如何管理记忆，如何把有限的显存变成可持续使用的计算资源。

这两个看似相距甚远的问题，其实指向同一个核心：计算能力的真正价值，不取决于硬件拥有多少，而取决于资源能否被灵活调度、重复利用，并且按照实际需求支付。

换句话说，云计算和高效推理都在完成同一场革命：把计算从一项必须预先购买的固定资产，变成一种可以动态管理的流动资源。

计算的瓶颈，不是算力不足，而是资源被锁死

传统的计算思维很直观。想运行更大的程序，就购买更强的机器；想处理更多请求，就增加更多服务器；想支持更长的对话，就准备更大的显存。这种思路把计算能力等同于硬件规模，却忽略了一个更关键的问题：资源在什么时候被占用，又有多少时间处于闲置状态。

金融领域有一个重要区别：资产规模不等于流动性。一个拥有大量固定资产的企业，未必比现金较少但资金周转灵活的企业更有竞争力。计算系统也一样。一张显存很大的显卡，如果大量空间被重复保存、长期占用，实际能提供的服务能力可能不如一张更小但管理效率更高的显卡。

语言模型推理中的 KV Cache，就是一个非常具体的例子。模型在连续对话时，需要保留前面内容的中间状态，以便理解上下文。最简单的做法，是为每一轮都保存完整的键值信息。上下文越长，缓存越大，显存就越快被消耗。结果是，模型可能并不是算不动，而是因为过去已经处理过的信息占据了太多“工作资本”，导致它没有空间继续工作。

ChatGLM2 采用多查询注意力机制，减少生成过程中的 KV Cache 显存占用，同时通过因果掩码让连续对话复用前面轮次的缓存。其意义并不只是某个模型的工程优化，而是一种普遍的资源管理原则：不要重复购买已经拥有的中间结果。

在有限显存上，初代模型生成约 1119 个字符就可能耗尽空间，而改进后的模型可以达到至少 8192 个字符。这不是简单的容量增加，而是资本周转率的提高。同一块显存被更充分地使用，同样的硬件承载了更长的服务周期。

系统的效率，不是把更多东西塞进资源，而是让每一份资源在被占用之后仍然能够继续产生价值。

云计算把算力变成了一种金融产品

云计算最深刻的变化，也许不是服务器被搬到了远程数据中心，而是它改变了计算资源的交易方式。

在传统模式中，企业需要预测未来几年会需要多少计算能力，然后提前购买机器、建设机房、招聘运维人员。这是一种高额的预先承诺。企业必须为峰值需求配置资源，即使大部分时间只使用其中一小部分。节日促销、突发新闻或新产品发布时，系统可能需要十倍于平时的容量，但这十倍容量在其他时间却处于闲置状态。

云计算则提供了另一套制度安排：按需使用，短期租赁，根据实际消耗付费。它把计算资源从“购买一台机器”改造成“获得一段时间的计算服务”。这与金融机构处理资金有相似之处。资金可以被汇集、拆分、定价和转移，计算资源也可以通过虚拟化和多路复用，被不同用户在不同时间共同使用。

超大规模数据中心的价值，不只是规模带来的低价，更在于它们能够把大量随机、波动、互不相关的需求组合起来。某个组织的服务器在夜间闲置，另一个组织恰好在夜间进行批量计算。通过资源池化，两者不必分别购买完整的峰值容量。原本沉睡的硬件，被转换成可以出租的生产力。

这就是“Computing is necessary, Computers are not”的含义：企业真正需要的是计算结果和计算能力，不是对某台物理机器的所有权。

这个判断也解释了为什么云原生不仅是一组开发工具，更是一种经营逻辑。容器、自动扩缩容、无状态服务、微服务和弹性调度，表面上是在改善软件结构，实质上是在让应用能够适应一种按需计价、动态供给的资源市场。

如果应用必须依赖一台固定服务器，无法快速复制，无法释放闲置资源，那么它虽然运行在云上，却仍然保留着传统固定资产的思维。真正云原生的系统，必须让计算资源像现金流一样可以快速进入和退出业务：需求增加时扩张，需求下降时收缩，故障发生时转移，任务结束后归还。

KV Cache 与云资源池，其实是同一种组织智慧

把模型推理和云计算放在一起看，会出现一个很有用的对应关系。

模型的 KV Cache，类似企业为了维持业务连续性而持有的流动资金。它保存了过去的状态，使系统不必从头计算，但也会占用有限资源。如果保存过多，后续请求就会受到挤压；如果完全不保存，每次都重新计算，响应速度和成本又会恶化。因此，缓存不是越多越好，而是要在速度、容量和复用率之间找到平衡。

云数据中心中的服务器，也类似一种被多个组织共享的资本。单个客户无法保证持续使用，但大量客户的需求叠加起来，就能形成较高的总体利用率。虚拟化和多路复用的作用，就是把原本分散且波动的需求，转化为更稳定的资源流。

二者都遵循三个层次的效率原则。

第一，减少重复计算和重复占用。

在模型中，复用已有的 KV Cache，避免每轮对话都重新保存同样的信息。在云平台中，复用通用基础设施，避免每个组织都独立建设一套只在高峰期使用的系统。无论对象是张量还是服务器，重复建设都会把有限资本锁死。

第二，将峰值需求与常态需求分开处理。

如果按照峰值配置整个系统，成本一定会被少数极端时刻拉高。更好的做法是让常态负载使用稳定资源，让短暂峰值通过弹性扩张获得额外能力。模型的上下文窗口、批处理策略和缓存淘汰机制，也应当区分“必须长期保留的信息”和“只在瞬间有价值的信息”。

第三，让资源的定价接近真实使用。

云计算通过按量付费，降低了使用者的前置承诺。模型推理也需要类似的资源核算：一次请求究竟消耗了多少显存、缓存、带宽和计算时间？如果所有请求都被按照最大上下文长度配置资源，系统就会把不必要的成本转嫁给每一次调用。

这带来一个重要的架构判断：性能优化不应只看每秒处理多少请求，还要看每个请求占用了多少不可回收的资源。

一个响应速度很快，却需要长期保留巨大缓存的系统，可能只是把成本从时间转移到了空间。另一个单次响应稍慢，但能够及时释放资源、稳定服务更多用户的系统，反而具有更高的经济效率。

从“买设备”转向“设计流动性”

对于企业和个人开发者而言，这种视角会改变很多具体决策。

假设一个团队准备部署一个对话模型。传统问题是：需要购买多少显存？更好的问题是：用户的上下文有多长，历史信息中有多少必须保留，缓存能否复用，负载高峰持续多久，低峰时资源能否归还？

再假设一个电商系统正在为促销活动扩容。传统问题是：高峰期需要多少台机器？更好的问题是：哪些服务必须始终在线，哪些任务可以延迟处理，哪些状态可以外置，哪些计算可以批量完成，峰值过后资源能否自动收缩？

这两个问题的共同答案，是建立一套“计算流动性”指标。它至少可以包含以下四个维度：

• 占用周期：一份资源被申请后，平均多久才能释放。
• 复用次数：同一份中间结果或硬件容量，在生命周期内被多少次有效利用。
• 峰值弹性：系统从常态扩张到峰值的速度，以及从峰值收缩回常态的速度。
• 闲置成本：资源没有产生有效结果时，仍然需要支付多少代价。

这个框架可以用于模型服务，也可以用于整个企业的信息基础设施。它提醒我们，所谓“高性能”不是孤立的技术指标，而是资源在时间维度上的组织能力。

例如，模型服务可以采用分层记忆策略：最近几轮对话保留高精度缓存，较早内容压缩为摘要，更久远的信息只保留可检索索引。这样做并非单纯牺牲上下文，而是把不同信息按照未来复用概率进行定价。高频使用的信息占用快速但昂贵的记忆，低频信息转移到成本更低的存储层。

这与云计算中的分层存储、冷热数据分离和自动扩缩容，本质上是同一种思想：让资源的质量与它的使用频率相匹配。

Key Takeaways

• 把显存和服务器当作流动资本，而不是静态资产。 评估系统时，不只问容量多大，还要问资源能否快速释放和再次利用。
• 优先消除重复工作。 对模型推理，检查 KV Cache 是否重复保存；对业务系统，检查是否重复部署基础设施、重复计算相同结果。
• 按照常态需求配置基础能力，按照峰值需求设计弹性。 不要让少数极端时刻决定所有长期成本。
• 建立资源占用账本。 记录每个请求的显存、缓存、计算时间和带宽消耗，把技术指标转换为可比较的经济指标。
• 采用分层记忆与分层资源。 高频信息使用快速资源，低频信息转入更便宜的存储或计算路径，并设置明确的回收规则。

计算自由的真正含义

过去，人们把计算自由理解为拥有更多机器。今天，更重要的自由是：不必因为偶尔的峰值而永久拥有机器，不必因为历史状态而无限扩大缓存，也不必把未来不确定的需求提前变成今天的资本支出。

云计算释放的是基础设施的流动性。高效推理释放的是记忆的流动性。两者共同揭示了一个经常被硬件参数遮蔽的事实：计算能力不是设备的固有属性，而是资源组织方式产生的结果。

一块显卡能支持多长的对话，一座数据中心能服务多少用户，一个企业能否快速响应需求，最终都取决于同一个问题：过去产生的状态，是否正在阻塞未来的行动。

真正先进的系统，不是永远堆叠更多资源，而是知道什么应该保留，什么应该复用，什么应该共享，什么应该及时归还。当计算被这样管理时，我们购买的不再是机器本身，而是机器在正确时间、以正确成本，持续产生结果的能力。