Compute Strategy for VCs: AI-focused VCs raising funds now should 1.5-2x the amount they are targeting and spend the additional on reserved compute facilities that they allocate to portcos. Forward-thinking VCs are already doing this for late-stage funds and this strategy is starting to be adopted by growth and early-stage funds. Founders: If your lead VC cannot find you compute, that's not a lead, that's a co-investor. LPs: If a VC says they are investing in AI startups, ask them their compute strategy. 1. AI portcos will spend most of their money on compute anyway, so it is more efficient for VCs to directly acquire compute and benefit from economies of scale (pricing power, hard-to-acquire tacit knowledge) instead of each portco wasting time on it. 2. Compute will be very hard to find next year, so having compute becomes a serious capital differentiator i.e. access advantage, at the same time that most venture capital is becoming commoditized due to e.g. SPVs, crossovers. 3. Compute will likely become more expensive, so reserving compute now and offering "$50M worth of compute" in 6, 12 months may actually cost VCs much less than that. 4. VCs are positioned to bridge the creditworthiness gap between datacenters (i.e. their financiers) and startups. Because startups are new and unknown, they have to pay worse economic terms for GPUs and are often pushed to the back of the line for strategic reasons. The way that most startups get around this is to raise more money and lean on the prestige of their VCs. Consequently, VCs can and should make compute cheaper for their startups by loaning their prestige and name to compute procurement, directly. Example fund math and how to allocate a cluster: A serious early-stage fund should be raising $100-$200M today (If you want to do Seed and A in AI with less than that you are kidding yourself). Out of a $200M early-stage fund, perhaps 40% should be reserved for initial capital, 30% for follow-on, and 30% for compute (I'm eliding fees and overhead). That gets you $60M for compute. At a fictive price of $4.8 / GPU-hour for B300s, that's just about enough for a 64 node B300 cluster (512 GPUs) for 3 years. With a 64 node / 512 GPU cluster you should plan to allocate roughly like this (illustrative): * 1x 32 node block dedicated to large training jobs, held for 3-6month chunks * 1x 16 node block as a bridge cluster for R&D / training, held for 3 month chunks * 3x 4 node blocks as bridge clusters for inference, held for 1 month chunks * 4x 1 node blocks as flex blocks for compute grants to potential founders, nonprofit support, "spare change under the couch cushion" type capacity for portcos, held for 6-8 week chunks. Depending on your portfolio needs, you will want to adjust this schedule, but you want to hold a very large subset of the GPUs aside for large training jobs and as bridge capacity, a small amount as flex capacity and grants, and a medium amount for inference to help bridge for portcos. To be blunt, this is a very small amount of compute for neolabs, and only helps with bridging shortages, not with long term needs or ramps. But it hopefully provides a sense of the minimum sizes that will be needed to play in this space. That's one example. More aggressive VCs will reserve larger clusters and count on follow-on funds to pay the remaining term, or explore alternative vehicles or liquidity lines to pay for the largest cluster they can get their hands on. Finding, pricing, and closing on compute is challenging today and will get a lot harder in Q1. I'll have a longer blog post about this soon.