Great catch @skyshard! This definitely should be added. Would you like to submit a PR for this?

Hi @Michaelvll,

I'd like to pick this up. Thanks!

Hi @Michaelvll,

As far as I know, DiskTier is currently defined with four levels, low to ultra, and the best option also points to ultra, as shown here. For GCP, each tier maps one-to-one to a specific disk type, as illustrated in the following lines:

To support new disk types like hyperdisk-ml, I was thinking about introducing a GCP-specific DiskTier that includes additional tiers such as ACC_LOW, ACC_ULTRA, etc., optimized for accelerated workloads. Would that approach make sense to you? I’d love to hear your thoughts!

Also, I have a couple of questions:

1. How can users know the disk cost before spinning up the VM? I ask because I don’t see disk costs reported in the cost table. For instance:
   

I also noticed that disk costs aren’t currently considered during optimization:

2. How can users verify whether a given disk type is compatible with a specific instance_type before launching? As shown in the following figure, --disk-tier low should map to pd-standard, but this GCP docs doesn’t list pd-standard as a supported disk type for the a3-high series. Hence, I would expect an error raised in this case.

Thanks a lot!

Hello @JiangJiaWei1103 ! This is such an interesting problem, thanks for raising it. I took a look at the relevant code and found this:

1. GCP class's _get_disk_type function is only called from _get_disk_specs within the same class
2. GCP class's _get_disk_specs is only called from make_deploy_resources_variables within the same class. make_deploy_resources_variables is defined in the parent Cloud class, so its signature must stay the same.

Notably, when _get_disk_specs is called from make_deploy_resources_variables, the caller has access to the instance type.

I am wondering if we can pass the instance type all the way through to _get_disk_type, at which point we can implement all sorts of logic to get the correct disk given the desired type and the instance type. It could make SkyPilot really smart at figuring out the best disk type to use for specific instance type, for example.

This way we don't have to add more disk types specific to GCP - and specifying ultra disk tier for those high end GPU machine would work.

edit:

As for your question 2:

2. How can users verify whether a given disk type is compatible with a specific instance_type before launching?

There is check_disk_tier_enabled in GCP class, but also - with the changes described above, perhaps we can make low disk tier work for a3 instance types by having it pick some other disk tier actually compatible with it.

As for question 1:

How can users know the disk cost before spinning up the VM?

I don't actually have a good idea on this.

tangentially related: found this issue re: question 1

Hi @SeungjinYang,

Thank you so much for the insightful suggestions! To make sure I fully understand your proposal, I’ve opened a draft PR to illustrate the idea. The core concept is to use both instance_type and disk_tier to determine the appropriate disk type. For example, a combination like ("a3-ultragpu-8g", "ultra") could map to hyperdisk-extreme. I’ve included a simple implementation here:

Running sky launch -t g2-standard-4 --disk-tier ultra --dryrun yields:

Once confirmed, I’ll close the draft PR and follow up with a proper implementation.

Regarding question 2, do you mean we could automatically elevate the disk tier (e.g., from LOW to MEDIUM,which maps to pd-balanced) if a given tier isn’t supported by the selected instance? If so, we might also consider displaying a message to inform users about the tier elevation.

As for question 1, I’d love to dive deeper into that topic. Thanks for sharing the issue link. It’s so helpful to think about incorporating disk cost into optimization!

Took a look at the PR, direction looks good!

As for Q2, I was thinking more on the lines on mapping LOW tier to pd-balanced directly for higher specced SKUs that don't support pd-standard. With the change with hyperdisk-extreme SkyPilot is already starting to take an opinionated stance on what performance means in context of instance type, and I don't see a reason SkyPilot shouldn't be more opinionated elsewhere.

Sounds great! I’ll draft a mapping proposal for both general CPU and GPU instances and share it here. We can then continue the discussion and see if the mapping aligns with your expectations. Thanks!

Hi @SeungjinYang,

As you mentioned, SkyPilot can be more opinionated in selecting a better resource type (e.g., disk type) based on the instance type. Before we decide on the actual mapping between instance types and disk types, I’d like to share some relevant information.

According to the GCP doc, Google recommends using Hyperdisk due to several key advantages, such as customizable performance (you can adjust a Hyperdisk volume’s performance without changing its size), as well as superior IOPS and throughput limits. This section also provides guidance on choosing a suitable disk type. One crucial point is:

use Hyperdisk if it's available for your machine series.

If I'm not mistaken, this clearly suggests that Hyperdisk is preferred over Persistent Disk whenever it is available. Below is a table summarizing the disk type support for the instance types currently supported by SkyPilot GCP:

References: General-purpose machine family for Compute Engine, Accelerator-optimized machine family

Given the diverse combinations, if we aim to subjectively select the most suitable disk type based on a user-specified disk_tier (ranging from LOW to ULTRA), I’d love to hear your thoughts on what a good strategy would be to map (instance_type, disk_tier) to the supported disk types shown in the table above!

For N1 and N1+GPU, we can stick with Persistent Disks. Similarly, for A3 Mega and A3 High, it’s reasonable to default to Hyperdisks. However, the mapping for the remaining instance types is still open for discussion. Thanks!

Looking at this document on hyperdisks - there is one restriction that, for better or worse, makes this design simpler:

Hyperdisk Extreme, Hyperdisk ML and Hyperdisk Throughput volumes can't be used as boot disks.

Which leaves hyperdisk-balanced as the only disk type that is suitable for our use case. I agree that for A3 Mega and A3 High, it’s reasonable to default to Hyperdisks. Given that other VM types don't support hyperdisk-balanced, we can have these other VMs default to pd types.

Edit:
This does mean for instance types like G2, pd-balanced and pd-ssd are actually the only valid storage options for the boot disk. I didn't want to believe it so I checked the web console - it really is just those two.

So in cases like G2, we may have to pin HIGH/ULTRA/BEST to pd-ssd :< not how I expected the conclusion here to be, but this is indeed how GCP works.

As a meta comment, I'm actually quite happy/excited whenever I encounter less-than-intuitive behaviors like this on cloud providers - to me, being able to navigate things like this is where Skypilot should shine.