Skip to content

Conversation

cehongwang
Copy link
Collaborator

Description

Delete the extra copy INetworkDefinition creates

Fixes # (issue)

Type of change

Please delete options that are not relevant and/or add your own.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • My code follows the style guidelines of this project (You can use the linters)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas and hacks
  • I have made corresponding changes to the documentation
  • I have added tests to verify my fix or my feature
  • New and existing unit tests pass locally with my changes
  • I have added the relevant labels to my PR in so that relevant reviewers are notified

@github-actions github-actions bot added component: lowering Issues re: The lowering / preprocessing passes component: conversion Issues re: Conversion stage component: converters Issues re: Specific op converters component: api [Python] Issues re: Python API component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths labels Jun 17, 2025
@github-actions github-actions bot requested a review from gs-olive June 17, 2025 21:04
@cehongwang cehongwang force-pushed the cpu-memory-optimization branch from a609cfd to 85107c3 Compare June 17, 2025 21:56
@github-actions github-actions bot removed the component: converters Issues re: Specific op converters label Jun 17, 2025
@cehongwang cehongwang force-pushed the cpu-memory-optimization branch from 85107c3 to 53c1bcb Compare June 17, 2025 21:57
@cehongwang cehongwang force-pushed the cpu-memory-optimization branch from f147421 to 711446c Compare September 19, 2025 20:28
@github-actions github-actions bot added component: tests Issues re: Tests component: converters Issues re: Specific op converters labels Sep 19, 2025
@cehongwang cehongwang changed the base branch from main to moe-support September 22, 2025 23:48
@cehongwang cehongwang marked this pull request as ready for review September 22, 2025 23:48

class TRTInterpreterResult(NamedTuple):
serialized_engine: bytes
engine: trt.ICudaEngine | bytes
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@narendasan Should we set it to be engine when it is python runtime and serialized engine if it is cpp runtime? In this way we can do serialization in Interpreter.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can just be trt.ICudaEngineand post processing for the cpp runtime

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like I would have the CPP runtime determine if the engine is live or serialized, and if its live serialize the engine.

@github-actions github-actions bot removed component: tests Issues re: Tests component: converters Issues re: Specific op converters labels Sep 23, 2025

return rt_cls(
serialized_engine=interpreter_result.serialized_engine,
return PythonTorchTensorRTModule(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the rt_class still but there should be some preprocessing modifying the arguments


class TRTInterpreterResult(NamedTuple):
serialized_engine: bytes
engine: trt.ICudaEngine | bytes
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can just be trt.ICudaEngineand post processing for the cpp runtime


class TRTInterpreterResult(NamedTuple):
serialized_engine: bytes
engine: trt.ICudaEngine | bytes
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like I would have the CPP runtime determine if the engine is live or serialized, and if its live serialize the engine.

@needs_refit # type: ignore[misc]
def _insert_engine_to_cache(self, hash_val: str, serialized_engine: bytes) -> None:
def _insert_engine_to_cache(self, hash_val: str, engine: bytes) -> None:
serialized_engine = engine.serialize()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are doing this don't we end up paying the serialization cost again?

self.ctx.requires_output_allocator,
)
else:
serialized_engine = cuda_engine.serialize()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just have the TRTInterpreter return a live engine in all cases

def __init__(
self,
serialized_engine: Optional[bytes] = None,
cuda_engine: trt.ICudaEngine = None,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API should support both since uses may use this runtime independently, its just now we either support cuda_engine or serialized_engine

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing for the CPP runtime

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla signed component: api [Python] Issues re: Python API component: conversion Issues re: Conversion stage component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths component: lowering Issues re: The lowering / preprocessing passes component: runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants