1.chatGLM-6B安装与部署
2.AI与PDE（七）：AFNO模型的对话对话源代码解析
3.开源Open WebUI - 大模型LLM web 聊天界面及在K8S集群中的部署
4.Langchain 源码分析 Chain系列(一)
5.ChatGLM2-6B多轮对话训练方式
6.Qwen Function Calling 的对话模板及训练方法总结
chatGLM-6B安装与部署
ChatGLM-6B, 一个开源的双语对话语言模型，基于亿参数的模型模型GLM架构，特别适合消费级显卡部署（在INT4量化下，源码源码6GB显存即可）。对话对话然而，模型模型我使用GB显存的源码源码船舶监控程序源码RTX Ti时，只能选择INT8量化级别运行。对话对话首先，模型模型确保硬件（如Python、源码源码显卡驱动、对话对话Git等）和Pytorch环境的模型模型准备，可以参考之前的源码源码文章。
安装过程中，对话对话国内用户可选sjtu.edu镜像源下载ChatGLM要求。模型模型官方建议安装Git LFS，源码源码但新版本Git通常已包含。默认加载模型时需要GB显存，我的显存受限，因此尝试量化加载，通过以下代码实现：
尽管初始量化加载时间较长，但后续对话回复速度较快。此外，还展示了如何通过gradio部署网页版demo，ios activator源码只需修改web_demo.py中的部分代码。
尽管环境条件有限，下一篇文章将探索P-tuning。ChatGLM-6B的详细信息和源代码可在GitHub项目THUDM/ChatGLM-6B中找到。
AI与PDE（七）：AFNO模型的源代码解析
本文旨在解析AFNO模型的源代码，帮助读者理解模型细节与主干结构。首先，AFNO模型的主干框架在afnonet.py文件中定义，通过类AFNONet实现。模型的核心功能封装在多个类与函数中，依据代码注释逐步解析。
在代码中，forward_features函数负责模型的核心逻辑，包括patch切割与mixing过程。这些操作由PatchEmbed类实现。位置编码self.pos_embed通过高斯初始化得到，增加模型的表示能力。
关键模块AFNO2d位于代码中，它基于FNO的原理，负责处理输入数据。AFNO2d模块在forward_features函数中通过循环调用，实现数据的图像索引 源码转换与混合。
经过数个L layer处理后，模型进入类似解码器的结构，用于将中间结果映射为目标结果。这一过程通过self.head(x)实现，以解决特定分类问题。
本文通过梳理代码流程与结构图，直观展示了AFNO模型的工作原理。读者可参考AFNO的GitHub源代码与论文，深入理解细节。后续文章将继续探讨基于AFNO模型框架的其他应用，如FourCastNet。
开源Open WebUI - 大模型LLM web 聊天界面及在K8S集群中的部署
Open WebUI 是一个自托管的离线 Web 用户界面，专为支持多种大型语言模型（LLM）运行而设计。它提供丰富功能和直观界面，兼容 Ollama 和 OpenAI API。您可以在 GitHub 上找到源代码。
Open WebUI 提供全面平台，方便与大型语言模型交互，并具备功能性和灵活性，以满足不同用户和应用场景需求。它旨在优化模型管理、更新、昆明旅游源码交互、历史管理和数据管理，同时支持语音和图像集成，以及 API 和安全性功能。界面还提供国际化支持。
部署 Open WebUI 到 K8S 集群时，参考官方文档中的部署 YAML 文件。通常涉及编写简单的部署文件，如 `docker-compose.yaml`。部署过程中需注意服务配置和服务持久化卷（PVC）的设置。这些关键步骤确保 Open WebUI 在 K8S 环境中稳定运行，提供高效、安全的大型语言模型交互体验。
Langchain 源码分析 Chain系列(一)
Langchain是一个组件丰富的系统，其中"Chain"元素串联起prompt、memory、retrieval和model等组件，实现复杂功能。这些组件如prompt，能处理用户输入，大型模型提供反馈，反馈会被存储在memory中，民宿 源码供后续使用。Langchain提供了多种预设的chains以适应不同场景，也可根据需要自定义。
要入门，如LLMChain，它接收模板，格式化用户输入，通过LLM获取响应。创建一个水果描述的提示模板后，与LLM结合成简单的Chain，只需调用'run'方法，将获得对应水果特征的描述。run方法适用于单输入和单输出，且无需要额外输入字典。此外，chains模块还支持__call__方法，输出内容更灵活，可选返回仅输出项。
如果用聊天模型替换LLM，chains支持持久化数据的'Memory'参数，使chain具备状态，能存储和跨次调用保持信息。源码分析将深入探讨Chain、LLMChain和ConversationChain这三个核心类，它们在链式处理中起关键作用，各自带有抽象和具体方法，如prep_inputs预处理输入，prep_outputs验证输出，以及__call__作为执行入口点。
LLMChain是基于Chain的扩展，专门处理语言模型查询，如对话系统。它新增了特定于LLM的方法，简化处理过程。ConversationChain进一步扩展了LLMChain，支持对话和内存上下文管理。
ChatGLM2-6B多轮对话训练方式
ChatGLM2是一个经过指令微调的聊天模型，微调时应遵循官方数据组织格式以实现最佳效果。对比预训练模型，其训练数据组织格式较为灵活，而对于聊天模型，官方数据组织格式更为推荐。分析源码时，我们发现ChatGLM2的多轮对话训练存在不足。在训练过程中，只有最后一轮对话内容参与计算损失（loss），其他助手的回答内容并未参与，导致训练数据利用不充分，形成浪费。
在ChatGLM2的训练源码中，我们观察到输入`input_ids`是由`prompt`、`answer`和结束符（由tokenizer定义）拼接而成。`prompt`由`tokenizer.build_prompt(query, history)`生成，包含了历史对话和当前轮次用户输入的拼接。`answer`则为当前轮次的回复。通过查看huggingface上`chatglm2-6b`的tokenizer代码，我们发现`build_prompt`方法中包含了结束符`eos_token`，揭示了ChatGLM2多轮对话数据组织格式的关键点。对于`labels`，除了最后一个轮次回复内容对应的`b ids`外，其他位置都被置为`pad_token_id`，这意味着只有最后一个轮次的回复内容参与计算loss，其他回复内容未参与，从而导致训练数据未被充分利用。
对于现有的多轮对话训练方式，我们总结了三种方法：不充分、不高效以及Firefly方法。不充分的方法将所有对话输入视为模型输入，仅最后一个回复内容参与loss更新，忽视了其他回复的潜在信息，造成训练数据浪费。不高效的方法将多轮对话拆分为多条数据进行训练，提高了利用度但降低了训练效率。Firefly方法则采取了一种更充分利用数据的策略，通过并行计算每个位置的loss并仅更新Assistant部分的权重，从而实现了更高效的训练。
Firefly方法之所以可行，归功于因果语言模型的特性。以GPT为代表的因果语言模型具有对角掩码矩阵的attention mask特性，使得每个位置的编码只依赖于它之前的信息，从而实现了并行计算每个位置的logits。虽然GLM和UniLM等模型存在prefix attention mask的设计，但ChatGLM通过单向注意力机制进行了调整，与Firefly方法保持了兼容性。在训练时，通过数据拼接、tokenize和生成目标mask，Firefly方法充分实现了多轮对话数据的高效利用。
值得注意的是，尽管ChatGLM2在数据组织和训练方法上存在不足，改进如Firefly方法的实现能够显著提升多轮对话模型的训练效果和数据利用率。通过合理的数据格式和loss计算策略，训练多轮对话大模型能够达到更高效、更充分的训练状态，实现更好的对话生成质量。实践证明，即使简化数据组织形式，多轮对话模型也能展现出卓越的性能，这一方法值得在实际应用中进一步探索和优化。
Qwen Function Calling 的对话模板及训练方法总结
本文总结了Qwen Function Calling的对话模板及训练方法，旨在帮助理解其工作原理和使用方式。Qwen项目支持插件功能，通过研究部署源码，我们了解到其对function calling的处理策略。
对话模板示例中，Qwen的生成结果会根据是否显式调用functions有所不同。在无function调用时，模型的自然交互体现在"Thought: "和"Final Answer: "部分。而当调用functions时，生成结果会包含"Action: "和"Action Input: "，表示执行的操作和参数。
训练时，Qwen通过混合常规对话样本和包含functions的样本，以指令微调的方式增强function calling能力。这两种样本在输入模型时，INSTRUCTION中会包含functions信息和特定格式的问题和回答。
总结来说，无论是常规问答还是function调用，Qwen在训练和推断过程中都会应用对话模板，并对问题和答案进行适当的包装。然而，对于调用者看到的输出，function调用会增加一层“所见非所得”的复杂性。