AI applications do several kinds of work
Modal's homepage describes cloud infrastructure for teams that develop, train and serve AI applications. That range is significant. A product may need to serve a model quickly, run a long training job or execute code generated by an agent. Those tasks share a need for compute but differ in how they start, how long they live and what they are allowed to access.
Modal organizes its offer around primitives rather than one finished AI application. Its site names Functions for serverless compute, Sandboxes for untrusted code and Servers for low-latency language-model inference. The aim is to give developers components they can combine into a larger system. For a founder, the first question is therefore which workload the product actually has, not whether it belongs somewhere in the broad category of AI.
Functions and the code
The company describes running arbitrary compute-heavy applications and making cloud compute feel closer to local development. The Function is the starting building block in its founder's account of the business: developers write code and Modal runs it. That can be relevant when an application needs resources that are inconvenient to keep available on an ordinary web server.
The useful evaluation still depends on the code. Record its dependencies, inputs, expected duration and output size. Include a realistic dataset rather than only a tiny demonstration. Measure the time the customer experiences from request to usable result. A fast-running core calculation may still be surrounded by model loading, file movement and application work that determines the actual experience.
Sandboxes respond to generated code
Modal's October funding announcement says the company launched Sandboxes in 2023 after seeing language models produce code that needed an isolated place to run. The homepage now describes agent computers for work ranging from interactive coding to reinforcement-learning rollouts. That connects the platform to an important practical problem: generated code needs an execution environment, but it should not inherit unlimited access to everything around it.
Define the boundary before running a task. Which files can the code read? Can it contact the network? Does it receive a secret, and is that secret necessary? What persists when execution ends? Isolation is useful, but it does not decide the business permission for an action. A sandboxed process can still cause unwanted effects if it is deliberately given broad credentials or a writable connection to an important system.
Serving and training are separate evaluations
Modal also describes low-latency inference, multi-node training and reinforcement-learning infrastructure. Its site lists a custom container runtime, image system and distributed storage for models, weights and datasets. These components address the operational work around models, including getting large assets to the place where code runs. The relevant performance measure changes with the task.
For an inference service, inspect response time, failures and behavior under uneven traffic. For training, examine data access, checkpoint recovery and the resources required for a complete run. A platform can be suitable for one workload without being the best fit for another. Keep the comparison attached to a concrete application rather than treating every GPU job as equivalent.
Scale claims need a small-team interpretation
Modal says its infrastructure spans more than 20 clouds and describes on-demand autoscaling. Its October announcement reports a $750 million Series D at a $15.75 billion post-money valuation, alongside company-reported growth figures. Those statements explain its business direction and intended scale. They do not tell a small team its own bill, cold-start time or operational burden.
Run an evaluation that includes success, interruption and retry. Inspect logs and decide who will investigate failures after launch. Modal lists metrics, logs and export to OpenTelemetry providers as observability features, which are relevant to that ongoing responsibility. Before committing, check current resource prices and limits for the exact workload. The product's value is in making a specific application easier to run well. Read the related funding and infrastructure announcement for the company's latest business context.
Cost follows the complete workload
A compute evaluation should include every stage the application actually needs: preparing input, loading assets, running the task, storing output and recovering from failure. An isolated benchmark of the main calculation can miss costs and delays in the surrounding workflow. Keep the test close to the production path, including realistic files and dependencies.
For variable demand, examine an ordinary day and a burst rather than assuming an average request represents both. Decide what the application should do when work queues, a task fails or a user retries. The correct response may be to resume, reject or wait, depending on the product. Modal's primitives provide places to run that work, while the application team defines its behavior. This distinction helps turn a compute trial into evidence for a production decision rather than a collection of impressive peak numbers.
Record the deployment configuration with each measurement. A performance number is more useful when the team can reproduce the resource choice and understand which parts of the application it included.