dependency issues, needing more than model weights to be able to consume models (Multiple Sequence Alignment needs to be split, has its own always on server, so on), more convenient if the inputs and outputs are hardened interfaces as different envs
Our general findings in the BioML are that the models are not at all standardized especially compared to the diffusion model world for example, so treating each with its own often weird dependencies helped us get out more tools quicker.
That’s interesting. We’ve developed a kubernetes-based scheduler that we’ve found better takes into account our custom job priority needs, allows for more strict data isolation between tenants, and a production grade control plane, though the core scheduling could certainly be implemented in something like HTCondor.
Originally, my first instinct was to use Slurm or AWS batch, but started having problems once we tried to multi cloud. We're also optimizing for being able to onboard an arbitrary codebase as fast as possible, so building a custom structure natively compatible with our containers (which are now automatically made from linux machines with the relevant models deployed) has been helpful.
It certainly was an investment for us to meet the security and enterprise-readiness criteria for our enterprise users. As an n of 1, we don't tend to do on-prem, and even much of the most skeptical companies will find a way to use cloud if they want your product enough.
I think most large companies have similar expectations around security requirements, so once those are resolved most IT teams are on your side. We occasionally do some specific things like allowing our product to be run in a VPC on the customer cloud, but I imagine this is just what most enterprise-facing companies do.
In this case the input to the model is the input structure of the protein target, i.e. you can define the whole search space for it to try to find a binder/drug against. We let you pick a preset recipe to follow at the top, which basically are common ways people are using this protocol for. The model itself can find a pocket, or the user can specify it if they know ahead of time. There is a very customizable variant for this tool, where you can set distances between individual atoms, make a custom scaffold for your starting molecule, but 90% of the time, the presets tend to be sufficient.
Runs vary significantly between models/protocols used, some generative models can take several hours, while some will run a few seconds. We have tools that would screen against DBs if the goal is to find an existing molecule to act against the target, but often, people will import and existing starting point and modify it or design completely novel ones on the platform.
Good amount of both! I would say proprietary models tend to be fine-tuned versions of the published ones, although many will be completely new architectures. We also let folks fine-tune models with their proprietary data on Tamarind directly.
We do let people onboard their own models too, basically the users just see a separate tab for their org, which is where all the scripts, docker images, notebooks their developers built interfaces for live on Tamarind.
That's fair, I wish we were able to just add in a calculator for getting a price on a per hour basis, given your models of interest and intended volume.
We actually did have this available early on, our rationale for why we structure it differently now is basically that there is a lot of diversity between how people use us. We have some examples where a twenty person biotech company will consume more inference than a several hundred person org. Each tool has very different compute requirements, and people may not be clear on which model exactly they will be using. Basically we weren't able to let people calculate the usage/annual commitment/integration and security requirements in one place.
We do have a free tier which tends to be decent estimate of usage hours and a form you can fill out if and we can get back to you with a more precise price.
Thanks! I think advantages we had over previous generations of companies is that demand and value for software has become much clearer for biopharma. The models are beginning to actually work for practical problems, most companies have AI, data science or bioinformatics teams that apply these workflows, and AI has management buy-in.
Some of the same problems exist, large enterprises don't want to process their un-patented, future billion-dollar drug via a startup, because leaking data could destroy 10,000 times the value of the product being bought.
Pharma companies are especially not used to buying products vs research services, there's also historical issues with the industry not being served with high quality software, so it is kind of a habit to build custom things internally.
But I think the biggest unlock was just that the tools are actually working as of a few years ago.
I would say primary concerns were:
dependency issues, needing more than model weights to be able to consume models (Multiple Sequence Alignment needs to be split, has its own always on server, so on), more convenient if the inputs and outputs are hardened interfaces as different envs
Our general findings in the BioML are that the models are not at all standardized especially compared to the diffusion model world for example, so treating each with its own often weird dependencies helped us get out more tools quicker.