网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

过去几年，AI 行业有一个最明显的发展方向：

模型越来越大

从：

Billion Parameters

到：

Trillion Parameters

从：

GPT-3

到：

GPT-4
Claude
Gemini
DeepSeek

整个行业似乎都在围绕同一个目标前进：

让模型变得更大

因为过去很长时间里，一个简单规律始终成立：

参数增加
↓
能力增强

于是：

更大模型
=
更强智能

成为行业共识，但随着越来越多企业开始把 AI 部署到真实业务场景，一个新的问题开始浮现。

很多团队发现：

模型能力已经足够强

可系统依然：

响应慢
成本高
吞吐低
扩展困难

问题出在哪里？很多时候并不是：

模型不会推理

而是：

系统无法承载推理

于是行业开始进入一个新的阶段，过去讨论的是：

Large Model

未来讨论的是：

Large System

因为决定 AI 上限的，已经不再只是模型本身，而是整个系统。

一、为什么大模型不等于高性能

很多人第一次接触 AI 时都会产生一个直觉：

模型越强，系统越快。

但现实往往恰恰相反，例如：

response = model.generate(prompt)

看起来只有一行代码，但背后实际上经历：

Prompt处理
Tokenization
KV Cache加载
GPU调度
网络同步
结果生成

真正耗时的往往不是：

generate()

本身，而是：

数据准备
状态管理
资源调度

于是现代 AI 系统经常出现一个现象：

GPU利用率不到50%

但：

用户延迟依然很高

因为性能瓶颈已经从：

Compute

逐渐转向：

System

二、性能问题为什么开始从模型转向系统

在传统软件时代，性能优化通常围绕：

算法复杂度

展开，例如：

O(n²)
↓
O(n log n)

系统立刻获得提升，但 AI 系统不同。现代 AI 服务往往包含：

模型层
缓存层
向量数据库
Agent层
工具层
网络层

例如一次 Agent 请求：

用户输入
↓
Planner
↓
Memory
↓
Tool
↓
LLM
↓
Verifier
↓
输出

可能涉及：

数十次调用

于是：

模型推理

仅仅只是整个链路的一部分，未来系统延迟越来越来自：

链路复杂度

而不是：

模型复杂度

三、长上下文让性能挑战发生质变

过去：

4K Context

已经很大，今天：

128K
256K
1M Context

正在成为趋势。问题在于，长上下文带来的不仅仅是：

更多Token

而是：

更多状态

例如：

seq_len = 1000000

hidden = 4096

memory = (
    seq_len *
    hidden *
    2
)

print(
    memory /
    1024 /
    1024 /
    1024
)

结果很容易达到：

数GB甚至数十GB

于是：

GPU还没算满

但：

显存已经满了

性能问题开始从：

算不快

变成：

存不下

四、Agent系统为什么比模型更难优化

过去的 AI：

问
↓
答

一次请求结束，状态销毁。但 Agent 不同，Agent 会维护：

记忆
计划
执行状态
历史任务

例如：

class Agent:

    def __init__(self):

        self.memory = []

        self.tasks = []

随着运行时间增长：

Memory越来越大

系统复杂度持续增加，于是性能问题开始变成：

状态管理问题

而不是：

推理问题

未来 Agent Runtime 的挑战越来越接近：

数据库

而不是：

模型服务

五、多Agent正在制造新的性能灾难

未来越来越多系统开始采用：

Multi-Agent

例如：

Planner Agent
Coder Agent
Research Agent
Review Agent

每个 Agent 都需要：

Context
Memory
State

例如：

agents = 1000

memory_per_agent = 100

total_memory = (
    agents *
    memory_per_agent
)

print(total_memory)

结果：

100000 MB

即：

100GB+

而且还没计算：

同步成本
通信成本
共享状态成本

于是未来 AI 最大的问题很可能不是：

模型太慢

而是：

Agent太多

六、AI Runtime正在成为新的性能中心

过去：

模型决定能力

未来：

Runtime决定效率

因为 Runtime 负责：

任务调度
缓存管理
状态管理
资源管理

例如：

class Runtime:

    def schedule(self):

        pass

    def allocate(self):

        pass

    def recover(self):

        pass

未来 Runtime 的重要性越来越像：

操作系统

传统 OS 管理：

CPU
Memory
Process

未来 Runtime 管理：

Agent
State
Model
Context

七、真正的瓶颈开始从Compute转向State

过去：

性能问题
=
计算问题

未来：

性能问题
=
状态问题

因为 AI 正在拥有：

长期记忆
持续推理
多Agent协作
自治执行

这些能力都会带来海量状态，于是：

State Throughput

开始变得比：

Compute Throughput

更重要，未来很多系统的瓶颈可能不是：

GPU算不动

而是：

状态搬不动

八、为什么AI系统越来越像操作系统

如果回顾整个演化过程。会发现，传统软件：

管理代码

云计算时代：

管理服务

AI时代：

管理智能

而管理智能的本质就是：

管理状态
管理资源
管理协作

这与操作系统解决的问题高度相似，因此未来很多 AI 平台最终都会演化成：

AI OS

其核心职责不再是：

运行模型

而是：

运行智能系统

九、从大模型到大系统

过去几年，行业关注的是：

Model Scaling

未来几年，行业关注的将是：

System Scaling

因为：

100B模型

已经不再稀缺，真正稀缺的是：

能够稳定运行100万Agent的系统

未来企业竞争的关键能力越来越不是：

训练模型

而是：

运营智能系统

总结

过去十年，AI 行业经历的是：

模型革命

核心问题是：

如何让模型更聪明

未来十年，AI 行业正在进入：

系统革命

核心问题变成：

如何让智能持续运行

因为当 AI 开始拥有：

长上下文
长期记忆
多Agent协作
自治任务

真正复杂的问题已经不再是：

模型如何推理

而是：

系统如何承载推理

所以从大模型到大系统，AI 性能挑战正在发生一次根本性的迁移：

Compute Scaling
↓
Model Scaling
↓
System Scaling
↓
State Scaling

未来决定 AI 上限的，很可能不再是模型参数数量。而是：

谁能够构建一个稳定、高效、可扩展的智能运行系统。

这场从“大模型”到“大系统”的演进，或许才是 AI 基础设施真正的主战场。