Z-ai/glm-5.2 hosted NIM stalls with 0 bytes depending on public egress path

AI & Data Science NVIDIA NIM Access/Accounts
, ,
1

Hi,

I’m seeing a reproducible issue with the hosted z-ai/glm-5.2 model through:

POST https://integrate.api.nvidia.com/v1/chat/completions

The exact same request behaves differently depending on the public egress path.

Observed behavior

Scenario Result
Residential connection in Brazil HTTP 200, normal response
Contabo VPS in France Timeout, 0 bytes received
Same French VPS through reverse SOCKS using Brazilian residential egress HTTP 200, ~3s
Same French VPS through a Cloudflare Worker relay Timeout, 0 bytes received

The reverse SOCKS test is especially interesting because the machine, API key, payload, curl client and model remain the same. Only the public egress changes, and GLM-5.2 immediately starts working again.

Control models

From the same Contabo VPS and using the same NVIDIA API infrastructure:

  • nvidia/nemotron-3-super-120b-a12b → HTTP 200
  • nvidia/nemotron-3-nano-30b-a3b → HTTP 200

So the VPS can communicate with NVIDIA normally. The issue appears specific to z-ai/glm-5.2.

Already ruled out

I reproduced the behavior with direct curl, completely bypassing LiteLLM.

I also tested or verified:

  • DNS resolution
  • IPv4 / IPv6
  • HTTP/1.1 vs HTTP/2
  • TLS handshake
  • firewall / UFW
  • HTTP proxy configuration
  • /etc/hosts
  • MTU
  • API key validity
  • client-side middleware

In the failing case, TCP/TLS complete successfully and the POST body is sent, but no response bytes are received until the client times out.

The same API key works when the request exits through the Brazilian residential connection.

Minimal reproduction

curl -v \
  --max-time 60 \
  https://integrate.api.nvidia.com/v1/chat/completions \
  -H "Authorization: Bearer $NVIDIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "z-ai/glm-5.2",
    "messages": [
      {
        "role": "user",
        "content": "Reply only: OK"
      }
    ],
    "max_tokens": 16,
    "stream": false
  }'

From the affected cloud egress this receives 0 bytes until timeout.

Using the same VPS and request through a reverse SOCKS tunnel with residential Brazilian egress returns HTTP 200 normally.

What I am NOT claiming

I’m not claiming intentional IP/datacenter blocking.

The behavior could also be caused by routing, edge selection, load balancing, geo-affinity, an upstream provider policy, or another model-specific serving issue.

What the A/B tests show is that the public origin/egress path is strongly correlated with whether z-ai/glm-5.2 responds.

Could NVIDIA please check whether GLM-5.2 currently has any known routing, geo-affinity, edge-selection, or access-policy issues affecting certain cloud/datacenter egress ranges?

If useful, I can provide additional timing information, traceroute/MTR results, or the affected VPS public IP privately for investigation.

Thanks.