I would not treat this only as a request for a bigger builder.

NODE_OPTIONS=--max-old-space-size=7168 is probably too high for an 8 GB build environment. That setting only caps V8 old-space. The build still needs memory for Node native allocations, SWC, webpack, package-manager work, child processes, the OS, and file cache. With a 7 GB old-space cap, the process can run the builder out of headroom before garbage collection has enough room to recover.

I would test this first:

NODE_OPTIONS=--max-old-space-size=4096
NEXT_TELEMETRY_DISABLED=1

If that gets farther but still fails, try 5120. I would not set old-space close to the full machine limit.

The code splitting you listed mostly helps the runtime bundle. It does not necessarily reduce build-time memory if the AI/ML packages are still reachable from the Next.js app graph. With Hugging Face, TensorFlow, ONNX Runtime, and SDK packages in the same app, the important check is whether any file imported by app/, pages/, layout, route handlers, or client components imports the AI stack directly or indirectly.

I would split the dependency graph like this:

1. Keep the Next.js service focused on UI, routing, auth, and API calls.
2. Move model, embedding, inference, and document-processing code into a separate worker or API service.
3. In the Next.js app, import only a small HTTP client or typed interface for that worker.
4. Make sure no client component, shared layout, or common lib/* helper imports the AI modules indirectly.
5. Run npm ls @tensorflow/tfjs onnxruntime-node plus the package-manager equivalent for your Hugging Face packages, then remove anything that is not needed by the web build.

For Railway, I would use one of these paths:

1. Reduce builder pressure inside Railway:

NODE_OPTIONS=--max-old-space-size=4096
NEXT_TELEMETRY_DISABLED=1

Then rebuild after isolating the AI/ML imports from the web app graph.

1. Split the app into two services:

web: Next.js standalone app
worker/api: AI, ML, embeddings, document processing

The web build should not need to install or compile the whole AI stack.

If the web app truly needs more than the Railway builder can provide, build outside Railway in CI with a larger runner, publish a Docker image, and have Railway deploy that image. Railway's own build docs mention building your own image and deploying it directly as the option when build behavior or cache requirements need more control.

If the build succeeds with a lower old-space cap after the AI/ML imports are isolated, the issue was builder headroom and dependency graph pressure, not just an absolute memory quota problem. If it still fails after the split, then a larger external build runner or prebuilt Docker image is the cleaner option than trying to force the whole monolith through the Railway builder.