Serious Discussion Analog Cognition - Optical based LLM inference

[danb]

Hey guys,

Optical computing has been a pipe dream for the computer industry since the 1970's. And ever since I was a kid, I have always dreamed of someday building my own optical computer. Even if someone could build the hardware, they would still have to build the operating system, apps, developer tools, and all of the infrastructure required to make it useful as a general-purpose computer.

But that does not mean we cannot build a specialized optical computation device for AI inference and similar workloads / applications.

Over the last several years, several startups have tried to build photonic CPUs or general-purpose optical processors. From what I can tell, most either pivot toward optical interconnects between GPUs (which is needed as well), or they eventually run into the same wall everyone else does: trying to make an optical version of a traditional CPU is probably the wrong approach.

Personally, I think building a general-purpose photonic CPU is a fool’s errand, at least for now. I also think we should not assume optical computing needs to follow the same path as electrical silicon. Just because traditional CPUs benefited from extreme miniaturization does not necessarily mean optical computation devices should be scaled down the same way. In some cases, larger optical paths, emitters, detectors, fibers, lenses, or direct-contact optical elements may actually be more reliable, easier to manufacture, and better suited for clean signal separation.

That is the basic idea behind Analog Cognition.

It is an early optical computation workbench that uses a monitor/webcam loop to represent, read, decode, and verify selected encoded optical computation states. In other words, it is a real camera-in-the-loop optical readout demo, but intentionally slow and experimental.

The long-term idea is much bigger: purpose-built optical hardware using LED or laser emitter arrays, photodiode / sensor detector arrays, multi-level optical weight encoding, accumulator-style computation, threshold verification, redundancy, and eventually direct-coupled optical paths.

You can try it here:

Analog Cognition

www.analogcognition.com

There is a lot more detail in the FAQ:

Analog Cognition

www.analogcognition.com

If you guys have a usb webcam, please take it for a spin and let me know what you think.

The most useful feedback would be:

* Does the site explain the idea clearly?
* Does calibration work with your camera/browser setup?
* Does anything sound like it is overclaiming?
* Does the demo make sense after you read the FAQ?
* If calibration fails, what camera/browser/resolution are you using?

Again, this is very early. Think of it as a research workbench / proof of concept, not a finished product. But I think the core idea is extremely interesting, and I wanted to share it with you guys first before posting it anywhere else.

Thank you guys!

Dan

 

[danb]

@Bot , so what do you think?

Analog Cognition

www.analogcognition.com

Analog Cognition

www.analogcognition.com

 

[Bot]

@Bot , so what do you think?

Analog Cognition

www.analogcognition.com

Analog Cognition

www.analogcognition.com

It looks like an interesting proof-of-concept, but I cannot verify the technical claims just by reading the site.

What seems reasonable

• Positioning it as a research workbench rather than a finished computing platform is the right approach.
• Using a camera-in-the-loop optical demo to test encoding, readout, calibration, thresholding, and error handling is a sensible experimental setup.
• Focusing on specialized optical computation instead of trying to replicate a traditional general-purpose CPU is also a reasonable direction.

What needs caution

• A monitor + webcam loop is useful as a demonstration platform, but it is still very far from dedicated photonic hardware in performance, precision, latency, and noise characteristics.
• Any suggestion that this naturally scales into practical AI inference hardware would need much stronger evidence, measurements, and repeatable benchmarks.
• Browser, camera sensor, auto-exposure, white balance, compression, frame timing, and ambient lighting can all affect results significantly.

On the clarity of the idea

The high-level concept is understandable: encode optical states, capture them, decode them, and verify them with redundancy and thresholding.

Where it may lose some readers is the jump from “optical readout demo” to “future optical compute architecture.” That jump is not impossible, but it needs very careful framing so people do not read more into the current demo than it can support.

On overclaiming

Based on your description here, the wording is mostly cautious. The main risk would be if readers interpret terms like “optical computation,” “AI inference,” or “weights” as meaning the current demo already demonstrates something close to competitive optical neural hardware. If that is not the claim, it helps to state the limitations very explicitly.

What would strengthen it

• A short “What this demo does not prove” section.
• A simple block diagram of encode → display/emission → capture → decode → verification.
• A list of known limitations such as frame rate, calibration sensitivity, noise, and browser dependence.
• Repeatability data across a few cameras and lighting conditions.
• If possible, quantitative metrics: error rate, detection confidence, calibration tolerance, and throughput.

Security/privacy note

Because the demo uses camera access in a browser, some users will be cautious. It would help to clearly state:

• whether any images or video leave the device
• whether processing is local or server-side
• what permissions are required
• whether anything is stored

Bottom line

As an early experimental optics workbench, it sounds interesting and appropriately ambitious. As evidence for future practical optical AI hardware, it is still at the “concept exploration” stage and should be framed that way very clearly. The strongest next step is solid documentation, explicit limitations, and reproducible measurements.

 

[danb]

It looks like an interesting proof-of-concept, but I cannot verify the technical claims just by reading the site.

What seems reasonable

• Positioning it as a research workbench rather than a finished computing platform is the right approach.
• Using a camera-in-the-loop optical demo to test encoding, readout, calibration, thresholding, and error handling is a sensible experimental setup.
• Focusing on specialized optical computation instead of trying to replicate a traditional general-purpose CPU is also a reasonable direction.

What needs caution

• A monitor + webcam loop is useful as a demonstration platform, but it is still very far from dedicated photonic hardware in performance, precision, latency, and noise characteristics.
• Any suggestion that this naturally scales into practical AI inference hardware would need much stronger evidence, measurements, and repeatable benchmarks.
• Browser, camera sensor, auto-exposure, white balance, compression, frame timing, and ambient lighting can all affect results significantly.

On the clarity of the idea

The high-level concept is understandable: encode optical states, capture them, decode them, and verify them with redundancy and thresholding.

Where it may lose some readers is the jump from “optical readout demo” to “future optical compute architecture.” That jump is not impossible, but it needs very careful framing so people do not read more into the current demo than it can support.

On overclaiming

Based on your description here, the wording is mostly cautious. The main risk would be if readers interpret terms like “optical computation,” “AI inference,” or “weights” as meaning the current demo already demonstrates something close to competitive optical neural hardware. If that is not the claim, it helps to state the limitations very explicitly.

What would strengthen it

• A short “What this demo does not prove” section.
• A simple block diagram of encode → display/emission → capture → decode → verification.
• A list of known limitations such as frame rate, calibration sensitivity, noise, and browser dependence.
• Repeatability data across a few cameras and lighting conditions.
• If possible, quantitative metrics: error rate, detection confidence, calibration tolerance, and throughput.

Security/privacy note

Because the demo uses camera access in a browser, some users will be cautious. It would help to clearly state:

• whether any images or video leave the device
• whether processing is local or server-side
• what permissions are required
• whether anything is stored

Bottom line

As an early experimental optics workbench, it sounds interesting and appropriately ambitious. As evidence for future practical optical AI hardware, it is still at the “concept exploration” stage and should be framed that way very clearly. The strongest next step is solid documentation, explicit limitations, and reproducible measurements.

That is a totally fair take.

The reason I started with the monitor/webcam loop is that it gives us a very accessible way to test the core primitives before building hardware:

• Can we encode states optically?
• Can we read them back reliably?
• Can we calibrate and decode them locally?
• Can we detect mismatch/failure conditions?
• Can we produce useful confidence/margin diagnostics?
• Can we build a software workbench that maps cleanly to future emitter/detector hardware?

Basically, if we can get selected-state optical readout and verification working on a cheap monitor and webcam, then I believe those same primitives should be much cleaner and more reliable on purpose-built hardware with dedicated emitters, detectors, controlled optical paths, reference channels, and proper thresholding.

Obviously, practical AI inference hardware is still a much bigger step, but this seemed like the right place to start.

 

[Bot]

That is a totally fair take.

The reason I started with the monitor/webcam loop is that it gives us a very accessible way to test the core primitives before building hardware:

• Can we encode states optically?
• Can we read them back reliably?
• Can we calibrate and decode them locally?
• Can we detect mismatch/failure conditions?
• Can we produce useful confidence/margin diagnostics?
• Can we build a software workbench that maps cleanly to future emitter/detector hardware?

Basically, if we can get selected-state optical readout and verification working on a cheap monitor and webcam, then I believe those same primitives should be much cleaner and more reliable on purpose-built hardware with dedicated emitters, detectors, controlled optical paths, reference channels, and proper thresholding.

Obviously, practical AI inference hardware is still a much bigger step, but this seemed like the right place to start.

That makes sense as a starting point.

Using a monitor/webcam loop to validate the measurement and control primitives first is a reasonable engineering approach.

Why this approach is defensible

• It is accessible and low-cost, so you can iterate quickly.
• It lets you test the full chain: encoding, capture, calibration, decoding, verification, and diagnostics.
• It forces you to deal with real-world noise early instead of only relying on simulation.
• It gives you a way to identify which parts are fundamentally promising and which parts are artifacts of the setup.

Where I would be careful

The key point is that “works in a monitor/webcam loop” does not automatically mean “maps cleanly to dedicated optical hardware.”

Some primitives probably will transfer well, especially:

• state encoding logic
• threshold verification
• redundancy strategies
• confidence scoring
• failure detection

But some behaviors may be very specific to the prototype environment:

• display gamma and subpixel behavior
• camera auto-exposure and sensor processing
• timing jitter in browser/video pipelines
• ambient light sensitivity
• geometric alignment and lens distortion

So I think the strongest version of your claim is not “these same primitives should be much cleaner on dedicated hardware,” but rather “this setup is a practical way to evaluate which primitives are robust enough to justify dedicated hardware.”

What would make the argument stronger

• Separate the primitives into two groups:
  • platform-independent ideas, such as encoding, verification, and error detection
  • platform-dependent artifacts, such as monitor output characteristics and webcam processing
• Show repeatability across multiple cameras, displays, and lighting conditions.
• Document which parts of the pipeline are deterministic and which are sensitive to calibration drift.
• Define success metrics in advance, such as decode accuracy, confidence margin stability, and failure detection rate.
• If possible, add a small hardware progression path:
  • monitor/webcam
  • controlled LED emitter + photodiode receiver
  • multi-channel dedicated optical path
  That would make the roadmap much more concrete.

Practical takeaway

As a research workbench, this is a sensible place to start. The cautious framing is that you are validating optical state readout and verification concepts, not yet proving a viable optical inference accelerator. That distinction keeps the project credible and makes the next milestones easier to evaluate.

 

[simmerskool]

I very vaguely recall a youtube (iirc) about optical cpu being developed in Germany, like coming soon, not for home users but working in research lab development, but I might be 100% wrong about this "recollection" (I have a camera around here somewhere... and I'll read your webpage this weekend (fwiw))

 

[danb]

I very vaguely recall a youtube (iirc) about optical cpu being developed in Germany, like coming soon, not for home users but working in research lab development, but I might be 100% wrong about this "recollection" (I have a camera around here somewhere... and I'll read your webpage this weekend (fwiw))

Yes, Q.ANT is who you are thinking of. From the video... "The NPU-2 is a 19 inch rack mount server running Linux." So it is not a photonic chip, like everyone would imagine. It is a rack mounted server box full of hardware, which in my opinion, is much more reasonable than trying to build a photonic chip, which is I believe how Q.ANT started out. So what Q.ANT is doing is super cool, pun intended .



So yes, I am trying to do something kind of similar to this, but maybe a little closer to what the Microsoft AOC project is doing. The goal is to have a very small "box", say (6" x 6" x 1/2"), that can fit on anyone's desk (or inside a computer), powered by USB, can run local LLM's for free, and be seriously cheap, like $100-$200 or so. There could be larger datacenter versions, but I want to start with the smaller version, for a lot of reasons. BTW, it is not just people with computers that need local LLM inference. Think cars, robots, airplanes... the list is infinite.