Catalina A Musrri of the University of Sydney and Georgina Wood of Flinders University discuss the significance of underwater seaweed forests and how to preserve them.

A version of this article was originally published by The Conversation (CC BY-ND 4.0)

Australia’s Great Southern Reef is built not by coral but by seaweed. The seaweed forests on these rocky reefs stretch more than 8,000km around southern Australia.

Amid the swaying fronds live seadragons, rock lobsters, giant cuttlefish and southern blue devils. The reef is home to more than 1,500 seaweed species and contributes billions to the economy each year.

But these remarkable cold water forests face a worsening threat. The ocean is getting steadily warmer, pushing seaweed species outside their survival zone. Much of this damage is done by sudden marine heatwaves, where temperatures spike and remain high for some time. Heatwaves have driven the decline of seaweed forests across the country.

To protect these underwater forests, we need to preserve their genetic diversity. We led the first attempt to cryopreserve (freezing and storing reproductive material at ultra-low temperatures) a key Australian seaweed, crayweed, and found the idea shows promise, though the techniques need to be perfected.

Why does seaweed matter?

Most of us encounter seaweed as a slightly stinky mass spotted when walking along a beach. But underwater, these large algae (not plants) form beautiful forests swaying in the current – some as tall as 30 metres.

Seaweed forests are among the most productive ecosystems on Earth. Like forests on land, they provide habitat, shelter and food for many creatures. They underpin valuable fisheries such as lobster and abalone.

When local populations are wiped out, they take something important with them – genetic diversity. Species with high genetic diversity can better adapt to change. Some populations will be able to tolerate heat better, for instance. But if these populations disappear, their unique genes go with them.

In 2011, an extreme marine heatwave in western Australia led to two common seaweed species losing an estimated 30pc to 65pc of their genetic diversity. These losses may mean poorer outcomes in response to intensifying threats.

Consider the crayweed

Golden-brown crayweed (Phyllospora comosa) once formed extensive underwater forests along Sydney’s coastline. Many of these disappeared in the 1980s, likely due to sewage pollution. But crayweed didn’t return even after pollution levels fell.

Over the past 14 years, scientists and divers have replanted this species around Sydney through Operation Crayweed. Their work has led to the return of self-sustaining populations, including Australia’s first named seaweed forest – Yanggaa forest at Coogee Beach.

But restoration may not be enough in a rapidly warming ocean. Our research shows separate crayweed populations harbour unique genetic diversity – and some individuals appear better equipped to tolerate heat. It may make sense to plant germlings (baby seaweed) from these individuals in vulnerable populations to boost their chances of survival.

Of seed banks, biobanks and cryopreservation

For decades, thousands of land-based plant species have had their genetic diversity preserved through seed banks. The seeds stored are sleeping but still alive. If planted in the right conditions, they will grow.

Some kelp species can also be kept alive in biobanks – not as seeds, but in a microscopic form (gametophytes) able to be kept alive in laboratories for years. Current kelp collections support research, aquaculture and restoration programmes around the world, including in Australia.

These banks are important. But they won’t be enough. The majority of seaweed species dominating the Great Southern Reef are known as fucoids. Unlike true kelps, fucoids don’t have this microscopic life stage; they release sperm and eggs directly into seawater that fertilise and form germlings. This makes species such as crayweed, bull kelp (Durvillaea potatorum), Cystophora sp and Scytothalia dorycarpa more challenging to conserve.

It is possible to bank species which rely on sexual reproduction, such as humans, cows, corals and fucoids. Assisted reproduction methods such as IVF rely on cryopreservation: storing reproductive material, tissue or early life stages at ultra-low temperatures (around –196°C) so it remains viable for future use.

Our recent research tested whether frozen crayweed sperm and germlings were viable after being thawed. We found the sperm did well, but the germlings did not (for now). Our ultimate goal is to develop proven methods able to work across a broader range of Australian seaweed species.

Preserving the genetic diversity of seaweed species would mean these genes can be drawn on to bring them back. This buys valuable time and keeps the door open for new methods such as assisted gene flow, where individuals from better-adapted populations are used to help vulnerable ones cope with warmer conditions.

Time for seaweed biobanks?

Australia already has an impressive algal culture collection and is a global leader in coral cryobanking.

Even so, it will take real work to develop methods of preserving the forest-forming seaweed species that rely on sexual reproduction. We need to learn which populations contain unique or threatened genetic diversity, understand which are most vulnerable to climate change, and improve freezing and recovery techniques.

Choosing which species and populations should be done alongside indigenous custodians, governments, conservation organisations and local communities.

Cryobanking doesn’t solve climate change or replace the need to protect habitat. It’s an insurance policy for biodiversity. Much has already been lost. Preserving the remaining genetic diversity of our seaweed forests may well be critical to the survival of the Great Southern Reef.

By Catalina A Musrri and Georgina Wood

Catalina A Musrri of the University of Sydney recently completed her PhD in seaweed forest restoration in the context of climate change. She is interested in the impacts of climate change and other anthropogenic activities, such as pollution and overfishing, on coastal habitats.

Georgina Wood is an early career Australian Research Council fellow at Flinders University and adjunct research fellow at the University of Western Australia whose research focuses on repairing nature in a changing climate, particularly temperate kelp forest ecosystems.

Don’t miss out on the knowledge you need to succeed. Sign up for the Daily Brief, Silicon Republic’s digest of need-to-know sci-tech news.

Even as the geopolitical conversation around AI continues to grow more fraught following the U.S. government’s actions to limit the new models from Anthropic and OpenAI, Chinese open source darling DeepSeek is back with yet another open release that could once again change AI development around the globe.

Over the weekend, the firm released DSpark, a new, MIT-Licensed system designed to make large language models answer faster without changing what the underlying model is trying to say.

The easiest way to think about it is this: most AI chatbots write like someone crossing a river one stepping stone at a time. They choose one small chunk of text, then the next, then the next.

DSpark gives the system a scout that runs a few steps ahead, guesses the likely path, and lets the larger model quickly check which steps are safe. When the guesses are good, the model moves faster. When the guesses are weak, DSpark tries not to waste time checking them.

DeepSeek published the work with a technical paper, model checkpoints and DeepSpec, a codebase for training and evaluating speculative decoding systems. The release is available through DeepSeek’s public GitHub and Hugging Face pages, both under the permissive, friendly, commonplace MIT license, making the new technique broadly usable by developers, researchers and commercial enterprise operations that want to study or adapt the approach.

The system is aimed at one of the most expensive problems in AI deployment: serving large models quickly enough for real users, while using hardware efficiently enough to make the economics work. That matters for consumer chatbots, coding assistants, agentic workflows and enterprise AI systems where users expect long answers to stream quickly rather than crawl out word by word.

DeepSeek is applying DSpark to its own latest frontier open model, DeepSeek-V4.

Specifically, DeepSeek used its new DSpark framework on DeepSeek-V4-Flash, its already speed-optimized 284-billion-parameter mixture-of-experts model with 13 billion active parameters, and DeepSeek-V4-Pro, its more thoughtful and powerful 1.6-trillion-parameter model with 49 billion active parameters (Both support context windows up to one million tokens).

But the broader significance is that DSpark is not conceptually limited to DeepSeek-V4. DeepSeek’s own tests and released checkpoints cover other open model families, including Alibaba’s open weights Qwen and Google’s open weights Gemma.

That means enterprise teams running open-weight models could, in principle, train or fine-tune DSpark-style draft modules for their own target models. It is not a switch that any API customer can flip from the outside, but it is a method that can travel to other models when the operator controls the weights and serving stack.

Staggering speed increases for generating tokens during inference

In DeepSeek’s live production tests, DSpark improved aggregate throughput by 51% for DeepSeek-V4-Flash at an 80-token-per-second-per-user service target, and by 52% for DeepSeek-V4-Pro at a 35-token-per-second-per-user target. At matched system capacity, DeepSeek reports per-user generation speedups of 60% to 85% for V4-Flash and 57% to 78% for V4-Pro over its prior MTP-1 production baseline.

The different speed claims measure different things. The 60% to 85% figure for V4-Flash, and the 57% to 78% figure for V4-Pro, describe how much faster individual users receive generated tokens when DeepSeek compares DSpark with MTP-1 at matched practical system capacity.

Those are the cleaner “generation speed” numbers. DeepSeek also reports much larger 661% and 406% increases, but these measure aggregate throughput under very strict speed targets: 120 tokens per second per user for V4-Flash and 50 tokens per second per user for V4-Pro.

At those targets, DeepSeek says its older MTP-1 baseline approaches an operational cliff, meaning it can keep only a small number of concurrent requests running while preserving that level of responsiveness.

DSpark avoids more of that collapse, so the percentage difference in total system output becomes much larger. Put simply: the 85% number is closer to “how much faster the ride feels for a user” under comparable conditions, while the 661% and 406% figures are closer to “how much more traffic the road can still carry” when the old system is already bottlenecking.

Why speculative decoding matters

LLMs usually generate text one token at a time. A token can be a word, part of a word, punctuation mark or other small piece of text. Every new token depends on the text already produced, so the model has to keep pausing, checking the full context and choosing the next piece.

That is accurate, but slow. It is like having a senior editor approve every word before a writer can move to the next one. The editor may be excellent, but the process creates a bottleneck.

Speculative decoding, developed in the early Transfomer era, tries to fix that bottleneck. Instead of asking the large model to produce every token one by one, the system uses a smaller or lighter draft component to suggest several likely next tokens. The large model then checks that batch of guesses in parallel. If the draft guessed correctly, the system moves ahead several tokens at once. If the draft made a bad guess, the system rejects the bad token and anything after it, adds a corrected token, and tries again.

The point is speed without changing the larger model’s intended output. In the standard speculative decoding setup, the draft model is not replacing the target model. It is acting more like an assistant who prepares a rough next sentence for the senior editor to approve or reject.

The idea did not appear out of nowhere with today’s large language models. A key precursor came in 2018, when Mitchell Stern, Noam Shazeer and Jakob Uszkoreit proposed blockwise parallel decoding for deep autoregressive models. Their method predicted multiple future steps in parallel, then kept the longest prefix validated by the main model. That paper established much of the draft-and-check intuition behind later speculative decoding work.

The research line became more explicit in 2022. Heming Xia, Tao Ge and co-authors introduced SpecDec, a draft-and-verify approach for sequence-to-sequence generation. Later that year, Yaniv Leviathan, Matan Kalman and Yossi Matias posted “Fast Inference from Transformers via Speculative Decoding,” which helped define the modern version of the technique for transformer-based language models. DeepMind researchers followed in 2023 with a closely related method called speculative sampling.

Those 2022 and 2023 papers are the clearest ancestors of how speculative decoding is discussed in current LLM inference work: a faster draft process proposes tokens, and the larger target model verifies them in a way designed to preserve the target model’s output distribution.

Since then, the field has moved quickly through several variants, including separate draft models, multi-token prediction heads, tree-based verification, feature-level methods such as EAGLE, self-speculation, Medusa-style extra heads and parallel/blockwise drafters such as DFlash.

The key metric is not how many tokens a draft model can guess. It is how many of those guesses the larger model actually accepts. Long speculative blocks help only if enough of the proposed tokens survive verification. Otherwise, the system spends compute checking guesses that it throws away.

That is the context for DSpark. Speculative decoding is already an established inference technique before DeepSeek’s release, with support in major serving stacks and multiple competing research approaches. But it is still not a solved problem. Speedups depend heavily on the draft model, the workload, the serving setup and the current traffic level. DSpark’s contribution is to improve both sides of the trade-off: it tries to draft more coherent token blocks and then verify only the parts of those blocks that are likely to pay off under real serving conditions.

What DSpark changes

DSpark tackles two related problems: bad guesses and wasted checking.

First, the system uses what DeepSeek calls semi-autoregressive generation. In plain English, that means DSpark tries to combine speed with a bit more awareness of sequence.

A fully parallel drafter can guess several tokens at once, which is fast, but its later guesses can become less coherent because each position is predicted too independently. A purely step-by-step drafter can keep better track of how one token leads to the next, but it loses much of the speed advantage.

DSpark tries to keep the best of both. It uses a parallel backbone for most of the drafting work, then adds a lightweight sequential head that lets the draft take nearby token relationships into account. In the paper’s example, a parallel drafter might confuse likely phrase endings such as “of course” and “no problem,” producing awkward combinations because it is guessing positions too separately. DSpark’s sequential component helps the system make the later tokens fit the earlier ones.

Second, DSpark adds confidence-scheduled verification. Rather than always asking the target model to check the same number of draft tokens, DSpark estimates which prefix of the draft is likely to survive. A hardware-aware scheduler then adjusts how much of each draft should be verified based on both model confidence and current serving load.

A simple analogy: when a restaurant is quiet, the head chef can inspect more of the prep cook’s work. When the kitchen is slammed, the chef spends attention only on the dishes most likely to be ready. DSpark applies a similar idea to AI serving. Under lighter traffic, the system can afford to check longer draft prefixes. Under heavier traffic, it trims low-confidence trailing guesses before they consume batch capacity that could be used for other users.

DeepSeek frames this as an answer to a common production trade-off. Static multi-token drafting can look attractive in isolation, but can hurt throughput under high concurrency because the system keeps checking tokens that are likely to be rejected. DSpark’s scheduler makes the verification budget flexible instead of fixed.

Offline results: better draft acceptance across Qwen and Gemma

DeepSeek tested DSpark offline on Qwen3-4B, Qwen3-8B, Qwen3-14B and Gemma4-12B target models across math, coding and chat benchmarks.

In those tests, the team compared DSpark with DFlash, a parallel drafter, and Eagle3, an autoregressive drafter. The paper reports accepted length per decoding round, a measure of how many tokens survive verification on average.

Across the three Qwen3 model sizes, DSpark improved macro-average accepted length over Eagle3 by 30.9%, 26.7% and 30.0%, respectively. Compared with DFlash, it improved accepted length by 16.3%, 18.4% and 18.3%. The paper also says the gains generalized to Gemma4-12B.

That supports a point raised by developer Daniel Han, who highlighted on X that DeepSeek showed DSpark working beyond DeepSeek’s own V4 models, including Gemma and Qwen. I would include Han as community reaction, not as the sole evidence for the claim. The stronger support comes from DeepSeek’s own benchmarks and released checkpoints.

The offline results also show why workload matters. Structured tasks such as math and code tend to have higher accepted lengths than open-ended chat. That makes intuitive sense: a code completion or math step often has fewer reasonable next moves than a free-form conversation.

For enterprises, this means DSpark-style methods may be especially attractive for coding assistants, data analysis agents, structured workflow automation and other settings where outputs follow more predictable patterns.

How enterprises could use DSpark without DeepSeek-V4

One of the most important questions is whether DSpark is a DeepSeek-only optimization or a broader method that can be applied to other models. The answer is: broader method, but not automatic plug-in.

For open-weight models, the path is relatively clear. An enterprise running Qwen, Gemma, Llama, Mistral, Granite, Command-style open weights or another model it hosts itself could train or fine-tune a DSpark-style draft module against that target model.

The team would then measure acceptance on its own workloads and integrate the verification scheduler into its inference stack.

That is different from simply downloading DeepSeek’s DSpark module and attaching it to any model. Speculative decoding depends on alignment between the draft module and the target model. The draft has to learn what the target model is likely to accept. A drafter trained for DeepSeek-V4 will not automatically be the right drafter for a different model, especially one fine-tuned on a company’s internal data or configured for different reasoning behavior.

DeepSpec’s workflow reflects this. The process involves preparing data, regenerating target-model answers, building a target cache, training the draft model and evaluating speculative-decoding acceptance. For domain-specific use, the draft model may need additional fine-tuning, especially if the target model runs in a thinking or reasoning mode.

For proprietary models, the answer depends on what the enterprise controls. If a company owns or fully hosts the model weights and serving stack, it could theoretically train and deploy a DSpark-style drafter. If the model is available only through a hosted API from a vendor, the customer cannot directly add DSpark from the outside. The API provider could implement a similar optimization internally, but the customer generally cannot access the token verification loop, logits, batching behavior or serving scheduler needed to make DSpark work.

That distinction matters for enterprise buyers. DSpark strengthens the case for open or self-hosted AI infrastructure because it gives advanced teams another lever to improve speed and cost. But it also shows why model serving is becoming a specialized discipline. The value is not just in picking a model, but in how intelligently that model is run.

What developers get from DeepSpec

For developers, DeepSpec gives a concrete implementation path for training and evaluating speculative decoding draft models. It includes data preparation, training and benchmark evaluation steps, along with released checkpoints for several open model families. That makes the release useful not only for running DeepSeek-V4 with DSpark, but also for researchers and infrastructure teams studying how to add faster decoding to other open models.

There are real deployment caveats. DeepSpec’s own README says the default Qwen3-4B data preparation setup can require roughly 38 TB of target cache storage, and the default scripts assume a single node with eight GPUs. That makes the release more immediately relevant to AI labs, cloud teams and sophisticated enterprise AI infrastructure groups than to ordinary application developers.

Still, releasing the training pipeline matters. Many inference optimizations appear only as papers, vague benchmarks or closed production claims. DeepSpec gives developers something closer to a set of blueprints: not a finished enterprise product, but a way to reproduce, adapt and evaluate the method.

Early community testing

The release has already drawn fast developer attention. Developer Rafael Caricio published a GitHub pull request documenting single-stream DeepSeek-V4-Flash DSpark work, reporting warmed benchmark anchors of 26.33 tokens per second without speculative decoding, 39.88 tokens per second with MTP-1, and roughly 60 tokens per second with DSpark — about 1.5x over MTP-1 and 2.3x over no-spec decoding.

A later commit in the same thread recorded a five-run mean of 60.31 tokens per second, with a 1.51x gain over MTP-1 and 2.29x over non-speculative decoding.

The same work also points to an important practical limit: in realistic multi-turn coding sessions, performance can degrade as draft acceptance falls with growing context. In other words, DSpark can make decoding faster, but acceptance quality still determines how much speed the system actually realizes.

That is a useful reality check. DSpark is not magic. It still depends on how predictable the next tokens are and how well the drafter stays aligned with the target model. But the early implementation work suggests DeepSeek’s claims are not purely academic. Developers are already testing the method in practical serving environments and reporting gains close to the paper’s single-stream expectations.

The bottom line

DSpark shows how much performance remains available in the inference layer, even when the underlying model architecture stays the same. As AI companies compete on model quality, context length and pricing, decoding efficiency is becoming another major battleground.

Faster generation means lower latency for users, higher throughput for providers and better economics for teams serving open models at scale.

DeepSeek’s release is notable because it combines a production-tested method, open code, public checkpoints and a detailed paper. The main innovation is not just drafting more tokens. It is making the system more selective about which speculative work is worth verifying.

For enterprise teams, the broader lesson is that the next wave of AI performance gains will not come only from larger models. It will also come from smarter ways to run the models companies already have — especially when those companies control enough of the stack to tune the model, train a compatible draft module and optimize the serving engine around real workloads.

When eCoustics first encountered the Dynaudio Symphony Opus One at CES 2025, Chris Boylan named it our Best Concept Soundbar because it clearly was not another skinny TV speaker pretending to deliver real home theater. Opus One was something very different: a full-scale, ultra-premium all-in-one system from a serious loudspeaker company, aimed as much at music-first listeners as design-conscious home theater buyers.

Early pricing chatter suggested it could land near $20,000 USD, which made the concept feel even more audacious. Now that Dynaudio has moved Opus One closer to reality, the details are starting to look a lot more concrete.

At HIGH END Vienna 2026, Dynaudio brought Opus One back for its European debut, giving the ultra-premium all-in-one system a much larger hi-fi stage. A few days later, Dynaudio made it official with a launch event at its new Copenhagen concept showroom during 3daysofdesign, moving Opus One from impressive showpiece to actual product.

The latest confirmed hardware is substantial: 24 distinct drivers, including six soft-dome tweeters, 14 mid/bass drivers, and four dual-diaphragm force-cancelling subwoofers, powered by 1,500 watts of digital amplification and managed by Dynaudio’s proprietary spatial-audio processing. The 186.4 cm-wide chassis is built around a precision-machined aluminum-alloy frame, 72 motorized Karimoku wooden fins, and a footprint optimized for 83 to 85 inch TVs.

Dynaudio now lists Opus One at 1864 x 236 x 207 mm or 73.4 x 9.3 x 8.1 inches, with a weight of 45 kg / 99 pounds. In other words, this is not something you casually slide under the TV after dinner.

Dynaudio has also confirmed pricing and initial availability. The base model is listed at €13,000 RRP, with stands and mounting accessories priced between €500 and €5,000. Opus One will launch first in Denmark and China before rolling out to other markets. US pricing, US availability, and a firm global shipping timeline have not been confirmed but we believe that the $20,000 USD price will be accurate.

Some important AV details remain unresolved. Dynaudio has not yet published the final HDMI/eARC input configuration, HDMI passthrough support, streaming platform compatibility, Wi-Fi or Bluetooth specifications, full codec support, or the complete input/output package.

The company has confirmed that setup uses a microphone built into the remote to help the system identify whether it has been placed on a stand, mounted on a wall, or positioned in free space, then optimize its performance for that location. That is useful, but it is not the same thing as a fully disclosed room correction platform.

Dynaudio also says it intends to add support for wireless subwoofers and rear surround speakers in the future, integrated into the same system. That is worth mentioning, but it should still be treated as roadmap language rather than part of the launch package. At this level, “future support” and “included in the box” are separated by a very expensive Danish fjord.

That matters because this is not chasing Sonos, Samsung, or Bose. Dynaudio is aiming at a far more rarefied slice of the market already occupied by Canvas HiFi, Bang & Olufsen, and Steinway & Sons Lyngdorf. Interesting wrinkle? All of them have deep Danish roots or Danish manufacturing ties, making this emerging luxury soundbar category feel less like a global arms race and more like Denmark quietly deciding that big TVs deserve better sound.

eCoustics Editor-at-large Chris Boylan was on-site in Vienna for a hands-on preview of the Dynaudio Symphony Opus One. How did it sound? In a word? “Impressive.”

According to Chris, “Rather than simply throwing a wide wall of sound, the all-in-one Dynaudio system produced an enveloping bubble of richly layered sound that held together across multiple seating locations without rear surrounds, ceiling speakers or external subwoofers. When switching between movie and music sound, the system used its motorized fins to direct sound to specific areas of the room in order to best represent Dolby Atmos content vs. standard stereo music. And its size made it a perfect visual and audible match to the 85-inch TV it was paired with.”

Dynaudio has not yet published a frequency-response figure for the Opus One, which is an unusual omission for a €13,000 system. At 73 inches wide and designed to partner with 83-inch to 85-inch televisions, it is clearly aimed at large living rooms and media spaces; in a smaller room, its sheer physical presence could be harder to justify than the price tag. The current system should deliver an unusually ambitious all-in-one experience, but a true dedicated-theater role will depend on Dynaudio following through with the wireless subwoofer and surround speakers it has previously said were planned.