nodja

If you want really accurate timestamps, the current state of the art is to ask claude to implement forced alignment using a CTC transcription model. It uses the logprobs of a character based transcription model to find the best matching overlap. I've used this technique to generate sync files for epub/audiobooks and it's really good even when the data is dirty.

This method aligns the transcript of a 60 hour book in 20 minutes on my GPU using Parakeet CTC 0.6B which is english only, but there's similarly sized models in other languages, the models don't need to be that good at transcribing to generate good alignments.

Yes, even the comment you replied to is very noticeably claude authored.

These models are, in a sense, distillations of language models. They wouldn't be as good without a pre-trained language model, so it's unfair to compare them.

Image models are essentially a mapping of text embedding space -> image. So the clearer and cleaner the text embedding space is the better model you get as you need less weights trying to interpret a text prompt, recent image models even use multimodal versions of LLMs (Flux uses Qwen3 VL) so all the visual separation was done beforehand making the model even more efficient.

edit: Maybe a better analogy is that the image models are only half the model in a encoder-decoder sense, where the LLM is a pretrained frozen encoder and the image model is the decoder.

I don't know what you would call it, but reasoning/thinking/whatever it is, is a way for LLMs to tighten their sampling space, while allowing for wide sampling to still happen. This is akin to people brainstorming ideas.

I know that sounds confusing, let me break down how I think about this.

1. LLMs don't pick the token that ends up being used. This is by design, if the LLM gives a wide choice, it can better adapt to real world scenarios. i.e. generalize.

2. Without reasoning, this means that the LLM either locks in on whatever the sampler picked. Or decides mid-sentence/response to correct itself. This is what used to happen before reasoning, still happens if you turn reasoning off.

3. With reasoning, the LLM can make as many mistakes as it wants and explore its sampling space. Then use its vast pattern matching capabilities to decide which parts of the reasoning make sense and which were idiot ideas.

4. Enabling reasoning makes it so LLMs are much more confident on the final response, and the logits should theoretically all be near 99% on a single token for every token, i.e. much closer to greedy decoding. It analyzed all the possible options and figured out the best outcome, so a stray sample doesn't cause the answer to go awry.

This is why reasoning traces are filled with "but wait". I don't know if those were added in organically or artificially in the RL training, but regardless they're a good way to let the LLM keep generating other options and explore it's sampling space to the fullest.

Note: I haven't tested any of this and it's just my theory, but I'm sure if you really wanna know you can have claude run some smoke tests :)

PS5 emulation on x86 hardware will be more like running wine, so as long as your PC is as powerful as a PS5, performance should be close...eventually. The real performance bottleneck will be the GPU translation layer, much like converting DirectX to Vulkan isn't trivial, so isn't converting GNM (PS5's graphics API) to Vulkan, even tho the APIs are close (IIRC, they're cousin APIs)

They exist to detect degradation. Datasets are not perfect and if a batch contains too much bad data it can ruin a run, also an opportunity to find bad data and improve the dataset filtering.

Same reason they go into low margin with the PS4/PS5 and other projects. Market penetration.

Youtube allows you to AB test with up to 3 titles and thumbnails.

The whole site looks like and reads like AI slop. The outcomes also don't make any sense and don't feel rigorously tested (no, having claude test for you doesn't count as rigorous).

I'm the same way, I have a very low/sporadic usage of any subscription I've tried. I now just use openrouter with DS4 pro/flash. It also gets rid of usage anxiety where I would try to justify the $20/month by forcing myself to use the tokens for projects as the weekly limit deadline neared.

The way I think about it is that it's unreasonable for a compute graph with a static number of operations to be able to answer both y=a*10 and something like y=((((x+x)*(x+1))/((2*x)+2))+((x*(x+3))/(x+3))-((x*x)/(x+1))+((x*x)/(x+1))-((x*(x+3))/(x+3))) in a single forward pass. Tokens are essentially a unit of work and can also be used for intermediate steps, not just final results.

I'm not a heavy user of agentic coding, but still use them quite a bit for some automation here and there. I've been going around shopping all the ~$10 subscriptions and I finally settled on openrouter + ds4 pro. The more intensive days cost me $1 and I set a $2 weekly limit which I've never hit the past 3 weeks, to me it's way cheaper than most subscriptions and I don't have to worry about maximizing my weekly quota/resets.

Yes, the whole list will always sum to 1 (100%) because there's lots of more sampling parameters. top_p, top_k and temperature are just the ones that affect output the most. Most parameters do math around assuming the list sums to 1 and order is not always the same, some software even lets you change the order around.

top_a is not very common and is better explained if I explain how the much more common min_p works. min_p filters out tokens below a certain threshold. The formula is <filter threshold> = <min_p> * <top token probability>. So if the top token has 0.5 probability, min_p = 0.1 would cut out tokens below 0.05. This is a tunable that lets you filter out other tokens depending on how confident the model is.

top_a is almost the same formula but you just square the <top token probability>. So <filter threshold> = <top_a> * <top token probability> ^ 2. This makes the filtering ramp up faster (cut out more tokens) if the model has a much more confident top choice, but keep more choices if the model is not so confident.

The posted answers are either behind a paywall or very obtuse so I'll just explain. I'll assume you know what tokens are.

A models output is not a single token, but a list with the probability for all the tokens that it knows, so we need to use a sampler to select the token that it's going to be the next token in the sentence. For example a simple greedy sampler will choose the token with the highest probability, but samplers normally pick a random token weighted by probability. A model usually knows about ~250 thousand tokens and the probability of some of these tokens are gonna be high, but the vast majority is close to but not actually 0% so there's a chance the sampler might pick some random token that doesn't make much sense, so we filter tokens.

top_k filters the tokens so that only the k top tokens are selected. So top_k=50 will filter those 250k tokens to only 50. This is assuming the list of tokens is sorted by probability.

top_p filters the top tokens until a percentage is accumulated. So if for example if you set the top_p to 0.6 and the model gave the top token a 0.5 (50%) probability and the second top token a 0.2, those 2 token accumulated to 0.7 which is greater than what you set it to (0.6) so no more tokens are selected. If this ran after top_k=50 it'll turn the list of 50 tokens into one of 2.

After each filter parameter is processed, the probability of the tokens is adjusted to sum to 1 (100%), Also note that order of operation here matters, i.e. top_p could be applied before top_k, but most providers follow what's on huggingface, I think I've only seen different implementation in certain local model hosting frameworks.