Program-as-Weights: A Programming Paradigm for Fuzzy Functions Review

2026-09-21 9 분 소요

0. Introduction

한 줄 요약: Program-as-Weights, PAW는 자연어로 정의한 fuzzy function을 매번 large model API로 실행하는 대신, 4B compiler가 frozen small interpreter용 LoRA weight를 한 번 생성하고 이후 local inference에서 재사용하게 한다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

LLM을 매 input마다 호출하는 solver가 아니라 reusable function artifact를 만드는 compiler로 재정의한다.
Natural-language specification을 prompt text가 아니라 continuous parameter program으로 바꾼다.
Frozen 0.6B interpreter와 shared LoRA basis를 사용해 on-device execution을 목표로 한다.
FuzzyBench 10M examples로 specification-conditioned function programming을 별도 benchmark로 만든다.
Accuracy뿐 아니라 adapter size, quantization, cold start, MacBook throughput을 함께 평가한다.

일상적인 software에는 rule로 쓰기 어렵지만 반복적으로 필요한 function이 많다. 예를 들면 중요한 log line만 고르기, malformed JSON을 복원하기, user intent에 따라 search result를 정렬하기, text label을 custom taxonomy로 mapping하기가 있다.

현재는 이런 function을 구현하기 위해 large language model API를 매 input마다 호출하는 경우가 많다. 이 방식은 flexible하지만 latency, cost, privacy, reproducibility, provider dependency가 생긴다.

PAW가 제안하는 방향은 compiler와 interpreter를 분리하는 것이다.

Function definition 시점: 큰 compiler를 한 번 호출한다.
Function application 시점: 작은 local interpreter를 반복 실행한다.

이때 compiled program은 discrete instruction text만이 아니라 parameter-efficient weight다.

1. Problem Setting

1-1. Problem definition

Rule-based function은 input과 output relation을 명시적으로 쓸 수 있을 때 강하다. 반면 fuzzy function은 자연어 의미, context, preference, ambiguity를 다루기 때문에 exact rule로 구현하기 어렵다.

Specification을 $s$, input을 $x$, desired output을 $y$라고 하면 fuzzy-function programming의 목표는 다음과 같다.

\[p = \mathrm{Compiler}(s), \qquad \hat{y} = \mathrm{Interpreter}(p,x)\]

여기서 $p$는 reusable program이다. PAW에서는 $p$가 다음 두 부분을 가진 hybrid artifact다.

\[p = (p_{discrete}, p_{continuous})\]

$p_{discrete}$: cleaned specification and examples
$p_{continuous}$: interpreter에 적용할 adapter weights

Compiler는 function definition마다 한 번 실행되고, interpreter는 input마다 실행된다. 같은 function을 많이 호출할수록 compile cost가 amortize된다.

1-2. Why previous approaches are insufficient

1) Direct prompting은 호출마다 큰 model이 필요하다

Prompt를 잘 만들어도 매 input마다 large model forward가 필요하다. Function call 수가 많으면 cost와 latency가 선형으로 누적된다.

2) Few-shot prompt는 context budget을 사용한다

Specification, examples, formatting rule을 매번 input 앞에 붙이면 interpreter가 실제 input을 처리할 context가 줄어든다. Long instruction과 multimodal input에서는 이 문제가 더 커진다.

3) Per-function fine-tuning은 너무 무겁다

각 fuzzy function마다 full fine-tuning이나 별도 LoRA를 학습하면 data collection, optimization, checkpoint management가 필요하다. User가 자연어로 새 function을 정의할 때 즉시 compile하기 어렵다.

4) Generated code는 fuzzy semantics를 완전히 담기 어렵다

LLM이 Python rule을 생성하는 방식은 deterministic logic에는 좋지만, semantic judgment를 rule set으로 축약하기 어려운 task에는 한계가 있다.

5) Prompt cache는 behavior를 artifact로 고정하지 못한다

KV cache나 prompt prefix caching은 execution cost를 줄일 수 있지만, model과 serving stack에 강하게 묶인다. PAW는 parameter artifact를 저장하고 small interpreter에서 실행하는 것을 목표로 한다.

2. Core Idea

2-1. Main contribution

PAW system은 세 model component로 구성된다.

Pseudo-program generator
- Untrained Qwen3-4B-Instruct-2507이 raw specification을 정리하고 examples를 만든다.
LoRA compiler
- 별도의 trained Qwen3-4B compiler가 specification과 pseudo-program을 읽는다.
- 마지막 64개 learned token의 hidden state를 program representation으로 사용한다.
Frozen interpreter
- Qwen3-0.6B가 input을 처리한다.
- Compiler가 만든 mixing coefficient로 shared LoRA basis를 결합해 function-specific adapter를 적용한다.

Compiler가 모든 LoRA matrix element를 직접 출력하면 output dimension이 너무 크다. PAW는 미리 학습된 basis adapter를 공유하고, specification마다 basis mixing coefficient만 생성한다.

2-2. Design intuition

PAW의 핵심은 natural-language specification을 low-dimensional weight coordinate로 바꾸는 것이다.

각 target module $m$에 $N$개의 shared LoRA basis가 있다고 하자.

\[\Delta W_m(s) = \sum_{n=1}^{N}\alpha_{m,n}(s) B_{m,n}A_{m,n}\]

$A_{m,n}, B_{m,n}$: shared LoRA basis parameter
$\alpha_{m,n}(s)$: compiler가 specification $s$에서 만든 mixing coefficient
$\Delta W_m(s)$: function-specific adapter update

논문의 main setting은 rank $r=64$, basis count $N=64$다. Target module은 attention의 q_proj, k_proj, v_proj, o_proj와 MLP의 gate_proj, up_proj, down_proj다.

이 구조는 two-level learning으로 볼 수 있다.

Dataset-level training은 reusable basis와 compiler를 학습한다.
New function compile은 basis coordinate를 선택한다.

즉 새 function마다 optimizer를 다시 돌리지 않고, compiler forward 한 번으로 weight program을 만든다.

3. Architecture / Method

3-1. Overview

Component	Model	Role
Pseudo compiler	Qwen3-4B-Instruct-2507	Specification cleaning and example generation
LoRA compiler	Trained Qwen3-4B	Program token representation 생성
Mapper	Small neural mapper	Layer/module별 basis mixing coefficient 생성
Interpreter	Frozen Qwen3-0.6B	Input별 function execution
Continuous program	Shared LoRA basis mixture	Function-specific behavior 저장
Discrete program	Pseudo specification	Explicit instruction context 유지

3-2. Module breakdown

1) Pseudo-program generation

Raw specification은 짧거나 ambiguous할 수 있다. Pseudo compiler는 이를 cleaner instruction과 examples로 확장한다.

Pseudo-program은 두 역할을 한다.

Compiler에게 더 structured specification을 제공한다.
Interpreter에도 discrete context로 남아 weight program이 놓친 detail을 보완한다.

이 model은 PAW training으로 update되지 않는다. Pre-generated pseudo-program을 사용해 main compiler training cost를 분리한다.

2) Program tokens

LoRA compiler input은 raw specification, pseudo-program, EOS, 64 learned program token으로 구성된다. 마지막 program token의 hidden state는 function representation이 된다.

단일 pooled vector만 사용하는 대신 여러 token을 두어 layer and module별 information을 나눠 담을 수 있게 한다.

3) Layer alignment

Compiler hidden state와 interpreter layer를 대응시킨다. Mapper는 compiler representation을 interpreter의 각 target module에 필요한 coefficient로 바꾼다.

논문은 여러 mapper design을 비교하지만, 더 expressive한 design이 항상 좋은 것은 아니었다. Simple mapping이 strongest setting으로 보고된다. Compiler representation 자체가 충분히 rich하면 복잡한 mapper가 optimization을 어렵게 만들 수 있다.

4) Shared LoRA basis

Interpreter weight는 frozen이고, 각 module에는 64개의 rank-64 LoRA basis가 있다. New function은 basis를 새로 학습하지 않고 coefficient를 바꾼다.

이 방식의 storage는 function마다 full 0.6B checkpoint를 저장하는 것보다 작다. 다만 function별 adapter artifact가 완전히 무료는 아니며, basis와 coefficient format이 interpreter architecture에 묶인다.

5) Differentiable compilation

Training loss는 frozen interpreter의 next-token likelihood다.

\[L = -\sum_t \log P_{\theta_I,\Delta W(s)}(y_t \mid x,y_{<t},p_{discrete})\]

Interpreter base weight $\theta_I$는 frozen이지만, gradient는 interpreter computation을 통과해 adapter basis, mapper, compiler로 흐른다. 따라서 compiler는 specification을 읽고 downstream output loss를 줄이는 weight를 생성하도록 학습된다.

6) Hot-swappable execution

Runtime에서는 function별 adapter를 load하고 same interpreter process에서 교체한다. 여러 fuzzy function을 pipeline으로 이어도 base model은 하나만 resident하면 된다.

논문은 log monitoring, website navigation, reranking, tool pipeline, game logic 같은 case study를 제시한다.

7) Multimodal extension

Compiler를 Qwen3-VL-4B로 바꾸면 image specification에서 text interpreter program을 만들 수 있다. Diagram classification에서는 가능성을 보이지만, long-form Im2LaTeX에서는 LoRA program이 prompt prefix보다 크게 뒤처진다.

이 결과는 weight program이 모든 specification information을 압축하기에는 아직 제한적임을 보여준다.

4. Training / Data / Recipe

4-1. Data

논문은 FuzzyBench를 새로 구축한다.

전체 규모: 10M개의 (specification, input, output) triple
생성 model: gpt-5.2
Split: specification 기준 80/10/10
Benchmark variant: 29개
Category: 800개 이상
최상위 group: 7개

Split을 example이 아니라 specification 기준으로 나눈다는 점이 중요하다. Test function은 training specification과 달라야 compiler의 new-function generalization을 평가할 수 있다.

Verified test set은 gpt-5-mini와 gpt-5.2가 agreement하는 example을 사용한다. Reference label noise를 줄이기 위한 장치지만, 두 OpenAI model이 공유하는 bias는 남을 수 있다.

Noise benchmark는 typo, abbreviation, incomplete instruction, conflicting example 같은 specification corruption을 포함한다.

4-2. Training strategy

Main training configuration은 다음과 같다.

Hyperparameter	Value
LoRA compiler	Qwen3-4B
Interpreter	Qwen3-0.6B frozen
Compiler learning rate	$2\times10^{-5}$
Precision	bf16
Mapper precision	fp32
LoRA rank	64
Basis count per module	64
Epochs	3
Batch size	16
Gradient accumulation	3
Effective batch size	48
Compiler sequence length	1,280
Interpreter sequence length	1,024
Optimizer	AdamW
Schedule	No warmup, no scheduler

0.6B interpreter run은 3 epoch에 약 72 hours가 걸렸다고 보고한다. Hardware environment는 project phase에 따라 single B300 또는 8 H200을 사용한 것으로 기술된다.

4-3. Engineering notes

1) Compiler and interpreter version을 함께 pin해야 한다

PAW program은 특정 interpreter layer와 module name에 맞춰진다. Interpreter checkpoint를 교체하면 compiler와 basis를 다시 학습해야 한다.

2) Function artifact에 provenance를 넣어야 한다

Compiled specification, compiler version, interpreter version, basis checksum, quantization setting, expected output schema를 함께 저장해야 재현 가능하다.

3) Compile cost와 call count를 함께 봐야 한다

한 번만 호출할 function이라면 direct prompting이 더 간단할 수 있다. PAW는 same function을 반복 호출할 때 가치가 커진다. Break-even call count를 latency와 cost로 계산해야 한다.

4) Adapter swapping overhead를 측정해야 한다

Hot swapping이 가능해도 function 수가 많으면 adapter load, cache invalidation, batching fragmentation이 생긴다. Multi-tenant serving에서는 function popularity를 고려한 cache가 필요하다.

5) Discrete and continuous program을 ablate해야 한다

Pseudo prompt와 weight program이 각각 얼마나 기여하는지 분리해야 한다. Heavy typo setting에서 pseudo-program이 더 중요할 수 있다.

6) Safety boundary를 명시해야 한다

Weight artifact는 text prompt보다 inspect하기 어렵다. Unknown specification, adversarial compiler input, prohibited function에 대한 compile-time validation이 필요하다.

5. Evaluation

5-1. Main results

FuzzyBench exact accuracy의 대표 결과는 다음과 같다.

Method	Execution model	Exact accuracy
PAW	Qwen3-0.6B interpreter	73.78
Direct prompting	Qwen3-32B	68.70
PAW with 0.8B interpreter	0.8B	67.29
PAW with GPT-2 interpreter	GPT-2 scale	54.39

PAW 0.6B가 이 table의 Qwen3-32B direct prompting보다 높지만, 모든 larger model보다 높은 것은 아니다. 예를 들어 gpt-oss-20B와 stronger API model은 PAW보다 높은 결과를 보인다.

같은 0.6B base에서 program mechanism을 비교하면 다음과 같다.

Adaptation	Exact accuracy
Fixed LoRA rank 64	52.10
Same 0.6B base full fine-tuning	58.40
PAW	73.78

이 결과는 단순히 interpreter에 LoRA capacity를 추가하는 것보다 specification-conditioned basis mixture가 중요하다는 것을 보여준다.

Quantization and local execution

Representative quantization 결과는 다음과 같다.

Format	Base size	Adapter size	Accuracy
PyTorch bf16	1,515 MB	-	65.80
Q6_K + Q4_0 adapter	623 MB	23 MB	65.75
Q4_K_M + Q4_0 adapter	484 MB	23 MB	64.53

Q6_K에서는 bf16과 거의 같은 accuracy를 유지한다. MacBook M3의 Q5_K_M setting에서는 약 31.6 tokens/sec와 0.48 sec cold latency를 보고한다.

5-2. What really matters in the experiments

1) Comparison unit은 model size가 아니라 function lifecycle이다

PAW는 compiler 4B를 사용하므로 단순히 “0.6B가 32B를 이겼다”고 말하면 불완전하다. 정확한 comparison은 다음이다.

Direct prompting: Large model을 every call에 사용
PAW: 4B compiler를 function definition마다 한 번 사용하고 0.6B를 every call에 사용

Function reuse count가 충분할 때 memory and latency advantage가 나타난다.

2) Shared basis가 meta-learning 역할을 한다

PAW는 FuzzyBench 전체에서 반복되는 semantic transformation pattern을 basis에 저장한다. New specification은 basis combination을 선택한다. 따라서 benchmark 다양성과 specification split이 핵심이다.

3) More expressive mapper가 항상 낫지 않다

Mapper capacity를 늘린 variant가 simple design보다 낮았다. Bottleneck은 coefficient generator의 표현력보다 compiler-interpreter alignment와 optimization stability일 수 있다.

4) Noise robustness는 discrete program과 함께 봐야 한다

Combined heavy noise에서도 accuracy degradation이 제한적이라고 보고한다. 하지만 clean and noisy table은 checkpoint나 subset이 다른 경우가 있어 숫자를 직접 섞어 비교하면 안 된다. Robustness claim은 동일 table 안의 paired result로 보는 것이 안전하다.

5) Multimodal long-form task는 아직 어렵다

Im2LaTeX에서 LoRA program accuracy가 0.181이고 prompt prefix가 0.391로 더 높다. Long detailed specification을 64-token compiler representation과 adapter weight로 압축하는 데 정보 bottleneck이 있음을 보여준다.

6. Limitations

Compiler와 interpreter가 강하게 결합된다.
- Interpreter architecture나 layer layout을 바꾸면 compiler와 basis를 다시 학습해야 한다.
- Universal executable artifact는 아니다.
Continuous program은 inspect하기 어렵다.
- Text prompt처럼 rule을 직접 읽거나 diff하기 어렵다.
- Debugging, compliance, safety audit를 위한 interpretability tool이 필요하다.
Single-step function 중심 평가다.
- Stateful multi-turn interaction, long-horizon tool use, exception recovery는 충분히 검증되지 않았다.
FuzzyBench가 synthetic data 중심이다.
- 10M examples가 gpt-5.2로 생성되었다.
- Real user specification과 production error distribution에서 같은 performance가 유지되는지 불분명하다.
Verified test도 model agreement에 의존한다.
- gpt-5-mini와 gpt-5.2가 같은 오류를 공유할 수 있다.
- Human-authored external benchmark가 필요하다.
Best PEFT form은 task-dependent할 수 있다.
- Shared LoRA basis가 classification and transformation에는 잘 맞아도 long-form generation에는 정보 capacity가 부족할 수 있다.
Compiler cost가 사라지는 것은 아니다.
- Function이 자주 바뀌거나 한 번만 실행되면 amortization advantage가 작다.
Security surface가 새로 생긴다.
- Malicious specification이 harmful adapter를 만들 수 있다.
- Artifact signing, sandbox, output validation이 필요하다.

7. My Take

7-1. Why this matters for my work

PAW는 PEFT method라기보다 deployment abstraction에 가깝다. Prompt를 매 요청마다 보내는 대신, 자주 반복되는 semantic function을 weight artifact로 compile한다는 관점은 small model service의 비용 구조를 바꿀 수 있다.

Document AI에서는 document type별 validator, field normalizer, evidence reranker, output formatter처럼 작지만 반복 호출되는 fuzzy function이 많다. 이런 task가 stable specification을 가진다면 PAW-style compile-once execution을 실험할 가치가 있다.

7-2. Reuse potential

1) Schema-specific extraction helper

새 schema description을 compact adapter로 compile하고, shared small interpreter가 document row를 반복 처리하게 할 수 있다.

2) Reranking function library

User intent나 domain policy별 reranker를 adapter artifact로 저장하고 query routing에 따라 swap할 수 있다.

3) Local compliance classifier

Sensitive data가 외부 API로 나가지 않도록 function을 local interpreter에 compile할 수 있다.

4) Hybrid verifier

PAW output을 deterministic rule과 larger fallback model로 검증하는 cascade가 현실적이다. Confidence가 낮거나 specification이 novel할 때만 expensive model을 호출한다.

5) Artifact registry

Function specification, adapter checksum, benchmark score, allowed input schema, expiration date를 관리하는 neural function registry를 만들 수 있다.

7-3. Follow-up papers

HyperNetworks
LoRA: Low-Rank Adaptation of Large Language Models
LoraHub
HyperLoRA
Prompt Tuning
Code2LoRA
Model Editing at Scale

8. Summary

PAW는 natural-language fuzzy function을 discrete prompt와 continuous LoRA program으로 compile한다.
4B compiler가 shared basis mixing coefficient를 만들고, frozen 0.6B interpreter가 반복 실행한다.
FuzzyBench 10M examples에서 new specification generalization을 평가한다.
PAW 0.6B는 reported table에서 Qwen3-32B direct prompting보다 높지만 stronger large model 전체를 능가하는 것은 아니다.
실용성은 function reuse count, artifact audit, interpreter coupling, real-world benchmark에 달려 있다.

Twitter Facebook LinkedIn