1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
//! The Model Runtime boundary: [`Model`] and [`Backend`].
//!
//! Everything above this line ([`crate::generate`], and eventually
//! `kopitiam-ai`'s real `ModelAdapter` — see this crate's parent epic) is
//! written against these two traits, not against [`crate::model::QwenModel`]
//! directly, the same way `kopitiam-workflow` is written against
//! `kopitiam_ai::ModelAdapter` rather than any one concrete adapter. That
//! mirroring is deliberate: it is the same "own the boundary, not the
//! implementation" shape CLAUDE.md's Architecture section asks every layer
//! of this platform to follow.
use ;
use Tensor;
use crateKvCache;
/// A causal (decoder-only) language model that can run a forward pass and
/// produce next-token logits.
///
/// # Why this trait exists with exactly one implementation
///
/// [`crate::model::QwenModel`] is the only [`Model`] today. That is not
/// reason enough on its own to add a trait — CLAUDE.md is explicit that
/// unused abstraction is a cost, not a virtue — but this one earns its
/// keep on two counts: [`crate::generate`] is written against `Model`, not
/// `QwenModel`, so it does not have to change when a second architecture
/// (a non-GQA LLaMA checkpoint, say, or a future non-transformer
/// architecture) arrives; and it marks precisely the seam a second
/// architecture would implement against, the same role
/// [`kopitiam_core::Device`]'s single `Cpu` variant plays for backends (see
/// that type's docs, which this trait's shape deliberately echoes).
/// The execution backend a [`Model`] runs its tensor ops on.
///
/// # Why this trait exists with exactly one implementation
///
/// Today every [`Model`] impl computes directly against
/// `kopitiam_tensor::Tensor`'s plain-CPU `f32` kernels — there is no
/// dispatch through this trait yet, and adding one purely to satisfy this
/// task brief's ask for a `Backend` seam, without a second backend that
/// would use it, is exactly the unnecessary abstraction CLAUDE.md warns
/// against. So this trait is deliberately minimal: it names the seam (what
/// a caller would ask a backend for — its [`Device`]) without inventing a
/// dispatch mechanism no code calls yet. A real second backend (a
/// SIMD-tuned kernel set, a threaded scheduler — see the parent epic's
/// Phase 2/3) is expected to grow this trait's surface *and* wire `Model`
/// impls to route their tensor ops through it; until then, [`CpuBackend`]
/// exists so [`crate::model::QwenModel`] has something concrete to report
/// through [`Model`]'s eventual `device()` accessor rather than hardcoding
/// [`Device::Cpu`] as a bare literal at every call site.
/// The only [`Backend`] the Kopitiam Runtime implements: plain CPU
/// execution via `kopitiam-tensor`'s `f32` kernels. See [`Backend`]'s docs
/// for why this is a real (if minimal) type rather than a bare `Device`
/// literal.
;