# Vetting an open model before deployment > Source: > Published: 2026-11-09 11:55:57+00:00 A small team wanted to replace a paid API with an open model from the Hub to cut costs. The model looked great in a notebook demo and ranked well on public leaderboards. Before switching, they read the model card, which noted weaker performance on non-English text and a license with commercial-use conditions. Their user base included Spanish and Hindi speakers, so they tested on a sample of real, anonymized queries in those languages. Quality dropped noticeably on longer inputs, and memory use under realistic load was higher than expected. The team chose a larger quantized variant, added a fallback to the previous API for long inputs, and kept the old setup deployable for rollback. The leaderboard score hadn’t predicted any of those issues, only testing on their own data did. [DHEIVER](https://discuss.huggingface.co/u/DHEIVER) 2 Leaderboard metrics on synthetic or short-text benchmarks rarely correlate with production latency or memory footprint under load. The degradation on longer inputs confirms that context window utilization and KV cache management expose bottlenecks invisible in standard evals. Switching to a larger quantized variant was a necessary compromise: 4-bit or 5-bit quantization reduces VRAM pressure but introduces precision loss in complex reasoning, particularly affecting non-English token distributions. The fallback mechanism to the previous API remains the only robust pattern for handling these edge cases without blocking the user. Real data testing is the only way to validate the actual cost-per-token and latency profile before full migration.