25 篇
1 个三级分类
三级分类
技术笔记整理
技术体系化整理、工程实践与开发笔记。
专题分组
二级专题与三级分类
39 篇
2 个三级分类
19 篇
3 个三级分类
42 篇
2 个三级分类
12 篇
2 个三级分类
26 篇
3 个三级分类
1 篇
1 个三级分类
三级分类
当前页继续展示这个根分类下的全部文章；上面的二级专题和三级分类用于快速定位更细的主题入口。
计算机网络6 分钟
ping 延迟、三次握手、 TLS/SSL 握手 延迟
这篇笔记围绕网络请求中的 RTT 成本展开，用 ping 返回的 time=44ms 说明它表示从发出到收到回复的完整往返时间，系统不会把结果除以二来显示单程延迟。正文先从广州到北京的光纤传播估算切入，指出即使理想直连往返约 22ms，真实链路还会受到骨干路由跳数、线路绕行以及电光转换等因素影响，因此 44ms 中包含明显的网络损耗。随后文章用时间线拆解 TCP 三次握手，强调真正阻塞客户端继续发送数据的是等待 SYN-ACK 返回的 1 个 RTT，第三次 ACK 不必等服务器收到后才进入下一阶段。对于 HTTP 请求，第三次 ACK 可以和 HTTP 数据捎带发送，因此一次未加密请求可近似理解为 TCP 建连 1 个 RTT 加请求响应 1 个 RTT。对于 HTTPS，请求在 TCP 之后还要完成 TLS/SSL 协商，TLS 1.3 通常再消耗 1 个 RTT，TLS 1.2 可能更多，所以 HTTPS 最快约为 3 个 RTT 加服务器处理时间。文章也说明四次挥手通常不计入一次请求的可感知耗时，因为业务代码拿到 response 时关键路径已经结束，断开连接多在后台完成，适合需要估算接口首包延迟、理解 TCP/TLS 建连成本的后端和网络学习者阅读。
4 分钟
Python 异步编程 async 处理规则
这篇笔记围绕 Python 异步服务中哪些操作该 await、哪些不能指望 async 加速这一边界展开，适合在 FastAPI 等事件循环模型下处理接口、数据库、缓存、对象存储和本地计算任务的开发者参考。文章先强调网络 I/O 本身不消耗 CPU，调用 OpenAI、数据库、Redis、S3 等等待型操作时，应使用 httpx、asyncpg、motor 等异步库并显式 await，让主线程在等待网络返回时继续处理其他请求。随后区分 CPU/内存密集任务：Pandas 处理 Excel、视频转码、哈希计算或超长循环即使写进 async def，也仍会占用主线程并卡住 Event Loop，协程语法不会把单线程计算变成并行计算。针对这类阻塞，文章给出两类“扔到池子里”的处理方式：优先用 asyncio.to_thread 或线程池释放事件循环，尤其适合 Excel 解析、图片处理和许多 Pandas/Numpy 操作，因为其底层 C 实现可能在重计算或 I/O 时释放 GIL。对于纯 Python 重计算，文中建议使用 ProcessPoolExecutor 绕开 GIL，但同时提醒进程创建、序列化传输和无法共享内存都会带来更高成本。最后还提供了一个 AsyncWrapper 示例，用 __getattr__ 将同步厂商 SDK 方法统一包装成 await asyncio.to_thread(...) 的异步调用形式，用较小线程切换开销换取异步服务对旧同步接口的兼容。
4 分钟
自用 VPS 配置 github action self-hosted runner
这份配置记录聚焦在自用 VPS 上部署 GitHub Actions self-hosted runner，并按“中心安装包 + 项目独立运行目录”的方式管理多个仓库。目录设计把 runner 压缩包统一放在 `/root/github-runners/package/actions-runner.tar.gz`，只需从 GitHub releases 下载一次，后续项目如 `go-react-prod`、`new-api` 都从该位置解压，避免重复下载和混用运行文件。首个项目配置时，需要创建专属目录、解压安装包，并在以 root 用户运行的 VPS 上先设置 `RUNNER_ALLOW_RUNASROOT=1`，再执行 `config.sh` 绑定仓库；如果 GitHub 页面生成的 token 过期，则要重新复制新的 token。运行方式上不建议直接执行 `./run.sh`，而是通过 `./svc.sh install root`、`./svc.sh start` 和 `./svc.sh status` 将 runner 安装为 root 用户下的系统服务，保证后台持续运行。新增仓库时重复建目录、复用压缩包、使用对应仓库 URL 和新 token 配置，再安装并启动服务即可。最后在 GitHub Actions workflow 中指定 `runs-on: self-hosted`，任务就能调度到这台 VPS，适合希望用个人服务器承接构建或部署流程的开发者。
7 分钟
CPU 跑 Rerank 太慢？一个脚本开启 INT8 量化，性能大幅度提升！
面向企业级 RAG 系统中在 CPU 服务器部署 HuggingFace text-embeddings-inference Rerank 的场景，内容聚焦默认 FP32 ONNX 模型推理慢、CPU 利用率不高的问题。文章先用 FP32 与 INT8 的数据宽度差异解释瓶颈来源：全精度权重占用更多内存带宽和计算资源，而 Rerank 更关注排序相对结果，适合通过量化降低推理成本。随后结合 AMD EPYC、Intel Xeon 等现代 CPU 的 AVX-512/VNNI 能力，说明 INT8 在 SIMD 并行吞吐和内存占用上的优势，并给出理论上更高并发处理能力的原因。实践部分提供了基于 optimum.onnxruntime 的动态量化脚本，将 bge-reranker-v2-m3 的 FP32 ONNX 文件转换到 quantized 目录，并使用 avx512_vnni 配置面向 CPU 推理优化。脚本中特别处理了 TEI 启动所需的 tokenizer、config 等文件复制，以及将 model_quantized.onnx 重命名为 model.onnx 的兼容性细节。最后只需在 docker-compose.yml 中把 rerank 模型挂载路径切换到 quantized 目录，TEI 镜像无需更换即可加载 INT8 模型，适合需要在现有 CPU 资源上提升 Rerank 吞吐的 RAG 开发和运维人员参考。
7 分钟
tei-rerank 部署重排模型bge-reranker-v2-m3
这份记录聚焦在用 Hugging Face Text Embeddings Inference 的 CPU 镜像部署 BAAI/bge-reranker-v2-m3 重排模型，场景是为检索结果增加一个独立的 rerank 服务，而不是普通 embedding 服务。流程先通过 snapshot_download 将模型完整下载到本地目录，再安装 optimum、onnx、onnxruntime，并用 ORTModelForSequenceClassification.from_pretrained(export=True) 将 PyTorch 模型导出到模型目录下的 onnx 子目录，同时保存 tokenizer。docker-compose 配置的关键点包括使用 ghcr.io/huggingface/text-embeddings-inference:cpu-1.5，挂载本地模型目录到 /data/rerank，开放 38190:80 端口，并通过 --model-id 指向容器内路径，配合 --auto-truncate 和 --dtype float32 启动服务。文章特别强调 shm_size: 1g 的必要性，因为 Docker 默认共享内存只有 64MB，AI 推理程序在并发或大矩阵数据传输时可能因共享内存不足直接 Bus error 崩溃。最后用 /rerank 接口测试“我想买一个手机”与三星、苹果、联想笔记本三段文本的相关性排序，结果显示手机相关文本得分约 0.3，而笔记本得分接近 0.0001。读者可以从中获得一套可复现的 TEI rerank 部署步骤，并理解重排模型更应关注候选项之间的相对差距和排序效果，而不是孤立解读绝对分值。
2 分钟
本地部署 ollma+ qwen 7B大模型
这是一份面向本机 Docker 环境的 Ollama 部署记录，目标是在本地启动可调用的 Qwen2.5 大模型服务，并通过接口验证生成能力。正文给出 docker-compose.yml 的核心配置，包括 11434 端口映射、./ollama_data 持久化模型数据、容器自动重启，以及 OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS、OLLAMA_ORIGINS 等运行参数。资源部分显式限制容器最多使用 18G 内存，同时用常驻内存、4 路并发和最多加载 2 个模型来平衡响应速度与本机资源占用。模型操作通过 docker exec 进入 ollama 容器执行 ollama run qwen2.5:7b，也补充了 qwen2.5:14b 的可选尝试，并提示 14B 的 4bit 量化大约需要 9GB 内存。文章还区分了模型文件存放在硬盘与按请求 model 参数加载到内存的行为：请求 7B 会加载 7B，请求 14B 时可能卸载 7B 再加载 14B。最后用 curl 调用 http://localhost:11434/api/generate，指定 qwen2.5:7b、prompt 和 stream 参数，作为部署是否可用的最小验证，适合需要快速搭建本地中文大模型 API 的开发者参考。
7 分钟
搭建tei-embedding 与配置bge-m3 文本模型
这篇笔记聚焦于将 BAAI/bge-m3 文本向量模型部署为本地 Hugging Face TEI embedding 服务，适用于需要离线或内网提供语义向量接口的检索、RAG 和相似度计算场景。流程先用 huggingface_hub 的 snapshot_download 下载模型到指定绝对路径，并特别设置 local_dir_use_symlinks=False 以保存真实文件，同时启用断点续传，避免 Docker 挂载后因软链接或缓存路径导致模型不可用。部署部分给出 Docker Compose 配置，使用 ghcr.io/huggingface/text-embeddings-inference:cpu-1.5 镜像，将宿主机模型目录挂载到容器 /data/bge-m3，并通过 --model-id 指向该路径触发离线加载。配置中还清空代理环境变量、设置 no_proxy=*，并指定 cls pooling、最大客户端 batch size 为 32、dtype 为 float32，强调在 CPU 版本下以稳定可用为目标。验证环节先通过 curl 调用 127.0.0.1:8080/embed，若返回一组浮点向量即可确认容器、端口、模型加载和推理链路正常；若出现 Connection refused，则优先检查容器是否启动和端口映射。最后用 requests 调用接口、NumPy 计算三句话向量的余弦相似度，结果显示“男人吃苹果”和“吃水果”的相似度高于与“天气”的相似度，从语义区分能力上确认服务可用于后续文本向量化任务。
1 分钟
ubuntu 使用 Miniconda
这份笔记记录了在 Ubuntu 64 位环境中安装和初始化 Miniconda 的最小流程，适合需要为 Python 项目隔离依赖、但不想安装完整 Anaconda 的用户。正文先给出通过 wget 下载 Miniconda Linux x86_64 安装脚本、再用 bash 执行安装的命令，覆盖了从获取安装包到启动安装器的基本入口。安装完成后，作者特别建议关闭默认自动进入 base 环境，并使用 conda config --set auto_activate_base false 避免 shell 启动时污染全局命令行环境。由于 Anaconda 更新了服务条款，笔记还补充了通过 conda tos accept 分别接受 pkgs/main 和 pkgs/r 官方频道条款的命令，否则后续下载包可能受阻。环境管理部分以运行 Ollama 脚本或 Milvus Python 代码为例，建议创建名为 ai_tools 的 Python 3.10 环境，并给出创建、激活、退出和查看已安装包的常用命令。这更像是一份快速备忘清单，重点在可直接复制执行的配置步骤，适合 Ubuntu 上进行 AI 工具、向量数据库或其他 Python 实验项目的开发者参考。
AI 大模型开发11 分钟
部署milvus 向量数据库与可视化attu
这份笔记记录了用 docker-compose 搭建 Milvus Standalone 向量数据库及 Attu 可视化界面的完整过程，场景是已有或单独部署 MinIO 后，将 Milvus、Etcd、Attu 接入同一个外部 Docker 网络。配置部分分别给出 MinIO 的端口、数据卷和 root 账号密码设置，以及 Milvus v2.5.0 连接 Etcd、外部 MinIO、指定 bucket、暴露 19530 与 9091 端口的 compose 示例，同时提醒需要按实际情况修改 MINIO_ACCESS_KEY_ID 和 MINIO_SECRET_ACCESS_KEY。文章特别记录了启动时因鉴权配置导致报错的处理路径：先 down 掉容器、删除旧 milvus.yaml，下载官方 v2.5.0 配置文件后将 authorizationEnabled 从 false 改为 true，再重新 docker compose up -d。Attu 通过 MILVUS_URL 指向 standalone:19530，并将 Web UI 映射到 8000 端口；Milvus 开启鉴权后的默认账号为 root，默认密码为 Milvus，登录后可在界面中修改密码。后半部分用“计算中心、对象仓库、元数据记账本、前台界面”的分工解释 milvus-standalone、MinIO、Etcd 和 Attu 的职责，强调向量数据与索引主要落在 MinIO，集合结构和文件归属依赖 Etcd。它适合需要快速搭建本地或服务器端向量数据库实验环境、并希望理解各容器依赖关系和持久化风险的开发者参考。
3 分钟
Github Action 官方托管 与自托管区别
这篇笔记围绕 GitHub Actions 的官方托管 Runner 与 Self-hosted Runner 做取舍说明，重点回答默认机器规格、是否自动扩容、计费方式和运行环境差异。官方 Linux 标准 Runner 通常是 2 vCPU、7GB 内存、14GB SSD，Windows 标准环境也接近 2C7G，macOS 规格相对更高；这些资源不会随构建负载动态增加，任务内存不足时会失败，只有手动选择并付费配置 Larger Runners 才能提升规格。Self-hosted Runner 不消耗 GitHub Actions 每月分钟数，即使长期运行也不会在 GitHub 侧产生分钟账单，但服务器、网络和维护成本需要自行承担。对比部分指出，官方 Runner 每次任务结束后销毁虚拟机，环境纯净、维护成本低，更适合公开仓库；自托管环境持久，能保留 Docker 镜像、node_modules 等本地缓存，构建速度可能明显提升。代价是需要自己安装和维护 Docker、Git、系统环境，并定期清理磁盘，否则容易被缓存和镜像占满。安全边界尤其关键：公开仓库不应随意使用自托管 Runner，因为恶意 PR 可以修改执行脚本并控制服务器；而在内网集成测试、访问私有资源或需要自定义并发能力的场景，自托管才更有优势。