-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easier to use ML.NET in an ASP.NET app/service #3239
Comments
I certainly support this feature. 👍 |
I like this. In terms of where it should be, I vote for |
As far as distributing the work among the pool, would it be random based on resources available or would there be a strategy? Would that functionality instead be better served by something like a load balancer rather than logic built into the pool? |
@markus Agree, we should host this in the place it will be able to evolve more agile. @luisquintanilla- Load balancing makes sense when you are distributing load across multiple machines/servers, or distributed nodes in an orchestrator like when using containers. But in this case, it is a single pool of objects in a single hardware machine, same memory, same resources. I don’t think we need any load balancing here, it would be making it more complex without really needing it. |
This package makes it easier to use ML.NET with app models that support Microsoft.Extensions - i.e. ASP.NET and Azure Functions. Specifically it contains functionality for: - Dependency Injection - Pooling PredictionEngines - Reloading models when the file or URI has changed - Hooking ML.NET logging to Microsoft.Extensions.Logging Fix dotnet#3239
* Add Microsoft.Extensions.ML integration package. This package makes it easier to use ML.NET with app models that support Microsoft.Extensions - i.e. ASP.NET and Azure Functions. Specifically it contains functionality for: - Dependency Injection - Pooling PredictionEngines - Reloading models when the file or URI has changed - Hooking ML.NET logging to Microsoft.Extensions.Logging Fix #3239 * Add XML doc comments. Format the code so lines aren't so long. Remove unnecessary IPredictionEnginePoolBuilder interface, and just use a regular class. * Respond to PR feedback. * PR feedback Rename MLContextOptions to MLOptions. Make MLContext lazy loaded, so callers can provide their own. Use the loaded model in the test.
Problem
With
1.0.0-preview
bits, it is currently harder than it needs to be to use ML.NET inside an ASP.NET service or application. The first problem users hit is whether they can cache aPredictionEngine
statically and reuse it for multiple requests. As described in #1789, you cannot use a PredictionEngine on multiple threads at the same time. Doing so will cause problems in your application.Thus the recommendation is to use a pooling technique, but writing one from scratch is rather hard and potentially error prone.
Also, by default the MLContext's Log operation is not aware of any logging infrastructure currently used by ASP.NET apps/services. Thus the log goes nowhere, and is lost.
Proposal
We propose to add a new library (
Microsoft.ML.Extensions?
,Microsoft.Extensions.ML?
) that is aware of bothMicrosoft.ML
andMicrosoft.Extensions.DependencyInjection
/Microsoft.Extensions.Logging
and glues the two together. This should make it much easier to consume ML.NET models inside ASP.NET apps/services, as well as any other app model that integrates with theMicrosoft.Extensions.*
libraries.Usage
Adding a new ML.NET model into an ASP.NET application could be as simple as two steps:
Other potential scenarios
.zip
file from sources other than a file path@glennc @CESARDELATORRE @glebuk @TomFinley
The text was updated successfully, but these errors were encountered: