Live data from Hacker News

Show HN: Cortex – machine learning infrastructure for developers

github.com

11–15 of 15 posts

Re: Show HN: Cortex – machine learning infrastructure for developers

#11
post #5

I work on ML infrastructure at some big company, so I'm always interested to see whats new in this field. This seems to be a thin wrapper around tf.estimator, which provides a majority of the functionality. The only novel things are yaml config for defining some basic transformations and data format. It doesn't seem super useful, am I missing something?

curious what kind of infrastructure have you built for deployment, serving and managing models?

We use TesnorFlow serving (https://www.tensorflow.org/serving) for serving the trained models. We also run Flask to transform the incoming JSON to match the way the data has been transformed at training time.

Re: Show HN: Cortex – machine learning infrastructure for developers

#12
post #3

Somewhat unfortunate name clash with the now-back-burnered deep learning framework written in Clojure, also called Cortex: https://github.com/originrose/cortex

LOL...every other AI related project these days is called some variation or part of: Cortex Mental Mind Neural/Neurons

Which is, of course, hilarious, since none of them have anything to do with the brain or mind whatsoever, being slightly advanced computational statistics programs.

Re: Show HN: Cortex – machine learning infrastructure for developers

#14
post #13

How does this compare to KubeFlow?

We have a lot of respect for the work that the KubeFlow team is doing. Their focus seems to be on helping you deploy a wide variety of open source ML tooling to Kubernetes. We use a more narrow stack and focus more on automating common workflows.

For example, we take a fully declarative approach; the “cortex deploy” command is a request to “make it so”, rather than “run this training job”. Cortex determines at runtime exactly what pipeline needs to be created to achieve the desired state, caching as aggressively as it can (e.g. if a hyperparameter to one model changes, only that model is re-trained and re-deployed, whereas if a transformer is updated, all transformed_columns which use that transformer are regenerated, all models which use those columns are re-trained, etc). We view it as an always-on ML application, rather than a one-off ML workload.

Post reply on HN