The goal of encryption is typically to provide at least privacy: that is, unauthorized parties should not be able to determine the contents of the message. If you assume that there is an unauthorized party that wants to read the message, that unauthorized party might also want to modify the message. AES-CTR is extremely vulnerable to this in that changing a bit in the ciphertext results in the corresponding bit changing in the plaintext.
Thus, you absolutely need a MAC or an AEAD, since your goal is presumably to properly secure the message. If you do not care about securing the message, then there is no need to encrypt it, either.
Using an AEAD in this case is extremely fast. AES-256-GCM on my laptop can encrypt at over 6.9 GB/s, AES-256-OCB can encrypt at over 9.6 GB/s, and even ChaCha20-Poly1305 can encrypt at 2.7 GB/s. ChaCha20-Poly1305 will perform better on machines without AES acceleration, and the other two will perform better on machines with AES acceleration. Assuming you properly verify the tag and use them in a secure way, all of these are solid, respectable choices for algorithms, and they can usually encrypt faster than you can write the data to disk or over the network, so performance is usually not a concern.
If you're going to encrypt or decrypt large amounts of data, you can simply use a chunked approach with a chunk counter in the additional data, and then use a standard cryptographic library like OpenSSL to do the encryption and decryption, which is secure and very easy to do.
Note that if you do not use a MAC or AEAD, then your software will contain a security vulnerability, and someone will likely issue a CVE for it, which you'll then need to address. Since you'll have to fix the problem then anyway, you might as well design a secure approach in the first place, which will be faster and easier than having to do it later on, and it will also make users have more confidence in your software.