alt.hn

2/21/2026 at 8:57:30 PM

Show HN: Llama 3.1 70B on a single RTX 3090 via NVMe-to-GPU bypassing the CPU

 https://github.com/xaskasdf/ntransformer

by xaskasdf

2/22/2026 at 2:35:22 AM

Yeah, GPUdirect should allow you to dma straight to a storage device.

I wonder... what if the m.2 storage was actually DRAM? You probably don't need persistence for spilling a model off the GPU. How would it fare vs just adding more host memory? The m.2 ram would be less flexible, but would keep the system ram free for the CPU.

by 01100011

2/22/2026 at 3:14:05 AM

Yeah a ramdisk would probably work wonders. It's a shame Intel optane didn't became a standard, those type of workflows would be amazing for it.

by javchz

2/22/2026 at 3:07:31 PM

Ya know, here on the local market there are a bunch of optanes hanging around, I'll try to manage one to check if there's any improvement

by xaskasdf

2/22/2026 at 6:08:47 PM

Optanes will be good for latency, but not so much for BW which seems to be your major bottleneck if I'm not mistaken?

by jonassm

2/22/2026 at 8:06:24 PM

yeah, the mobo upgrade is something I gotta do anyway, so I'll cover that up more or less, the optane is something I didn't thought about

by xaskasdf

2/22/2026 at 3:54:30 AM

Ahhh damn it. Intel! Come back!

by TechSquidTV

2/22/2026 at 7:39:49 AM

This is exactly what I was wondering

I gave a talk a few years ago at dask summit (conf?) on making the stars align with dask-cudf here. We were helping a customer accelerate log analytics by proving out our stack for nodes that look roughly like: parallel ssd storage arrays (30 x 3 GB/s?) -> GPUDirect Storage -> 4 x 30 GB/s PCIe (?) -> 8 x A100 GPUs, something like that. It'd be cool to see the same thing now in the LLM world, such as a multi-GPU MoE, or even a single-GPU one for that matter!

by lmeyerov

2/22/2026 at 5:12:12 AM

Isn't m.2 storage but DRAM - hopefully, meaning NVMe/PCIe not SATA speed - already exists as Compute Express Link (CXL), just not in this specific m.2 form factor? If only RAM wasn't silly expensive right now, one could use 31GB/s of additional bandwidth per NVMe connector.

by ElectricalUnion

2/21/2026 at 10:57:45 PM

0.2 tok/s is fine for experimentation, but it is not interactive in any meaningful sense. For many use cases, a well-quantized 8B or 13B that stays resident will simply deliver a better latency-quality tradeoff

by randomtoast

2/22/2026 at 1:11:17 AM

yeah, actually I wanted to see if this was possible at all. I managed to get around 3000 tokens/s on a ps2 with classic transformers, since the emotion engine is capable of 32 bit addresses, but it has like 32gb of ram. So I ran into the question of why was that fast and I couldn't get that speed even with small models, and the deal is that the instructions went right of the memory to the gpu and that's the main difference that does when a regular computer does inference: it has to request the instructions to the cpu every time. As I mentioned too, on professional cards you can avoid these problems naturally, since they got instructions precisely for this, but sadly I don't have 30k bucks to spare on a gpu :(

by xaskasdf

2/24/2026 at 12:07:41 AM

The $5/hr B200 rate is fine for training, but cloud latency usually breaks real-time signal processing. I’ve been hitting similar walls with MemeRadar; when you're processing high-volume spikes, the bottleneck is memory bandwidth, not raw TFLOPS. Quantizing to fit L3 cache is an option, but you lose the precision needed for spotting subtle rug-pull patterns. For 24/7 production workloads, local hardware TCO usually beats cloud rentals.

by SmithRenaldo

2/22/2026 at 1:32:14 AM

*32MB of RAM (plus 4MB of video RAM and a little sound and IOP memory).

by derstander

2/22/2026 at 5:46:12 AM

> I don't have 30k bucks to spare on a gpu :(

Do you have $2/hr to rent an RTX 6000 96GB or $5/hr for B200 180GB on the cloud?

by eleventyseven

2/22/2026 at 3:00:00 PM

I thought about that, but idk if they allow me to modify the linux kernel and nvidia cuda kernel at all

by xaskasdf

2/22/2026 at 5:37:01 PM

In those systems you could probably leverage something like Nvidia SCADA or GDS directly.

by jonassm

2/22/2026 at 8:07:28 PM

Actually since they have direct GDS it should perform really well on professional gpus

by xaskasdf

2/22/2026 at 5:23:11 PM

I think you can do a bunch of that on Digitalocean's GPU droplets.

by green-salt

2/22/2026 at 5:47:57 AM

I'd rather not give money to scalper barons if I can avoid it. Fab capacity is going to that for rental rather than hardware for humans.

by superkuh

2/22/2026 at 4:14:29 AM

3000 tokens per sec on 32 mb Ram?

by anoncow

2/22/2026 at 4:56:21 AM

fast != practical

You can get lots of tokens per second on the CPU if the entire network fits in L1 cache. Unfortunately the sub 64 kiB model segment isn't looking so hot.

But actually ... 3000? Did GP misplace one or two zeros there?

by fc417fc802

2/22/2026 at 3:48:40 PM

I wondered the same, but the rendering seems right, the output was almost instant. I'll recheck the token counter; anyway as you say, fast isn't practical. Actually I had to develop my own tiny model https://huggingface.co/xaskasdf/brandon-tiny-10m-instruct to fit something "usable", and it's basically a liar or disinformation machine haha

by xaskasdf

2/21/2026 at 11:57:59 PM

I can imagine a couple scenarios in which a high-quality, large model would be much preferred over lower latency models, primarily when you need the quality.

by Wuzado

2/21/2026 at 11:30:05 PM

I didn't really understand the performance table until I saw the top ones were 8B models.

But 5 seconds / token is quite slow yeah. I guess this is for low ram machines? I'm pretty sure my 5950x with 128 gb ram can run this faster on the CPU with some layers / prefill on the 3060 gpu I have.

I also see that they claim the process is compute bound at 2 seconds/token, but that doesn't seem correct with a 3090?

by tyfon

2/21/2026 at 11:59:48 PM

LLM speed is roughly <memory_bandwidth> / <model_size> tok/s.

DDR4 tops out about 27Gbs

DDR5 can do around 40Gbs

So for 70B model at 8 bit quant, you will get around 0.3-0.5 tokens per second using RAM alone.

by tgrowazay

2/22/2026 at 12:17:53 AM

DRAM speeds is one thing, but you should also account for the data rate of the PCIe bus (and/or VRAM speed). But yes, holding it "lukewarm" in DRAM rather than on NVMe storage is obviously faster.

by someguy2026

2/23/2026 at 8:00:24 PM

Yes.

In general systems usually have PCIE version with bandwidth better than RAM of that system.

For example a system with DDR4 (27Gbs) usually has at least PCIE4 (32Gbs at 16x).

But you can bottleneck that by building a DDR5 (40Gbs) system with PCIE4 card.

by tgrowazay

2/22/2026 at 1:28:02 AM

yeah, actually, I'm bottlenecked af since my mobo got pcie3 only :(

by xaskasdf

2/22/2026 at 12:47:23 AM

Channels matter a lot, quad channel ddr4 is going to beat ddr5 in dual channel most of the time.

by uf00lme

2/22/2026 at 2:03:27 AM

Four channels of DDR4-3200 vs two channels of DDR5-6400 (four subchannels) should come out pretty close. I don't see any reason why the DDR4 configuration would be consistently faster; you might have more bank groups on DDR4, but I'm not sure that would outweigh other factors like the topology and bandwidth of the interconnects between the memory controller and the CPU cores.

by wtallis

2/22/2026 at 12:13:05 AM

Faster than the 0.2tok/s this approach manages

by vlovich123

2/22/2026 at 12:28:30 AM

Should be active param size, not model size.

by zozbot234

2/23/2026 at 7:55:22 PM

Yes, you’re right.

LLama 3.1 however is not MoE, so all params are active.

For MoE it is tricky, because for each token you only use a subset of params (an “expert”) but you don’t know which one, so you have to keep them all in memory or wait until it loads from slower storage, potentially different for each token.

by tgrowazay

2/22/2026 at 3:56:59 AM

That's slower than just running it off CPU+GPU. I can easily hit 1.5 tokens/s on a 7950X+3090 and a 20480-token context.

by fluoridation

2/22/2026 at 4:27:27 AM

0.2 tok/s is slow for chat but perfectly fine for batch/async workloads. I run automated content generation pipelines where a single job kicks off dozens of LLM calls (script generation, metadata, descriptions) and none of them need to be interactive. The whole job takes 20 minutes anyway because of image generation bottlenecks. Being able to run a 70B model locally for those batch calls instead of paying per-token API costs would be a significant cost reduction, even at this speed.

by umairnadeem123

2/22/2026 at 5:07:27 AM

Cost wise it does not seem very effective. .5 token / sec (the optimized one) is 3600 tokens an hour, which costs about 200-300 watts for an active 3090+system. Running 3600 tokens on open router @.4$ for llama 3.1 (3.3 costs less), is about $0,00144. That money buys you about 2-3 watts (in the Netherlands).

Great achievement for privacy inference nonetheless.

by esquire_900

2/22/2026 at 6:33:11 AM

I think we use different units. In my system there are 3600 seconds per hour, and watts measure power.

by teo_zero

2/22/2026 at 9:24:51 AM

OP probably means watt-hours.

by IsTom

2/22/2026 at 2:45:48 PM

And 0.5 tokens/s should work out to 1800 tokens at the end of the hour. Not 3600 as stated.

by dotancohen

2/22/2026 at 5:29:03 AM

Something to consider is that input tokens have a cost too. They are typically processed much faster than output tokens. If you have long conversations then input tokens will end up being a significant part of the cost.

It probably won't matter much here though.

by Aerroon

2/22/2026 at 12:09:14 PM

Open router is highly subsidized. This might be cheaper in the long run once these companies shift to taking profits

by qoez

2/22/2026 at 7:09:23 PM

But why not cross that bridge then. By that time you might have much more optimized local infrastructure. Although I do see that someone suffering through the local slowness now is what drives the development of these local options.

by culopatin

2/22/2026 at 10:18:13 AM

> Cost wise it does not seem very effective.

Why is this so damn important? Isn't it more important to end up with the best result?

I (in Norway) use a homelab with Ollama to generate a report every morning. It's slow, but it runs between 5-6 am, energy prices are at a low, and it doesn't matter if it takes 5 or 50 minutes.

by thatwasunusual

2/22/2026 at 5:45:39 PM

> Why is this so damn important? Isn't it more important to end up with the best result?

You’re wondering why someone would prefer to get the same or better result in less time for less money?

by xienze

2/22/2026 at 5:43:07 AM

Are you taking into account energy costs of running a 3090 at 350 watts for a very long time?

by eleventyseven

2/22/2026 at 10:56:22 AM

I doubt it’s at full TDP if it’s running at 0.2 tokens per second.

by teaearlgraycold

2/22/2026 at 2:57:09 PM

Actually I can't go full tdp with a 650w PSU, I got to upgrade it asap

by xaskasdf

2/22/2026 at 8:12:30 AM

You can run a RTX3090 at 250w and still get a lot of its performance with nvidia-smi.

by ekianjo

2/22/2026 at 1:38:06 AM

This is an interesting area for experiments. I suspect that in the longer term model optimization (knowing which bits you can leave out without affecting the functioning of the model) will become the dominant area of research just like it did with compression algorithms because effectively a model is a lossy compression scheme.

And that's good because that increases democratization of AI away from the silos that are being created.

by jacquesm

2/22/2026 at 6:18:47 AM

The compression analogy is interesting. Another way of looking at it could be fine-tuning as "knowing what to leave out" - a 3B model for example tuned for a narrow task doesn't need the capacity that makes 70B good at many things.

by serendip-ml

2/21/2026 at 11:42:41 PM

Nice. I've been looking at doing something similar, more on the order of running a 1T model with less than half the available VRAM.

One workup indicated it was theoretically possible to modify a piece of SGLang's routing layer to support JIT predict-ahead expert swaps from Gen5 NVMe storage straight into GPU memory.

I'm hoping that proves true. The setup relies on NVIDIA Dynamo, so NIXL primitives are available to support that.

Curious if anyone's tried this already.

by rl3

2/22/2026 at 1:14:00 AM

That would be nice to see. Actually I was thinking about getting another 3090 and a mobo upgrade since I'm bottlenecked by pcie3 to tryna run glm 4.7 or 5 at q4_k_m, it should be possible.

by xaskasdf

2/22/2026 at 5:30:48 AM

Really cool. I'm wondering: what background did you need to be able to think of the question that resulted in this project?

I know you said you're involved in some retrogaming and were experimenting, but as someone who works in a world where hardware is pretty heavily abstracted away, even if I got into retrogaming I don't know that I'd consider that there may be a systems improvement lying around. Beyond the creative aspect, it feels like there is some systems and hardware background that helped put the idea together (and I'd be interested to go learn about of that systems/hardware knowledge myself).

by civicsquid

2/22/2026 at 2:35:24 PM

This was the experiment itself https://github.com/xaskasdf/ps2-llm

The idea was basically to run a llm on a ps2, then I ran into some problems as the 32mb ram cap with 4mb vram cap; so I had to figure out a way to stream layers on the forward pass. Given that ps2 manages to give instructions directly to the vram that's capable of 32bit addresses, it gave an insane amount of tok/s, then I wondered if I could do the same on my puter

by xaskasdf

2/22/2026 at 5:49:06 AM

I wonder too, DMA plays a huge role in most older gaming consoles when the CPUs were far more sluggish.

Perhaps that's what made them think to try.

Perhaps the current batch of smart memory cards which on the PS2 I believe have quite complex DMA capabilities to stream from the SD card game data.

by rustyhancock

2/22/2026 at 6:53:35 AM

Why not the PS5? That's when games started streaming assets straight from the NVME SSD to the GPU. In this case the assets are weights.

by charcircuit

2/22/2026 at 2:37:19 PM

Actually I'm thinking about buyin an AMD BC-250 that's bassically a ps5 with pcie factor format; and it's linux capable by default, maybe next month

by xaskasdf

2/22/2026 at 4:16:44 PM

Just because he mentioned retro gaming.

Otherwise DMA is everywhere.

In the PS5 case since it uses unified memory it's not quite the same as say an GBA streamed from a flash cart to video RAM.

by rustyhancock

2/22/2026 at 12:50:05 PM

Really interesting experiment i should have done this before Do you have numbers on effective throughput vs PCIe theoretical bandwidth? I’m curious whether this is primarily latency-bound or bandwidth-bound in practice Can some tell me??

by davideom0414

2/22/2026 at 3:03:07 PM

Actually is purely bandwidth-bound, the major bottleneck of the whole process, for me in this case, is the B450 mobo I got that's only capable of pcie3 and 1x8 in the pcie lanes for gpu instead of 1x16; so I'm capped until I get an X570 maybe. I should get around twice or triple the tok speed with that upgrade alone

by xaskasdf

2/22/2026 at 12:07:13 AM

I wonder - could this be used for multi-tier MoE? Eg. active + most used in VRAM, often used in RAM and less used in NVMe?

by Wuzado

2/22/2026 at 12:11:24 AM

Yeah I’ve often wondered why folks aren’t training two tier MoEs for VRAM + RAM. We already have designs for shared experts so it cannot be hard to implement a router that allocated 10x or 100x as often to “core” experts vs the “nice to have” experts. I suppose balancing during training is tricky but some sort of custom loss on the router layers should work.

I’ve also wondered why the routers aren’t training to be serially consistent so you can predict layers to swap into VRAM a few layers ahead to maximize available bandwidth.

by rao-v

2/22/2026 at 12:26:40 AM

I think part of the issue is that in production deployments, you're batching high enough that you'll be paging in those long tail experts constantly.

Unless you're handing that in some kind of fancy way, you'll be holding up the batch while waiting for host memory which will kill your throughout.

It makes much more sense for non batched local inference, especially if you can keep the MoE routing stable like you say, but most folks aren't optimising for that.

by reitzensteinm

2/22/2026 at 12:32:38 AM

Ideally, you should rearrange batches so that inference steps that rely on the same experts get batched together, then inferences that would "hold up" a batch simply wait for that one "long tail" expert to be loaded, whereupon they can progress. This might require checkpointing partial inference steps more often, but that ought to be doable.

by zozbot234

2/22/2026 at 12:46:42 AM

I think this is doable for very long tail experts that get swapped in for specialised topics - say, orbital mechanics.

But for experts that light up at, say, 1% frequency per batch, you're doing an awful lot of transfers from DRAM which you amortize over a single token, instead of reads from HBM which you amortize over 32 tokens.

by reitzensteinm

2/22/2026 at 6:46:43 PM

I think your analysis is right this would make sense mostly for the 30B-3A style models that are mostly for edge / hobbyist use, where context length is precious so nobody is batching.

Given that experts live per layer I dont think it makes sense to have orbital mechanics experts but … I have wondered about swapping out the bottom 10% of layers per topic given that that is likely where the highest order concepts live. I’ve always wondered why people bother with LORA on all layers given that the early layers are more likely to be topic agnostic and focused on more basic pattern assembly (see the recent papers on how LLMs count on a manifold)

by rao-v

2/22/2026 at 12:22:42 AM

Maybe I am misunderstanding something but:

1) This is basically the intention of several recent MoE models: keep particular generally useful experts hot in VRAM.

2) Unless you can swap layers in faster than you consume them there is no point to predicting layers (what does this even really mean? did you mean predicting experts?).

It seems at the moment the best you can do is keep experts and layers more likely to be used for a given query in VRAM and offload the rest, but this is work-dependent.

by svnt

2/23/2026 at 7:24:06 PM

So llama.cpp currently statically puts overflow MoE experts in RAM and inferences them on CPU, so you get a mix of GPU + CPU inferencing. You are rooflined by RAM->CPU bandwidth + CPU compute.

With good predictability of MoE, you might see a world were it's more efficient to spend PCI bandwidth (slower than RAM->CPU) on loading MOE experts for the next ~3 layers from RAM to VRAM so you are not rooflined by CPU compute.

VLLM / SGLang (AFAIK) just assume you have enough VRAM to fit all the experts (but will page KV cache to RAM).

by rao-v

2/22/2026 at 12:21:41 AM

I don't have links handy but there is active research in this area.

by hedgehog

2/23/2026 at 7:13:23 PM

I'd love any keywords to search for to find active research on this topic!

by rao-v

2/23/2026 at 8:45:43 PM

Most of the work I'm aware of starts from the perspective of optimizing inference but the implication that pushing the lessons upstream gets mentioned here and there.

Not All Models Suit Expert Offloading: On Local Routing Consistency of Mixture-of-Expert Models (https://arxiv.org/abs/2505.16056)

Breaking the MoE LLM Trilemma: Dynamic Expert Clustering with Structured Compression (https://arxiv.org/abs/2510.02345)

by hedgehog

2/22/2026 at 12:08:26 PM

Cool hack but 0.5 tok/s on 70B when a 7B does 30+ on the same card. NVIDIA's own research says 40-70% of agentic tasks could run on sub-10B models and the quality gap has closed fast.

by 7777777phil

2/22/2026 at 12:25:40 PM

[flagged]

by valianteffort

2/22/2026 at 2:00:48 PM

Can we not? Make a valiant effort to rephrase.

by tclancy

2/21/2026 at 11:14:32 PM

Didn't DirectX add an API for loading assets directly to GPU memory? Would that work?

by throwaway2027

2/21/2026 at 11:36:43 PM

My impression is that that is limited to assets and really needs to fit into the DirectX framework. From what I can tell, the gpu-nvme-direct is mostly similar to https://github.com/enfiskutensykkel/ssd-gpu-dma and https://github.com/ZaidQureshi/bam

by someguy2026

2/22/2026 at 3:30:30 AM

Actually this idea was fueled by those since I went to check if there was anything near to what I wanted to achieve, pretty useful tho

by xaskasdf

2/22/2026 at 9:22:24 AM

nvmlib/ssd-gpu-dma and BaM (based on the same code base) are pretty cool as they allow you to initiate disk reads/writes directly from a CUDA kernel (so not only reading/writing directly to GPU memory but also allowing the GPU to initiate IO on its own). Sometimes called GPU-initiated I/O or accelerator-initiated I/O.

by jonassm

2/22/2026 at 6:03:25 AM

Cool project. Can you provide more details about your DKMS patching process for consumer GPUs? This would be fun to try out, but I’d need some more details on that patch process first.

by Aurornis

2/22/2026 at 2:43:49 PM

I updated the documentation to provide more info for the patching process, I added the patches themselves too and provided some risk info about the patches

by xaskasdf

2/21/2026 at 11:32:25 PM

Could be neat to see what giving the 8b like 6gb ram instead of 10gb. Something in-between, where you still need NVMe, but not like the 3x ratio of the 70b model on 23GB.

Nice work. PCI-P2P (GPU-Direct (tm)) is such great stuff. Cool to see!

by jauntywundrkind

2/22/2026 at 12:46:36 AM

I feel like we need an entirely new type of silicon for LLMs. Something completely focused on bandwidth and storage probably at the sacrifice of raw computation power.

by exabrial

2/22/2026 at 12:50:37 PM

Something like this? (Llama 3.1-8B etched into custom silicon delivering 16,000 tok/s, doesn't use much PCIe bandwidth):

- https://taalas.com/the-path-to-ubiquitous-ai/ - https://chatjimmy.ai/

by garethsprice

2/22/2026 at 3:13:44 PM

Wowsa that’s amazing! Exactly what I was imagining. To do that with 2500 watts is incredible.

by exabrial

2/22/2026 at 11:34:58 AM

Interesting. Can AMD GPUs do direct io like this?

by stuaxo

2/22/2026 at 10:16:06 AM

I've often wondered doing this with extreme compression. What if you did extreme compression + decompression on the GPU? Because you're leaving a lot of compute unused.

by spwa4

2/22/2026 at 2:42:16 PM

I did it, but with different quantization compressions, It ran into quality issues, I will try to rerun with the same quants if that fixes the issue, but the most that looks unused, its being used by rotating layers that are being swapped by the cpu from the ram itself, that manages to keep layers warm, ready to use while inferencing and discarding already used ones

by xaskasdf

2/22/2026 at 3:03:16 PM

I'm not sure, but I suspect that LLM weights don't compress all that well. The intuition here is that training an LLM is compression of the training data into the weights, so they are probably very information dense already. Can't squeeze them down much.

by nathan_compton

2/23/2026 at 7:40:27 AM

I've found this to often be untrue when optimizing on the CPU. I wish someone would pay me to dive deep into this problem and the scheduling problem. I'd be amazed if I can't squeeze out a 50% speed increase on both problems.

by spwa4

2/22/2026 at 9:01:38 AM

Isn't that linux DMA buf?

by sylware

2/22/2026 at 7:04:54 AM

Umm sorry but the cpu can easily keep up shuttling around to/from your nvme. Especially ancient gen3 pcie. Not sure why ud do this.

by timzaman

2/22/2026 at 2:39:45 PM

Did you even read anything? hahaha

by xaskasdf

2/22/2026 at 10:49:38 AM

[dead]

by MarcLore

2/23/2026 at 9:11:29 AM

No it is not. CPU and GPU overhead is close to 0 anyways if you are loading weights at 10GB/s.

by YetAnotherNick

2/22/2026 at 5:43:59 PM

NVMEs are much, much slower than RAM. Especially unified/soldered RAM.

by fabifabulous

2/23/2026 at 5:34:42 AM

Bandwidth-wise, it's fun when you have a storage array instead of just 1 nvme. Then you can saturate the pcies, and go beyond what's cost effective on ram. Interesting to think of this as opening the door to 10-100T MoEs..

by lmeyerov

2/23/2026 at 6:28:52 AM

Wasn't there a storage device some Years ago (decade plus) that was RAM strapped to a PCI-E card with the electronics to present the RAM as a storage device?

by placatedmayhem

2/22/2026 at 7:17:44 PM

To be fair, llama.cpp had this feature for over a year now. It just applies to GGUF.

by 3abiton

2/22/2026 at 2:27:00 PM

I got an m3, I will test it on metal and check how it goes

by xaskasdf

2/22/2026 at 8:07:02 PM

[dead]

by johnbarron

2/22/2026 at 3:31:33 PM

[dead]

by ai_hack3r

2/22/2026 at 3:00:23 PM

[dead]

by builderhq_io

2/22/2026 at 6:59:33 AM

[flagged]

by dhjjdjjjd

2/22/2026 at 5:01:36 AM

[flagged]

by turingsroot

2/22/2026 at 6:02:01 AM

> No cuBLAS means they wrote their own GEMM kernels, which is a massive undertaking

Not to diminish the impressiveness of this overall project, but it says right up front that these were vibe coded and the Opus 4.6 co-author lines are right in the commit messages. Those pieces were adapted from existing work via LLM, which is exactly the right use in a proof of concept project like this.

by Aurornis

2/22/2026 at 7:46:25 AM

Please don't use LLMs to post on HN...

by snovv_crash

2/22/2026 at 9:59:12 AM

or at least don't make it too obvious.

by flux3125

2/22/2026 at 8:35:55 AM

Yeah I don't even get the motivation for that. Are HN accounts valuable in any way?

by IshKebab