waterdropw 的博客

基于源码调试过程，以及如下两篇文章整理。 This repo is line by line walk through of the inference file in llama2.c. Its very verbose & intended for beginners.You will need some familiarity with transformers architecture. If you are a complete novice refer to this excellent blog first. RahulSChandcllama2.c-for-dummies The Illustrated Transformer。 jalammarillustrated-transformer llama2.c 包含了训练代码和推理实现，作者提供了如下几个预训练模型，可以直接运行 run 这个demo程序生成一个简短的小故事。 model dim n_layers n_heads n_kv_heads max context length paramet ...

与早期版本（详情可以参考这里：4e23ad8 23'7/27）不同，目前的版本有两种模式，一是generate， 根据给定的prompt生成一个简短的英文小故事。二是chat， 需要输入system prompt和问题，生成一个回答并退出，没有多轮对话，并且回答与问题没有太大关联性而且有不少问题（尤其是15M模型），所以该模式还不完善，并且有一个 feature/chat 分支处于开发中有兴趣可以关注该分支。我们主要关注代码更新的部分。 执行流程该版本代码进行了重构，sampler封装到结构体里，其次把分阶段的执行流程各自封装到函数里面，调用逻辑会更清晰一些。同样的，main主要处理命令行参数，然后是模型推理流程。 main 执行流程 解析命令行参数，包括 checkpoint 文件路径, temperature, steps等。 调用build_transformer，会调用read_checkpoint加载checkpoint 文件内容，包括模型配置和权重。其次调用malloc_run_state初始化运行时变量，包括kv cache等。注意，这里没有再 ...

大模型因为参数量巨大，即使是Finetune也只能在多卡GPU的机器上训练（全精度），如果是A100 8卡40GB机器，用上DeepSpeed的各种优化之后勉强能训3B模型，7B模型训不了，必须要多机多卡才行。这里记录一下早期探索，使用裸机环境配置多机多卡来跑大模型训练遇到的一些问题。 多机多卡训练需要一个高效的通信框架来协调多个设备之间的数据传输和计算任务。常见的通信框架包括MPI、NCCL等。同时，多机多卡训练还需要一些额外的技术支持，如数据并行化、模型并行化等，以便将计算和存储任务分配到不同的设备上。 虽然多机多卡训练可以大大加速深度学习模型的训练速度，但也面临一些挑战，如设备故障、通信延迟等。因此，在应用多机多卡训练时需要谨慎选择合适的硬件设备和软件工具，并进行充分测试和优化。 测试一环境配置两台主机加入 swarm worker，docker 指定overlay network 容器启动之后，需要手动启动ssh 1/etc/init.d/ssh start 运行 DeepSpeed-chat 多机训练 1NCCL_DEBUG_SUBSYS=ALL NCCL_IB_DIS ...

LLaMA: Open and Efficient Foundation Language Models，是一个包含了 7B ~ 65B 参数量的基础语言模型集合。并且仅仅在公开数据集上训练，T级别的数据量，可以达到Sota 水平。 对于要达到的模型性能，最好的模型并不是训练起来最快，而是推理起来要最快，这样才能节省部署成本。比起快速训练一个大模型，利用更长时间来训练一个小模型，能获得更好的推理性能。我们发现用 1T tokens 训练 7B 模型可以达到的性能，比用 200B tokens 训练一个 10B 的模型还要好。 这项工作的重点是使用更多的训练数据，在不同的推理预算内训练一系列模型，使其达到最佳性能，并且对比现有的 LLMs 的性能。比如 LLaMA-13B 在大多数benchmarks 测试中性能优于 GPT-3，而参数量减小了 10x 以上。LLaMA-65B 模型则可比肩目前最好的大模型如 Chinchilla、PaLM-540B。 训练方法预训练数据预训练数据如下表：除了Wikipedia & Books 用了2个epoch，其它都只用了1个epoch ...

Android NDK 有一些巨坑，编译链接没什么问题，运行时出错，而且非常难查。比如声明有返回值的函数实现漏写return语句， 会导致函数调用之后跑飞，x86不会有问题。最近遇到另外一个巨坑，采用静态链接第三方库，如果有同名函数，即使是函数签名不同，函数实现会被覆盖，也就是调用到的是第三方库实现，本地实现被覆盖掉, OMG~~~~ 编译环境：Host： MacOSTarget: Android NDKr20ToolChain: bazelLink: Static Library 动态链接会报同名函数重定义错误~~ 该问题仅限于静态链接 本地函数声明如下， 123456789101112#ifdef __cplusplusnamespace libfcc {extern "C" {#endifLIBFCC_APIint I420ToNV12(const u8 *src_i420, u8 *dst_nv12, int width, int height);#ifdef __cplusplus} // extern "C& ...

我们也把 Camera 拆分成 三驾马车 来看：App Framework, CameraService, Camera HAL 前面两个是 Android AOSP 代码，随着 Android 系统升级会持续更新，包含在 system.img 里面，同时 Java 部分接口也会包含在 Android SDK 一起发布。 随着 Android 8.0 的 Treble 架构发布，相当于是把三驾马车里面的前两架放到了 system.img 里面，一起随着 Android 系统升级更新，而最后一个则独立拆分出来，不仅仅是放到了新的进程里面，而且在手机系统上要求放到 vendor 分区，这样可以各自独立升级。 三驾马车先附上 Google 官方图例： App Framework 部分是最上层部分，包括 Java & C++ 代码，实现了 Android Camera2 API 接口，提供给 android 应用使用，Java 部分包含在 Android SDK 里面。 source tree Java 实现： https://android.googlesour ...

如前述文章所述，Google 在 Android P 上提供了对 usb camera 设备的支持，官方叫法是 External USB Cameras ，提供了完整 HALv3 实现并接入到 CameraProviderManager；可以让任何三方相机应用轻松调用到外接 USB 摄像头功能，而且使用方法跟内置相机几无差别，都是透过 Android Camera API2 调用。 遗憾的是该功能默认关闭，并且 OEM 厂商大概率也会去改 AOSP 代码，比如 multi-caemra，SAT 等功能的实现，有可能会对其造成影响。 这篇文章详述如何开启 Android 手机上原生支持 USB 外接摄像头这个功能。因为底层走 V4L2 接口，所以支持 UVC 驱动的视频设备都能支持，包括常见的单反，微单，PC 机用的 usb 摄像头，网络摄像头等等，应用非常广泛。 目前看网络上还没有这方面的相关资料，一些嵌入式设备可能有类似的功能实现 (基于 Linux 或 Qt)，基于 android 系统开发的也有可能是直接使用这套方案的。当然也可以实现自己的 HAL 模块并接入 Android C ...

Android 设备基于 linux kernel, 自带 V4L2 支持，但是 OEM 厂商实现不同，大多默认关闭该功能。所以一般开发者或终端用户想要在 Android 设备上使用 usb camera 不是一件容易的事情。 这里简单介绍几种针对开发者来说，可选择的实现方案. 基于 libuvc 开发libuvc 是一个跨平台开发库，基于 libusb，功能包括 UVC 设备识别与控制，视频流传输，视频流格式转换等。 Android 平台上已有一个 Usb Camera 的开源项目，基于 libucv 的Android 应用，UVCCamera 无需 root 权限即可预览显示连接到手机的 usb camera 设备。 libuvc 官网介绍： libuvc is a cross-platform library for USB video devices, built atop libusb. It enables fine-grained control over USB video devices exporting the standard USB Video Cla ...

camera.v4l2 实现了 Camera HALv3 接口，底层调用了 Video For Linux 2(V4L2)，因此适用范围比较广泛，可以适配兼容 V4L2 接口的所有设备。不过相对于 Android Camera 来说，V4L2 存在一些局限性，内置相机具备的一些功能可能不支持，但对于大多数应用场景来说，是没有问题的。 这篇文章根据官方介绍，结合实践经验来介绍一下 camera.v4l2 的一些特性。有空再补充一些细节~ 当前状态camera.v4l2 可以自由使用，但是它不是由 Android Camera team 官方维护的， 实际上官方维护的是另外一个随着 Android P 一起更新发布的实现：External USB Cameras 该 HAL 实现在现有 Android 系统默认是关闭的，不会编译到系统里面。可以按照如下方式打开 编译方法修改 .mk 文件，增加如下配置： 123USE_CAMERA_V4L2_HAL := truePRODUCT_PACKAGES += camera.v4l2PRODUCT_PROPERTY_OVERRIDES += r ...

Android Camera HAL 作为 Framework 层 Camera2 API 接口与底层硬件实现的桥梁，起着承上启下的作用。另外从 Android 8.0 开始使用了新的 Treble 架构（HAL 接口与实现代码在 hardware/interfaces/camera/），舍弃了原本旧的架构实现（Legacy HAL: hardware/libhardware/modules/camera/）。 Legacy HAL 当前还保留的内容： hardware/libhardware/include/hardware/camera*.h, Camera Hal 接口定义，持续更新 hardware/libhardware/modules/camera/3_0/, camera.default Legacy 默认实现 hardware/libhardware/modules/camera/3_4/, camera.v4l2 非官方实现（树莓派）0 截止目前最新版本是 HALv3，高端机型基本上都支持。Camera HAL 属于相对比较复杂的一个硬件模块，随着硬件模组的发展， ...