Coder Social home page Coder Social logo

replicate / cog Goto Github PK

View Code? Open in Web Editor NEW
7.6K 67.0 530.0 7.18 MB

Containers for machine learning

Home Page: https://cog.run

License: Apache License 2.0

Go 45.79% Python 52.78% Shell 1.42%
containers cuda deep-learning docker machine-learning pytorch tensorflow ai

cog's Introduction

Cog: Containers for machine learning

Cog is an open-source tool that lets you package machine learning models in a standard, production-ready container.

You can deploy your packaged model to your own infrastructure, or to Replicate.

Highlights

  • ๐Ÿ“ฆ Docker containers without the pain. Writing your own Dockerfile can be a bewildering process. With Cog, you define your environment with a simple configuration file and it generates a Docker image with all the best practices: Nvidia base images, efficient caching of dependencies, installing specific Python versions, sensible environment variable defaults, and so on.

  • ๐Ÿคฌ๏ธ No more CUDA hell. Cog knows which CUDA/cuDNN/PyTorch/Tensorflow/Python combos are compatible and will set it all up correctly for you.

  • โœ… Define the inputs and outputs for your model with standard Python. Then, Cog generates an OpenAPI schema and validates the inputs and outputs with Pydantic.

  • ๐ŸŽ Automatic HTTP prediction server: Your model's types are used to dynamically generate a RESTful HTTP API using FastAPI.

  • ๐Ÿฅž Automatic queue worker. Long-running deep learning models or batch processing is best architected with a queue. Cog models do this out of the box. Redis is currently supported, with more in the pipeline.

  • โ˜๏ธ Cloud storage. Files can be read and written directly to Amazon S3 and Google Cloud Storage. (Coming soon.)

  • ๐Ÿš€ Ready for production. Deploy your model anywhere that Docker images run. Your own infrastructure, or Replicate.

How it works

Define the Docker environment your model runs in with cog.yaml:

build:
  gpu: true
  system_packages:
    - "libgl1-mesa-glx"
    - "libglib2.0-0"
  python_version: "3.12"
  python_packages:
    - "torch==2.3"
predict: "predict.py:Predictor"

Define how predictions are run on your model with predict.py:

from cog import BasePredictor, Input, Path
import torch

class Predictor(BasePredictor):
    def setup(self):
        """Load the model into memory to make running multiple predictions efficient"""
        self.model = torch.load("./weights.pth")

    # The arguments and types the model takes as input
    def predict(self,
          image: Path = Input(description="Grayscale input image")
    ) -> Path:
        """Run a single prediction on the model"""
        processed_image = preprocess(image)
        output = self.model(processed_image)
        return postprocess(output)

Now, you can run predictions on this model:

$ cog predict -i [email protected]
--> Building Docker image...
--> Running Prediction...
--> Output written to output.jpg

Or, build a Docker image for deployment:

$ cog build -t my-colorization-model
--> Building Docker image...
--> Built my-colorization-model:latest

$ docker run -d -p 5000:5000 --gpus all my-colorization-model

$ curl http://localhost:5000/predictions -X POST \
    -H 'Content-Type: application/json' \
    -d '{"input": {"image": "https://.../input.jpg"}}'

Why are we building this?

It's really hard for researchers to ship machine learning models to production.

Part of the solution is Docker, but it is so complex to get it to work: Dockerfiles, pre-/post-processing, Flask servers, CUDA versions. More often than not the researcher has to sit down with an engineer to get the damn thing deployed.

Andreas and Ben created Cog. Andreas used to work at Spotify, where he built tools for building and deploying ML models with Docker. Ben worked at Docker, where he created Docker Compose.

We realized that, in addition to Spotify, other companies were also using Docker to build and deploy machine learning models. Uber and others have built similar systems. So, we're making an open source version so other people can do this too.

Hit us up if you're interested in using it or want to collaborate with us. We're on Discord or email us at [email protected].

Prerequisites

  • macOS, Linux or Windows 11. Cog works on macOS, Linux and Windows 11 with WSL 2
  • Docker. Cog uses Docker to create a container for your model. You'll need to install Docker before you can run Cog. If you install Docker Engine instead of Docker Desktop, you will need to install Buildx as well.

Install

If you're using macOS, you can install Cog using Homebrew:

brew install cog

You can also download and install the latest release using our install script:

# fish shell
sh (curl -fsSL https://cog.run/install.sh | psub)

# bash, zsh, and other shells
sh <(curl -fsSL https://cog.run/install.sh)

# download with wget and run in a separate command
wget -qO- https://cog.run/install.sh
sh ./install.sh

You can manually install the latest release of Cog directly from GitHub by running the following commands in a terminal:

sudo curl -o /usr/local/bin/cog -L "https://github.com/replicate/cog/releases/latest/download/cog_$(uname -s)_$(uname -m)"
sudo chmod +x /usr/local/bin/cog

Alternatively, you can build Cog from source and install it with these commands:

make
sudo make install

Or if you are on docker:

RUN sh -c "INSTALL_DIR=\"/usr/local/bin\" SUDO=\"\" $(curl -fsSL https://cog.run/install.sh)"

Upgrade

If you're using macOS and you previously installed Cog with Homebrew, run the following:

brew upgrade cog

Otherwise, you can upgrade to the latest version by running the same commands you used to install it.

Next steps

Need help?

Join us in #cog on Discord.

Contributors โœจ

Thanks goes to these wonderful people (emoji key):

Ben Firshman
Ben Firshman

๐Ÿ’ป ๐Ÿ“–
Andreas Jansson
Andreas Jansson

๐Ÿ’ป ๐Ÿ“– ๐Ÿšง
Zeke Sikelianos
Zeke Sikelianos

๐Ÿ’ป ๐Ÿ“– ๐Ÿ”ง
Rory Byrne
Rory Byrne

๐Ÿ’ป ๐Ÿ“– โš ๏ธ
Michael Floering
Michael Floering

๐Ÿ’ป ๐Ÿ“– ๐Ÿค”
Ben Evans
Ben Evans

๐Ÿ“–
shashank agarwal
shashank agarwal

๐Ÿ’ป ๐Ÿ“–
VictorXLR
VictorXLR

๐Ÿ’ป ๐Ÿ“– โš ๏ธ
hung anna
hung anna

๐Ÿ›
Brian Whitman
Brian Whitman

๐Ÿ›
JimothyJohn
JimothyJohn

๐Ÿ›
ericguizzo
ericguizzo

๐Ÿ›
Dominic Baggott
Dominic Baggott

๐Ÿ’ป โš ๏ธ
Dashiell Stander
Dashiell Stander

๐Ÿ› ๐Ÿ’ป โš ๏ธ
Shuwei Liang
Shuwei Liang

๐Ÿ› ๐Ÿ’ฌ
Eric Allam
Eric Allam

๐Ÿค”
Ivรกn Perdomo
Ivรกn Perdomo

๐Ÿ›
Charles Frye
Charles Frye

๐Ÿ“–
Luan Pham
Luan Pham

๐Ÿ› ๐Ÿ“–
TommyDew
TommyDew

๐Ÿ’ป
Jesse Andrews
Jesse Andrews

๐Ÿ’ป ๐Ÿ“– โš ๏ธ
Nick Stenning
Nick Stenning

๐Ÿ’ป ๐Ÿ“– ๐ŸŽจ ๐Ÿš‡ โš ๏ธ
Justin Merrell
Justin Merrell

๐Ÿ“–
Rurik Ylรค-Onnenvuori
Rurik Ylรค-Onnenvuori

๐Ÿ›
Youka
Youka

๐Ÿ›
Clay Mullis
Clay Mullis

๐Ÿ“–
Mattt
Mattt

๐Ÿ’ป ๐Ÿ“– ๐Ÿš‡
Eng Zer Jun
Eng Zer Jun

โš ๏ธ
BB
BB

๐Ÿ’ป
williamluer
williamluer

๐Ÿ“–
Simon Eskildsen
Simon Eskildsen

๐Ÿ’ป
F
F

๐Ÿ› ๐Ÿ’ป
Philip Potter
Philip Potter

๐Ÿ› ๐Ÿ’ป
Joanne Chen
Joanne Chen

๐Ÿ“–
technillogue
technillogue

๐Ÿ’ป
Aron Carroll
Aron Carroll

๐Ÿ“– ๐Ÿ’ป ๐Ÿค”
Bohdan Mykhailenko
Bohdan Mykhailenko

๐Ÿ“– ๐Ÿ›
Daniel Radu
Daniel Radu

๐Ÿ“– ๐Ÿ›
Itay Etelis
Itay Etelis

๐Ÿ’ป
Gennaro Schiano
Gennaro Schiano

๐Ÿ“–

This project follows the all-contributors specification. Contributions of any kind welcome!

cog's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cog's Issues

Predict shouldn't have network access

It's common for models to download weights in the setup() function. This isn't reproducible (models might run without a network connection and weights files can disappear from the internet) so we should discourage it. In cases where you actually need network access we can provide a config option to allow the model to hit the network.

The tricky bit is allowing incoming access for the HTTP server, while disallowing outgoing connections. On a cursory search, there seems to be no simple way to do this without iptables rules on the host, or the container to a private network and using another container as a proxy. Some creativity might be needed.

As a start, perhaps we could bodge it inside the container. That way we can guarantee it isn't downloading any files for reproducibility reasons, but doesn't have any security guarantees.

There are some cases where network access might be needed. A few ideas:

  1. We don't add any way of allowing network access now, and see how far we get. Maybe we don't need to add an option at all.
  2. If you want network access, you need to run it via Docker directly.
  3. We add an option in cog.yaml to allow network access. However -- Untrusted models not having network access is a neat security feature, so it would be a shame to allow model creators to break this.
  4. We add a runtime option to allow network access. For users who are in control of their environment, this lets them do weird stuff like this. "Turn this off at your own risk."

[This issue has been authored by @andreasjansson and @bfirsh.]

Make Dockerfile generation more robust

There is a lot of string concatenation without escaping and things like that. This feels like it needs a DSL.

Perhaps the simplest way would be to put all generated data inside environment variables, which can easily be escaped, then carefully input that data in fixed commands through the rest of the Dockerfile.

We can also do stuff like use the RUN ["foo", ...] form.

Ideally we wouldn't use Dockerfiles at all, which is a larger piece of work in #21.

Output of build should not display as console log messages

โ•โ•โ•โ•ก Building gpu image
โ•โ•โ•โ•ก   * Installing Python prerequisites
โ•โ•โ•โ•ก   * Installing Python 3.8
โ•โ•โ•โ•ก   * Installing system packages
โ•โ•โ•โ•ก   * Installing Python packages
โ•โ•โ•โ•ก #11 sha256:6ba92f3047b5dec04235ade8528c87bc142e66bb38015765dc4f9cbb7d185cd8
โ•โ•โ•โ•ก #11 DONE 0.5s
โ•โ•โ•โ•ก
โ•โ•โ•โ•ก #12 [ 9/15] RUN pip install -f
   โ”‚ https://dl.fbaipublicfiles.com/detectron2/wheels/cpu/index.html -f
   โ”‚ https://download.pytorch.org/whl/cu101/torch_stable.html
   โ”‚ --extra-index-url=git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI
   โ”‚ cachetools==4.1.0 chardet==3.0.4 future==0.18.2 fvcore==0.1.dev200506
   โ”‚ idna==2.9 importlib-metadata==1.6.0 jsonpatch==1.25 jsonpointer==2.0
   โ”‚ markdown==3.2.2 mock==4.0.2 opencv-python==4.3.0.38 portalocker==1.7.0
   โ”‚ pyasn1==0.4.8 pyasn1-modules==0.2.8 pydot==1.4.1 requests==2.23.0
   โ”‚ requests-oauthlib==1.3.0 rsa==4.0 tabulate==0.8.7 termcolor==1.1.0
   โ”‚ urllib3==1.25.8 visdom==0.1.8.9 websocket-client==0.57.0 werkzeug==1.0.1
   โ”‚ yacs==0.1.7 zipp==3.1.0 cython==0.29.22 pyyaml==5.1 dominate==2.4.0
   โ”‚ detectron2==0.1.2 torch==1.5.0 torchvision==0.6.0 pycocotools==2.0.2
   โ”‚ ipython==7.21.0 scikit-image==0.18.1
โ•โ•โ•โ•ก #12 sha256:84e81bafd53e4595c28450182c770765e490c57fe351dd48fbad3418b7ad1697
โ•โ•โ•โ•ก #12 1.283 Looking in indexes: https://pypi.org/simple,
   โ”‚ git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI
โ•โ•โ•โ•ก #12 1.283 Looking in links:
   โ”‚ https://dl.fbaipublicfiles.com/detectron2/wheels/cpu/index.html,
   โ”‚ https://download.pytorch.org/whl/cu101/torch_stable.html
โ•โ•โ•โ•ก #12 1.370 WARNING: Cannot look at git URL
   โ”‚ git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI/cachetools/
   โ”‚ because it does not support lookup as web pages.
โ•โ•โ•โ•ก #12 2.202 Collecting cachetools==4.1.0
โ•โ•โ•โ•ก #12 2.235   Downloading cachetools-4.1.0-py3-none-any.whl (10 kB)
โ•โ•โ•โ•ก #12 2.265 WARNING: Cannot look at git URL
   โ”‚ git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI/chardet/
   โ”‚ because it does not support lookup as web pages.
โ•โ•โ•โ•ก #12 2.942 Collecting chardet==3.0.4
โ•โ•โ•โ•ก #12 2.950   Downloading chardet-3.0.4-py2.py3-none-any.whl (133 kB)
......

Console โ•โ•โ•โ•ก messages are for displaying messages to the user, not for large amounts of debugging output. The build output should be displayed as plain text, clearly delineated from the informational messages.

Build Docker images with buildkit directly

Instead of using Dockerfiles. Concatenating strings is fragile. https://www.docker.com/blog/compiling-containers-dockerfiles-llvm-and-buildkit/

Note that we use buildkit to build Dockerfiles for CPU. This is about calling the buildkit API directly instead of going via a Dockerfile.

We could also call the Docker API to create and commit containers, emulating the build process.

A nice side-effect of using Dockerfiles is we can generate a Dockerfile for users if they want to "eject" from Cog.

Related to #165

Local image management

As part of implementing local mode and on server (#18) we need a sensible way of managing local images.

Requirements

  • Tags should not grow uncontrollably, so that images can be cleaned up by docker system prune
  • The image should be given a name so you can identify it in docker images
  • The previous image should be removed

For clarity, this is additional work on top of #18. This also includes picking a sensible name when running locally and you aren't pointed at a registry.

Design prediction API versioning

I want to rename /infer to /predict but we can't change it because all the old models have it and there is no way for Cog to detect what version it is and what it should call.

Alternatively, perhaps it is the client which should detect what version of Cog the model has been made with, and adjust its API calls as appropriate.

End to end tests don't work on macOS

From #118, the end to end tests can't connect to the bridge IP on macOS:

Screen Shot 2021-06-15 at 10 58 06

This should either be run in a consistent dev environment, or if we actually want to run the end to end tests on macOS (which probably makes sense in CI?), then we might need some kind of OS-based switch in there.

Better error message when `Model.setup()` is not set

If you don't set a setup() function, you get an incomprehensible error:

โ•โ•โ•โ•ก Traceback (most recent call last):
   โ”‚   File "/usr/bin/cog-http-server", line 8, in <module>
   โ”‚     cog.HTTPServer(Model()).start_server()
   โ”‚ TypeError: Can't instantiate abstract class Model with abstract methods setup
   โ”‚
โ•โ•โ•โ•ก Container exited unexpectedly

My feeling is we should require setup() to encourage users to do the right thing, but there should be a clearer error message.

Throw error if invalid keys exist in cog.yaml

Currently invalid keys are silently ignored.

For example, a cog.yaml that contains this:

buildd:
  python_version: "3.8"
  python_packages:
    - "torch=1.8.0"

Will silently not install torch, instead of complaining that the key buildd doesn't exist.

Future

We may also want to validate the values at some point. For example, ensuring python_version is a string and matches a given pattern. (If you omit the quotes, 3.1 and 3.10 are indistinguishable! Thanks YAML!)

(Edited by @andreasjansson and @bfirsh.)

Jupyter Notebook Integration

Would love to see some kind of notebook integration. Can we expose the environment built in Docker as a Jupyter Notebook kernel possibly?

Cog should work in subdirectories

Cog should search up the file tree for cog.yaml, like Keepsake does.

For example, if /home/ben/hotdog-detector/cog.yaml exists, then I should be able to run cog predict in /home/ben/hotdog-detector/subdir/ and it should do what I expect.

There is some nuance here with cog run. Should the working directory be the relative current directory inside the container?

Use separate `required` option for `@cog.input()`

The double behavior of default is not obvious.

This might want to be optional=True instead, so that inputs are required by default. If the inputs were not required by default, then users normally would make them required. If required inputs are not marked as required, this will cause breakage.

Design how to run arbitrary scripts

There is preinstall but it implies that it comes before installing other things, but it doesn't -- it becomes before copying code. We should:

  1. Figure out the "default" place to run arbitrary commands
  2. Figure out the right name for it

Support streaming real-time prediction

Currently Cog requires you to upload an input file, then it's processed and results are returned. But there are cases when you might want to stream a continuous input to the model. For example, if you have a model that does audio event detection, you might want to display the current event as it happens.

gnutls_handshake() failed: The TLS connection was non-properly terminated.

cog build
โ•โ•โ•โ•ก Uploading /Users/tekumara/code3/cog-examples/inst-colorization to localhost:8080/examples/inst-colorization
โ ‹ uploading (925 MB, 269.985 MB/s) โ•โ•โ•โ•ก Building model...
โ•โ•โ•โ•ก Received model
โ•โ•โ•โ•ก Building cpu image
โ•โ•โ•โ•ก   * Installing Python prerequisites
โ•โ•โ•โ•ก   * Installing Python 3.8
โ•โ•โ•โ•ก   * Installing system packages
โ•โ•โ•โ•ก   * Installing Python packages
โ•โ•โ•โ•ก   * Installing Cog
โ•โ•โ•โ•ก   * Copying code
โ•โ•โ•โ•ก Successfully built 507cf5936fd9
โ•โ•โ•โ•ก Pushing localhost:5000/inst-colorization:507cf5936fd9 to registry
โ•โ•โ•โ•ก Building gpu image
โ•โ•โ•โ•ก   * Installing Python prerequisites
โ•โ•โ•โ•ก   * Installing Python 3.8
โ•โ•โ•โ•ก  ---> Using cache
โ•โ•โ•โ•ก  ---> 68aac6e4699f
โ•โ•โ•โ•ก Step 8/20 : RUN curl https://pyenv.run | bash && 	git clone https://github.com/momo-lab/pyenv-install-latest.git "$(pyenv root)"/plugins/pyenv-install-latest && 	pyenv
   โ”‚ install-latest "3.8" && 	pyenv global $(pyenv install-latest --print "3.8")
โ•โ•โ•โ•ก  ---> Running in ae5b74d815ca
โ•โ•โ•โ•ก   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
โ•โ•โ•โ•ก                                  Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   285  100   285    0     0    198      0  0:00:01  0:00:01 --:--:--   198  0
โ•โ•โ•โ•ก Cloning into '/root/.pyenv'...
โ•โ•โ•โ•ก Cloning into '/root/.pyenv/plugins/pyenv-doctor'...
โ•โ•โ•โ•ก Cloning into '/root/.pyenv/plugins/pyenv-installer'...
โ•โ•โ•โ•ก Cloning into '/root/.pyenv/plugins/pyenv-update'...
โ•โ•โ•โ•ก fatal: unable to access 'https://github.com/pyenv/pyenv-update.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
โ•โ•โ•โ•ก Failed to git clone https://github.com/pyenv/pyenv-update.git
โ•โ•โ•โ•ก Error: Failed to build Docker image: exit status 255

High CPU usage during the build.

Cog stalls when pushing large, cached files

Steps to reproduce:

  1. Push some large files
  2. Push again

It now stalls saying โ ™ uploading (3.1 kB, 0.494 kB/s). Perhaps it's calculating some hashes, or something. Whatever it's doing it should show progress instead of looking broken.

Rename "run arguments"

We don't use the word "arguments" anywhere else. This is "input types" or "inputs" or something along those lines?

Sensible defaults for `.cogignore`

As suggested by @zeke.

.npmignore defaults to .gitignore, but there is a dangerous silent failure in that: Suppose .gitignore ignores secrets.json. If you then you add .npmignore with something new you want to ignore, it stops inheriting from .gitignore therefore unignoring secrets.json.

There is also an additional consideration for machine learning models: .gitignore will normally ignore your model weights, but you want to include that for Cog, so maybe in this case the default would always be not what you want. In which case, it probably shouldn't be the default.

Maybe we need some sensible defaults that are clear to the user? Maybe there's something clever we can do based on .gitignore?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.