Month: October 2024

试用 Llama-3-8B-Instruct AI 模型

2024-10-30 | 阅读(40)

IT 从业人员累的一个原因是要紧跟时代步伐，甚至是被拽着赶，更别说福报 996. 从早先 CGI, ASP, PHP, 到 Java, .Net, Java 开发是 Spring, Hibernate, 而后云时代 AWS, Azure, 程序一路奔波在掌握工具的使用。而如今言必提的 AI 模型更是时髦，n B 参数, 量化, 微调, ML, LLM, NLP, AGI, RAG, Token, LoRA 等一众词更让坠入云里雾里。

去年以机器学习为名买的(游戏机)一直未被正名，机器配置为 CPU i9-13900F + 内存 64G + 显卡 RTX 4090，从进门之后完全处于游戏状态，花了数百小时对《黑神话》进行了几翻测试。

现在要好好用它的 GPU 来体验一下 Meta 开源的 AI 模型，切换到操作系统 Ubuntu 20.04,  用 transformers 的方式试了下两个模型，分别是

  1. Llama-3.1-8B-Instruct: 显存使用了 16G，它的老版本的模型是 Meta-Llama-3-8B-Instruct(支持中文问话，输出是英文)
  2. Llama-3.2-11B-Vision-Instruct: 显存锋值到了 22.6G(可以分析图片的内容)

都是使用的 torch_dtype=torch.bfloat16, 对于 24 G 显存的 4090 还用不着主内存来帮忙。如果用 float32 则需更多的显存，对于 Llama-3.2-11B-Vision-Instruct 使用 float32, 则要求助于主内存，将看到

Some parameters are on the meta device because they were offloaded to the cpu.

反之，对原始模型降低精度，量化成 8 位或 4 位则更节约显卡，这是后话，这里主要记述使用上面的 Llama-3.1-8B-Instruct 模型的过程以及感受它的强大，可比小瞧了这个 8B 的小家伙。所以在手机上可以离线轻松跑一个 1B 的模型。 阅读全文 >>

ECS Task Definition 中需要的 image:tag 明明在 ECR 中存在却找不到 image

2024-10-17 | 阅读(12)

这是近些天遇到的一个问题，因为早先使用 ECS 为求快速验证新的 Docker Image, 一直是用相同的 Tag 覆盖 ECR 中原有的 Docker Image，然后停掉 ECS 中相应的 Task, 新的 Task 起来，拉取最新 Docker Image，这样不用重新部署 Infrastructure, 以最小的改动就能达到偷梁换柱的效果。比如下面的情景：

  1. ECS 任务定义中所用的 Image 是 123456789012.dkr.ecr.us-east-1.amazonaws.com/demo:1.10
  2. 构建新的 Docker Image, 然后再 docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/demo:1.10
  3. 覆盖后，在 ECR 中将有两个 Tag,  刚 push 的是 1.10, 被覆盖的变成 -, 多次覆盖将会产生更多的 -
  4. 停掉 ECS 相应的 Task, 新的 Task 起来，拉取 123456789012.dkr.ecr.us-east-1.amazonaws.com/demo:1.10 代表的新镜像

这种做法在以前是灵验的，每次修改代码，覆盖现有 Tag, 重启 Task 就能快速测试, 不用重新创建 Task Definition 和别的 Infrastructure。

然而最近突然不起作用了，本地不断的修改代码，构建新的镜像，覆盖原有 Tag, 重启 Task, 可是依旧跑的是老代码。怀疑 ECR 中的 Image 有问题，用 docker pull 下来看确实是新代码，就差进到 ECS Task 实例中去找问题。而且即使是重新运行 Terraform 来部署整个 Infrastructure 都无济于事，就是 aws_ecs_service 中指定了 force_new_deployment = true 也没辙，因为只要 Docker Image 的 Tag 没变,  Terraform 就认为是 no change。 阅读全文 >>

Python logging 使用笔记

2024-10-16 | 阅读(22)

使用 Python 的话用不着像 Java 那样是考虑用 Logback  还是 Log4J 的问题，因为它内置提供了完备功能的 logging 库。虽然 JDK  也有 java.util.logging(JUL), 它的特性其实也不差，如日志级别，输出格式，不同的输出目的地的选择，但在 Logback 和 Log4J 的光环之下几乎无人问津。相比而言 Python 的 logging 却极为受宠，非必要时基本不会去考虑引入第三方的日志库，如 Loguru, LogBook, Structlog, Picologging, 尽管它们也很出色，毕竟是庶出。

logging 的最基本用法

在基本前面加是最 字，是因为这一节仅仅是如何让 logging 作为 print() 的替代品，暂不涉及到参数的传递，异常的输出，以及格式定制，日志往哪里输出的问题。

运行，什么也看不到，因为 Python logging 的默认级别是 warning, 这不符合人的基本认知，一般 logging.info() 起码是用来替代 print() 的，居然直接用无法输出，不知该库的设计者是怎么个想法。 阅读全文 >>

多线程环境中使用 Mockito 来 Mock 静态方法

2024-10-10 | 阅读(43)

回看三年前的一篇日志 Mockito 3.4.0 开始可 Mock  静态方法，最后对 Mockito 产生的缺憾是它无法用来 Mock 非测试线程(主线程)中的静态方法调用。其实这也是可以变通的，下面慢慢道来。

首先回顾一下 Mockito  的静态方法 Mock 的使用方法，随着 Mockito 版本的升级，引入依赖的方式也发生了些许的变化，以 Maven 项目为例，如果在 JUnit 5 下用 Mockito 的 pom.xml 依赖中为

由它引入的全部相关依赖

阅读全文 >>