GET requests should be idempotent, which means you can't invalidate the token once used because any repeat requests won't give the same response.
GET requests should also never make state changes to the system, therefore should not be required to have CSRF protection. Even logout should not be a GET request for the method that actually executes the logout (although you could have a GET link that navigates to another page before a POST request carries out the action).
To fix the idempotent problem, with a repeated GET request and with the same CSRF token supplied, you could display the cached response from the first request, without making any state change. However, you're still violating the standard if you make state changes at all, see rfc7231:
Request methods are considered "safe" if their defined semantics are
Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe.
As a side note, I would also argue that resource intensive processes should also be POSTs (with CSRF protection) rather than GETs, otherwise an attacker could DoS a system using a CSRF vector.
Therefore, if you need CSRF for a method, then don't implement this as a GET.