Meridian Line wants to serve a third-party foundation model that is not hosted on Databricks, using it as one option the charter-desk assistant can call, while keeping the API key out of application code and keeping usage visible through the same interface used for Databricks-native models. Which Model Serving capability is designed for exactly this?

External Models is designed to expose a third-party or externally hosted foundation model through a Databricks-managed serving endpoint. The provider’s credentials can be stored securely rather than embedded in application code, and the model can be queried through a unified interface with logging and AI Gateway controls such as rate limiting, usage tracking, and payload logging. This meets the requirements for secret management, a common query interface, and visible usage. A Direct Vector Access index configured to proxy the provider is not suitable: Direct Vector Access is a retrieval mechanism over embedded documents, not a way to proxy model inference calls. A Delta Sync index pointed at the provider’s documentation is also a retrieval mechanism; it can make indexed documentation available for search, but it does not serve the provider’s model. A custom fine-tuned model trained to imitate the provider is a different and much more expensive, slower approach, and its outputs would not be reliably equivalent to calling the actual model. For the exam, distinguish wrapping an externally hosted model with External Models from building a separate model that imitates it. As a practical check, confirm that the endpoint uses the provider’s model, keeps its credential out of application code, and exposes usage through the Databricks serving interface.