@Djaron
实际用下来是按照显存最低的那张卡的显存*利用率为实际每张卡使用的显存

@MeePawn666 第一次用 TensorRT-LLM ，运行起来有些复杂啊，convert_checkpoint.py 转换模型设置--tp_size 4 的时候，生成的 4 个 rank*.safetensors 看起来大小是相同的，用 mpirun 简单跑了跑小模型，看到日志里面显示 Rank 0 is using GPU 0 ，Rank 1 is using GPU 1 ，推测显存占用还应该是平均分配啊

@mohumohu zerotier 还可以，之前在固定网络环境下用的也比较多，就是国内跑 udp 流量可能存在 qos 等问题，另外一些临时的外部服务可能不适合 zerotier 直接组成一个局域网，npc 直接一个可执行文件一条命令就通了，挺方便的。

@wwhc 作为用的很多的基础软件，ssh 安全应该有保障。ssh 隧道还可以，但反向隧道时间长了会容易出现映射的端口假死的情况，需要杀进程重新连接

@MeiJiayun 看描述新增的 tls_bridge 功能客户端忽略证书校验，看起来有一定的中间人风险。不转发明文协议原版还可以将就着用，日后慢慢清退 nps 服务了。

wireshark 抓包验证后，npc 向管理端的通信流量的确没加密，内部 http 数据都是明文的，被那个加密选项骗了得有 4 年了。

请问只有控制流量是加密的，转发的真实请求流量是不加密的吗 · Issue #1151 · ehang-io/nps
https://github.com/ehang-io/nps/issues/1151
害怕😂 居然有这种事情

过了一夜，啥操作没做，再次访问，中间人的现象自动消失了😮

问题解决了，不知道为什么 B 点单节点同时向 A 点和 C 点进行打洞存在问题，不管是 zerotier 还是 frp 都是如此，直接在 B 点建了两台虚拟机，一台和 A 点打洞，一台和 C 点打洞，虚拟机之间通过内网传输，就可以了，真是折腾。。。

@42371838 搭过 moon 节点了，0kbps 的问题还是一样

@Xymmh 有一处上网环境不是自己的，改不了 ipv6 。另外 ipv6 全局可访问，如果泄露了 ip ，别人可以直接攻击到你，还是躲在 ipv4 的 nat 后面感觉更安心。

@ruidoBlanco 我这 8124m 没核显直接没救了。。

@12101111 限制挺多的，貌似还不稳定，倒是可以折腾折腾。。

@v2da 那就好，不用花钱白折腾了。。。

@swulling
@dann73580
@dann73580
@eason1874
@littlewing
@wonderfulcxm 大家都挺认可再办一个宽带。。我找个时间去营业厅咨询咨询

@mineralsalt 伪装太难了，线，噪音，体积都是大问题。。

@Kowloon @ferock 有五台，主要还是有噪音，也影响美观。要是能够有方案踢出住宅，也挺好的

@luyunpsyduck @lin559671 公网线路垃圾。其实这 bonding 的多个线路还是走的 cloudflare cdn 通过 v2ray 任意门转发出来的

@dsnap5 机场之类的也在用，流量有限，带宽给他们占满了也不好。折腾这个主要是因为用自己的 vps 可以无限流量，中转一下长期挂着 BT 下载，也有些图拉丁思想。这个 bonding 可能效果就是这么差吧。。。。逃