The Cerebras Wafer-Scale Cluster appliance running Cerebras ML Software 2.10 supports SDK 2.10,
the current version of SDK software. Note that the current and future versions of the SDK will
match the ML software versioning scheme.The Cerebras Wafer-Scale Cluster appliance running Cerebras ML Software 2.5 supports SDK 1.4.
See here for SDK 1.4 documentation.The Cerebras Wafer-Scale Cluster appliance running Cerebras ML Software 2.4 supports SDK 1.3.
See here for SDK 1.3 documentation.
Summary
The Cerebras Wafer-Scale Cluster is our solution to training massive neural networks with near-linear scaling. The Wafer-Scale Cluster consists of one or more CS systems, together with special CPU nodes, memory servers, and interconnects, presented to the end user as a single system, or appliance. The appliance is responsible for job scheduling and allocation of the systems. There are two types of SDK jobs that can run on the appliance: compile jobs, which are used to compile code on a worker node, and run jobs, which either run the compiled code on a worker node using the simulator, or run the code on a real CS system within the appliance. We will walk through some changes necessary to compile and run your code on a Wafer-Scale Cluster. Modified code examples for supporting a Wafer-Scale Cluster can be requested from developer@cerebras.net. Note that there are currently some limitations for running SDK jobs on a Wafer-Scale Cluster. Unlike ML jobs, SDK jobs can only use a single worker node and CS system. See SDK Appliance API Reference for the full API documentation.Setup and Installation
First, learn about the components of the Cerebras Wafer-Scale Cluster here. The user interacts with the Wafer-Scale Cluster via a user node. Start by setting up a Python virtual environment on the user node:cerebras_appliance and cerebras_sdk Python wheels
in the virtual environment, specifying the proper Cerebras Software release:
Compiling
As an example, we’ll walk through porting GEMV Tutorial 1: A Complete Program. In the containerized SDK setup, this code is compiled with the following command:SdkCompiler::compile function takes four arguments:
- the directory containing the CSL code files,
- the name of the top level CSL code file that contains the layout block,
- the compiler arguments,
- and the output directory or output file for the compile artifacts.
--fabric-dims argument to compile for a real hardware run.
The SdkCompiler() constructor can take a few optional kwargs, including:
resource_cpu: amount of CPU cores on the WSC’s management node used by the compile job in units of 1/1000 CPU (default: 24000, or 24 cores)resource_mem: number of bytes of memory requested from the management node for the compile job (default:64 << 30, or 64 GiB)disable_version_check: specifies whether to ignore version differences between appliance client and server
kwargs can be used to
request less resources from the management node and increase the number of
simultaneously running jobs.
Running with SdkLauncher
In the containerized SDK setup, our Python host code for running is as follows:run.py and the compilation output is in the directory out,
we run it with the command:
--cmaddr flag.
We provide an SdkLauncher class for running host code directly
from a worker node within the appliance. This class allows files to be staged on the
appliance before running the same host code that you would with the Singularity container.
We demonstrate below using SdkLauncher to run the host code for the example above.
We also include a demonstration of stage for transferring a file to the appliance.
To pass a system address to a run script when using SdkLauncher,
the user must use the %CMADDR% template string, as demonstrated below.
Running with SdkRuntime Bindings
Note
The
The
SdkRuntime appliance bindings are deprecated. Use SdkLauncher to
wrap an SDK host Python script instead.run.py script
and run this on the appliance:
- The imports have changed to reflect appliance modules.
- We read the path of our compile artifacts from the JSON file generated when compiling.
- We no longer need to specify a CM address when running on real hardware.
Instead, we simply pass a flag to the
SdkRuntimeconstructor specifying whether to run in the simulator or on hardware. load()andrun()are replaced bystart().- We must use a context manager
for the runner object.
If we do so, the
start()andstop()functions are implicit, and we do not need to explicitly call them.
Appliance Logging
When running with the appliance, you can control the level of appliance-related logging printed to the console. By default, the logger for the appliance is set toWARNING, which means only WARNING
and higher level messages will be enabled. You can set the level of the logger directly
to enable other levels, such as INFO or DEBUG. For example:
Appliance Job Monitoring and Management
Jobs can be monitored on the cluster with thecstcl CLI tool. Find more information on cluster
job monitoring and csctl in the
Cerebras training docs.
Ctrl-C can be used to cancel a running job.