All generally depend on the size of your application, its architecture, …
I would take the simple case of a Django application (or any application with an interface allowing the user to upload a photo, click on a button to analyze and receive the corresponding catecter as output).
Let’s suppose that you have finished training (and validating…) your model (let’s say of myModel class, inheriting of course from torch.nn.Module) and that you have saved it (with toch.save for example) : you have a ‘path/to/my/model/file’ file.
Let’s suppose that you have developed a small django application with a view main that takes the image uploaded by the user, switches to your model and returns the output to the front-end.
You must first move the file containing your model into your django application, as well as the myModel class.
def  myModel(...) :
	...
	...

def main(request) :
	...
	...
	img = request.GET["image"]
	
	img = conver_img_to_vector(img)
	
	img = torch.tensor(img)

	model = myModel(your params)
	
	model.load_state_dict('path/to/my/model/file')

	label = model(img) 
	return label

The main drawback of this method is that you have to load your model every time a new image is sent. One way to correct this is to initialize your model in the __init__.py file of your application:
model = myModel(your params)
model.load_state_dict('path/to/my/model/file')

Create a django view that you will call at the very beginning of your application to load your model.
In views.py.
import model # equivalent to : form __init__ import model
...
...
def main(request) :
	...
	img = request.GET["image"]
	
	img = conver_img_to_vector(img)
	
	img = torch.tensor(img)

	label = model(img) 

	return label

With this the instance of your model will be the same for the whole lifetime of the application (application scope, singleton design pattern…) : you will just be able to update the 'path/to/my/model/file' file from time to time and reload your application, without destroying the structure of the application.
But in many cases the web application execution environment is not a python environment like Django (Angular, …), or we don’t have enough space to store the models in the context of the application (case of mobile applications). In this case, instead of developing a single frontend+backend application like here, you’ll rather set up a Django api that receives an image request, calls the model and sends back the answer label: with this type of architecture any application made in any framework will be able to interrogate your api to make predictions, without really knowing what’s going on behind it.
This is just a very simplified description of what is done in practice for reasons of simplification.