ModelExpress P2P transfer may not use EFA

[negz]

What happened?

On a Dynamo cluster we bind an EFA device through DRA and add IPC_LOCK because GPUDirect RDMA needs to pin memory, so the intent is that ModelExpress moves weights over the fabric. But modelexpress_env doesn't inject MX_NIXL_BACKEND:

modelplane/functions/compose-model-replica/function/backends/base.py

Lines 176 to 184 in 960c645

	return [
	{"name": "MX_SERVER_ADDRESS", "value": address},
	{"name": "MODEL_EXPRESS_URL", "value": address},
	{"name": "MX_MODEL_REVISION", "value": cache_pvc_name(_namespace(replica.metadata), ref.name)},
	{"name": "MX_P2P_METADATA", "value": "1"},
	{"name": "POD_NAME", "valueFrom": {"fieldRef": {"fieldPath": "metadata.name"}}},
	{"name": "POD_UID", "valueFrom": {"fieldRef": {"fieldPath": "metadata.uid"}}},
	{"name": "POD_NAMESPACE", "valueFrom": {"fieldRef": {"fieldPath": "metadata.namespace"}}},
	]

ModelExpress defaults MX_NIXL_BACKEND to UCX, which covers InfiniBand and RoCE. Its NIXL Backend Selection docs say to set LIBFABRIC on AWS EFA, "where the UCX backend can silently fall back to TCP depending on the libibverbs / EFA installer combination on the host".

If that applies to us, a replica on an EFA cluster still pulls weights from a peer rather than reading storage, so nothing looks broken, but the transfer may be crossing TCP rather than the fabric we claimed a device for. Upstream's wording is conditional, so it may come down to the host image, and I haven't measured it either way.

I noticed this reading the code, so it needs checking on a real EFA cluster before we act on it.

How can we reproduce it?

ModelExpress logs the backend when it creates a NIXL agent, so checking should be enough to settle it.

What environment did it happen in?

Modelplane version: main (960c645)

EKS, Dynamo serving stack, GPU pool claiming an EFA device through DraNet.