adiraja
Joined 3 years ago
Joined 3 years ago
Also regarding the no rate limits, we agree this is a real challenge and it's part of why we're interested in building this as well. I think the clever GPU utilization tricks are exactly what we're building out and also looking forward to see what the various issues we're going to run into at such scale.
But across all users on our system, the throughput is better because doing more prefills or a large number of grouped decodes has better utilization of the GPU.
The idea is that this works for someone who wants to build a product that is consistent across users in terms of initial response but can trade-off some E2E latency. It ensures that no one is waiting for a long time before getting the first response.
So this means that you end up either having many decodes wait for prefills to complete or you end up scheduling decodes with prefills. Both scenarios result in slower decodes which is why we're seeing an increase in the ITL. This is the main tradeoff we've made.
When building our dev tool we decided to try out runtime injection of these statements with Python AST rewriting. You basically highlight a region in VSCode / Cursor, say the type of AST injection you want to do, it stores it in a config and you can use our SDK to inject this code at runtime without actually editing your source code.
We don't want to limit this to just TorchRecord and NVTX markers, so if you think you could benefit from this, we'd really appreciate contributions and suggestions for new injectors - or tell us why you think this is a terrible idea :)
SDK - https://github.com/nCompass-tech/ncompass Extension - https://open-vsx.org/extension/nCompassTech/ncprof-vscode