Vetch

Neural network weights are better viewed as source code because they specify what function the network computes. As we're operating purely on feed-forward networks, there are no loops. Therefore, weights fully describe everything relevant for executing their represented function on inputs. Weights can be seen as a sort of intermediate language (with lots of stored data and partially computed states) interpretable by some deep learning library.

The network architecture itself is not source code, but a rough specification constraining the optimizer, which searches for possible program descriptions that within the specified constraints, minimize some loss function with respect to the data.

Neither data nor network architecture are the actual source, they are better seen as recipes which if followed (will at great expense), allow finding behaviorally similar programs. As you can see, the standard ideas of open source don’t quite carry over because the actual "source-code" is not human interpretable.

The tokenizer differences are major as LLMs are sensitive to whitespace handling. If I am reading the github page properly, OpenLLama failed to learn how to model code properly? Code contains many implicit reasoning tasks.

What other differences are there? The page doesn't mention how numbers are handled. These are two major things that impact model reasoning and numeric ability.

> Meh it's poorly supported by both PyTorch and TF.

This does not match my experience. Most new model architectures port fine to ONNX from pytorch, only occasionally having to fill in rare functions.

> Not even by a long-shot - first party compilers are generally faster because of smoother interop but even amongst third-party you have TRT and TVM.

Again, in my experience, there is little by way of documentation for any of these platforms nor as broad support for as many OS and Hardware combinations.

> I have no idea what anyone uses ONNX for these days

Huggingface has strong support for ONNX and leverages it for improved performance in places.

https://huggingface.co/docs/optimum/onnxruntime/usage_guides...

https://huggingface.co/docs/optimum/onnxruntime/usage_guides...

It's curious how impressions can differ so.

Base model performance is what's most important and also impacts fine-tuning quality. Practically, a model that's good out of the box with minimal fine-tuning is also useful to more people. Since they focused on being training compute optimal for some budget, expect their models to lag behind Llama overall. Their 6.7B version should lag behind GPT-J, assuming 20 tokens per parameter.

The Pythia models are also worth checking out, they might be better than or matched to CerebrasGPTs at each size (although they warn it is not intended for deployment).

Conclusion: the landscape of top open models remains unchanged.

This is interesting. What sizes are you seeing this for?

It's not just that it's accessible, it's also significantly higher in quality than previous local runnable causal LMs.

I suspect people saying it's not good are prompting it like ChatGPT, not realizing how much trickier a raw model is to prompt. Getting the hyperparameters for good sampling is another stumbling block. The models are very good if you do everything properly.

There was only ever a 6B GPT-J, you must be thinking of GPT-neo's for smaller sizes. GPT-J was the best of its kind for a long while but even just the 7b version of LLaMa soundly surpasses it in how well it follows examples to solve problems and do useful work like summarization, keyword extraction and a mini search agent. Being able to run something on your laptop that matches the original davinci GPT3 and can be tuned to go beyond is nothing to sniff at.

The best models will be by API but there is a threshold of utility for LLMs, below which they're just bad story telling toys, that hasn't been available for home users until recently, with FlanT5s and LLaMas.

SantaCoder's impressive but that's probably misleading. It's reported that incoder doesn't generate as diverse a set of solutions but does do better at the ones it generates. This means it performs well at a lower number of tries when compared to other similar models, which is what matters in practice. The numbers reported here required many trials.

With a fuller context and just a handful of tries, it's unlikely that 6.7B version of incoder will be outperformed by SantaCoder.

Perhaps the Eureka effect (https://en.wikipedia.org/wiki/Eureka_effect)?

NB: huggingface has long had a rust based tokenizer.

Probably, they're still using relatively simple queries. Maybe the memory is larger, but with 4096 tokens, GPT-3 is no slouch either. RLHF has tuned it so the conversational output of GPT is more inline with human expectation, it's also less likely to make glaring errors. The cost of their approach is it sometimes get stuck rephrasing things and wraps everything in boilerplate that can derail subsequent generation.

Does it make sense to put this on the chrome store? OpenAI is eventually going to end the beta period or Azure will run out of GPUs, whichever is first, then it'll no longer be accessible.

In theory we can replicate this with GPT-3 but ChatGPT has better access to its knowledge, when it's not being a nagging busybody, which makes it much friendlier to interact with, when it's not being a nagging busybody.

For practical tasks, I would like to say FlanT5 11B which is 45GB but my experience is if you're using huggingface the usual way, it can initially take up to 2x the memory of the model to load.

GPT-JT was released recently and seems interesting but I haven't tried it. If you're focused on scientific domain and want to do Open book Q/A, summarization, keyword extraction etc. Galactica 6B parameter version might be worth checking out.

If our main language is not English one of the mt0 models might be worth a try https://huggingface.co/bigscience/mt0-xl

These models are distinguished by being able to follow relatively complex natural language instructions and examples without needing to be finetuned.

For inference, the best models are so large they won't fit in System RAM. GPT@home is not going to make a difference in that scenario.

For training such large models, data parallelism is no longer sufficient and tensor/pipeline parallelism is required. The problem is communication bottlenecks, differing device/network speeds and massive data transfer requirements become serious enough issues to kill any naive distributed training across the internet approach. Deep learning companies use fancy 100Gbps+ connections, do kernel hacking and use homogeneous hardware and it's still a serious challenge. There is no incentive for them to invest in something like GPT@home.

But it's not impossible and there's some research being done in the area. Although, it'll be a while until a GPT@home approach becomes a ready alternative. See https://arxiv.org/abs/2206.01288 and their recent GPT-JT test for more. Another development would be for networks to become more modular.

The reason is that Dall-E 2 type models are small and can run on a wide class of commodity hardware. This makes them very accessible which means a large number of people can contribute.

Large language models gain key capabilities as they increase in size: more reliable fact retrieval, multistep reasoning and synthesis, complex instruction following. The best publicly accessible is GPT-3 and at that scale you're looking at hundreds of gigabytes.

Models able to run on most people's machines fall flat when you try to do anything too complex with them. You can read any LLM paper and see how the models increase in performance with size.

The capabilities of available small models have increased by a lot recently as we've learned how to train LLMs but a larger model is always going to be a lot better, at least when it comes to transformers.

No, I meant finetuned. I also meant finetuned when I said trained. Experience with applying finetuned sentiment classifiers on real world data found gain vs cost of running to not be worth it. They remain nearly as brittle as cheaper classifiers and have a habit of gloming too much unto certain adjectives. They are also prone to overfitting on finetuned data's domain. Transformers trained not specifically on sentiment but on general domains like question answering or entailment are just leagues better for sentiment tasks.

> NN based sentiment analysis is certainly a lot better than non-NN based techniques.

I wouldn't say this. Sentiment analysis trained on the standard datasets is one place where performance is barely better than old-school linear classifiers. They remained brittle and easy to trick until recent flexible systems systems based on question answering, zero-shot entailment or lotsa instruction finetuning (improving in that order). I strongly advice against using something fine-tuned solely on sentiment datasets. It'd be a total waste.

> AGI does not mean “human level.”

The term general intelligence is ambiguous and will mean different things to different people. My understanding of the term AGI is it was coined to differentiate from narrow AI, which AI had diluted over time to mean.

AGI is AI broad and deep enough to be able to learn and perform any task a human can and is at least within the range of top human performers.

The wikipedia definition seems to agree:

> Artificial general intelligence (AGI) is the ability of an intelligent agent to understand or learn any intellectual task that a human being can

It is possible but not practical scaling-factor-wise when synchronization demands, communication bottlenecks on heterogeneous hardware and connection speeds are accounted for. The larger the transformer model, the less practical this quickly becomes.

A fair compromise is any marketplace for clusters with good interconnect but a lot cheaper than the cloud. Tuning distributed training and network transport layer for settings not as homogeneous as the cloud will also help on top of generally good interconnect. Security is a concern.

Building on points raised by pmoriarty, being able to scrape data makes up for lacking labeled data in the era of self-supervised training. IP-hawks are now putting a damper on that option, which is why I worry this might backfire from a freedom perspective.

What about future models with fewer artifacts that are much easier to communicate with and better at generation? Opportunity costs might favor just sending your data to and paying corps with compliance guarantees than spend time fiddling with 2022 era diffusion models. And don't forget this affects 3D, video snippets and music going forward.

> that many companies will, ironically, use "ethical" as a pretext to not be open.

Yes, weaponized ethics as sleight of hand for control is a common historical pattern.

That's fine until the next brand new model based on a better architecture where the above hacks won't suffice. My concerns here are long term, like 1 or 2 years out in AI-years.

What's the point of downloading it when it'd just stagnate? This isn't like regular software where people can easily put in hard work and sweat to improve it.

LLMs have the unfortunate limitation of being both powerful and lending themselves to centralized control choke-points due to how resource intensive they are to train. Under this paradigm, I fear commercial entities will be able to easily navigate the legal landmines and continually improve while open efforts perpetually lag far behind.

There are many vested interests who want this control for various reasons they justify as: protection from x-risk, keeping it out of the hands of abusers and bullies, economic advantage. Their reasons for want of control are either well intended but wrong-headed or profit-motivated and disingenuous.

Rather than challenging the likes of GPT-3 and Copilot enabling freedom, I fear folks will be forced to send all their videos, pictures, text and code to the servers of Microsoft, Amazon and Google or lose access to advantages as LLMs continue to improve at a rapid clip.

Code ingestion is not limited to github or copilot. Your best recourse is to make your code publicly inaccessible.

First, the music and to an extent movie industry enforcement of IP are uniquely pathological. But I am not talking about music or movies. I am contending that a simple search extension being much less capable than Copilot and so even more scopeable as aiding copyright violation would not be taken down.

> surely no one would have any problem with feeding it massive amounts of corporate programs?

There is a similar gymnastics done by human engineers today due to the issue of patents. I don't think this is a good trend to uphold.

> I am not aware what writers are doing but there have been plenty of uproar regarding stable diffusion

Yes but mostly in the art community. On HN there were plenty of arguments just the other day how it is not the same for art and programmers have a stronger case. I disagree but regardless, the case is exactly equivalent for GPT-3 and writers but it wasn't an issue generating about a thousand comments on respecting IP and ceasing deployment of LLMs until copilot.

Just about two-thirds of an octopus's neurons is found outside its central brain, distributed across its 8 arms. An octopus can be likened to a hive-mind of sorts.

Yes, I agree there's a measure of double standards to this. It's why I feel it's important that AI does not remain in the control of just a handful of corporations. The decks are stacked against though, given how data and compute intensive SOTA is.

But in defense of copilot, code regurgitation is uncommon in routine use. An editor extension allowing search of github would be at least as easy to use to violate licenses but I do not think it'd be taken down since that would not be its core offering.

Copilot goes far beyond mere search and provides a useful service. GPT-3 can also be prompted into generating copyrighted works of writers but I do not see people talking as if that is its primary utility nor as much clamoring in these forums to end that service.

The main reason AI will be reproducing copyrighted works while the original license is not trivial to identify will be that in those instances, humans are already violating copyright at a high rate. It's just flown under the radar thus far as required machinery to so easily surface violations was not available.

Copilot is capable of going beyond retrieval and is competent at using variables, comments, types and local context to infer intention and generate appropriate code and even comment on it. Whenever copilot correctly predicts code of yours that's a novel combination of concepts, copilot has originated novel code.

For esoteric concepts, you usually already have to know how to prime it but Copilot is especially useful when it helps you bump into things you didn't know you didn't know (one way to increase the odds of this happening is to write out your thinking so far in markdown or comments. You'd be surprised how helpful and clever Copilot can be in some instances). My point here is Github isn't charging $10/month for run of the mill retrieval. My opinion is code-gen LLMs contribute value and more open versions are worth building.

No, this is not meant as a defense. My point is that it's an issue that is already rampant and what Copilot (or any model) does is make it more readily visible.

This is not like youtube because Github is already hosting those violations and people are already inappropriately copying or including such code. It matters not whether the local inclusion was fetched by copilot or a human fetched it using more manual steps through search.

One thing I worry about is if the uncertainty around copyright violation cools down activity in open models while raising the price of commercial offerings. Commercial entities can afford devoting resources towards mitigating copyright violations such as eating the cost of maintaining a database of frequently copied code and identifying most likely origin combined with a large semantic database of code snippets.

An open equivalent might be wary of being accused of contributing to copyright violations since in that scenario, there is no way to force people to respect it.

> which is what copilot has been show to sometimes do

In those cases it seems that humans are already copying code without also propagating licenses appropriately. LLMs are more likely to memorize things which occur a lot (and I'd bet rare things that are representative of some conceptual axis).

The main examples presented so far, Davis and Carmack, have the property of having been copied a lot. The generative model is only surfacing an existing pattern of ignoring attribution. Sort of like the code-gen version of generating bigotry if appropriately prompted.

I'll also note that this pattern of retrievable memorizing of copyrighted and sensitive material is present in GPT-3 too and not just for code. As the situation is equivalent, a lawsuit should address the concerns of non-programmers too.