HN user

edflsafoiewq

4,891 karma
Posts2
Comments1,711
View on HN

PrismML released a ternary model recently. However AFAICT they don't use this packing, instead packing trits as 2 bits each (as least for the GGUF).

Hy-MT2 also came out with a 1.25bit model using a technique called Sherry, where weights are trits with the additional constraint that exactly one trit in a group of four is 0. Four possible positions for the 0 times 2^3 possibility for the other three positions = 32 possibilities, so it fits in 5 bits exactly. You can also exploit the sign symmetry by factoring out a sign bit and you have sixteen possibilities for a group where the first non-zero trit is +1. Unpacking can then be done with a 16 bytes lookup table, which is small enough to do really fast with SIMD.

I actually don't think LLMs are "really" intelligent either, but we do seem to be pawing our way towards something. Everyone is talking about safety and risk and alignment. But I never read anything about what kind of moral obligations we might have towards our hypothetical AI children.

People swear up and down these things are real intelligences and not stochastic parrots until the ethical questions come out and then they're just fancy washing machines.

It appears they are using Q2_0 in llama.cpp, which is 2 bits per weight + 1 float16 scale per group of 64 weights. This is inefficient in two ways: one bit pattern is wasted on each weight, since ternary weights only use {-1,0,1} and Q2_0 allows {-1,0,1,2}; and their group size is 128 weights, so the scale will be stored twice in two groups of 64 instead of stored only once in one group of 128.

Their fork corrects the second inefficiency by using a group size of 128, but still uses 2-bit weights AFAICT.

It's possible to pack 5 trits into a byte, but the unpacking is not very efficient. Another recent idea is to add the constraint that exactly one weight in each group of four be zero, which gives exactly 32 possible states, so it fits in 5 bits.

I find it kind of interesting the whole output wasn't released. A common criticism of mathematical writing is results are "pulled out of a hat"; you only write up a polished, final proof, but hide everything that went into developing it. It's kind of ironic the practice is even carried on when an LLM writes the proof.

In data structure terms, attributes do allow nodes to be decorated with additional information without forcing any change on existing parsers. In JSON, this would require swapping, eg. "str" -> {"value": "str", "attrib1": "..."}.

What makes you think this is going to stave off that world? More likely you'll get both, since I doubt this API is going to satisfy other states' age verification requirements.

You also need the group structure, ie. a(bG) = b(aG) = (ab)G.

But AFAICT, elliptic curve groups really are the best known groups where DH is hard. The "Why curves win" section talks about it terms of key size, but the reason other groups require larger keys is they have some kind of structure which can be exploited to attack the "hard" direction (eg. in a finite field, the ability to factor over primes can be used to solve discrete logs), so the group size has to go up to compensate.

O(1) just means "a bounded function (on a neighborhood of infinity)". Unlike f(x), which refers to some function by name, O(1) refers to some function by a property it has. It's the same principle at work in "even + odd = odd".

Programmers wringing their hands over the meaning of f(x)=O(g(x)) never seem to have manipulated any expression more complex than f(x)=O(g(x)).

My immediate thought was combining characters eg

  934 = CISTERCIAN STAFF + 
        COMBINING CISTERCIAN 900 +
        COMBINING CISTERCIAN 30 +
        COMBINING CISTERCIAN 4
Would require allocating (1 staff) + (9 digits) * (4 places) = 37 code points.

Were you thinking

  934 = CISTERCIAN 900 +
        ZWJ + 
        CISTERCIAN 30 +
        ZWJ +
        CISTERCIAN 4

?

Oh, ding ding! Opening in a hex editor, there's the string "Added imperceptible SynthID watermark" in an iTXt chunk. SynthID is apparently a watermark Google attaches to its AI-generated content. This is almost certainly the noise.

I believe the main interest in recompilation is in using the recompiled source code as a base for modifications.

Otherwise, yeah, a normal emulator JIT basically points a recompiler at each jump target encountered at runtime, which avoids the static analysis problem. AFAIK translating small basic blocks and not the largest reachable set is actually desirable since you want frequent "stopping points" to support pausing, evaluating interrupts, save states, that kind of stuff, which you'd normally lose with a static recompiler.