Agent Notes

部署 · 技术问答 ​

必会 ​

重点 LLM 为什么需要矩阵运算？ ​

  • LLM的核心是将文本转化为高维向量进行处理。每个词会转为一个向量（如4096维），整句话就形成一个矩阵。Transformer架构通过矩阵运算来捕捉词与词之间的复杂关系。
  • 例如：
    • 输入句子有100个token，每个转为1×4096向量，堆叠成100×4096的矩阵。
    • 注意力机制计算 token A与token B的相关度，本质是Query矩阵 × Key矩阵的乘法。
    • 当模型有1750亿参数 => 处理的矩阵运算，计算量极其庞大。

GPU 上为什么要把数据从显存（HBM）搬到 SRAM？有哪几种用法？ ​

口述：推理大量时间花在搬数，不在算。HBM 是芯片外大仓库，SRAM 是片内超高速小仓库；先搬进 SRAM 再共享，比反复读显存快一个数量级。

内存墙

  • SRAM：极快、极小（课件：单 SM 约 128KB，聚合带宽远高于显存），线程间交换数据用它。
  • HBM：显存主力，容量大但比 SRAM 慢一个数量级以上。课件里的 HBM3e TB/s 数字不当自己实测。

SRAM 三种用法

  1. 数据复用（Tiling / 分块） — 矩阵乘、卷积里很多线程会反复读同一块全局内存。先把块从 HBM 搬进 SRAM，块内共享，避免重复读显存。
  2. 并行归约与协作 — 块内求和、最大/最小、矩阵行列归一化；前缀和等需要线程之间传数据的算法。
  3. 结果聚合与缓存 — 卷积多通道复用同一输入特征；Transformer 里 Q/K/V 矩阵乘的中间结果先放 SRAM，再写回。

本质：用极低延迟，让线程以比访问显存快 10–100 倍的速度共享中间数据。优化推理先抠少搬 HBM（量化、KV 卸载、算子融合），不是只堆算力。

重点 为什么 LLM 推理卡在数据搬运？ ​

口述：工厂（SM）加工很快，原料（权重）在十几公里外的仓库（HBM）。加工再快也是 90% 时间在等货车。这就是内存墙：算力被内存带宽卡死。

  1. 参数塞不进 SRAM — 几百 GB 权重远大于片内小仓库，每步计算都要从 HBM 往 SM 搬。
  2. 搬比算慢 — 课件口径：搬运速度比 SM 计算慢 50 倍以上，所以墙钟时间主要在等数，不在乘加。
  3. Decode 更明显 — 每生成一个 token 几乎要把相关权重再扫一遍，带宽吃满、算力闲着。
  4. 怎么办 — 量化减小搬运量、算子融合少往返、KV 分层卸载、换更高带宽的卡。只加 TFLOPS 解不了这堵墙。

和上一题的关系：上一题讲「搬进 SRAM 之后怎么用」；本题讲「为什么不得不反复搬、所以慢」。

CPU 与内存的隐形瓶颈？ ​

口述：推理不只是 GPU。CPU 管调度、分词、JSON；DRAM 不够或 CPU 过载，GPU 会饥饿等数。

  1. CPU 干什么 — 并发调度、Tokenization、前后处理（JSON / 正则）。Tokenizer 串行，吃单核频率。
  2. 配不好会怎样 — 并发一大，CPU 打满或 DRAM 不足 → GPU 空转。
  3. 课件配比 — 每张 GPU：16–32 核 + 512GB–1TB DRAM（量级，按并发和 KV 卸载调）。
  4. 别和内存墙混 — 内存墙是片内等 HBM；本题是整机 CPU / 内存把 GPU 饿死。

什么是 llama.cpp？ ​

llama.cpp 是软件名称，也是 GitHub 上的开源项目名称。https://github.com/ggml-org/llama.cpp。 .cpp 是 C++ 的源代码文件后缀，它明确用 .cpp 后缀告诉开发者：这是一个用 C++ 语言编写的项目

  • llama.cpp 是开源的高性能LLM推理引擎，纯C/C++实现，主打跨平台本地部署。
  • 支持GGUF格式量化（4/8bit压缩），让消费级CPU甚至手机也能流畅运行大模型
  • 零依赖、可离线使用，被Ollama、LM Studio等工具广泛采用，是本地LLM生态的核心基础设施。

重点 如果你想在企业内部搭建 Agent，做 API 服务选哪个？ ​

口述：Agent 平台和推理引擎分开。对内 API 可先评估 vLLM；如果请求前缀重复、结构化生成和性能压测显示存在瓶颈，再评估 SGLang。Ollama 更常用于本地开发或小规模服务，是否适合线上要由实际压测、可用性和运维要求决定。

稳妥：vLLM

  1. PagedAttention — 用块化 KV Cache 降低碎片并提高可调度性；收益取决于模型、上下文和负载。
  2. 生态最熟 — Hugging Face 格式几乎都能跑，文档和 Issues 现成答案多。
  3. 生产验证 — 不少对内大模型 API 是在它上面改的。
  4. 代价 — 不同版本、硬件和负载下的性能差异很大，选型前必须用自身请求分布压测。

性能：SGLang

  1. 什么时候换 — 有底层优化能力，且要极致性价比（少卡 = 省钱），前缀重复又多。
  2. 吞吐 — 只有在模型、硬件、输入输出长度、并发、版本都相同的基准下才有可比性；不要背离开条件的 tok/s 或成本数字。
  3. RadixAttention — 对共享前缀的多轮、Agent、RAG 请求可能减少重复 prefill；命中率由实际请求相似度决定。
  4. 结构化输出 — 重点比较格式约束能力、兼容性、错误处理和真实延迟，不承诺固定数量级差异。
  5. 现状 — 已能跑 DeepSeek V3/R1、AMD、昇腾 910B，文档和社区仍不如 vLLM 熟，排障成本更高。

OpenClaw 管编排，引擎只提供 /v1。先 vLLM 稳住，前缀命中和 JSON 成为瓶颈再迁 SGLang。数字是公开对比，别报成自己压测。

进阶 ​

D1. CPU 和 GPU 在 LLM 推理里各干什么？CPU 还能丢掉吗？ ​

答题要点

  • GPU：海量小核，吃矩阵乘（Attention 等），大模型推理主要靠它。
  • CPU：核少、擅长控制流；推理服务里仍做请求调度、分词、JSON / 后处理。
  • CPU 或内存成为瓶颈时，GPU 会空转（饥饿）。
  • 经验方向：一张 GPU 配够 CPU 核和内存，具体以机房规格为准。

加分句：面试别说「推理 = 只有 GPU」；说出调度和 Tokenizer 在 CPU 上。

D2. vLLM、SGLang、TensorRT-LLM、Ollama 怎么选？ ​

答题要点

  • Ollama：本地 / 边缘 / 快速验证，封装 llama.cpp。
  • vLLM：PagedAttention，高吞吐生产，生态熟。
  • SGLang：Radix / 前缀 KV 复用，多轮、Agent、RAG 共享前缀多时更合适。
  • TensorRT-LLM：NVIDIA 上抠极致延迟 / 吞吐。
  • 口诀：先跑通用选 vLLM；对话前缀长选 SGLang；本机 demo 选 Ollama；绑死英伟达极致性能再上 TRT-LLM。

加分句：选型先看「单轮吞吐 vs 多轮前缀复用 vs 是否锁 GPU 品牌」，再报框架名。

了解 ​

单卡 4090 / 笔记本怎么跑 Agent？ ​

答题要点

  • 量化 FP16 → Int8 / Int4（如 GGUF）。
  • 推理：vLLM（PagedAttention）、Ollama、llama.cpp。
  • 课件数字（显存 +50%、速度 ×3）当量级，用自己压测说话。