## Summary

Saving a model in the admin UI persists server-computed display fields into `LiteLLM_ProxyModelTable.model_info`. The model listing endpoints inject `access_via_team_ids` (a list of every team that can use the model) and `direct_access` into each model's `model_info` so the dashboard can display team access. The dashboard's edit-model save then re-sends the entire `model_info` it received, and the update path merges and persists it verbatim. The result is that `model_info` in the DB grows O(number of teams) after any UI save, the persisted team list goes stale as soon as team membership changes, and every code path that deep-copies deployment dicts pays for the blob on every request

Observed in production: 1,438 teams produced a ~66KB `access_via_team_ids` array per saved model row. Five of six wildcard model rows carried it (each had been saved via the UI); the sixth, never saved via the UI, remained at 126 bytes. This is the organic source of the "tens of KB model_info" that makes #33636 an outage rather than a slowdown

## Mechanism (verified against the v1.92.0 tag)

1. `_populate_team_access_on_models` (litellm/proxy/proxy_server.py:10795 and 10801) sets `model_in…