Ran the public endpoint (api.wikimedia.org) from Toolforge, which bypasses the 100/hour cap via the known-network tier. Same fixed config as the internal baseline, so the numbers compare directly.

Config: dataset random, input/output 1024/128, --ignore-eos, --prompt-token-ids, seed 42, 200 requests/run, backend openai /v1/completions, sweep 1/8/32/64. Public base-url per model, no Host header, valid TLS (no --insecure). Background traffic was ~nil during both runs, so these compare cleanly to the internal baseline.

llm-qwen36-27b (FP8, full GPU, ml-serve1012)
Window (UTC): 2026-07-24 14:48:28 → 15:01:22 · dashboard

llm-qwen3-14b (FP8, 24 GB partition, ml-serve1013)
Window (UTC): 2026-07-24 15:08:31 → 15:28:51 · dashboard

*(latencies in ms)*

Public vs. internal — gateway/mesh/CDN overhead is negligible:

• Throughput, saturation point, and E2EL match the internal baseline for both models. The only measurable cost is a small TTFT bump of ~40–300 ms at low-to-moderate concurrency, and within run-to-run noise at saturation (at conc 64 the public 27B TTFT is actually lower). Relative to multi-second E2EL, it's in the noise.
• So the user-facing experience ≈ the internal path — the bottleneck is the model/replica, not the gateway. This also validates the internal baseline as a fair proxy for public.
• 0 failures at every level, including conc 64 at --request-rate inf → confirms Toolforge egress gets the known-network/unlimited tier even under high concurrency.
• The 27B-full-GPU vs 14B-24GB-partition gap holds on the public path too (~2× throughput; saturates ~64 vs ~32).
• KV-cache usage (from the dashboard): ~5% (27B, full GPU) vs. ~65% (14B, 24 GB partition) — much less KV headroom on the partition.

Repro note: public runs use the public base-url with the Host header omitted. Found a small wrapper bug doing this — benchmark_llm.sh used ${HOST_HEADER:-default}, which ignores an empty override; fixed to ${HOST_HEADER-default} so HOST_HEADER="" sticks. Will send a follow-up patch.