This is the multi-page printable view of this section. Click here to print.
Lambda GPU Cloud provides instant access to high-performance cloud GPUs at the best prices on the market.
Looking to use our new API?
Read our documentationWith Lambda GPU Cloud, you have:
Requests to the Cloud API are generally limited to 1 request per second.
Requests to the /instance-operations/launch endpoint are limited to 1
request every 10 seconds.
You can launch an instance from the command line using the Cloud API:
Create a file named request.json that contains the
necessary payload.
For example:
{
"region_name": "us-east-1",
"instance_type_name": "gpu_1x_a100_sxm4",
"ssh_key_names": [
"SSH-KEY"
],
"file_system_names": [],
"quantity": 1
}
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instance-operations/launch -d @request.json -H "Content-Type: application/json" | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
You can list your running instances from a command line using the Cloud API.
First, generate an API key. Then, run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instances | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
You can list the instances types offered by Lambda GPU Cloud by first generating an API key, then running the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instance-types | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
It currently isn’t possible to pause (suspend) your instance rather than terminating it. But, this feature is in the works.
Until this feature is implemented, you can use persistent storage to imitate some of the benefits of being able to pause your instance.
You can use the Cloud API to:
Following these instructions won’t add the SSH key to existing instances.
To add SSH keys to existing instances, read our FAQ on using more than one SSH key
To add an existing SSH key to your account:
Generate an API key if you don’t have one already.
Create a file named ssh-key.json that contains the
necessary payload.
For example:
{
"name": "my-new-key",
"public_key": "ssh-ed25519 KEY COMMENT"
}
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/ssh-keys -d @ssh-key.json -H "Content-Type: application/json" | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
To generate a new SSH key pair:
Generate an API key if you don’t have one already.
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/ssh-keys -d '{ "name": "my-generated-key" }' -H "Content-Type: application/json" | jq -r '.data.private_key' > my-generated-private-key.pem
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
The private key for your SSH key pair will be saved as
my-generated-private-key.pem.
Run chmod 400 my-generated-private-key.pem to set the correct file
permissions for your private key.
To list the SSH keys saved in your account, generate an API key if you don’t already have one. Then, run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/ssh-keys | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
To delete an SSH key from your account, generate an API key if you don’t already have one. Then, run the following command:
curl -u API-KEY: -X DELETE https://cloud.lambdalabs.com/api/v1/ssh-keys/SSH-KEY-ID
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
Replace SSH-KEY-ID with the ID of the SSH key you want to delete.
If you want to save data even after you terminate your instance, create a persistent filesystem.
When you create a persistent filesystem, a directory with the name of your
persistent filesystem is created in your home directory. For example, if the
name of your persistent filesystem is PERSISTENT-FILESYSTEM, the directory
is created at /home/ubuntu/PERSISTENT-FILESYSTEM. Data not stored in this
directory is erased once you terminate your instance and cannot be
recovered.
We can’t estimate how much your job will cost or how long it’ll take to complete on one of our instances. This is because we don’t know the details of your job, such as how your program works.
However, the performance of our instances is close to what you’d expect from bare metal machines with the same GPUs.
In order to estimate how much your job will cost or how long it’ll take to complete, we suggest you create an instance and benchmark your program.
Check out our GPU benchmarks to form a general idea of the performance provided by our instances. Keep in mind that real-world performance doesn’t always match the performance provided by benchmarks.
For help benchmarking or optimizing your ML jobs, contact our Machine Learning team.
We currently don’t support Kubernetes, also known as K8s.
On-demand instances are billed in one-minute increments from the moment you spin up (start) the instance up to the moment you terminate (stop) the instance.
Be sure to terminate any instances that you’re not using!
You will be billed for all minutes that an instance is running, even if the instance isn’t actively being used.
The GPU Cloud dashboard allows you to view your resource usage.
Invoices are sent weekly for the previous week’s usage.
On-demand instances require us to maintain excess capacity at all times so we can meet the changing workloads of our customers. For this reason, on-demand instances are priced higher than reserved instances.
Conversely, we offer reserved GPU Cloud instances at a significant savings over on-demand instances, since they allow us to more accurately determine our capacity needs ahead of time.
To reset your Lambda Cloud password, visit the Reset Password page.
The dashboard makes it easy to get started using Lambda GPU Cloud.
From the dashboard, you can:
To launch an instance:
Click Instances in the left sidebar of the dashboard.
Then, click Launch instance at the top-right of the dashboard.
Click the instance type that you want to launch.
Click the region in which you want to launch the instance.
Click the persistent storage file system that you want to attach to your instance.
If you don’t want to or can’t attach a persistent storage file system to your instance, click Don’t attach a filesystem.
Select the SSH key that you want to use for your instance. Then, click Launch instance.
Review the license agreements and terms of service. If you agree to them, click I agree to the above to launch your instance.
In the dashboard, you should now see your instance listed. Once your instance has finished booting, you’ll be provided with the details needed to begin using your instance.
You can also launch instances using the Cloud API.
You can also use the Cloud API to get details of a running instance.
Restart instances by clicking the checkboxes next to the instances you want to restart. Then, click Restart at the top-right of the dashboard.
Terminate instances by clicking the checkboxes next to the instances you want to terminate. Then, click Terminate at the top-right of the dashboard.
When prompted to do so, type in erase data on instance, then click Terminate instances.
To create a persistent storage file system:
Click Storage in the left sidebar of the dashboard.
Then, click Create filesystem at the top-right of the dashboard.
Enter a name and select a region for your file system. Then click Create filesystem.
You should now see your persistent storage file system listed in the dashboard.
To add an SSH key that you already have:
Click SSH keys in the left sidebar of the dashboard.
Then, click Add SSH key at the top-right of the dashboard.
In the text input box, paste your public SSH key. Enter a name for your key, then click Add SSH key.
To generate a new SSH key:
Instead of pasting your public SSH key as instructed, above, click Generate a new SSH key. Type in a name for your key, then click Create.
The private key for your new SSH key will automatically download.
Delete SSH keys by clicking Delete at the far-right of the SSH key you want to delete.
Generate API keys by clicking API keys in the left sidebar of the dashboard.
Then, click Generate API Key at the top-right of the dashboard.
Delete API keys by clicking Delete at the far-right of the API key you want to delete.
Use the Demos feature by clicking Demos in the left sidebar of the dashboard.
View usage information by clicking Usage in the left sidebar of the dashboard.
Click Team at the bottom of the left sidebar to access the Team feature.
Learn how to manage a Team by reading our FAQ on getting started with the Team feature.
Click Settings at the bottom of the left sidebar to modify your account settings, including your password and payment method.
The Demos feature allows you to easily share your Gradio machine learning app (demo) both publicly and privately.
To get started using the Demos feature, you need to:
The new instance hosting your demo can be used like any other Lambda GPU Cloud on-demand instance. For example, you can SSH into the instance and open Jupyter Notebook on the instance.
As with other Lambda GPU Cloud on-demand instances, you’re billed for all of the time the instance for your demo is running.
The Demos feature can be hosted on multi-GPU instance types. However, Demos uses only one of the GPUs.
Also, demos currently can’t be hosted on H100 instances.
In the left sidebar of the dashboard, click Demos. Then, click the Add demo button at the top-right of the dashboard.
The Add a demo dialog will appear.
Under Demo Source URL, enter the URL of the Git repository containing your demo’s source code.
The Demos feature looks in your Git repository for a file named
README.md. If the file doesn’t exist, or if the file doesn’t contain the
required properties, you’ll receive a Demo misconfigured error.
The README.md must have at the top a YAML block containing the
following:
---
sdk: gradio
sdk_version: GRADIO-VERSION
app_file: PATH-TO-APP-FILE
---
Replace GRADIO-VERSION with the version of Gradio your demo is built
with, for example, 3.24.1.
Replace PATH-TO-APP-FILE with the path to your Gradio application file
(the file containing the Gradio
interface code),
relative to the root of your Git repository. For example, if your Gradio
application file is named app.py and is located in the root directory of
your Git repository, replace PATH-TO-APP-FILE with app.py.
Properties other than sdk, sdk_version, and app_file are ignored by
the Demos feature.
If you don’t yet have your own demo, you can try the Demos feature using the demos created by Lambda’s Machine Learning team. Demos created by Lambda’s Machine Learning team include:
Under Visibility, choose:
Under Name, give your demo a name. If you choose to make your demo public, the name of your demo will appear in the Lambda library of public models. The name of your demo will also appear in your demo’s URL.
(Optional) Under Description, enter a description for your demo.
The description shows under the name of your demo in your library of demos. If your demo is public, the description also shows under the name of your demo in the Lambda library of public models.
Click Add demo, then follow the prompts to launch a new instance to host your demo.
Your new instance will take several minutes to launch and for your demo to become accessible.
The link to your demo might temporarily appear in the Instances dashboard, then disappear. This is expected behavior and doesn’t mean your instance or demo is broken.
The models used by demos are often several gigabytes in size, and can take 5 to 15 minutes to download and load.
Once your instance is launched and your demo is accessible, a link with your demo’s name will appear under the Demo column. Click the link to access your demo.
To see a gallery of all of your demos, at the top-right of the Demos dashboard, click the See your demos button.
If you experience trouble accessing your demo, the Demos logs can be helpful for troubleshooting.
To view the Demos log files, SSH into your instance or open a terminal in Jupyter Notebook, then run:
sudo bash -c 'for f in /root/virt-sysprep-firstboot.log ~demo/bootstrap.log; do printf "### BEGIN $f\n\n"; cat $f; printf "\n### END $f\n\n"; done > demos_debug_logs.txt; printf "### BEGIN journalctl -u lambda-demos.service\n\n$(journalctl -u lambda-demos.service)\n\n### END journalctl -u lambda-demos.service" >> demos_debug_logs.txt'
This command will produce a file named demos_debug_logs.txt containing the
logs for the Demos feature. You can review the logs from within your instance
by running less demos_debug_logs.txt. Alternatively, you can download the
file locally to review or share.
The Lambda Support team provides only basic support for the Demos feature. However, assistance might be available in the community forum.
If you’re experiencing problems using the Demos feature, running the above
command and
providing the demos_debug_logs.txt file to the Support team
can help with future improvements to the Demos feature.
Here are some examples of how problems present in logs:
### BEGIN /home/demo/bootstrap.log
Cloning into '/home/demo/source'...
Traceback (most recent call last):
File "<stdin>", line 17, in <module>
File "<stdin>", line 15, in load
File "pydantic/main.py", line 526, in pydantic.main.BaseModel.parse_obj
File "pydantic/main.py", line 341, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 3 validation errors for Metadata
sdk
field required (type=value_error.missing)
sdk_version
field required (type=value_error.missing)
app_file
field required (type=value_error.missing)
Created symlink /etc/systemd/system/multi-user.target.wants/lambda-demos-error-server.service → /etc/systemd/system/lambda-demos-error-server.service.
Bootstrap failed: misconfigured
### END /home/demo/bootstrap.log
### BEGIN /home/demo/bootstrap.log
Cloning into '/home/demo/source'...
Traceback (most recent call last):
File "<stdin>", line 17, in <module>
File "<stdin>", line 15, in load
File "pydantic/main.py", line 526, in pydantic.main.BaseModel.parse_obj
File "pydantic/main.py", line 341, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 2 validation errors for Metadata
sdk
unexpected value; permitted: 'gradio' (type=value_error.const; given=docker; permitted=('gradio',))
sdk_version
field required (type=value_error.missing)
Created symlink /etc/systemd/system/multi-user.target.wants/lambda-demos-error-server.service → /etc/systemd/system/lambda-demos-error-server.service.
Bootstrap failed: misconfigured
### END /home/demo/bootstrap.log
The Firewall feature allows you to configure firewall rules to restrict incoming traffic to your instances.
To use the Firewall feature:
Click Firewall in the left sidebar of the dashboard to open your firewall settings.
Under General Settings, use the toggle next to Allow ICMP traffic (ping) to allow or restrict incoming ICMP traffic to your instances.
ping and mtr to be able to reach
your instances, you need to allow incoming ICMP traffic.
Next to Inbound Rules, click Edit to configure incoming TCP and UDP traffic rules.
In the drop-down menu under Type, select:
In the Source field, either:
203.0.113.1.203.0.113.0/24.To allow incoming traffic from any source, enter 0.0.0.0/0.
If you choose Custom TCP or Custom UDP, enter a Port range.
Port range can be:
8080.8080-8081.(Optional) Enter a Description for the rule.
(Optional) Click Add rule to add additional rules.
(Optional) Click the x next to any rule you want to delete.
Click Update to apply your changes.
In the dashboard, click Team at the bottom-left of the dashboard. Then, click Invite at the top-right of the Team dashboard.
Enter the email address of the person you want to invite to your team. Select their role in the team, either an Admin or a Member. Then, click Send invitation.
Be sure to invite only trusted persons to your team!
Currently, the only differences between the Admin and Member roles are that an Admin can:
This means that a person with a Member role can, for example:
You can’t send an invitation to an email address already associated with a Lambda Cloud account. If you try to, you’ll be presented with a message that says there is already a Lambda Cloud account associated with the email address you’re trying to send an invitation to.
The person you’re inviting to your team must first close their existing Lambda Cloud account before they can be invited to your team.
The person you invited to your team will receive an email letting them know that they’ve been invited to a team on Lambda Cloud.
In that email, they should click Join the Team.
Until the person you invited to your team accepts their invitation, they will be listed in the Team dashboard as Invitation pending.
You can delete the invitation while it’s pending by clicking ⋮ where the person is listed in your Team dashboard, then choosing Delete invitation.
In the Team dashboard of the person you invited to your team, the person will see that they are on your team. In your Team dashboard, you’ll see the person you invited listed.
To change the role of a person on your team from Member to Admin, click ⋮ where the person is listed in your Team dashboard, then choose Change to Admin.
Conversely, to change the role of a person on your team from Admin to Member, click ⋮ where the person is listed in your Team dashboard, then choose Change to Member.
To close a teammate’s account, click the ⋮ where your teammate is listed in your Team dashboard. Then, choose Deactivate user.
To change the name of your team, click Settings at the bottom-left of the dashboard, then click Edit team name. Enter a new name for your team, then click Update team name.
You can
learn your instance’s private IP address
with the ip command.
You can
learn what ports are open on your instance
with the nmap command.
To learn your instance’s private IP address, SSH into your instance and run:
ip -4 -br addr show | grep '10.'
The above command will output, for example:
enp5s0 UP 10.19.60.24/20
In the above example, the instance’s private IP address is 10.19.60.24.
If you want your instance’s private IP address and only that address, run the following command instead:
ip -4 -br addr show | grep -Eo '10\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
The above command will output, for example:
10.19.60.24
You can use Nmap to learn what ports on your instance are publicly accessible, that is, reachable over the Internet.
First, install Nmap on your computer (not on your instance) by running:
sudo apt install -y nmap
Next, run:
nmap -Pn INSTANCE-IP-ADDRESS
Replace INSTANCE-IP-ADDRESS with your instance’s IP address, which you can get from the Cloud dashboard.
The command will output, for example:
Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-11 13:22 PST
Nmap scan report for 129.159.46.35
Host is up (0.041s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 6.42 seconds
In the above example, TCP port 22 (SSH) is publicly accessible.
If nmap doesn’t show TCP/22 (SSH) or any other ports open, your:
nmap -Pn INSTANCE-IP-ADDRESS only scans the 1,000 most common TCP ports.
To list your persistent storage file systems using the Cloud API:
Generate an API key if you don’t already have an API key.
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/file-systems | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
To open Jupyter Notebook on your instance:
You can restart instances from the command line using the Cloud API:
Generate an API key if you haven’t already generated one.
Create a file that contains the necessary payload. For example:
{
"instance_ids": [
"0920582c7ff041399e34823a0be62549"
]
}
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instance-operations/restart -d @INSTANCE-IDS -H "Content-Type: application/json" | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
Replace INSTANCE-IDS with the name of the payload file you created in the previous step.
You can retrieve the details of an instance from a command line using the Cloud API.
First, generate an API key. Then, run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instances/INSTANCE-ID | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
Replace INSTANCE-ID with the ID of the instance you want details about.
You can terminate instances from the command line using the Cloud API:
Generate an API key if you haven’t already generated one.
Create a file that contains the necessary payload. For example:
{
"instance_ids": [
"0920582c7ff041399e34823a0be62549"
]
}
Run the following command:
curl -u API-KEY: https://cloud.lambdalabs.com/api/v1/instance-operations/terminate -d @INSTANCE-IDS -H "Content-Type: application/json" | jq .
Replace API-KEY with your actual API key. Don’t remove the trailing colon (:).
Replace INSTANCE-IDS with the name of the payload file you created in the previous step.
By default,
Lambda GPU Cloud reserved instances
allow incoming connections only to TCP port 22, which is typically used for
ssh access.
To allow incoming connections to ports other than TCP port 22, the instance’s default firewall rules need to be modified.
iptables can be used to modify the firewall rules or disable the firewall
entirely.
The instructions below completely disable the firewall on the instance and don’t follow best security practices.
For security, firewalls should be configured to allow incoming connections only to the ports needed for specific services. For example:
http and https, respectivelysshsmtpThe instructions below provide a quick, simple, but insecure way to ensure network traffic between instances isn’t being blocked by a firewall.
We highly recommend that you:
Read the iptables manual page to
learn more advanced usage of iptables, including how to fine-tune firewall
rules
Configure your firewall rules to allow incoming connections only to the ports needed for the services that you’re running
To entirely disable the firewall on the instance, run the following commands:
sudo iptables -P INPUT ACCEPT # accept all incoming traffic by default
sudo iptables -P OUTPUT ACCEPT # accept all outgoing traffic by default
sudo iptables -P FORWARD ACCEPT # accept all forwarded traffic by default
sudo iptables -F # delete all rules in the filter table
sudo iptables -t nat -F # delete all rules in the nat table
sudo iptables -t mangle -F # delete all rules in the mangle table
sudo iptables -X # delete all non-built-in chains
To keep the firewall disabled after rebooting, run:
sudo iptables-save | sudo tee /etc/iptables/rules.v4 > /dev/null
The firewall that restricts traffic from the Internet to your Lambda GPU Cloud reserved instances is managed by Lambda.
Contact the Lambda Support team if you need this firewall’s rules to be modified.
You can use the Lambda Cloud Storage feature to save:
For saving the state of your system, including:
apt-getpipWe recommend creating containers using Docker or other software for creating containers.
You can also create a script that runs the commands needed to re-create your system state. For example:
sudo apt install PACKAGE_0 PACKAGE_1 PACKAGE_2 && \
pip install PACKAGE_3 PACKAGE_4 PACKAGE_5
Run the script each time you start an instance.
If you only need to preserve Python packages and not packages installed system-wide, you can create a Python virtual environment.
You can also create a conda environment.
Single-GPU instances usually take 3-5 minutes to launch.
Multi-GPU instances usually take 10-15 minutes to launch.
By default, all ports are open to TCP and UDP traffic. ICMP traffic is also allowed by default.
It’s possible to allow more than one SSH key to access your instance. To do
so, you need to add public keys to ~/.ssh/authorized_keys. You can do
this with the echo command.
This FAQ assumes that you’ve already generated another SSH key pair, that is, a private key and a public key.
Public keys look like this:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK5HIO+OQSyFjz0clkvg+48YAihYMo5J7AGKiq+9Alg8 [email protected]
SSH into your instance as you normally do and run:
echo 'PUBLIC-KEY' >> ~/.ssh/authorized_keys
Replace PUBLIC-KEY with the public key you want to add to your instance.
Make sure to keep the single quotes (' ').
You should now be able to log into your instance using the SSH key you just added.
You can make sure the public key has been added by running:
cat ~/.ssh/authorized_keys
The last line of output should be the public key you just added.
With the Cloud API, you can:
If an invoice remains unpaid after we’ve made 4 attempts to charge the card on file, we may suspend your account.
If your account is suspended, your running instances may be terminated and your files may be deleted without prior notice.
Eventually, all of your instances will be terminated and all of your persistent storage file systems will be deleted.
Your account will be permanently banned from Lambda GPU Cloud. Your account will be referred for collection. Legal action may be taken against you.
The bandwidth between instances in our Utah, USA region (us-west-3) can be up to 200 Gbps.
Bandwidth to the Internet can be up to 20 Gbps.
The bandwidth between instances in our Texas, USA region (us-south-1) can be up to 200 Gbps.
Bandwidth to the Internet can be up to 20 Gbps.
The bandwidth between instances in our Arizona, USA region (us-west-2) can be up to 3.7 Gbps when using the instances’ private IP addresses.
When using the instances’ public IP addresses, the bandwidth can be up to 3.5 Gbps.
Bandwidth to the Internet can be up to 10 Gbps.
The bandwidth between instances in our Virginia, USA region (us-east-1) can be up to 7.2 Gbps when using the instances’ private IP addresses.
Bandwidth to the Internet can be up to 10 Gbps.
The bandwidth between instances in our Arizona, USA (us-west-2) and Virginia, USA (us-east-1) regions can be up to 100 Mbps.
The bandwidth tests for connections between instances were performed using iPerf3.
The bandwidth tests for connections to the Internet were performed using Speedtest CLI.
If you’re seeing in your instance’s logs error messages about Timeout waiting for RPC from GSP!, the system software installed on your instance needs to be
upgraded.
nvidia-smi might also produce output similar to the following:
+-------------------------------+----------------------+----------------------+
| 4 NVIDIA A100-SXM... On | 00000000:8C:00.0 Off | 0 |
| N/A 34C P0 60W / 400W | 0MiB / 81920MiB | 0% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+
| 5 ERR! On | 00000000:91:00.0 Off | ERR! |
|ERR! ERR! ERR! ERR! / ERR! | 0MiB / 81920MiB | ERR! Default |
| | | ERR! |
+-------------------------------+----------------------+----------------------+
To upgrade the system software installed on your instance, run:
sudo apt update && sudo apt full-upgrade && sudo reboot
You can safely disregard the error message: “Uhhuh. NMI received for unknown reason […] .”
This error message might show up in, for example:
/var/log/syslog.dmesg.journalctl.The error message results from a bug in AMD’s newer processors, including processors used in our servers. The bug has no impact other than causing the “NMI received for unknown reason” error message to appear in system logs.
To learn more about the “NMI received for unknown reason” error message, see:
The Linux Kernel Mailing List (LKML) discussion about the bug.
The patch that suppresses the error message in newer versions of the Linux kernel.
If you try to launch an instance from the dashboard and see that the instance type you want is grayed out, then we’re currently at capacity for that instance type.
Unfortunately, the NVIDIA cuDNN license limits how cuDNN can be used on our instances.
On our instances, cuDNN can only be used by the PyTorch® framework and TensorFlow library installed as part of Lambda Stack.
Other software, including PyTorch and TensorFlow installed outside of Lambda Stack, won’t be able to find and use the cuDNN library installed on our instances.
Software outside of Lambda Stack usually looks for the cuDNN library files in
/usr/lib/x86_64-linux-gnu. However, on our instances, the cuDNN library
files are in /usr/lib/python3/dist-packages/tensorflow.
Creating symbolic links, or “symlinks,” for the cuDNN library files might allow your program to find the cuDNN library on our instances.
Run the following command to create symlinks for the cuDNN library files:
for cudnn_so in /usr/lib/python3/dist-packages/tensorflow/libcudnn*; do
sudo ln -s "$cudnn_so" /usr/lib/x86_64-linux-gnu/
done
Common reasons why credit and debit card transactions are declined include:
We don’t accept prepaid cards. We only accept major credit and debit cards.
We currently only support customers in the following regions:
Purchases made while using a VPN are flagged as suspicious.
We make a $10 pre-authorization charge to a card before accepting it for payment, similar to how gas stations and hotels do. If the card issuer denies the pre-authorization charge, then we can’t accept the card for payment.
Card purchases won’t go through if the CVV (security code) is entered incorrectly. Also, card purchases will be denied if the ZIP Code doesn’t match with the card billing address.
If none of these are applicable to you, contact the Lambda Support team for help.