V2EX › nakroy 的所有回复 › 第 1 页 / 共 2 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2

❮

❯

2025 年 12 月 12 日

回复了 nakroy 创建的主题 › 程序员 › 请教各位大佬，有没有合适的文档管理系统推荐

@astu 我们后面使用了一个叫 Pydio Cells 的开源 DMS ，https://github.com/pydio/cells ，支持使用 k8s helm 部署和管理，在线访问 office 使用的是开 OnlyOffice 的容器，然后 Pydio Cells 里面接入 OnlyOffice ，打开 office 文档的时候自动跳转到 OnlyOffice 的编辑界面。
这个开源 DMS 功能比较完善，UI 界面也比较现代化，是用 GO 语言写的，所以性能上比 nextcloud 强。但是因为是开源，所以开源不稳定偶尔出 bug 的情况也是不可避免的，这时候一般只能求助 Pydio Cells 的论坛了，版主回复还是挺积极的。

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@mightybruce 好的兄弟，我去看看

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@mightybruce 我现在有 4 台 910B 的机器做测试，不纠结分布式存储那直接用本地为每一个模型分片存储确实成本最低。因为训练场景不多，主要还是推理场景。但是华为的人推的方案就有提到搭配他们的存储产品，所以不知道和传统的分布式存储有啥区别

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@mhycy 好的，了解了。那看来对于集群场景，使用专门的存储节点确实不是必须的

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@mightybruce 所以实际模型权重一直保留在内存里，需要的时候直接加载到 GPU 上？这里的内存是指存储节点的内存，而不是计算节点的内存，例如 GPU 节点能直接读取存储节点内存上的模型参数加载到 GPU 上，而不是先加载到 GPU 节点的内存上，然后再从 GPU 节点的内存上再加载到 GPU 节点的 GPU 上？

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@mightybruce IB 和 RDMA 技术有过了解，英伟达就有专门的配套用 IB 交换机的网络方案，但是一般的客户根本玩不起，而且我这里根本没说每次加载都从磁盘加载，而是考虑到 GPU 节点首次需要使用存储的模型权重或者数据集时可能的读写性能瓶颈，如果你一次全部把所有模型所有数据全加载到内存上一直用，也不用导出到磁盘作存储，那你无敌了

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@sampeng 就是传统的分布式存储无法满足大模型场景的读写性能，应该有专门针对大模型场景 I/O 优化的硬件软件方案

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@paopjian 因为很多情况下，机器可能需要加载多个模型而不只是一个模型，或者如果单个模型非常大，假设你要使用多个机器去加载，占用的存储空间还是很大的，每个节点都为每个模型备份一次，就显得比较繁琐。当然我这里还没讨论到千卡万卡规模的集群，我认为这种级别的集群也是使用分布式存储的，只是因为是商业方案不会公开这些架构细节

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@paopjian 也就是直接把模型加载到存储节点的内存，然后让其他节点通过光纤直接读存储节点内存的数据？

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@fcten 考虑到同步的问题，例如同时用多个 GPU 节点做微调和训练，从集中的存储系统读取和存储而非每个节点都存储 checkpoint 副本，如果数据集很大，也不会考虑每个节点都存这个数据集

2024 年 10 月 25 日

回复了 nakroy 创建的主题 › 程序员 › AI 大模型的分布式存储方案

@zhlxsh 存储系统读写性能大概要多高才行呢？

2024 年 10 月 17 日

回复了 xyyandxyy 创建的主题 › 问与答 › 求推荐云盘或其他方案用于分享数据集(2T)

既然都开源了，那可以放在 huggingface 上，国内可以用同步的镜像站 hf-mirror.com 下载，很适合直接在服务器上用 huggingface-cli 命令行直接下载

2024 年 10 月 15 日

回复了 nakroy 创建的主题 › 云计算 › 本地集群的 LoadBalancer 方案

@ZxykM 这个算是很成熟的方案了，成本也比较低，直接用硬件负载均衡应该是大型公司才会考虑的

2024 年 10 月 15 日

回复了 nakroy 创建的主题 › Kubernetes › 本地裸金属集群的 LoadBalancer 方案

@wangyzj 感觉开源的 LoadBalancer 项目 git star 数都不多，可能大部分人不会用这种方案做 LoadBalancer

2024 年 10 月 15 日

回复了 nakroy 创建的主题 › Kubernetes › 本地裸金属集群的 LoadBalancer 方案

@nuII 几个开源的方案基本都是跟 k8s 集群耦合的，如果是直接硬件负载均衡和独立于集群之外的一层框架可能确实更好（应该是基于你们专业人士的实践得出的结论）

2024 年 10 月 15 日

回复了 nakroy 创建的主题 › Kubernetes › 本地裸金属集群的 LoadBalancer 方案

@wangyzj 所以高可用场景的做法都是将 LoadBalancer 独立于 k8s 集群之外的一个框架吗？“haproxy+keepalive+nodeport” 这个方法也提到过很多，之前有留意过

2024 年 10 月 15 日

回复了 nakroy 创建的主题 › 云计算 › 本地集群的 LoadBalancer 方案

@ZxykM 我对比了 MetalLB 、PureLB 、OpenLB 和 kube-vip 方案，前三个部署和使用比较方便，第四个部署比较麻烦（高可用要先于 k8s 集群部署，属于集群之外），由于我的路由器不支持 BGP 模式，所以我只能参考 layer2 的模式，对比这几个的 layer2 模式的性能。另一个回复中提到了 haproxy+keepalive+nodeport 的方案，也是独立于 k8s 集群之外的一层 LoadBalancer ，可能这种做法可靠性更高

2024 年 10 月 13 日

回复了 nakroy 创建的主题 › Kubernetes › 本地裸金属集群的 LoadBalancer 方案

@Qetesh 这个方案貌似和 kube-vip 差不多

2024 年 10 月 13 日

回复了 nakroy 创建的主题 › Kubernetes › 本地裸金属集群的 LoadBalancer 方案

硬件负载均衡暂时没有这个条件...

1 2

❮

❯