知乎 - 皮振伟

4 篇内容

个人心得知乎 - 皮振伟

hugetop 诞生记:从实践中来,到实践中去

文章记录了作者为 procps-ng 增加 hugetop 工具的经历,并借此说明系统级开源贡献通常源自真实工作痛点。前半部分先解释 procps-ng 作为 Linux 基础工具集为什么新增命令门槛极高:必须是通用需求,还要兼容多架构、多内核版本以及各种边缘异常。随后作者以大页内存观测为例,指出过去需要在 /proc/meminfo、/sys/ 节点目录和 /proc/PID/smaps 之间来回切换,排障成本高且容易出错。基于自身在内核、虚拟化和高性能场景中的需求,他实现了 hugetop,提供 NUMA 维度和进程维度的大页可视化,并最终通过上游评审合入正式版本。文章的核心结论是:有价值的开源贡献不必等到“万事俱备”,从自己遇到的问题出发,把方案做成通用、稳妥的工具,再回到实践中验证其价值,才更容易形成可持续的公共收益。

推荐收录,因为正文给出了一个具体、可复用的开源贡献案例:从大页观测痛点出发,最终把个人脚本问题升级为上游通用工具。适合想参与 Linux/开源社区、做系统工具或从实践提炼需求的读者参考。

个人心得知乎 - 皮振伟

一个“外行人”与Redis/Valkey的六年

文章回顾作者从 Linux 内核、KVM 和存储虚拟化背景切入 Redis/Valkey 社区的六年经历,强调自己并非缓存数据库“专家”,却能借助外行视角持续发现内核、网络与数据库之间的协作点。前半部分列举了线程命名、CPU 亲和性、THP 开关和 LTTNG trace 等改动,说明这些功能如何帮助观测、隔离和排查长尾延迟。后半部分重点讲述 Valkey Over RDMA 与 Valkey Over MPTCP:前者围绕 RESP3 与 RDMA 消息语义的适配、连接抽象层改造和上游合入,验证了高性能网络可带来约 2.5 倍性能提升;后者则面向跨机房同步与多路径容错完成了客户端、服务端和工具链适配。文章也交代了从 Redis PR 长期无回应到 Valkey 社区推进落地的过程,并记录了社区协作、测试验证和发行版打包的推进路径。整体更像一篇带有技术细节的开源成长记录,适合想参与基础设施和数据库开源项目的读者参考,但方法论总结偏经验化而非系统化教程。

推荐收录,因为文章给出了从“外行”切入核心开源项目的具体证据:RDMA、MPTCP、THP、LTTNG 等改动都落到可验证的代码与性能结果上。对想参与基础设施开源、做跨层性能优化或理解社区协作流程的读者,具有可迁移的实践参考价值。

工程实践知乎 - 皮振伟

漫谈AI推理与存储

这篇文章围绕 AI 推理中的存储需求展开,重点分析了模型权重加载、KV Cache 的数据形态、外部存储布局,以及单机和分布式场景下的 IO 路径选择。作者把 LLM 推理中的启动延迟、GPU 空转、缓存共享、存储分层和成本控制串成一条完整链路,并系统比较了 mmap、GDS、Direct IO、RDMA、NVMe-oF、对象存储等方案的适用边界。最后,文章结合自研 GD2FS 和若干实测数据,提出了面向推理场景的 GPU 直连分布式存储架构,但也明确这些优化高度依赖数据对齐、缓存形态和具体工作负载。

推荐收录,因为它不是泛泛谈“AI 存储”,而是从推理引擎的数据特征出发,逐层分析了存储栈、网络栈和 GPU 直连路径的取舍,具有很强的工程可迁移性。文中还给出了自研系统和实测结果,适合做 AI 基础设施、推理优化和分布式存储方向的长期参考。

工程实践知乎 - 皮振伟

LLM分布式推理终极方案——以GPU为中心的云原生架构

文章围绕 LLM 推理部署中 KV Cache 依赖带来的扩缩容困难、命中率波动、内存冗余和成本不透明等问题,提出以 GPU 为中心、通过 GD2FS 这类分布式文件系统承载 L2 缓存的无状态化推理架构。作者进一步用 Kubernetes 的弹性调度类比互联网后端演进,说明显式 KV Cache、零拷贝数据路径、预读分层缓存和可调副本策略如何提升资源利用率、降低主机内存占用,并给出了一组 RDMA/TCP 与多节点推理测试数据作为支撑。文章的主要边界在于:它更像一篇面向落地的架构提案与实践总结,部分性能结论需要结合具体硬件、负载和实现细节理解,不能直接泛化到所有推理场景。

推荐收录,因为它不是单纯讨论 LLM 推理概念,而是把缓存层级、调度弹性、状态管理和存储协议放到同一套架构框架里分析,具备较强的工程可迁移性。对做大规模推理平台、云原生基础设施和 GPU 资源调度的读者来说,这篇文章能提供有参考价值的设计思路、性能指标视角和权衡点。