Hi @venkatkittu,
I can help with this. The error code 132 you are seeing is actually a Unix signal, and understanding it will point you directly to the fix.
WHAT ERROR CODE 132 MEANS
In Unix systems, when a worker process exits with code 132, that is 128 + 4, which corresponds to signal 4 (SIGILL - Illegal Instruction). This means the FAISS library is attempting to execute a CPU instruction that is not supported on the hardware where the Model Serving container is running.
This typically happens because the pre-built faiss-cpu package from PyPI is compiled with advanced CPU instruction sets (such as AVX2 or AVX-512) that may not be available on the specific CPU in the serving container. Since FAISS relies heavily on vectorized CPU instructions for performance, this mismatch causes the process to crash immediately.
HOW TO FIX THIS
Here are several approaches, starting with the most straightforward:
1. USE faiss-cpu WITH A COMPATIBLE BUILD
Instead of the default faiss-cpu from PyPI, try installing a version built without advanced instruction set requirements. When logging your model with MLflow, specify the dependency explicitly:
import mlflow
pip_requirements = [
"faiss-cpu==1.7.4",
# your other dependencies here
]
mlflow.pyfunc.log_model(
artifact_path="model",
python_model=your_model,
pip_requirements=pip_requirements,
)
If version 1.7.4 still causes the same issue, try version 1.7.2 which may have broader CPU compatibility.
2. BUILD FAISS FROM SOURCE WITH GENERIC FLAGS
If you need more control, you can build faiss-cpu from source without AVX2. You can include a setup script in your conda environment that compiles FAISS with generic instruction sets:
conda_env = {
"channels": ["conda-forge", "defaults"],
"dependencies": [
"python=3.10",
{"pip": [
"faiss-cpu==1.7.4",
# other pip packages
]},
],
"name": "faiss_env",
}
mlflow.pyfunc.log_model(
artifact_path="model",
python_model=your_model,
conda_env=conda_env,
)
Using the conda-forge channel may provide a build that is more compatible with varied CPU architectures.
3. SWITCH TO GPU-BASED SERVING
If your use case allows it, you can serve the model on a GPU endpoint and use faiss-gpu instead. When creating your serving endpoint, select a GPU compute type (such as GPU_SMALL for a T4 with 16GB memory). FAISS GPU builds do not rely on the same CPU instruction sets and can avoid this problem entirely, while also giving better performance for large indexes.
4. CONSIDER DATABRICKS VECTOR SEARCH AS AN ALTERNATIVE
Depending on your use case, Databricks Vector Search may be an excellent alternative to managing FAISS directly inside your model. Vector Search is a fully managed service that:
- Automatically scales with your index size
- Syncs with Delta tables in Unity Catalog
- Supports hybrid keyword + semantic search
- Provides a simple REST API for queries
Instead of embedding FAISS inside your model, you could have your served model call the Vector Search endpoint at inference time. This removes the FAISS dependency from your model entirely and gives you a production-grade similarity search. You can learn more here:
https://docs.databricks.com/en/generative-ai/vector-search.html
DEBUGGING TIPS
To help debug further if the above approaches do not resolve the issue:
- Check the container logs in the serving endpoint UI under the "Logs" tab to see if there are more detailed error messages before the crash.
- Test your model locally before deploying by using mlflow.pyfunc.load_model() and running a prediction to verify FAISS loads correctly.
- Make sure you are specifying all required dependencies (including numpy and any other libraries FAISS depends on) in your MLflow model's pip_requirements or conda_env.
For more details on deploying custom models with proper dependency management, see the documentation:
https://docs.databricks.com/en/machine-learning/model-serving/custom-models.html
I hope this helps you get your endpoint up and running!
* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.
