<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>FedorAS: Federated Architecture Search under system heterogeneity · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2206.11239/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2206.11239/feed.xml" rel="self" type="application/rss+xml" /><item><title>FedorAS: Federated Architecture Search under system heterogeneity — mentioned by niclane7</title><link>https://news.ycombinator.com/item?id=35262726</link><guid isPermaLink="false">urn:hackerpapers:mention:2206.11239:35262726</guid><pubDate>Wed, 22 Mar 2023 15:37:09 GMT</pubDate><description>&lt;p&gt;Yes, this would be exciting to see. One approach wouldn&amp;#x27;t require federated learning however. If you had direct access to the data then you could build a conventionally trained large language model (i.e., collect all the data together placed in a data center). However, given the context of this discussion -- you are probably asking about if we could use Flower to train in a federated manner. I believe so. Although again, we&amp;#x27;d probably be training a LLM which brings added complications due to its size (and other factors). Internally at Flower we have been testing methods to overcome this and…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2206.11239/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.LG</category></item></channel></rss>
