Hacker Newsnew | past | comments | ask | show | jobs | submit | mrinterweb's commentslogin

If data center water use is such a concern, why not require that data centers invest in closed-loop cooling systems? By closed-loop, I'm talking about re-condensing evaporated water and allowing the water to cool. Cooling the water would be more expensive in hotter environments, but still achievable. These data centers seem to have wild amounts of money for investment, why not just mandate conservation requirements?

> These data centers seem to have wild amounts of money for investment, why not just mandate conservation requirements

This IS the complaint.


Data center water use is in fact not a valid concern.

We should just charge a fair price for water. Something that covers capital, operating, and decommissioning costs. No need to pass specific regulations or add legal complexity. It would solve itself. Imagine any other service saying "Oh no, we have too much demand, we need to make it illegal." Just put out bonds, and build up capacity.

For places with plenty of water, that makes sense. Capacity can be increased.

For places that don't have plenty of water, that becomes trickier: Capacity is finite.


Condensing/cooling the water takes even more electricity though. So you're trading water savings for increased energy use. Maybe OK if it's all renewable, but in most areas it's not.

imo this is a pricing problem more than a cooling-design problem. datacenters get cheap clean water while locals pay for the pipes and grid upgrades.

Regulating AI? America would never!

The tradeoff is power vs water. Water is currently cheaper.

Anthropic is loosing the good will they built with devs faster than they built it. Its the anti-competitive and anti-opensource behviors that will erode their dev customer base. No clue how much of Anthropic's revenue is based on devs paying for claude subscriptions, but they are going to lose that quickly.

I would have jumped ship, but OpenAI saying "hold my beer" when Anthropic declined the Pentagon's safeguard removal demands is the only thing that has prevented me from jumping ship. I've considered Chinese AI services but I'm too concerned with data (proprietary code) exfiltration.


Then you should consider alternative LLM API providers, who are not based in China but host the same (or roughly the same, depending on the quantization and other deployment specifics) models as your "Chinese AI services".

I only use copilot for the occasional auto-complete suggestion. I'm betting I could run a lightweight local LLM with llama.cpp to get similar functionality. Maybe this would be a decent replacement https://github.com/TabbyML/tabby

I'm too concerned with data exfiltration to use many AI services unless their terms of service state they will not use your data for training or anything else. Zero retention is what I'm looking for. I care because I frequently work on proprietary code that I do not personally own (as most employed software devs do). So if I am using an AI service with proprietary code, I want assurances that there is no retention and no training happening. From my American perspective Chinese companies don't have the best track record of not training on proprietary information. I guess LLMs in general are trained on a lot of proprietary information. I just don't want to be responsible for unintentionally exfiltrating my employer's proprietary code.


My recent frustration with Claude has been it feels like I'm waiting on responses more. I don't have historical latency to compare this with, but I feel like it has been getting slower. I may be wrong, and maybe its just spending more time thinking than it used to. My guess is Anthropic is having capacity issues. I hope I'm wrong because I don't want to switch.


There was a really good point in this podcast episode about the speed of LLMs. They are so slow that all of the progress messages and token streaming are necessary. But the core problem is that the technology is so darn slow.

https://podcasts.apple.com/us/podcast/this-episode-is-a-cogn...

As someone who both uses and builds this technology I think this is a core UX issue we’re going to be improving for a while. At times it really feels like a choose 2+ of: slow, bad, and expensive.


About slowdowns... I have this theory that if they sneak some sleep(1) calls while processing medium to complex prompts they can serve more clients.

But I think "context switching" between 2 different prompts might be too expensive for GPUs to be worth it for LLM providers. Who knows.


I feel like there have been enough hyperbolic claims by Anthropic, that I'm starting to get some real Boy Who Cried Wolf energy. I'm starting to tune out, and assume it is a marketing ploy. Trust me, I'm an Antropic fan, and I pay my $200/month for max, but the claims are wearing thin.


Thank you. I have the same card, and I noticed the same ~100 TPS when I ran Q3.5-35B-A3B. G4 26B A4B running at 150TPS is a 50% performance gain. That's pretty huge.


I feel the global instability could easily be very disruptive to SpaceX. Just imagine if Russia gets vindictive and starts destroying these satellites or blowing up their satellites to create orbital debris that could knock satellites out of orbit. A really bad solar storm could be devastating.

Just saying there are some decent risks, and pricing it at 1.75T IPO seems risky enough. I would not take that gamble.


> A really bad solar storm could be devastating.

Starlink already accounts for these (e.g. https://www.theregister.com/2025/11/18/starlinks_method_of_d... ), and in any case they are put in orbit so that they eventually fall back to earth in case control is lost.


> imagine if Russia gets vindictive and starts destroying these satellites

Sounds like lots of demand for new launches from the military-industrial complex.

> imagine if Russia gets vindictive and starts destroying these satellites

Space is big. It’s almost always cheaper to individually target satellites than to try and blanket orbits. And with Starship vs ASAT, the cheap drones are the satellites. Russia would bankrupt itself trying to sink Starlink and Starshield.

(They would also set a precedent that would let the U.S. deny China a LEO constellation.)


> It’s almost always cheaper to individually target satellites than to try and blanket orbits.

The problem is that even one satellite could start the Kessler syndrome due to how many are currently in orbit, and the numbers are expected to keep increasing rapidly - everyone wants their "sovereign" Starlink now that it has been shown to be feasible and performant.


> problem is that even one satellite could start the Kessler syndrome

No, it can’t. Not in LEO. Militaries have searched for these one-shot solutions; there is no known orbital system for which it works. (In LEO.)

The only fuck-you orbits are in GEO.


> very disruptive to SpaceX

And to most everything else


I think two recent advances make your statement more true. The new Qwen 3.5 series has shown a relatively high intelligence density, and Google's new turboquant could result in dramatically smaller/efficient models without the normal quantization accuracy tradeoff.

I would expect consumer inference ASIC chips will emerge when model developments start plateauing, and "baking" a highly capable and dense model to a chip makes economic sense.


Who will be funding state of the art local models going forward? AI models are never done or good enough. They will have to be trained on new data and eventually with new model architectures. It will remain an expensive exercise.

I could be wrong because I'm not following this too closely, but the open weights future of both Llama and Qwen looks tenuous to me. Yes, there are others, but I don't understand the business model.


If turboquant can reliably reduce LLM inference RAM requirements by 6x, suddenly reducing total RAM needs by 6x should have a dramatic shift on the hardware market, or at least we can all hope. I know 6x is the key-value cache saving, so I'm not sure if that really translates to 6x total RAM requirements decrease for inference.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: