Quant Trading Bot Devlog

한국어로 보기

Removing a Secondary GPU - A Fail-Loud Registry Flagged the Blast Radius Instantly

Pulled a secondary graphics card ahead of a planned sale, and the fail-loud checks I'd already built pinpointed the exact impact the moment the system rebooted.

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

The system stayed off from Friday night to Sunday, and a secondary GPU came out

The system stayed powered off from Friday evening through Sunday afternoon while a secondary graphics card (a different brand from the main one) got physically removed.

The plan is to sell this card if a week goes by with no issues. A full check after rebooting showed the main GPU and the integrated graphics were fine, and the slot the secondary card used to occupy now shows a different storage device instead.

Two red alerts turned out to be working exactly as designed

Right after reboot, a boot-check unit and a power-cap unit both immediately flipped to a failed state.

Both are built to detect "the registered card list doesn't match the actual hardware" and fail loudly instead of quietly limping along. Seeing them turn red right on schedule was actually confirmation that the design worked as intended.

Handed the "is this really safe" question to another AI tool

The working assumption was that both the overnight production path and the intraday secondary-analysis path were already running entirely on the main GPU, so removing the secondary card shouldn't break anything. Another AI tool was asked to verify that assumption against the actual logs.

After digging through the logs, the AI confirmed the assumption held — none of the currently active paths depended on the secondary card.

It did flag a few dormant, not-currently-used features that are coded to refuse to start at all without the secondary card. Since those were already switched off and kept around purely for preservation, that wasn't an immediate problem.

Started with a minimal cleanup, then held off once the blast radius turned out bigger than expected

The initial plan was to only make the easily-reversible change: drop the secondary card's single line from the registry.

That one line broke far more tests than expected — ten instead of the anticipated two. So that change got rolled back, and the plan was to just tolerate the red alerts for the rest of the observation week.

Later that evening, the call changed to "just finish the cleanup now"

Later the same evening, the decision shifted away from leaving things half-done toward finishing the cleanup properly right away.

The secondary card got fully removed from the registry, and the tests that broke as a result were fixed with a dedicated test fixture that makes the secondary card appear present only inside the tests that need it. The actual code now assumes the card is gone; only the tests simulating the old hardware fake its presence where necessary.

The power-cap unit got disabled, and the four resident processes tied to this change were restarted and came back up clean. The boot check was re-run and passed.

All the related tests — over 400 of them — passed. The remaining dormant features will get cleaned up once the sale is finalized.

#quant #trading bot #devlog #operations #hardware #GPU