(I feel sure I've answered essentially this question before, but I can't find a dupe.)
OpenSSL partly created, and supports, two (or four depending how you count) types of PEM formats for private keys.
Your first file, with BEGIN EC PRIVATE KEY (and no Proc-type,DEK-Info inside), is the 'traditional' or 'legacy' format which is specific to one algorithm, EC. It contains the private key in the format defined by SEC1 from SECG and also available as rfc5915, then encoded/wrapped as 'PEM' i.e. base64 with linebreaks and header/trailer lines.
Your second file, with BEGIN PRIVATE KEY, is the 'new' (since about 2000!) PKCS8 format which is generic and covers all algorithms. Actual PKCS8 was first published by RSA Labs and has become harder to find since RSA was acquired by EMC and that by Dell but is also available as rfc5208, again encoded/wrapped in PEM. This format (but not the legacy format) is among several PEM formats which are updated and restandardized in rfc7468 (see section 10, even though the TOC doesn't hyperlink it correctly!)
Both of these have unencrypted and encrypted variants, which some people count separately (hence my two or four). Your Q uses only unencrypted forms of these files, and also of the OpenSSH new format (more below).
Although formatted differently, they do contain the same key:
$ cat se218335.a; openssl pkey -in se218335.a -noout -text
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBaYCj/CjZjq9aYehcvyejxqx5WVJ3OnfNbBq2+7iKyJoAoGCCqGSM49
AwEHoUQDQgAE1Rcx8Zo84aqSWqT/7i5NN7p+PI6dRfGdFFJapfcBlMhMjFsJkrxh
vncLphHuZHBoEILRMKf7hfVJ+tMwHMxQMA==
-----END EC PRIVATE KEY-----
Private-Key: (256 bit)
priv:
    16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
    3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
    ac:89
pub:
    04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
    4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
    01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
    ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
    30:1c:cc:50:30
ASN1 OID: prime256v1
$ cat se218335.b; openssl pkey -in se218335.b -noout -text
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgFpgKP8KNmOr1ph6F
y/J6PGrHlZUnc6d81sGrb7uIrImhRANCAATVFzHxmjzhqpJapP/uLk03un48jp1F
8Z0UUlql9wGUyEyMWwmSvGG+dwumEe5kcGgQgtEwp/uF9Un60zAczFAw
-----END PRIVATE KEY-----
Private-Key: (256 bit)
priv:
    16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
    3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
    ac:89
pub:
    04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
    4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
    01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
    ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
    30:1c:cc:50:30
ASN1 OID: prime256v1
OpenSSH began using the OpenSSL legacy formats (RSA and DSA as well as EC) decades ago, and ssh-keygen has never only recently (8.1 in 2021-10) been upgraded to write PKCS8, although it and the ssh and sshd (and ssh-add) programs have been able to read PKCS8 since almost forever, because they actually call OpenSSL library routines that can handle both types. In particular after extracting the pubkey and configuring it, I can use either of your files to authenticate just fine:
$ ssh -i se218335.a localhost echo hi
hi
$ ssh -i se218335.b localhost echo hi
hi
If you are having a problem using the second file and want to solve it, you might ask about that.
Per comment by https://security.stackexchange.com/users/277838/westfarmer (even though it wasn't really in the Q):
OpenSSL can convert between the formats it implements (traditional and PKCS8), as well as PKCS12 which is not relevant here.
# any non-ancient OpenSSL:
openssl pkey <in >out # reads PKCS8 OR trad, encrypted or not, and writes PKCS8 unencrypted
openssl pkey <in >out -$cipher # e.g. -aes128 same but writes PKCS8 encrypted
# OpenSSL 3.0.0 up
openssl pkey <in >out -traditional # reads any, writes traditional unencrypted
openssl pkey <in >out -traditional -$cipher # same but writes traditional encrypted
# all of the above work for all key types, not just EC(DSA)
# (although OpenSSH cannot use OpenSSL-format key for Ed25519)
# and where the input and/or output is encrypted you are prompted for the password(s)
# or you can specify -passin arg and/or -passout arg per the man page on your system 
# or at https://www.openssl.org/docs/manmaster/man1/openssl-passphrase-options.html 
# OpenSSL below 3.0.0, for EC (which can actually be ECDSA, ECDH, ECMQV) only
openssl ec <in >out # reads any, writes traditional=SEC1 unencrypted
openssl ec <in >out -$cipher # same, writes traditional=SEC1 encrypted
ssh-keygen can read traditional or PKCS8 OR since 6.5 OpenSSH's 'new' format with labels BEGIN/END OPENSSH PRIVATE KEY as shown in the Q and analyzed in the other answer; it can write traditional (except for Ed25519) since forever but in 7.8 up you must specify -m PEM, PKCS8 since 8.1 if you use -m PKCS8, or new format since 6.5 if you specify -o and since 7.8 by default. To get it to convert a keyfile just run it with the options -p -f $file to change the password; it reads whatever format the input is in, and writes whatever format you specify or allow to default, encrypted if you specify a password and unencrypted if you enter an empty string (just hit return). You can use options -P 'old' -N 'new' instead of being prompted. If the input is encrypted and you specify the new password to be the same as the old, you haven't really changed the password but you have rewritten the file in a possibly-different format. ssh-keygen can also import or export the public key in the rfc4716 format used by the 'commercial' SSH, ssh.com aka Tectia.
For near-completeness, the puttygen utility in the PuTTY suite can, in addition to generating keys, convert between (most or all of) the OpenSSH formats plus PuTTY's own 'PPK' format AND the ssh.com/Tectia format (which are both different yet again). puttygen works (very) differently between Windows and Unix/Linux and exactly what conversions and cases it supports have changed between versions, so investigating that is left (for now?) as an exercise.