<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Under the Model</title><link>https://oguzpastirmaci.com/</link><description>Recent content on Under the Model</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oguzpastirmaci.com/index.xml" rel="self" type="application/rss+xml"/><item><title>Why torchrun Can't Find Node Two on the Host Network</title><link>https://oguzpastirmaci.com/posts/why-torchrun-cant-find-node-two-on-the-host-network/</link><pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate><guid>https://oguzpastirmaci.com/posts/why-torchrun-cant-find-node-two-on-the-host-network/</guid><description>&lt;p&gt;If you want RDMA inside a Kubernetes pod, the simplest way is the host network. The pod uses the network namespace of the node, NCCL sees the RDMA NICs directly, and you get the bandwidth you paid for. On two BM.GPU4.8 nodes on OKE (8 A100 GPUs and 16 RDMA NICs each), NCCL &lt;code&gt;all_reduce&lt;/code&gt; reached about 191 GB/s bus bandwidth with an 8 GiB buffer.&lt;/p&gt;&#10;&lt;p&gt;Then torchrun gets confused. With the host network, every pod has the host name of its node. torchrun uses host names to make two decisions, and both go wrong. Either no node starts the rendezvous store, or node two cannot find node one.&lt;/p&gt;</description></item></channel></rss>