I realized that the FastTESR method of rendering (add vertices to a communal buffer, render buffer, throw away buffer and ask for more vertices) is, at least for my purposes, extremely wasteful. In my current situation, nothing changes location, so there's no need to discard the data after every frame, and reload it before the next.
As a result of this concept, I've mostly circumvented the system: no longer contributing to the buffer, and simply using the method as one that is called for each frame, for each tile entity.
Instead, when the graph is first loaded, I use the GlStateManager to generate a new call list (and delete the old one if it existed), and store the reference to this list within the TileEntity that I was given during FastTESR#renderTileEntityFast().
During subsequent frames, I then simply use GlStateManager#callList() to render the call list whose reference index is stored in the TileEntity.
It isn't a standard use of the FastTESR system, but it does produce a 7-fold performance improvement, or much more, depending on the circumstances.
The only problem this presents is that I'm no longer able to take advantage of the depth-sorting that's run on the vertices of the batched FastTESR buffer. This means that graphs are rendered "out of order," which is especially a problem for translucent ones.
I can fix the problem of individual graphs rendering out of order (e.g: a graph behind is rendered on top of one in front) by moving the actual rendering over to one of the rendering events, and then drawing the furthest graph first, etc, but I'm not sure if there's a way of fixing the order within a graph being off, while keeping to call lists (BufferBulder#sortVertexData() isn't applicable to call lists).
I'll keep looking, though.