我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
LLM是下一代操作系统
视频
音频
原始脚本
LLM 是新一代操作系统，从并发调度到上下文自治。 大多数人对大模型的认知仍停留在对话助手生成工具的层面。 但只要从工程运维、资源效率、并发架构的角度深入一层，就会发现一个更本质的事实。 现代 LLM 系统已经是一套面向 AI 服务的分布式操作系统。 它不是传统 OS 的替代品，而是在其之上构建了一层全新的资源抽象与调度体系。 一、从一个被绝大多数人忽略的常识开始，你在和 ChatGPT Gemini 对话时，是否下意识认为服务器一直在为你保持会话状态？你问一句话，模型回答。 你停顿几十秒、几分钟再继续。 在你的视角里，上下文是连续的。 但从运维现实看，这完全不可能。 OpenAI 每月服务数十亿级别的请求，全球数百万用户同时在线。 A 100H100级别的 GPU 成本极高，用户月费低廉。 大量请求免费，任何一家云厂商都不可能让单张 GPU 长期等待单个用户。 你一停顿，你的会话状态就必须被挪走。 这带来一个巨大的矛盾，用户需要连贯的长上下文，服务器必须高并发、高复用、低等待。 传统的做法是 用户下次输入时，重新把整个历史对话喂入模型，重新做一遍完整的 Transformer 推理，重新计算所有 token 的注意力，这是极高的冗余计算。 而真正高效的解法，早在半个世纪前的操作系统里就已经出现，Context Switch 上下文切换。 二， KV Cache，LLM 的进程上下文。 在传统操作系统中，当 CPU 从一个进程切换到另一个进程时，保存寄存器、页表、堆栈，这就是进程的运行状态。 在 LLM 中，对应的就是 KV Cache，它保存的是每一层。 每个 token 的 key 和 value，整个对话历史的注意力状态，模型记忆的全部物理载体。 只要 KV cache 被保存，模型就不需要重新计算历史。 这意味着用户暂停 KV cache 从显存换出，Swap out 。 用户继续 KV cache 直接载入显存，Swap in ，历史无需重算。 上下文直接延续，这不是优化，而是操作系统级别的调度能力。 三，并发的本质，交互式任务与批任务，早期大型机就定义了两种核心任务模式，今天在 LLM 架构中完全重现。 一、交互式任务，Interactive job，人类对话、问答、多轮聊天，人类输入慢、间隔长、不可预测，必须支持高频上下文切换，必须节约显存、高并发、高吞吐，不能让单个用户长期独占 GPU。 这就是 ChatGPT、豆包、Gemini 每天承载的主流服务。 不在 它的设计目标只有一个，用最少的硬件服务最多的用户。 二，批处理任务，Batch job，代码自动生成、自调试、自动规划，长推理链，长文档理解，多步骤执行，输出作为输入，持续自循环，中间部 可中断、不可换出、不可重置这类任务必须独占流，上下文持续增长，KV cache 不断累积，不被切换、不被置换，这正是未来 AI agent 的核心形态。 两种任务对应两种调度策略，两种策略共同构成 LLM 操作系统的基础。 四，长上下文不是功能，是地址空间。 传统操作系统有内存地址空间，限制程序能使用的内存大小。 LLM 则有上下文窗口，限制模型能看到的信息总量。 上下文长度等于模型的有效地址空间，KV Cache 等于近 程的驻留内存位置编码，Positioning encoding，等于地址总线的物理上限。 当我们谈论128K、256K、EM上下文时，我们谈论的不是能记住多少，而是这套操作系统能管理多大的任务空间。 长上下文的真正意义，支持完整代码工程，支持整本书，整份规范，整套逻辑，支持多轮不自断，不遗忘的自主执行。 5，自回归与自循环，LLM 的指令执行流传统，CPU 的执行模型是，取指、译码、执行下一条指令，LLM 的自回归生成式，已知历史预测下一个 token，追加到历史继续预预测，这是思维的指令流。 而当输出重新作为输入时，模型就进入了自循环执行模式。 写代码编译报错修正、推理验证反思、再推理、规划执行观测、迭代，这不再是问答，而是一个可以独立运行的进程。 这是 LLM 作为操作系统最关键的能力。 它可以在内部执行闭环任务，无需人类作为中间层。 六，LLLM 到底为什么是新一代操作系统？传统操作系统 Windows、Linux 的核心目标。 管理硬件、 CPU、内存、磁盘、网络，提供运行环境、进程、线程、文件、 IPC，让多个应用安全高效的共享机器，它们是硬件管理层。 而 LLM 操作系统的核心目标，管理知识、语言、意图、上下文。 记忆，调度 GPU 资源，用户请求推理任务，支持高并发、低延迟、长上下文、自制任务，让数百万用户共享全球分布式的推理基础设施。 它不直接管理硬件，而是管理智能请求与推理资源。 它的核心能力是多用户调度、类分时操作系统、上下文切换与换入换出，类进程管理，长上下文地址空间，类虚拟内存，自制执行与自循环，类进程执行。 所以，LLM 不是传统操作系统的替代品，它是构建在 GPU 与云基础设施之上的，面向智能服务的新一代操作系统。 7、总结回到最开始的问题，为什么你和 AI 聊天时，服务器不会空等你？因为它是一个多用户、高并发、分时复用的操作系统。 他保存你的 KV Cache，切换给其他用户，再在你回来时恢复。 这一切背后，KV Cache 等于进程状态，Context Switch 等于任务调度，Interactive Batch 等于两类任务模型，长上下文等于地址空间扩展，自循环等于自治进程执行。 当你看清这一层，就不会再把大模型当成聊天工具。 你看到的是一台全球分布式实时调度，面向智能的超级大型机，而你正在使用它的终端。
修正脚本
LLM 是新一代操作系统，从并发调度到上下文自治。 大多数人对大模型的认知仍停留在对话助手生成工具的层面。 但只要从工程运维、资源效率、并发架构的角度深入一层，就会发现一个更本质的事实。 现代 LLM 系统已经是一套面向 AI 服务的分布式操作系统。 它不是传统 OS 的替代品，而是在其之上构建了一层全新的资源抽象与调度体系。 一、从一个被绝大多数人忽略的常识开始，你在和 ChatGPT、Gemini 对话时，是否下意识认为服务器一直在为你保持会话状态？你问一句话，模型回答。 你停顿几十秒、几分钟再继续。 在你的视角里，上下文是连续的。 但从运维现实看，这完全不可能。 OpenAI 每月服务数十亿级别的请求，全球数百万用户同时在线。 A100、H100级别的 GPU 成本极高，用户月费低廉。 大量请求免费，任何一家云厂商都不可能让单张 GPU 长期等待单个用户。 你一停顿，你的会话状态就必须被挪走。 这带来一个巨大的矛盾，用户需要连贯的长上下文，服务器必须高并发、高复用、低等待。 传统的做法是：用户下次输入时，重新把整个历史对话喂入模型，重新做一遍完整的 Transformer 推理，重新计算所有 token 的注意力，这是极高的冗余计算。 而真正高效的解法，早在半个世纪前的操作系统里就已经出现，Context Switch 上下文切换。 二、 KV Cache，LLM 的进程上下文。 在传统操作系统中，当 CPU 从一个进程切换到另一个进程时，保存寄存器、页表、堆栈，这就是进程的运行状态。 在 LLM 中，对应的就是 KV Cache，它保存的是每一层、每个 token 的 key 和 value，整个对话历史的注意力状态，模型记忆的全部物理载体。 只要 KV cache 被保存，模型就不需要重新计算历史。 这意味着用户暂停时，KV cache 从显存换出，Swap out 。 用户继续时，KV cache 直接载入显存，Swap in ，历史无需重算。 上下文直接延续，这不是优化，而是操作系统级别的调度能力。 三、并发的本质，交互式任务与批任务，早期大型机就定义了两种核心任务模式，今天在 LLM 架构中完全重现。 一、交互式任务，Interactive job，人类对话、问答、多轮聊天，人类输入慢、间隔长、不可预测，必须支持高频上下文切换，必须节约显存、高并发、高吞吐，不能让单个用户长期独占 GPU。 这就是 ChatGPT、豆包、Gemini 每天承载的主流服务。它的设计目标只有一个，用最少的硬件服务最多的用户。 二、批处理任务，Batch job，代码自动生成、自调试、自动规划，长推理链，长文档理解，多步骤执行，输出作为输入，持续自循环，中间不可中断、不可换出、不可重置，这类任务必须独占流，上下文持续增长，KV cache 不断累积，不被切换、不被置换，这正是未来 AI agent 的核心形态。 两种任务对应两种调度策略，两种策略共同构成 LLM 操作系统的基础。 四、长上下文不是功能，是地址空间。 传统操作系统有内存地址空间，限制程序能使用的内存大小。 LLM 则有上下文窗口，限制模型能看到的信息总量。 上下文长度等于模型的有效地址空间，KV Cache 等于进程的驻留内存，位置编码，Positioning encoding，等于地址总线的物理上限。 当我们谈论128K、256K、EM上下文时，我们谈论的不是能记住多少，而是这套操作系统能管理多大的任务空间。 长上下文的真正意义，是支持完整代码工程，支持整本书，整份规范，整套逻辑，支持多轮不间断，不遗忘的自主执行。 五、自回归与自循环，LLM 的指令执行流。传统 CPU 的执行模型是，取指、译码、执行下一条指令，LLM 的自回归生成式，已知历史预测下一个 token，追加到历史继续预测，这是思维的指令流。 而当输出重新作为输入时，模型就进入了自循环执行模式。 写代码编译报错修正、推理验证反思、再推理、规划执行观测、迭代，这不再是问答，而是一个可以独立运行的进程。 这是 LLM 作为操作系统最关键的能力。 它可以在内部执行闭环任务，无需人类作为中间层。 六、LLM 到底为什么是新一代操作系统？传统操作系统 Windows、Linux 的核心目标是：管理硬件、 CPU、内存、磁盘、网络，提供运行环境、进程、线程、文件、 IPC，让多个应用安全高效的共享机器，它们是硬件管理层。 而 LLM 操作系统的核心目标是：管理知识、语言、意图、上下文、记忆，调度 GPU 资源，用户请求推理任务，支持高并发、低延迟、长上下文、自治任务，让数百万用户共享全球分布式的推理基础设施。 它不直接管理硬件，而是管理智能请求与推理资源。 它的核心能力是多用户调度、类分时操作系统、上下文切换与换入换出，类进程管理，长上下文地址空间，类虚拟内存，自治执行与自循环，类进程执行。 所以，LLM 不是传统操作系统的替代品，它是构建在 GPU 与云基础设施之上的，面向智能服务的新一代操作系统。 七、总结回到最开始的问题，为什么你和 AI 聊天时，服务器不会空等你？因为它是一个多用户、高并发、分时复用的操作系统。 它保存你的 KV Cache，切换给其他用户，再在你回来时恢复。 这一切背后，KV Cache 等于进程状态，Context Switch 等于任务调度，Interactive Batch 等于两类任务模型，长上下文等于地址空间扩展，自循环等于自治进程执行。 当你看清这一层，就不会再把大模型当成聊天工具。 你看到的是一台全球分布式实时调度，面向智能的超级大型机，而你正在使用它的终端。
英文翻译
LLM is a new generation operating system, from concurrent scheduling to context autonomy. Most people's understanding of large language models still remains at the level of a conversational assistant generation tool. But if you delve deeper from the perspectives of engineering operations, resource efficiency, and concurrent architecture, you will discover a more fundamental truth. Modern LLM systems have become a distributed operating system oriented towards AI services. It is not a replacement for traditional OS, but a new layer of resource abstraction and scheduling system built on top of it. 1. Starting from a common sense that most people overlook: when you converse with ChatGPT or Gemini, do you subconsciously assume that the server is always maintaining the session state for you? You ask a question, and the model answers. You pause for tens of seconds or minutes before continuing. From your perspective, the context is continuous. But from the reality of operations, this is completely impossible. OpenAI serves billions of requests per month, with millions of users online globally. GPUs like A100 and H100 are extremely costly, while user subscription fees are low. A large number of requests are free; no cloud provider can afford to have a single GPU wait long for a single user. As soon as you pause, your session state must be moved away. This brings a huge contradiction: users need coherent long context, while servers must have high concurrency, high reuse, and low latency. The traditional approach is: when the user inputs next time, the entire conversation history is fed back into the model, a full Transformer inference is performed again, and the attention for all tokens is recalculated – this results in extremely high redundant computation. But the truly efficient solution already appeared in operating systems half a century ago: Context Switch. 2. KV Cache – the process context of LLM. In traditional operating systems, when the CPU switches from one process to another, it saves the registers, page table, and stack – that is the running state of the process. In LLM, the counterpart is the KV Cache, which stores the keys and values of each layer and each token, the attention state of the entire conversation history, and the entire physical carrier of the model's memory. As long as the KV cache is saved, the model does not need to recompute the history. This means that when the user pauses, the KV cache is swapped out of the GPU memory. When the user continues, the KV cache is directly loaded into the GPU memory, swapped in, and history does not need to be recalculated. The context continues directly; this is not an optimization, but an operating system-level scheduling capability. 3. The essence of concurrency: interactive tasks and batch tasks. Early mainframes defined these two core task modes, and today they are fully reproduced in LLM architecture. First, interactive jobs – human conversations, Q&A, multi-turn chats. Human input is slow, with long intervals and unpredictability. It requires high-frequency context switching, must save GPU memory, achieve high concurrency and high throughput, and cannot allow a single user to monopolize a GPU for long. This is the mainstream service carried by ChatGPT, Doubao, Gemini every day. Its design goal is only one: serve the most users with the least hardware. Second, batch jobs – code auto-generation, self-debugging, automatic planning, long reasoning chains, long document understanding, multi-step execution, output as input, continuous self-loop. They cannot be interrupted, swapped out, or reset in the middle. Such tasks must occupy an exclusive stream, with context continuously growing and KV cache accumulating, without being switched or swapped. This is precisely the core form of future AI agents. The two tasks correspond to two scheduling strategies, and together they form the foundation of the LLM operating system. 4. Long context is not a feature; it is an address space. Traditional operating systems have a memory address space that limits the amount of memory a program can use. LLM has a context window that limits the total amount of information the model can see. Context length equals the model's effective address space, KV Cache equals the process's resident memory, and position encoding equals the physical limit of the address bus. When we talk about 128K, 256K, or EM context, we are not talking about how much can be remembered, but how large a task space this operating system can manage. The true significance of long context is to support complete code projects, entire books, entire specifications, entire sets of logic, and to support multi-turn, uninterrupted, non-forgetting autonomous execution. 5. Autoregression and self-loop – the instruction execution flow of LLM. The execution model of a traditional CPU is fetch, decode, execute next instruction. LLM's autoregressive generation predicts the next token based on known history, appends it to the history, and continues predicting – this is the instruction flow of thought. And when the output is fed back as input again, the model enters a self-loop execution mode. Writing code, compiling, fixing errors, reasoning, verifying, reflecting, reasoning again, planning, executing, observing, iterating – this is no longer Q&A, but a process that can run independently. This is the most critical capability of LLM as an operating system. It can execute closed-loop tasks internally, without needing humans as an intermediate layer. 6. So why is LLM truly a new generation operating system? The core goals of traditional operating systems like Windows and Linux are to manage hardware (CPU, memory, disk, network), provide a running environment (processes, threads, files, IPC), and enable multiple applications to share the machine safely and efficiently – they are the hardware management layer. The core goals of the LLM operating system are to manage knowledge, language, intent, context, memory; schedule GPU resources; handle user requests for inference tasks; support high concurrency, low latency, long context, autonomous tasks; and enable millions of users to share globally distributed inference infrastructure. It does not directly manage hardware, but manages intelligent requests and inference resources. Its core capabilities are multi-user scheduling (like time-sharing OS), context switching and swapping (like process management), long context address space (like virtual memory), autonomous execution and self-loop (like process execution). Therefore, LLM is not a replacement for traditional operating systems; it is a new generation operating system built on top of GPU and cloud infrastructure, oriented towards intelligent services. 7. Summary: Going back to the initial question, why does the server not wait idly for you when you chat with AI? Because it is a multi-user, high-concurrency, time-sharing operating system. It saves your KV Cache, switches to other users, and restores it when you come back. Behind all this, KV Cache equals process state, Context Switch equals task scheduling, Interactive/Batch equals the two task models, long context equals address space expansion, and self-loop equals autonomous process execution. Once you see this layer, you will no longer regard large models as just chat tools. What you see is a globally distributed, real-time scheduled, intelligence-oriented super mainframe, and you are using its terminal.
back to top