LLM推理时，模型的所有权重（weights）都必须可用，以便进行前向传播（forward pass）。所以一般情况下，需要加载整个模型到显存（GPU内存）。但有一些优化手段可以缓解显存压力，比如CPU+GPU混合推理（Offloading）。一部分模型参数驻留在CPU内存中，推理时按需移动到GPU（如 HuggingFace 的 accelerate、DeepSpeed）。但这样会牺牲一定的推理速度。

在LLM的一个对话Session中，对话是连续的，LLM看似是有记忆的，可以记得刚才说过了什么。但是实际上：在一次回答生成结束后，此次计算就完成了，除了计算结果（LLM的输出）外，不会有什么东西被保存，并不是「每个Session都对应一个计算中间状态」。
那么LLM是如何记住之前说过的话呢？这里LLM的记忆要分为「长期记忆（知识）」和「短期记忆」。
长期记忆：LLM 的“长期知识”存放在参数权重里（训练/Fine-tune 得来），但不会把某次对话的中间想法或状态写回权重。模型层面没有“对话级”的内在记忆。
短期记忆：每次模型的完整Input中，会自动包含之前的对话内容，所以LLM表现为有短期记忆。每次的完整Input包括：系统提示+工具结果+历史对话文本（有可能会被总结、精简，或者忽略较久之前的内容）+当前问题。多轮记忆，几乎都是通过应用层把历史对话（或其摘要、检索到的资料）拼进这次输入里实现的。
所以，我们在调用API的时候，每次向服务器发送的数据，除了本次的用户问题，有可能还需要包括完整的对话历史。

let messages = [
  { role: 'system', content: '你是一个有帮助的AI助手。' },
  { role: 'user', content: '你好,请介绍一下自己。' },
  { role: 'assistant', content: '你好！我是一个AI助手，可以帮助你解决问题。' },
  { role: 'user', content: '你能帮我写一个故事开头吗？' }
];

同时，这也解释了为什么：在同一个对话Session中，可以随时切换模型（因为对话所需的“状态”就是文本上下文。把同样的上下文喂给另一个模型，它就能继续回答——风格与能力可能不同，但不依赖某个模型保存过什么“隐形状态”）；自己之前发送的文本，可以随时回退、修改、重新发送。
总结：AI每次生成内容的时候，都是从无状态开始的，只是把前面的对话看一遍

用于认证的Token

Token 是模型处理文本的最小单位（切片），不是字数/字符数（但是约等于汉字/单词，要取决于分词方法，Token是「词片」单位）。英文：常见近似是 1 个 token ≈ 3–4 个英文字符，或 ≈0.75 个英文单词；中文/日文：常见情况下 1 个汉字/假名 ≈ 1 个 token，但成语、专有名词、数字/emoji 可能合并或拆分得更多/更少。
模型的“支持的 Token 长度”通常指上下文窗口，这是一次对话调用中，系统提示+历史对话+工具结果+你当前问题（=输入）加上模型要生成的回答（=输出）的总 Token 上限。
一些名词解释：Prompt tokens：这次请求中作为输入发送的 Token；Completion tokens：模型生成的 Token；Total tokens：两者相加，用于计费与窗口限制。
Token长度会影响什么？计算/费用与 Token 数近似线性增长；推理延迟与显存也与 Token 强相关（注意力是 O(n²)）；窗口装不下历史时，就需要截断/摘要/RAG 检索等手段。
Token长度是否可以控制？能控制，但主要是“控制输出的上限”，而不是神奇地让同一段输入占更少 token。在各家 API 里都提供了“最大输出 token（max_output_tokens）”与“停用序列（stop）”等参数来精细化控制长度与成本。另外，模型常在“说完为止”就停，不会因为你把上限设很高就硬凑字；停止原因在响应里能看到

在对话里除了你输入的“用户提示（user prompt）”，还会有一段（或多段）系统/开发者提示，用来规定整体角色、语气、约束与可用工具。它们与用户提示一样被送进模型，但优先级更高：冲突时通常以系统/开发者提示为准。
在 OpenAI 的对话格式里，消息有“角色（role）”，常见有 system/developer、user、assistant 等。system/developer 用来设定“这次助手应该如何表现、遵守哪些规则”，属于隐式内容，用户通常看不到，但它与用户消息一起进入模型的上下文。
OpenAI 的较新文档把“系统提示”的职责更多称作开发者消息（Developer message），本质就是更高优先级的指令层。
在使用ChatGPT的时候，能看到的只是用户提示；但在后台，请求会包含：系统/开发者提示 + 历史对话 +（可选）检索到的资料/工具结果 + 问题，一起作为输入发给模型。API 文档和指南都以这种多消息结构来描述对话。

[
  {"role": "developer", "content": "你是严谨的数据助理，先给结论，再给要点。禁止编造来源。"},
  {"role": "user", "content": "给我 3 条关于A公司的最新动态，并附上来源链接"}
]

在使用API请求的时候，是可以自己设定系统Prompt的。（例如在OpenWebUI中）

需要准备一个可以调用的search_internet函数（这里名字随便写的）
注意，这个函数接口不是通过system prompt传递给模型的（那是怎么传递的？）
执行这个函数的，到底是哪方？请求发起方还是OpenAI的服务器？
模型除了会输出文本之外，还会表达「想要搜索」的意愿吗？也就是可以输出「文本以外」的内容？

现在的LLM一般都会有一个入口请求url，比如：https://www.gpt4novel.com/api/xiaoshuoai/ext/v1/
这是 API 的 根路径，通常用来作为所有接口的前缀。它本身一般不会直接处理请求，而是作为统一入口点，下面会挂载不同的功能路径（resources）。

1. /chat/completions：对话接口
2. /images/generations：图片生成接口
3. /models：获取可用模型信息

而需要进行对话请求的时候，会有调用端点（具体接口 Endpoint）：https://www.gpt4novel.com/api/xiaoshuoai/ext/v1/chat/completions

一般用法：

1. 在配置LLM聊天软件（Open WebUI等）时，一般用的是入口url，软件会自动从/models下获取可用模型等。
2. 在实际发送聊天请求的时候，就需要把数据发送到具体接口 Endpoint了，如果使用的是LLM聊天APP，那么我们应该不用关心这个url，如果是自己写代码进行请求，就需要访问这个url了。

1. LLM的随机性

1. “Vibe coding” 是 2025 年初在程序员圈子里迅速流行起来的一个新术语，意指以“氛围”和“感觉”为主导、依赖 AI（特别是大型语言模型，LLM）生成代码的编程方式。什么是 Vibe coding？程序员只需用自然语言（中文、英文等）简单描述功能或氛围，比如“我要一个现代风格的待办清单应用”，AI 即能输出可运行的代码。
2. 「联邦学习」：Federated Learning（联邦学习）是一种分布式机器学习方法，允许多个参与方（如手机、边缘设备、组织）在不共享原始数据的情况下，共同训练一个机器学习模型。其核心思想是：数据不出本地，模型参数上传，从而实现隐私保护和数据安全。

1. MCP 到底是个什么鬼？ https://v2ex.com/t/1174927