# 当经典控制论遇上LLM推理：一场关于延迟、队列与GPU的11章探索 > 一个独特的学习项目将经典控制理论应用于LLM推理服务系统，通过11个章节的迭代实验，从仿真到真实GPU，揭示了控制设计中最重要的真理：理解被控对象比控制律本身更重要。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-17T17:45:55.000Z - 最近活动: 2026-05-17T17:50:35.410Z - 热度: 154.9 - 关键词: 经典控制理论, LLM推理服务, 延迟控制, 队列管理, 级联控制, PI控制器, 系统辨识, GPU调度, TTFT优化, 负载均衡 - 页面链接: https://www.zingnex.cn/forum/thread/llm-gpu11 - Canonical: https://www.zingnex.cn/forum/thread/llm-gpu11 - Markdown 来源: ingested_event --- ## 引言：控制论的跨界之旅\n\n在人工智能与工程学科的交叉地带，一个引人入胜的问题正在浮现：我们能否将经典控制理论——这门诞生于蒸汽机和反馈放大器时代的学科——应用于现代大语言模型的推理服务系统？\n\nHari Vasudevan的**LLM Inference Control**项目给出了肯定的答案，但这条道路远比想象中曲折。这个项目包含**11个章节**、**3个成功的控制器**、**8个具有教育意义的失败案例**，以及一个运行在真实GPU上的端到端闭环TTFT（Time-To-First-Token）调节器。\n\n贯穿整个项目的核心教训是：**表征被控对象是控制设计中最重要的步骤**。控制律本身从未出错——问题出在它被应用在了错误的抽象层。直到进行测量之前，作者甚至不知道正确的抽象层在哪里。\n\n## 项目背景：从仿真到现实的漫长旅程\n\n这个项目的起点是一个看似简单的问题：如何用经典控制理论来管理LLM推理服务的延迟和队列？作者选择了MATLAB和Python作为工具，从纯仿真开始，逐步过渡到Ollama本地部署、vLLM Apple Silicon版本，最终到达Modal云平台的NVIDIA T4 GPU。\n\n每个章节都遵循相似的结构：\n- 一个具体的控制架构设计\n- 在特定硬件/软件环境下的实现\n- 详细的实验结果分析\n- 失败原因的深度剖析\n\n## 章节全景：成功与失败的编年史\n\n### 成功的章节\n\n**第1章：单回路LQR + 极点配置（仿真）**\n\n项目从MATLAB仿真开始，使用单回路LQR控制器和极点配置技术。这是概念验证阶段，证明了经典控制理论在LLM推理场景中的可行性。\n\n**第2章：级联控制架构（仿真）**\n\n在仿真中验证了级联架构：内环控制批次大小B到队列深度q的映射，外环控制队列参考值q_ref到p95延迟l_p95的映射。这个架构在仿真中工作良好，因为批次大小B确实能够独立控制队列消耗速率和单请求延迟。\n\n**第4章：Ollama上的单回路积分控制（M-Mac）**\n\n在真实的Ollama部署上，作者放弃了级联架构，转而使用单回路积分控制器直接控制TTFT。这是第一个在真实硬件上成功的实现，证明了批次大小B可以通过GPU并发度直接控制TTFT。\n\n**第9章：级联控制在低层级GPU批处理工厂（Modal T4）**\n\n这是级联架构首次在真实GPU上成功运行。关键在于找到了正确的抽象层：使用精确的批次大小执行器、真实的遗留积压队列、以及测量的GPU服务时间。\n\n**第11章：闭环TTFT控制器（Modal T4）**\n\n最终章实现了完整的闭环控制。使用速度型PI控制器，在200ms、350ms、500ms的设定点下，实际值与目标值的偏差在5ms以内，并展示了负载阶跃扰动的抑制能力。\n\n## 失败的教育：8个章节教会我们什么\n\n### 第2a章：积分器饱和（仿真）\n\n**问题**：基于模型的积分器预测误差"应该"是多少，而不是累积测量到的误差。一个大的前馈项导致积分器饱和，系统将稳定在一个错误的平衡点。\n\n**教训**：积分应该基于测量值，而不是模型预测值。\n\n### 第3章：不存在的队列（Ollama）\n\n**问题**：级联尝试失败，队列深度q始终接近0。Ollama（以及大多数默认配置的LLM服务框架）不维护带有背压的持久队列。操作系统会立即将传入请求调度到GPU线程中。\n\n**教训**：级联内环正在调节一个在该硬件上不存在的系统状态变量。\n\n### 第5章：损坏的指标和无用的队列（vLLM Metal）\n\n**问题**：vLLM的Apple Metal后端存在两个独立故障：\n1. Prometheus的`num_requests_waiting`指标有bug——在到达时递增但从不递减\n2. 软件FIFO队列无用，因为vLLM在同一tick内调度到达的请求，队列等待时间始终接近零\n\n**教训**：在依赖指标进行控制之前，必须先验证指标的正确性。\n\n### 第6章：CPU时间片而非批处理（Intel Mac）\n\n**问题**：真实队列确实有效，但CPU使用时间片而非批处理，因此级联仍然无效。此外，发现总延迟l_total作为控制信号不稳定（在高q时符号翻转）。\n\n**教训**：硬件调度行为直接影响控制架构的有效性。\n\n### 第7章：服务器less开销掩盖信号（Modal T4）\n\n**问题**：远程GPU路径有效，但serverless开销掩盖了清晰的队列信号，vLLM队列始终接近零。\n\n**教训**：云环境的抽象层可能引入难以预测的信号噪声。\n\n### 第8章：错误的抽象层（Modal T4）\n\n**问题**：即使有了真实的包装器FIFO和显式的每tick批次调度，顶层LLM延迟信号仍然过于聚合。外环辨识得到`l_mean(q) = -4.9228·q + 648.76`——负斜率意味着更多队列反而导致更少延迟，这在物理上是不可能的。\n\n**根本原因**：延迟信号被vLLM的内部调度器、请求流式传输、KV缓存管理和单请求变异性所污染。第2章的方程是低层级调度方程，而非整个LLM API的方程。\n\n**核心教训**：控制律被应用在了错误的抽象层。\n\n### 第10章：错误的被控变量（Modal T4）\n\n**问题**：`ControlledScheduler`正确限制了每步的`max_num_scheduled_tokens`，TTFT确实在fraction<0.10时上升。但预期的被控变量——外部队列等待时间——在连续批处理中始终约为0ms，因为vLLM在同一调度步骤中调度每个到达的请求。没有队列可以调节。\n\n此外，GPU功耗在所有fraction下保持约65W不变（内存带宽下限：无论调度多少token，T4都必须在每个token步骤中将完整的3B参数权重通过HBM传输）。\n\n**教训**：正确的被控变量是TTFT，正确的执行器是到达速率计量，而非token预算。\n\n## 关键架构演进\n\n### 第1-2章：纯仿真\n```\nMATLAB控制器 ──► 仿真被控对象 (llm_plant.m)\n```\n\n### 第3-4章：真实硬件（M-Mac）\n```\nMATLAB/Simulink ──► Ollama HTTP ──► GPU (Apple Silicon)\n```\n\n### 第5章：vLLM on Apple Silicon（放弃——损坏的Prometheus指标）\n\n### 第6章：真实队列服务器（Intel Mac）\n```\nMATLAB控制器 ──► queue_server.py HTTP ──► Ollama ──► CPU\n```\n\n### 第7-9章：Modal远程GPU实验\n```\nMATLAB控制器 ──► Modal包装器 / vLLM ──► NVIDIA GPU\n```\n\n### 第10章：vLLM token预算调度器钩子——测量研究\n```\n负载生成器 ──► 准入包装器 ──► vLLM/Qwen (ControlledScheduler) ──► NVIDIA T4\n```\n\n### 第11章：闭环TTFT控制器——调度延迟执行器\n```\nrun_load_step.py ──► Modal包装器 ──► vLLM/Qwen ──► NVIDIA T4\n控制器: 速度型PI, 0.1s周期, kp=0.03 ki=0.002\n被控对象: sleep(delay_ms/1000) before send → TTFT = delay + vLLM_prefill\n```\n\n## 技术细节：控制器的实现\n\n### 第11章的成功配置\n\n**控制器参数**：\n- 类型：速度型PI（比例-积分）\n- 采样周期：0.1秒\n- 比例增益：kp = 0.03\n- 积分增益：ki = 0.002\n\n**被控对象设计**：\n- 执行器：外部调度延迟\n- 机制：在发送请求前执行`sleep(delay_ms/1000)`\n- 结果：TTFT = 延迟 + vLLM_prefill\n\n**性能指标**：\n- 设定点：200ms、350ms、500ms\n- 精度：±5ms以内\n- 负载阶跃：qps从4→8→4的变化\n- 相位裕度分析指导增益选择\n\n## 核心洞察：为什么控制律总是对的\n\n贯穿整个项目的主题是：**控制律本身从未出错，问题出在它被应用在了错误的层**。\n\n### 抽象层的重要性\n\n现代LLM服务系统（如vLLM、Ollama）提供了高层次的API抽象，但这些抽象往往隐藏了控制所需的底层信号。例如：\n\n- **顶层API延迟**：包含请求流式传输、KV缓存管理、内部调度器等多个因素的聚合，不适合直接控制\n- **队列深度指标**：可能因实现bug或连续批处理机制而失去物理意义\n- **GPU利用率**：可能受内存带宽限制而非计算负载主导\n\n### 测量先于建模\n\n作者反复强调：\n\n> "我不知道正确的抽象层，直到我进行了测量。"\n\n这意味着在建立控制模型之前，必须先通过实验数据理解系统的真实行为。\n\n## 工程启示\n\n### 对于LLM服务开发者\n\n1. **暴露底层信号**：如果希望系统可被外部控制，需要提供细粒度的、经过验证的指标\n2. **背压机制**：没有真正的队列和背压，就无法实现有效的负载管理\n3. **指标验证**：在依赖任何指标进行自动化决策之前，先验证其正确性\n\n### 对于控制工程师\n\n1. **被控对象表征是第一步**：在开始设计控制器之前，必须充分理解被控对象的动态特性\n2. **抽象层选择至关重要**：错误的抽象层会导致控制失效，即使控制律本身是正确的\n3. **从简单开始**：单回路控制往往比复杂的级联架构更鲁棒\n\n### 对于研究者\n\n1. **失败的价值**：8个失败的章节提供了比3个成功的章节更丰富的学习材料\n2. **跨学科思维**：经典控制理论在现代AI系统中仍然具有强大的解释力和实用价值\n3. **实验驱动**：理论推导必须与实际测量相结合\n\n## 工具链与复现\n\n项目使用了以下工具：\n- **MATLAB R2024b+**：用于控制器设计和系统辨识\n- **Control System Toolbox**：用于极点配置和LQR设计\n- **Python 3.11+**：用于实验运行和数据绘图\n- **Modal**：用于远程GPU实验（免费层即可）\n- **Ollama**：用于本地模型服务\n- **vLLM**：用于高性能推理服务\n\n每个章节都有详细的README和可复现的代码，为想要深入理解的读者提供了完整的学习路径。\n\n## 结语：控制的艺术与科学\n\nLLM Inference Control项目向我们展示了控制工程的本质：**它既是科学，也是艺术**。\n\n科学在于我们可以用数学模型描述系统行为，用控制理论设计反馈回路。艺术在于我们需要直觉和经验来选择正确的抽象层、正确的被控变量、正确的执行器。\n\n这个项目的价值不仅在于最终成功的闭环控制器，更在于那8个失败的章节所记录的探索过程。每一次失败都揭示了系统的一个隐藏特性，每一次调试都加深了对问题的理解。\n\n对于那些正在构建LLM服务系统、或者正在将控制理论应用于新领域的工程师和研究者来说，这个项目提供了一个宝贵的参考框架：**先测量，再建模；先理解，再控制**。\n\n正如作者所言：\n\n> "表征被控对象是控制设计中最重要的步骤。"\n\n这或许是所有控制工程师都应该铭记的箴言。\n\n---\n\n**项目链接**：https://github.com/hari-vasudevan/llm-serving-control\n\n**博客文章**：[Applying Classical Control Theory to LLM Inference Serving](https://vasudevanhari.substack.com/)\n\n**关键词**：经典控制理论、LLM推理服务、延迟控制、队列管理、级联控制、PI控制器、系统辨识、GPU调度、TTFT优化、负载均衡