Adding instance fields adds to both the instance object sizes as well as the size of the (internal) representation of the class to which field was added — so, due to the former (the object size increase) adding an instance field scale as follows: the more instance objects, the more memory consumed. Due to the latter (increase in metadata to represent the class) the representation of the class to which the instance field is added is minimally larger.
Adding overridable instance methods (and overriding in various implementations) adds to the size of the (internal) representation of the classes, though minimally. So, the more classes, the more memory consumed, but since this memory for class representation (code & vtables) will be shared among all instances, this will not increase the size of object instances.
You will have to consider your workload, but typically, even class count in the thousands is a small number, and, classes are usually fixed in number at runtime, whereas instances can be in the millions as they are dynamically created.
How should an abstract class require a value that will be constant for each subclass?
For memory consumption, the latter approach (overrides) is preferred for large numbers of instances.
Generally speaking (regardless of memory consumption), I would prefer using overrides since this is constant but different information for each subclass. If a subclass wants to have an internal field to assist them in implementation of this override, they can do that. But I find it a bit presumptuous to force that implementation on every subclass. (Further, you may find that it is not always a constant.)