A single video game can fill 100 GB, 150 GB, or even 200 GB of storage. With a library of modern titles, the space disappears fast. Creators face similar pressure as video, audio and project files pile up.
Yet gamers and creators often work with only a fraction of what they have stored. A game library might hold dozens of titles while only a few get regular play. A video editor might store terabytes of footage even though a small portion of it is needed for the current project.
That reflects a broader data reality: As capacity needs grow with the full dataset, the data benefiting most from faster access is usually a smaller, constantly changing subset.
Historically, PC users have handled that distinction manually by keeping performance-sensitive data on a solid-state drive (SSD) and parking the rest on a high-capacity hard drive (HDD), moving files as priorities shift.
FireCuda Forge moves these storage placement decisions into the device. Forge is an external desktop storage device that pairs an HDD with an NVMe SSD that users can select and install. When plugged in, the computer sees one volume rather than two separate drives.
Alkemi™, the technology powering Forge's cache management, monitors workload activity and prioritizes relevant data in the SSD cache while the broader library remains on the HDD. Developing Alkemi meant solving a harder engineering problem: how to manage the cache as the active data changes.
Studying real gaming workloads
Caching is a well-established storage technique. Alkemi adds an adaptive layer, responding to workload behavior rather than relying on a single cache-management policy.
To understand how an adaptive cache should respond to real gaming behavior, our researchers needed workloads that reflected how video games actually interact with storage. Existing public datasets represented other environments, including content delivery networks and cloud block storage, so the team collected block-level I/O traces of the read and write requests generated by gaming workloads.
We then tested several caching policies against those workloads. Cache performance varied as access patterns shifted from one gameplay session to another, reinforcing a central insight behind Alkemi: The active data changes over time, and cache management needs to adapt with it. Overall, we tested Alkemi across numerous gameplay sessions representing 4.3 million I/O requests. Across those workloads, the cache achieved a 90% hit rate.
How the cache works inside Forge
With FireCuda Forge, the SSD serves as a cache for the HDD-based volume, so its capacity isn't added to the volume users see. The HDD determines the volume's capacity, while Alkemi manages the SSD cache in the background.
The practical benefit is that games and projects that would benefit from faster storage do not have to be manually moved onto a separate SSD volume as priorities shift. Alkemi handles those cache-management decisions inside the device.
The computer sees a single volume, while inside Forge an HDD, SSD cache, onboard processing, memory and an operating system work together. Cache management runs entirely within the device rather than depending on the host computer. A field-programmable gate array (FPGA) and embedded Linux provide the processing and operating environment for those storage-management functions.
Running the logic inside Forge also creates practical engineering constraints: It has to operate within the device's available compute and memory while working across host systems with different behaviors.
Adapting as the active data changes
Recurring activity creates access patterns the system can observe. Regularly played games, frequently used applications and active project files all generate signals Alkemi can use to manage the cache.
Those usage patterns also vary by workload. Gaming tends to be read-heavy, while creative workloads such as video editing involve repeated reads and writes across large datasets. Someone may play one game for weeks, switch to another, and then return months later. The library may remain essentially the same, while the data benefiting most from faster access has shifted.
Alkemi continues monitoring those access patterns and can adjust its cache-management approach as the workload changes. With separate drives, users have to manage which data goes where and revisit those decisions as priorities shift. Forge puts those storage-placement decisions inside the device while presenting a single volume to the user.
Games change, projects change and workloads change with them. FireCuda Forge lets the storage respond to those shifts. Alkemi adapts the cache as usage changes, moving storage-placement decisions into the device instead of leaving users to continually manage them across separate drives.
That's ultimately what the engineering behind Alkemi enables: a growing body of data that remains in one place, while the storage adapts to what the user is doing now.
LEARN MORE: Explore how FireCuda Forge adapts storage as usage changes.
