> No. As far as Collage is concerned it just calls the abstract > CostEstimator::Estimate interface for each candidate partition, and can > remain ignorant as to where those costs come from. In the prototype it is > hard coded to tune, build and run locally to help us get going. Here at > OctoML we'll need to instantiate the interface to connect to our production > tuning/running/caching systems. In principle the interface could also be > instantiated to some analytical model a la the cascading scheduler, though > we're not planning to build one.
I'm thinking the CostEstimator object can just be passed into the CollagePartitioner to leave this extension point open. Ack. > I figured I'd at least measure that before adding a fix. But secondly, if > someone (the service, the user) is going to go to the trouble of caching the > optimal partitioning for a particular (model, targets) pair, why not just > cache the built artifact directly and skip all the bother? However let me > know if I over simplified and I can add that part back This might enable bring us to down to get the cost estimation but it will still explore the combinatorial partitioning possibilities of subgraphs x backends, right ? (lmk, if I am wrong here). I suppose having the abstraction might help a user to play around with what Collage generates as a base. I would consider that to be a useful feature -- even guide the next generation algorithm we might want to put there. In the absense of that, the user need to tweak the CostEstimator as a proxy. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1079276287 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/62/c1079276...@github.com>
