database-notes
全局变量@snum 表示全局变量 容易语法错误的地方 update不要table关键字，直接跟表名 insert不要table关键字，直接跟表名 想要切换database时，直接use其他的。比如user在mysql数据库中，直接use mysql 然后再select host,user from user; 数据库命令delimiter123delimiter //-- 将数据库的结束符号改
GPU-communication-test
背景由于需要实现张量并行，考虑测试实验室153服务器的GPU通信指标。 GPU间需要大量的交换数据，于是GPU通信性能成为了非常重要的指标。NVIDIA推出的GPUDirect就是一组提升GPU通信性能的技术。但GPUDirect受限于PCI Expresss总线协议以及拓扑结构的一些限制，无法做到更高的带宽，为了解决这个问题，NVIDIA提出了NVLink总线协议。 测试方式123cd /usr
MoE学习笔记
参考Blog：https://huggingface.co/blog/zh/moe MoE特点总结混合专家模型 (MoEs): 与稠密模型相比， 预训练速度更快 与具有相同参数数量的模型相比，具有更快的 推理速度 需要 大量显存，因为所有专家系统都需要加载到内存中 在 微调方面存在诸多挑战，但 近期的研究 表明，对混合专家模型进行 指令调优具有很大的潜力。 从图中可知，主要包括两部分：
LLM-with-fine-tuning-and-RAG
一些知识LLM处理长文本 有一个知识库 （Knowledge Base），用户输入时将用户的输入与knowledge base进行向量匹配（信息检索），结果称为reference，再将reference和user input一并送入model input，这样可以大大减少送入model input的输入长度，reference中只包括知识库中与用户输入有关的知识。 这里知识库有预处理，把知识库切成
gpt-fast
GPT-fast偶然发现Pytorch官方在2023年11月30号写了这个blog：https://pytorch.org/blog/accelerating-generative-ai-2/ 使用不到1000行pytorch原生代码实现针对大语言模型推理加速，于是拿来学习一番。 github仓库地址：https://github.com/pytorch-labs/gpt-fast 该项目主要从以
NSL-Spec-System-Optimization
虽然NSL-Spec是为科研手搓的投机推理系统，但经过实测发现多进程存在很大的性能问题。本篇记录一下笔者在打log发现系统性能瓶颈并解决的过程。 优化进程之间消息传递时间不固定的问题为了实现多个小模型并行进行自回归推理，同时避开python的GIL问题，故使用多进程加载小模型，每个小模型放置在一个单独的进程上。初步写代码发现小模型推理的time_line如下所示： 其中蓝色线表示把小模型自回归所
Medusa
投机采样的挑战 寻找理想的草案模型并非易事：确定一个“小而强大”的草案模型，能够与原始模型良好对齐（接受率不能太低），是一项复杂的任务。可能需要重训练与微调。 系统复杂性：在一个系统中托管两个（甚至是多个）不同的模型引入了多层复杂性，无论是在计算上还是在操作上，尤其是在分布式环境中。 采样效率低下：在进行推断解码抽样时，需要使用一种重要性抽样方案。这给生成过程带来了额外的开销，尤其是在较高的抽样温