Sedna's joint inference removes the SDK to make it convenient for users to use

[tangming1996]

What would you like to be added/modified:
At present, Sedna's joint inference tasks require users to write business logic based on the SDK provided by Sedna (that is, users' businesses need to be coupled with Sedna's joint inference framework). For users, this incurs a high cost of use. Firstly, users need to be familiar with Sedna's SDK, and secondly, they also need to be familiar with container technology. Undoubtedly, this will deter most users.
Based on the above pain points, we propose to strip the SDK from the inference paradigm. Users only need to perform simple model configurations and can achieve the rapid deployment of inference tasks without programming based on Sedna's SDK.
Why is this needed:
Reduce the usage cost for users.

[victorming666]

Great idea! We are on the edge of giving up Sedna, just as it intervines too much into our AI logic. From my view, users of Sedna only needs to care two things:

1. how models at cloud and edge to communicate: it's the protocol between cloud ai and edge ai. For example, input a image and output a json like '{result:{object_num:3,[obj_class,[bbx1,bby1,bbx2,bby2]...'; Sedna should leave this to users to define.
2. how to commit collaberation between cloud and edge ai: Sedna can provide some common pattern of collaberation, but the users can customize their own logic. Sedna should leave this to user to config instead of changing class_factory and rebuild and update the python api.

[MooreZheng]

Thank you all for your attention to the issues of usage cost and customization when using Sedna SDK. We could have a deep dive into this topic.

1. About the usage cost

• Using Sedna SDK is standardized work, which is critical for the community to reserve the possibility to align with other Sedna users and make algorithm-wise contributions. For instance, what is joint inference? Sedna aims to provide a standardized definition for the community instead of leaving the definition to users, which leads to chaos and breaks the bridge to share-and-harvest algorithms.
• BTW, once one gets familiar with the Sedna SDK, then not only one paradigm of joint inference but also all paradigms of Sedna could be used in the same way.
  Sedna SDK is a critical part of Sedna, like the global manager and local controller. Any move to strip a critical part from Sedna needs serious discussions.

2. About the issue of customization
   Sedna aims to provide edge-cloud collaborative AI templates, i.e., with the specific workflow.

• If one project looks like it fits the joint inference paradigm, then the AI part shall be following "the shallow model-hard sample mining -the large model", i.e., using Sedna SDK.
• If one project looks like it does not fit the current joint inference paradigm, then a paradigm or example can be provided using Sedna SDK. For instance, in the LLM joint inference case, routing (hard sample mining) could be used in a different order against the current joint inference design, so we are discussing establishing a new paradigm. Note that routing is still a critical part in the new joint-inference paradigm, with quite a few existing algorithms to fit as resources. In this case, state-of-the-art routing algorithms could be integrated into Sedna using Sedna SDK, and then all community members can benefit.

Sharing and harvesting algorithms require standardization, which might lead to extra learning and integration work. But in the end, it is worthwhile. The ability to share and harvest AI modules reflects why KubeEdge SIG AI is an AI community and what Sedna can do for the world. We can have more discussions to make this happen without too much cost.

[victorming666]

I agree that Sedna should be a route to coordinate Cloud AI and Edge AI. AI implementations on cloud and edge have different patterns in production. Cloud AI often runs on x86 servers with GPUs for fast and high throughput inference, and Edge AI normally runs on arm64 or risc-v boxes with NPU or something like that. The AI models running on cloud side and edge side have completely different formats. Normally these AI models are wrapped as Web Service for easy integration. So I think Sedna as the route should focus on communication and coordination instead of implementation of AI algorithms. From my point of view, Sedna's algorithms like joint-inference, federated learning or incremental learning are just toy-like, because real scenarios of AI cloud-edge collaberation are much more complex. It's unnecessary and impossible for Sedna to realize all these unseeable usages. Playing the role of route is enough.

[MooreZheng]

Sedna is designed to provide an edge-cloud collaborative AI framework that unifies resource orchestration, data governance, and model optimization across distributed environments. Many newcomers experience misunderstandings about Sedna due to unclear explanations of key concepts. As a co-founder of the KubeEdge-Sedna project, I try to clarify common misconceptions and core concepts.

Sedna paradigms: beyond algorithm implementation

A Sedna paradigm is NOT the implementation of an algorithm. Instead, it serves as a structural blueprint, acting as a framework or template. It underlies the design of a class of algorithms and thus an abstraction higher than a specific algorithm instance. Specifically, paradigms formalize essential algorithm components, to ensure infrastructure readiness (e.g., network connections and computation resources) for Sedna components before runtime.

Sedna has several built-in algorithm paradigms, such as joint inference, federated learning, incremental learning, and lifelong learning. Thus, the assertion that "Sedna focuses on algorithm implementations" is inaccurate and misleading given the understanding of Sedna paradigms.

Sedna examples v.s. business solutions

An example is NOT a business solution of algorithms. Sedna examples are simplified demonstrations of the proposed paradigm, illustrating its functionality.

• Since the paradigm is abstract, it is difficult for newcomers to understand how it works in detail. We then request that all paradigm founders provide at least one example each.
• The example is designed to be simple enough for newcomers to understand a paradigm with minimal deployment effort.

Business Solutions are production-grade implementations. Based on the established paradigms, Sedna has been utilized in more than 20 business solutions, including:

• Project Epidemic Surveillance for Shenzhen government using Multi-edge Joint Inference,
• Project Pangu Mining Large Model for Shandong Energy Group using Cloud-edge Lifelong Learning,
• Project Satellite Remote Sensing for Hunan xxxxxxx Constellation using Cloud-Edge Joint Inference.
• ...

20+ Sedna Case studies have been published in a Journal paper of 2024 and this blog. Proprietary business codes remain confidential due to contractual obligations, but the core components of Sedna—enhanced through these projects—are openly available. Claims that "Sedna's algorithms are toy-like" fail to recognize the proven scalability of these algorithms in critical applications.

Conclusion

Sedna’s mission is to establish edge-cloud AI paradigms that ensure reusability, adaptability, and readiness of runtime infrastructure, including network connections and computing resources.

We welcome further discussions to refine these paradigms and expand their impact.

[MooreZheng]

See more discussion in #477