Replies: 1 comment
-
Hi @MMelQin I think this is a great idea to let people know what particular features are available on the each map. Maybe we can ask @zephyrie to link us to a web-page similar as model-zoo, On this webpage we can explicitly specify what levels are the different MAPS? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have been talking about MAP Everywhere, and there have been activities to deploy MAP on multiple deployment platforms: AARM-V8, on Nuance PIN, Blackford etc. I think it is a good idea that I put forward the original design idea to deploy MAPs everywhere in combination with a clear definition of adoption/integration levels, see below. Please comment and discuss.
There are three levels of MAP adoption/integration, and for every MAP a level 1 is guaranteed. With the following levels, we can categorize the solutions and activities, and clearly show our progression on the road map,
Level 1. Directly use MAP as an OCI compliant Docker, where the hosting platform, via their own tooling, can inspect the metadata and ensure dependencies are satisfied. All MAPs, built using MONAI App SDK and its CLI, are already at least at this level. The MAPs deployment had been demonstrated in Argo-based MONAI Deploy workflow.
Level 2. This is MAP running "natively" on the platform. At this level, the platform specific adaptor/shim can understand both the MONAI App dependencies and the platform API. It also provides the entry point of the MAP Docker while internally managing the life cycle of the MONAI Deploy app instance.
The shim can potentially make the app a long running service, if it can remap/shuffle the inputs and outputs, as the app itself is re-runnable.
At the onset, the only native execution planned is on MONAI Deploy Express. An executor/shim is already embedded within a MAP, though not activated for simplicity and showing more details on the parameters required for the container.
We can further select a short list of platforms, and add their support in App SDK proper, including their version specific executor and Docker file etc.
Level 3, At this level, App SDK supports direct building platform specific MAP for any and all targeted platform, and likely an upcoming standard will be required (one is already in the works in the DICOM Working Group).
This may require more significant changes in App SDK framework and CLI, and is at least a mid-term goal.
Currently there are a number of App SDK issues already created and related to this. We'll need consolidate and come up with a solid design.
Ideally every platform can support MAP at Level 1, but the reality is different. Many, if not all, platforms requires specific interfaces and agents, unlike Argo.
Beta Was this translation helpful? Give feedback.
All reactions