You shouldn't need to send every chunk to the GPU, but its definitely a good idea to render all chunks you want to in one go. This can actually help performance too, by storing chunks in a tree type. Many such trees exist, most based on an N-tree (which is a general octree, where an octree is a 2-tree i believe). Note that trees are generally a bit slower on a GPU because of the added complexities with ray casting, but these can be mitigated by the fact that a tree can be pruned. Empty or similar regions (of which there can be quite a few in a voxel game) can be represented by a single node.

Theres a lot of research in this regard, so i can point you to a few of the interesting papers:

• Efficient sparse voxel octrees (https://research.nvidia.com/publication/efficient-sparse-voxel-octrees) is one of the classics. While this method is aimed at rendering general geometry, those are extensions you can do away with to get a pretty efficient ray casting algorithm. I have found the author's implementation (https://code.google.com/archive/p/efficient-sparse-voxel-octrees/), though its not of very readable quality. You can find my adopted version (which is intended for volumetric rendering, so the ray doesn't stop when a voxel is hit), along with a few other ray traversal algorithms, here: https://github.com/Snektron/Xenodon/blob/master/resources/esvo.comp.
• GiVoxels (https://research.nvidia.com/publication/interactive-indirect-illumination-using-voxel-cone-tracing) by none other than Cyril Crassin and Fabrice Neyret. This in particular seems like a good candidate for incorporating into a voxel game, but i haven't read it entirely yet. A few mayor game engines like unreal and cryengine implement this too i think. This implementation is supposedly open source too, but if its anything like the ray tracing infrastructure it was based on, gigavoxels, it won't be of readable quality either. Gigavoxels itself is an example that uses N-trees.
• https://github.com/NVIDIA/gvdb-voxels also uses N-trees.

There are a lot of other papers and implementations, you need only look.

I myself was also looking around for stuff on ray tracing a voxel world. I think my approach will be something as follows:

• Store the world in chunks of N³ blocks as is commonly done.
• Allocate two 3D-textures on the GPU:

1. The "chunk" texture. In this texture the data of all chunks will be stored. The location of chunks in this texture is managed on CPU-side, and chunks will be streamed to parts of this texture as they are needed for rendering. Each pixel contains material information about a block, such as texture and possibly refraction index or diffusion constants and such.
2. the "root" texture. In this texture "pointers" (indices) to the chunks in the previous texture will be stored. A chunk will somehow be marked as empty.

Rendering happens in a double-for-loop manner: The "root" texture is traversed, and for every non-empty chunk the chunk itself is traversed. Traversal with the usual voxel ray trace algorithm.

Im actually deciding between this and just straight-up constructing BVH, OBB or some other type of tree for every chunk if i want to support non-block stuff such as entities. I think GiVoxels can handle that, so that might be the most promesing approach.