Technicals

经典老文 orca Continuous batching: 把 prefill 和 decode 里的每个 token 打散重新做 batching. vllm 用 page attention 来管理 kv cache 来应对碎片化, 以及利用 cpu memory 来 offload (这部分好像不是重点)。 OSDI'24 一个会有一个 session 一篇文章讲同一个事，可怕。 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve 背景是现有 llm serving 系统（TRT-LLM, vLLM）要么等 decode 完了再 prefill, 要么有 prefill 就先做完整个 prefill, 导致 latency to first token 或者 decoding latency 不稳定。一个额外的坏处是这个事情影响 pp，因为 pp 里面有多个任务，每个任务时长不一样，就会有比较多的 bubble。 这文章把 prefill 任务 chunk 掉，这样调度的时候可以更好地复合 prefill 和 decode，控制 pp 里每个任务的 latency，从而对 decode 的 latency 也有保障了 (stall-free batching）。...

FastMoE 是世界上首个开源的在 PyTorch 上支持 MoE 模型分布式训练的框架. 经过持续不断的更新与优化, 其在性能上相比各类竞品持续保持了一定的优势. 从 2021 年 3 月开源至今, 已经历了若干个发行版本, 亦有一些相关学术工作发表在各大会议和平台上. 此处对官方提供的公开资料进行汇总整理. FastMoE 代码仓库 FastMoE 框架的开源版本开源在 GitHub 上. 链接 该开源版本支持 cuda 平台. 开源版本中也包含来自社区贡献的对 rocm 平台的支持, 但对新版本 FastMoE 的支持可能并不完善. 此外, 对于申威和一些其它国产加速平台, FastMoE 也有相应的私有版本. 如有兴趣, 请联系清程极智. FastMoE 使用方式 FastMoE 作为 PyTorch 的插件存在, 推荐的使用方式是和 Megatron-LM 框架一起使用. 开源版本代码仓库中提供了修改不同版本 Megatron-LM 并与 FastMoE 一起使用的教程和参考补丁. 在FastMoE 官网(暂停维护)和代码仓库的中有更多文档可供参考. FastMoE 及系列学术文章 FastMoE 支持专家并行的工作原理在一篇 arxiv 文章中进行了讲解. arxiv原文 中文博客版本. FasterMoE 是一个发表在 PPoPP 学术会议上的工作. 其对于专家并行中负载均衡和通信计算重叠进行了研究. 该论文中所述的优化均已集成到 FastMoE v1.0.0 以后的版本中....

laekov 遇到的问题是希望使用 mpi 进行一些 cpu 的通信, 以及用 nccl 来进行一些 gpu 间的通信. // 没错, 说的就是让 FastDecode 支持模型并行. 众所周知, pytorch 和 mpi 的关系不太好的亚子. 然而 mpi 其实是最方便, 也是最适合大规模使用的. 虽然新版的 pytorch 试图引入 ucc backend 来支持 cpu 和 gpu 的混合通信, 但在较老的版本或一些特定环境里还无法顺畅地使用 ucc. 事实上 pytorch 支持创建不同 backend 的不同 ProcessGroup. 然而如果写如下一段代码, 就会发现并跑不起来. dist.init_process_group(backend='mpi') ... g = dist.new_group(list(range(world_size)), backend='nccl') x = torch.ones(16, device='cuda') * (rank + 1) xs = [torch.empty_like(x) for _ in range(world_size)] dist.all_gather(xs, x, group=g) 甚至会获得一些在 ucx 里的错误栈, 再往上找会发现报错在 c10d::PrefixStore::set 这个函数里....

这是一篇 arxiv 文章 的中文简要版本. 摘要 这篇文章主要介绍了一种大语言模型的推理系统. 在自回归生成过程中, 序列中的元素 (token) 被挨个生成, 因此模型推理的序列长度 (sequence length) 为 1. 因此, 增大 batch size 对于 GPU 利用率的提升十分重要. 然而 KV-Cache 体积很大, 且与 batch size 成正比. 其大小阻止了 batch size 和 GPU 利用率的提升. 相比 vLLM 提出的 page attention 技术, FastDecode 对于 CPU 的利用进行了更加大胆的尝试. 其不仅利用了 CPU 的内存容量, 还利用了其计算能力和多机扩展能力, 从而达到了提升 batch size, 提升 GPU 利用率的目的, 并实现了端到端的推理吞吐量提升. 背景 在自回归生成过程中做 attention 时, 一个 token i 的特征向量 (feature vector) 会线性映射拆成 Qi, Ki, Vi 三个特征向量....

本检查单适用于在 PACMAN 实验室 安装新的服务器. 对于其它使用场景, 可视情况进行参考. 购买前 根据使用需求确定型号 PCIe 的连接方式是否符合预期 内存通道是否充足 在机房寻找一个合适的位置来放置机器, 需考虑如下因素 机柜的空位与承重能力 电源是否充足 网络 (如需使用 IB 网, 与需要的交换机是否足够近) 根据 CPU arch 确定是否接入某个 slurm 进行管理 现有的 slurm clusters: ja (AMD Epyc), nico (Intel Skylake) 注意: 除非这台机器永远只有一个人使用, 否则强烈建议接入 slurm 进行管理 起一个合适的 Hostname 向网络管理员申请一个合适的固定 ip 机器上架与硬件配置 (机房内) 检查机器完好 正确安装导轨 对机器的整体外观, 序列号进行拍照 插入系统盘和必要的存储, PCIE 设备 注意: 插入额外的 GPU 资产也需要事先对序列号和整体进行拍照 根据分配的固定 IP 配置 BMC 机器基础配置 (可远程) 在 NetBox 上更新相应信息, 包括但不限于序列号, 资产号, GPU 在 BIOS 中配置 CPU Sub-numa Clustering 以确保访存性能正确 Intel 简称 SNC, AMD 简称 NPS 可能在 ACPI 或 North Bridge 选项中 (视型号不同) PXE 引导安装 OS 机器软件配置 安装必要的基础软件 htop iotop iftop vim-common numactl rsync psutils ipmitool g++ 根据 Harry 的教程 配置 LDAP Client 安装 libnss-ldapd 和 libpam-ldapd 配置正确的服务器地址, base dn 和 LDAP 数据项 安装 nfs 客户端 安装 nfs-client nfs-common 挂载对应的 /home 配置 slurm 客户端 安装 libmunge-dev libmunge2 munge slurmd slurm-wlm libpam-slurm-adopt libpam-slurm libpmix-dev libpmi2-0 libpmi0-dev libpmi0 将主节点的 munge key 同步到新机器 /etc/munge/munge....

最近在实验室遇到一些情况必需搞一台 centos 的服务器, 但是还是想给它配置我们常用的一些东西, 于是踩了一些坑, 作一个记录. sshd 在别的端口 我们用这个来提供外网的仅公钥的访问, 然而 cent 里面配了 sshd_config 里的 port 之后竟然没法从别的机器访问到这个 port. 关掉 selinux 也没用, 最后发现需要 disable firewalld. (什么企业级安全) sssd ldap 无法 auth 相比 debian 底下使用 libnss-ldapd 和 libpam-ldapd, cent 下面用的是一个叫 sssd 的玩意. 然后使用 authconfig 来进行配置. 然而配好了之后可以 id 一个用户 , 却不能 getent. 发现需要在 sssd 配置文件里加上这个. enumerate = true 然而还是无法用 ldap 用户密码登录, 一通查发现是因为 SSSD always uses an encrypted channel for authentication, which ensures that passwords are never sent over the network unencrypted....

最近在一些奇怪的地方使用 pytorch. 那里的 python 十分的鬼畜, 以至于 python-debug 用不了. c 的栈打出来大概是这样的. #110 0x00004ffff061c03c in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at ../Python-3.6.8/Python/ceval.c:3351 #111 0x00004ffff061865c in PyEval_EvalFrameEx (f=0x6, throwflag=8387296) at ../Python-3.6.8/Python/ceval.c:754 #112 0x00004ffff06192fc in _PyEval_EvalCodeWithName (_co=0x58000044c980, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=0, kwnames=<optimized out>, kwargs=0x58000d8621b8, kwcount=2, kwstep=1, defs=0x580000449340, defcount=2, kwdefs=0x0, closure=0x0, name=0x5800003431c0, qualname=0x5800003431c0) at ../Python-3.6.8/Python/ceval.c:4166 #113 0x00004ffff0619768 in fast_function (kwnames=<optimized out>, nargs=0, stack=0x58000d8621b8, func=0x58000296f6b8) at ../Python-3.6.8/Python/ceval.c:4992 #114 call_function (pp_stack=0x500000804400, oparg=<optimized out>, kwnames=<optimized out>) at ....

用 gdb 的 py-bt 来看一个 python 程序的调用栈是一个非常有用的工具. 然而今天在集群上尝试使用这个功能的时候发现了一些问题. 使用 debian 12 自带的 python3.11 时可以正常工作, 而使用 spack 安装的 python3.10 的时候就无法工作了. 最初怀疑 configure python 的时候没有带 --withdebug, 于是重新装了一个 python 还是不管用. 然后在仔细观察输出的时候发现 gdb autoload 竟然还有 safe path 一说, 故需要在 .gdbinit 中加入 add-auto-load-safe-path /home/spack/* 才能安全工作. (具体见这篇文档 )

代码地址 这事情好像原理挺简单的. 让 srun 在完成的时候给自己发个邮件, 用个脚本一直 tail 邮件, 并喂到 tg 的 bot 里, 根据 chat id 来发消息.

最近写了一些 mpi 程序, 但是有 bug, 且只有在多机上能够复现. 然而因为工程太大, 编译一次需要时间比较长, 所以反复 print 也并不方便解决问题. 而且集群上也没有图形界面, ssh -X xterm 的方法不太好使. 所以需要一些新的解决思路. laekov 将目光瞄准了 tmux. 用 tmux new-session command 就可以在目标机器上新开一个进程, 跑 gdb. 然而 tmux 并不能继承环境, 所以需要再包一层脚本来重新加载环境 (这倒是和多机跑 mpi 程序差不多). 此外, 为了不需要手工一个一个进程地去 gdb 里开始, 可以用 gdb -ex 'r' --args command args 来让它自动开跑. ex 还可以用来批处理设断点之类的, 非常方便. 另一个问题是 laekov 用的集群配置了 slurm, 是用 srun 来启程序的. 但是 tmux 命令会立即退出, 进程是跑在该用户的另一个进程里的, 而且这俩还没有父子关系, 无法用 wait 来等. 但是 srun 的进程退出之后 slurm 就认为这个进程跑完了, 甚至会清理 worker 上该用户的所有进程....