The most important thing to understand is that even if you have more concurrent accesses than the concurrencyLevel, operations will still be thread-safe. That is, setting concurrencyLevel is a matter of performance, not correctness.
concurrencyLevel specifies the number of independent locks which are available for map operations. Each lock is associated with a different subset of the hash space, so accessing a given element requires holding a particular lock. This means that one thread’s access may block another thread’s, even if the number of concurrent accesses is well below concurrencyLevel. Raising the number of locks reduces the probability of lock contentions, but increases the cost of operations which must acquire all locks (those which examine the collection as a whole, such as Count, IsEmpty, or Values, as well as Add() when it needs to resize the table).
Profiling your application is really the only way to determine the optimal concurrencyLevel. Setting it to the expected number of worker threads is a good start, though.