开放权重AI为何重要：芯片架构与EDA部署面临的机遇与挑战

Key Takeaways:

• Local inference and model routing can help manage cost and protect sensitive data, but chip architects must account for memory capacity, sustained performance, changing models, and deployment security.
• For EDA, model quality depends on clean, trusted design data and integration into workflows, not just on choosing a larger model or fine-tuning its weights.
• Open weights can reduce dependence on proprietary AI services, but they do not automatically provide open training data, source code, or unrestricted usage rights.

Open-weight AI models are creating new challenges for chip architects as rapidly changing workloads strain memory, interconnects, and compute flexibility.

The focus is no longer just peak TOPS. The checklist has grown to include the best way to feed memory-hungry models, sustain performance across long-context and multi-agent inference, support rapidly changing numeric formats and sparse computation, and isolate models, data, and tools as part of the security boundary. Model architectures can change in weeks while silicon takes years, so the winners will build adaptable hardware-software platforms, rather than accelerators optimized for a benchmark that may be obsolete before tape-out.

Massive data centers are not a prerequisite for AI-driven scientific advances. Science has different infrastructure needs from consumer AI platforms serving millions of users. Open-weight AI models — whose trained parameters are publicly available — can be deployed locally, potentially widening access, improving compute efficiency, and supporting independent research.

Open weights also raise questions about control, cost, and who can build on AI technology.

Sharad Chole, chief scientist and co-founder at Expedera, said publishing weights can reduce vendor lock-in as it allows users to host a model themselves or choose a service provider. “If you want to use a service, or host it yourself, there is no vendor lock-in in terms of who is providing the next token for you or who is servicing your next request. But there are geopolitical and investment sides to it. There is also a push for open hardware, like what Meta and others do to enable different competing solution providers. As of September 2026, the larger open-weight models come primarily from outside the U.S., either Europe or Asia, and we are moving toward trillion-parameter models.”

Open-weight models make trained parameters downloadable, letting users run and adapt them on their own hardware rather than relying on a provider’s API, according to Guillaume Boillet, vice president of strategic marketing at Arteris. “They are not necessarily open source: training data, code and usage rights may remain restricted.”

While open-weight AI model releases publish trained parameters, open-source releases aim to publish the full recipe, and closed models publish neither, said Ashish Darbari, CEO of Axiomise.

Representative open-weight releases include Meta Llama, Alibaba Qwen, DeepSeek, Mistral, Google Gemma, Microsoft Phi, and OpenAI’s gpt-oss family. OpenAI reports that gpt-oss-120b runs on a single 80 GB GPU and gpt-oss-20b can run on devices with 16 GB of memory; both use MXFP4 quantization, Darbari noted. “These specifications illustrate the widening range of deployment options, but memory fit alone does not establish useful performance.”

Some U.S.-based AI companies use knowledge distillation to develop smaller models from larger teacher models, but approaches vary. Smaller models may also be pretrained independently or developed through a mix of techniques. Large-scale pretraining remains computationally intensive, while distillation and post-training are important parts of the model-development process.

Chole said the largest models continue to push toward trillion-parameter scales, while models intended for devices or local AI are often distilled into smaller versions. “It’s not like suddenly we’re going to have 100-billion-parameter models breaking all the benchmark records,” he said. He cited an effort to distill a 400-billion-parameter DeepSeek-C model into an 8-billion-parameter Qwen model, while noting that model distillation itself is not new. The broader point is that users now have many choices across model size, capability, and deployment method, and the largest model is not necessarily the right choice for every task.

On Hugging Face, the ‘GitHub for AI models’, there have been approximately 250 open-weight models released in the last two years by major companies, not including quantized variants or models from smaller companies, Chole noted.

But abundance is not the same as readiness, and turning this expanding model catalog into useful design intelligence requires EDA teams to supply trusted domain data, workflow context and rigorous ground truth.

From general-purpose models to EDA workflows
Whether commercial or open-source, general-purpose LLMs aren’t built for chip design tasks, according to Thomas Andersen, vice president for AI and machine learning at Synopsys. “A lot of them are very good at common tasks. They’re very good at creating PowerPoints and summarizing things. They’re good at coding, obviously, because there’s a lot of code out there. Those have been optimized to death. They’re not necessarily well suited to hardware development, not even the RTL coding, because even the RTL that’s out there is just not nearly as much as software. Because of that, every party, including EDA vendors and customers, needs to add their data, and that data is obviously proprietary. This is the difference versus all these models that take public knowledge and put it into the training data. There are both pre- and post-training capabilities, even beyond the weights themselves, where you can add data, and that’s an important key point. Otherwise, it just doesn’t work. It’s like asking a chatbot a question. It doesn’t always give the right answer because it has conflicting data, searches the internet, and people say all kinds of things. What’s the ground truth?”

Accurate results rely on both the query and the quality of the source data.

“The source data itself needs to be very clear, very crisp,” Andersen said. “On the internet, it doesn’t exist. You go on Reddit, people will say five different things when you ask them a question. That becomes the problem of the LLM. In our case, we obviously need very crisp data. In a corporate environment, it’s different. You have much better documentation of processes, of tools, and so on, so it’s a little bit easier. Without that, it doesn’t work. Still, general training of run-of-the-mill models is absolutely required.”

That said, open-weight models will have a place in chip design. “An open-weight model simply means you have an LLM model where you can train the weights of the model,” Andersen explained. “Agentic is a loop that sits around this LLM and then does certain tasks, so it’s a means to an end. There are multiple ways to train the model, which is more like tuning the answer’s correctness, but it doesn’t actually add data itself. There are other ways to add data. Once you have, let’s say, an LLM that knows everything the way you as a human would, then agentic just means you’re building an agentic loop that essentially optimizes your workflow, that does a sequence of tasks the way you as a human would do, rather than one-shot things. Or, you just ask a question and it comes back.”

That distinction between the model and the workflow around it leads directly to a practical deployment question: How should EDA teams route each task to the right model while balancing capability, cost, and control?

Ankur Gupta, executive vice president and head of EDA IC software at Siemens EDA, noted that anyone who is super cost-conscious, from a big chip design company to a small one, still wants to optimize. “They want to pay for the best commercial model, as long as it fits the task, so key architects can solve the hardest problems. It’s called model routing. We know that open-weight models are very useful. They’re effective. EDA companies are playing with them. We certainly are. Many of our developers are using open-weight models extensively because you don’t need to go pay a bunch of money for every single task. And I see this in our customers. They have pulled back on opening up the highest-strength models to everybody, and they’re doing model routing internally. We haven’t.”

Gupta suggests thinking about it in the context of an iceberg. “What you see above the water level is GPU and costs and tokens and all that. That’s on every CIO’s dashboard. It hasn’t gone away. What’s under the surface is also equally important. It’s connecting the silicon to the system to the facilities. There’s lossiness there that you have to recover cost from. Somebody’s going to figure out how to make token cost very viable, just like the entire semiconductor industry has been operating that way, like building in functionality and making that functionality cheaper. It’s just a matter of time before that happens.”

Steven Woo, fellow and distinguished inventor at Rambus, sees open-weight AI models as very helpful to chip designers. “You look at the success stories from companies like OpenAI with the Jalapeno chip and using their own tools, having a smaller team that was both nimbler and more able to do more turns more quickly. Designing that chip in nine months and getting it to work the first time out was incredible. We know that work has been going on in this area, and the tools are just getting better.”

The caveat is that organizations need to maintain control of data that distinguishes them from competitors. “In the beginning, when you had to access these things on the web, there weren’t private, walled areas where a company could ensure its data stayed inside, and many companies were reluctant to let employees use the technology,” Woo said. “But the industry heard and said, ‘Okay, well now we’re going to set up walled areas where we can be certain that your information won’t leak.’ The general idea of how to design a chip — for example, writing RTL to do certain functions and doing place-and-route — there are many examples out there that you can use to train a large language model or an AI entity to do this. Different industries and different companies have very specific ways they approach solutions to problems. Those you can’t really let out because they’re more like trade secrets. So then the question is, ‘How do I take these models that are trained on more general sets and tune them — really fine-tune them — to the specifics of what I do and what my customers care about, and that can’t leave the walled area?’ I’m hopeful that that kind of thing gets solved.”

Open-weight AI models might also be useful in the EDA tool flow to help control costs. “Cost is a big deal, and we want our customers to pay us, not the AI vendors,” said Chuck Alpert, AI fellow at Cadence. “The idea is that open-weight models are going to help keep the costs under control for customers. How do we do that? If you have an open-weight model, you can put it on a machine and never leave your network. If you’re using, say, Claude Opus [a closed, proprietary model by Anthropic], you have to leave the network. Some customers — maybe defense customers especially, who are very sensitive about their information — are part of an ecosystem that says they want to use agentic AI but don’t want to leave their system. A customer like that has to use Openlayer [an enterprise AI evaluation, observability, and governance platform]. There’s also currently the issue that open-weight models may not perform well. They’re getting better, and I’m finding some of them are quite good. But they’re still lagging, which is where doing some training of open-weight models could be a real improvement and an important development, and that we’re actively pursuing.”

One of the keys here is clearly defining the problem statement. “If you think about what chip design is, there’s a massive, multi-physics component, and then you distill it down to a math model, which is extensive — it could be 100,000 lines of the transistor model,” said Mo Faisal, CEO of Movellus. “After that, it is just matrix multiplication. When and how, I’m not sure, but it probably will be one of the new startups that is building semiconductor-specific models. They may start opening up the older things that are maybe trained on 180nm, and you can go build a chip of that and not open up whatever works with the more advanced nodes or more advanced architectures. There’s probably a surprise coming from the Googles or Microsofts or Metas of the world. Why can’t they open-weight their silicon models, since they do have internal silicon design models that they use?”

That possibility shifts the discussion from whether open-weight models can serve EDA to how their business model shapes where — and on what hardware — those models are deployed.

Distinguishing features
Open- and closed-weight models can use similar underlying architectures.

“The architectures are the same — the same transformer blocks, the same attention mechanisms, the same quantization tricks,” said Steve Roddy, chief marketing officer at Quadric. “A chip architect looking at the two would not be able to tell them apart from the compute graph. The difference is entirely a business model distinction. One vendor publishes the parameters for download, the other sells access by the token.”

That difference is what drives deployment. “In practice, the small and mid-sized open-weight models are the ones technically sophisticated users — engineers mostly — download and run on their own hardware, and the motivation is overwhelmingly cost,” Roddy said. “Some run locally to keep prompt data private, and that matters in regulated industries, but token economics is by far the bigger driver today.”

Roddy expects the closed-model vendors to come after that local token volume. “It would surprise no one to see the large private model companies orchestrate split deployments — a midsize front-end model running on the user’s own hardware, with the large model in the cloud handling what the local model can’t. Those big model companies absolutely do not want some other vendor or other model running locally to become the front door that gates access to the big paid model in the cloud. The pricing incentive is obvious — offer dramatically cheaper (maybe free) tokens for the ones the user generates on their own machine, on their own electricity, and cut the data center rental bill enormously. When an offhand tweet (Sam Altman, April 2025) says that the cost of users typing ‘thank you’ runs to tens of millions of dollars, the pressure to offload inference to the edge is not subtle.”

All of that puts pressure on local machines to run larger models, or portions of those models that are disaggregated into smaller models. “The world cannot build data centers fast enough, and it is not going to. But we can plug something the size of a household appliance into every home and office,” Roddy said. “That opens a new category of compute — the agentic computer, architected around running AI models as its primary workload, not as an afterthought bolted onto a phone or PC designed for something else. Today’s devices treat inference as a guest. The next generation will treat it as the host. The question chip architects should be asking is not, ‘How do I add an NPU to my SoC?’ It’s, ‘What does a system look like when model execution is the main job?’ Memory bandwidth and capacity, not TOPS. Sustained throughput, not burst benchmarks. Thermal envelope for continuous rather than intermittent load. And a software stack that can absorb a new model architecture every few months without a silicon respin.”

One of the problems here is the mismatch between chip and model cycles. “If you’re designing a chip for a particular model, models are changing on a weekly basis, or at best monthly, and your chip design cycle is in the best-case scenario 2.5 years,” said Vishal Chandrasekar, director of product management at Ayar Labs. “So how you are intercepting something over that kind of a time frame is hard to see. At the same time, chips that were made in 2019 are still valuable today, because now maybe you’re compute-limited. So a model that’s released today, even if there are 10 new models in two years, is still useful for some application.”

That mismatch makes adaptability the central design requirement — and it frames the practical questions chip architects must answer before committing to an open-weight AI platform.

Solaiman Rahim, chief product officer at ChipAgents, said chip designers should understand that the weights are open, so anyone can use them. “Not only the weights, but also the task list and the dataset they were trained on are provided with the model. So, if anybody wants to rebuild the model, they can. The goal of open-weight models is to give you a base model you can fine-tune to your needs, and performance and cost vary depending on the model. People think open-weight models perform poorly and cost little, but that’s not true. If you look at the latest open-weight model, GLM 5.3, the performance is pretty good. It’s in the 70% to 80% range, but the cost is also very high. It’s not because it’s open-weight that you necessarily get the lowest performance and the lowest cost. The cost and performance of many open-weight models really depend on which model you’re using. But it’s a good base model to fine-tune and build your workflow on top of to get your desired outcome. You also need to figure out how to integrate an open-weight model into your infrastructure.”

Deployment may be on-premises or in a cloud environment such as a virtual private cloud, depending on security requirements and whether a company is comfortable sharing data with its provider. “If you go to AWS, their cloud is very secure. Many customers use VPCs in AWS or other cloud providers, so you need to decide how you want to deploy that model,” Rahim said. “The model alone isn’t enough to start a cost-effective design task. You need to build the ontology layer yourself. You have to build the workflows. Our platform does that automatically so you don’t spend your time and investment trying to reinvent the same way that EDA was built 30 years ago. When everyone did their own synthesis, they came up with Design Compiler, which showed them they could do it with one and didn’t need to reinvent everything. The same thing is happening right now. We have our ontology, our workflows, and our own model layer. Our model layer can pick the best model for you automatically based on the task.”

Other considerations the architecture and design team should ask about include defining the range of models the system must support rather than predicting a single future model size, said Arteris’ Boillet. “Important variables include active parameter count, precision, context length, modality, concurrency, and latency. Teams should ask whether a smaller specialized model is sufficient, where the working set will reside, and how energy use changes under realistic loads. The meaningful measure is energy per useful result, not just TOPS or TDP.”

Taken together, those workload variables turn model selection into a system-architecture problem, with direct consequences for memory, compute, interconnect, and verification.

Axiomise’s Darbari noted that if more inference moves out of hyperscale data centers, it could shift inference silicon toward institutional servers, workstations, laptops, and edge SoCs running 1 billion to 100 billion parameter mixture-of-experts models locally, with a number of architectural implications such as:

1. Memory bandwidth, not FLOPS, as the binding constraint;
2. Sparse activation to change the arithmetic;
3. Low-precision in the ISA and datapath;
4. Heterogeneous SoCs as the delivery vehicle;
5. Mini-fridge servers as a real product category, and
6. Verification and PPA sign-off exercising MoE-style sparse traffic, MXFP4 arithmetic, KV-cache pressure at 128K context, and multi-agent concurrency, not just dense GEMM.

Those architectural priorities become concrete when teams estimate what it takes not merely to fit a model in memory, but to run it responsively in daily engineering workflows.

“Capable language, vision-language, and reasoning models with 20 billion to 30 billion parameters can now fit in roughly 16 to 24 GiB of memory after quantization,” Boillet said. “In my own synthetic benchmark on a 36 GB MacBook, models in this range fit. But fitting in memory was not the same as running productively. For the responsiveness needed to replace cloud models in daily work and agentic workflows, the cost can still climb above $10,000. Chip architects need to size compute, memory, and interconnect for the intended application while leaving room for the model mix to change. Being open-weight does not change the underlying model arithmetic. It does let users change precision, sparsity, fine-tuning, and model structure, so memory bandwidth, data movement, numeric flexibility, and quality of service matter more than peak TOPS alone. A dense model and a mixture-of-experts model with the same total parameter count can load the system very differently. Security priorities include authenticating model files and updates, protecting memory and DMA paths, isolating workloads, and supporting rollback.”

Conclusion
Open-weight AI will not eliminate the tradeoffs facing chip architects, but it will make them more explicit. Successful platforms will be designed around adaptable model mixes, sustained memory and interconnect performance, realistic energy and latency targets, and security that extends from authenticated weights through runtimes, tools, and data. For EDA teams, the advantage will come not from choosing open or closed models in isolation, but from combining the right models with trusted domain knowledge, disciplined routing, and hardware-software systems that can evolve long after tape-out.