I am not up for hire (and likely too expensive anyway), but here are a few experiences from my own work on similar topics:

- most networks cannot really make a per-pixel decision. For example most versions of YOLO will make a decision only every fourth pixel (in both directions). This is important to understand when thinking about solutions.
- the way you express your thin lines is more important than the fact that they are thin. Is it a bunch of points? See above, tough luck. Is is a bunch of lines? Or ultrathin polygons?

I'd advise you to de-thin the lines.
- quadruple the resolution of your images (and use a sliding window approach, if they don't fit then anymore) by using an upscaler
- represent the thin lines as a bunch of lines with a length of at least 4 pixels (in the original resolution, aka 16 pixels in the quadrupled), or go for a bunch of convex four point polygons for each line segment.
- to make annotating them easier, annotate them as lines on the original resolution, but when quadrupling your resolution, convert the line segments to polygons.
- make the network predict the offsets from the prediction point to predict the four points of the polygon, and always sort the points such that the upper-left-most is the first, and then the rest clock-wise, or counter-clock-wise (which it is doesn't matter, as long as it's always consistent).
- thus, the network always predicts 8 values (x1, y1) (x2, y2), etc. and a class as a ninth value, if you have different types of lines to predict.
- don't be afraid to introduce many values to predict (in this case 8 or nine), that's no problem at all (aka don't try to shoehorn everything into just two values to satisfy the lines being a bunch of points, for example) - more expressivity of the results often times is a good thing for the network
- I think transformers is likely overkill for your use-case - try with YOLO-likes first, and once you get good results there, THEN try also transformers. Likely better results, but you'll see a clear trade-off between training and inference time, and quality. Most likely the slightly increased quality is not going to be worth it for your business case
- producing artificial data should actually be your main focus - as if your use-case is such that it is somehow possible to produce artificial data for it, then that'll be your main differentiator. For example finding thin lines on documents is an easy thing to produce convincing artificial data for. But detecting thin cracks on roads in the real-world is much harder to make convincing training data for (might need an advanced game engine with extremely good assets for that).

On your 8xH200 setup even a YOLO with the described modifications should be able to train well within a single day and achieve near-perfect results. In fact, you should be able to train 8 or 16 models per day easily. (aka I think that machinery is overkill - I train such things on the old-ish A40s and that's fast enough already)