deepspeed mii fastgen example

[lxning]

Description

Please read our CONTRIBUTING.md prior to creating your first pull request.

Please include a summary of the feature or issue being fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #(issue)
#2780

Type of change

Please delete options that are not relevant.

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

Feature/Issue validation/testing

Please describe the Unit or Integration tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

• Test A
  Logs for Test A

• Test B
  Logs for Test B

Checklist:

• Did you have fun?
• Have you added tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

[mreso]

Overall is LGTM but I would like to move the check on LOCAL_RANK up the chain.

[mreso]

This low level method should not be concerned about checking the LOCAL_RANK env environment. We should just not call it when its not "0".

[lxning]

The checking is a central control to avoid this checking in handler implementation.

[mreso]

I see the intention here. I still think this is not the preferred place to put this check. The function creating a response from some arguments should not need to know about the concept of ranks. In fact we already have a central point to check for the rank in this PR which is here.
The only point where this is missing is here. Looking at this I think we should move send_intermediate_predict_response out of ts.protocol.otf_message_handler (Users should not need deal with the modules containing our comms between fe/be. What if we drop otf protocol?). My first instinct is to move it under ts.handler_utils. What do you think?

[lxning]

I'm fine to move it to handler_utils. The only concern is backward compatibility. It will break existing cx.

[mreso]

AFAIK we do not guarantee bc as of now. Its probably time to plan out our bc strategy for future release as we're running out or 0.X version numbers. Anyways, if your concern is very high you can leave a wrapper in otf_message_handler that fires a deprecation warning and then calls the one in handler_utils until next release. cx will only get worse if we let the code rot.

[mreso]

Could you check the deprecation decorator? I've added some checks to your test that should pass but every time foo is called the warning is emitted again.

[lxning]

Could you check the deprecation decorator? I've added some checks to your test that should pass but every time foo is called the warning is emitted again.

A deprecation warning message will be triggered once the deprecated function is called. For example, Two warning messages will be emitted if func foo is called twice in the test. This is what I expected. I updated the assertion:

Replace

assert len(record) == 0

with

assert len(record) == 2

[mreso]

Could you check the deprecation decorator? I've added some checks to your test that should pass but every time foo is called the warning is emitted again.

A deprecation warning message will be triggered once the deprecated function is called. For example, Two warning messages will be emitted if func foo is called twice in the test. This is what I expected. I updated the assertion:

Replace

assert len(record) == 0

with

assert len(record) == 2

@lxning If that is the expected outcome, can we remove this?

serve/ts/utils/util.py

Line 14 in 839782a

simplefilter("once", category=(PendingDeprecationWarning, DeprecationWarning))

[lxning]

Could you check the deprecation decorator? I've added some checks to your test that should pass but every time foo is called the warning is emitted again.

A deprecation warning message will be triggered once the deprecated function is called. For example, Two warning messages will be emitted if func foo is called twice in the test. This is what I expected. I updated the assertion:
Replace

assert len(record) == 0

with

assert len(record) == 2

@lxning If that is the expected outcome, can we remove this?

serve/ts/utils/util.py

Line 14 in 839782a

simplefilter("once", category=(PendingDeprecationWarning, DeprecationWarning))

Good catch. Remove this unused func. Thanks!

[mreso]

LGTM